Relentless Simplicity :: The Bonanzle Tech Blog

I’m all about putting order to “best of” and “worst of” lists, so why not give some brief props to the tools, plugins, and utilities that make life on Rails a wonderous thing to behold?

5. Phusion Passenger.  OK, this would probably be first on the list, but it’s already been around so long that I think it’s officially time to start taking it for granted.  But before we completely take it for granted, would anyone care to take a moment to remember what life was like in a world of round-robin balanced Mongrels web servers?  You wouldn’t?  Yah, me neither.  But no matter how I try, I cannot expunge memories of repeatedly waking up to the site alarm at 7am to discover somebody had jammed up all the Mongrels with their stinking store update and now I’ve got to figure out some way to get them to stop.

4.  jQuery / jRails.  This probably deserves to score higher, as the difference between jQuery and Prototype is comparable to the difference between Rails and PHP.  But since it’s not really Rails-specific, I’m going to slot it at four and give major props to John Resig for being such an attentive and meticulous creator.  Without jQuery and jQuery UI, the entire web would be at least 1-2 years behind where it is in terms of interactivity, and I don’t think that’s hyperbole.  (It even takes the non-stop frown off my face when I’m writing Javascript.  With jQuery, it’s merely an intermittent frown mixed with ambivalence!)

3.  Sphinx / Thinking Sphinx.  There’s a reason that, within about six months time, Thinking Sphinx usurped the crown of “most used full text search” utility from “UltraSphinx.”  And the reason is that it takes something (full text search) that is extremely complicated, and it makes it stupidly easy.  And not just easy, but extremely flexible.  Bonanzle has bent Sphinx (0.9.8) into doing acrobatics that I would have never guessed would be possible, like updating it in nearly-real time as users log in and log out.  Not to mention the fact it can search full text data from 4 million records in scant milliseconds.

Sphinx itself is a great tool, too, though if I were going to be greedy I would wish that 0.9.9 didn’t reduce performance over 0.9.8 by around 50% in our testing, and I would wish that it got updated more often than once or twice per year.  But in the absence of credible competition, it’s a great search solution, and rock solidly stable.

2.  New Relic.  OK, I’ll admit that I’ve had my ups and downs with New Relic, and with the amount of time I’ve spent complaining to their team about the UI changes from v1 to v2, they probably have no idea that it still ranks second in my list, ahead of Sphinx, as most terrific Rails tools.  But it does, because, like all the members of this list, 1) the “next best” choice is so far back that it might as well not exist (parsing logs with pl-analyze?  Crude and barely useful.  Scout?  Nice creator, but the product is still a tot.  Fiveruns? Oh wait, Fiveruns doesn’t exist anymore.  Thank goodness) and 2) it is perhaps the most essential tool for running a production-quality Rails site.  Every time I visit an ASP site and get the infinite spinner of doom when I submit a form, I think to myself, “they must not know that every time I submit a form it takes 60 seconds to return.  That would suck.”  On a daily basis, I probably only use 10% of the functionality in New Relic, but without that 10%, the time I’d spend tracking logs and calculating metrics would make my life unfathomably less fun.

1.  Rubymine.  The team that created this product is insane.  Every time that I hit CTRL-O and I type in “or/n” and it pops up all files in the “offers_resolution” folder starting with the letter “n,” I know they are insane, because having that much attention to productivity is beyond what sane developers do.  Again, for context’s sake, one has to consider the “next best” choice, which, for Linux (or Windows) is arguably a plain text editor (unless you don’t mind waiting for Eclipse to load and crash a few times per day).  But, instead of programming like cavemen, we have a tool that provides killer function/file lookup; impeccable code highlighting and error detection (I had missed that, working in a non-compiled language); a working visual debugger; and, oh yeah, a better Git GUI than any of five standalone tools that were built specifically to be Git GUIs.

Perhaps as importantly as what Rubymine does is what it doesn’t do.  It barely ever slows down, it doesn’t make me manage/update my project (automatically detecting new files and automatically adding new files to Git when I create them from within Rubymine), and it handles tabs/spaces like a nimble sorcerer (something that proved to be exceedingly rare in my quest for a usable IDE).

Like New Relic, I probably end up using only a fraction of the features it has available, but I simply can’t think of anything short of writing my code for me that Rubymine could do that it doesn’t already handle like a champ.  Two thumbs up with a mutated third thumb up if I had one.

Conclusion

Yes, it is a list of apples and oranges, but the commonality is that all five-ish of the lists members stand apart from the “second best” solution in their domain by a factor of more than 2x.  All of them make me feel powerful when I use them.  And all of them, except arguably New Relic, are free or bargain priced.  Hooray for life after Microsoft.  Oh how doomed are we all.

Bill Productivity, Rails, Rants, Technology

Introduction

Based on the skimpy amount of Google results I get when I look for queries relating to Rails slave database (and/or the best rails slave database plugin), I surmise that not many Rails apps grow to the point of needing slave databases.  But we have.  So I’ve been evaluating the various choices intermittently over the last week, and have arrived at the following understanding of the current slave DB ecosystem:

Masochism

Credibility: Was the first viable Rails DB plugin, used to rule the roost for Google search results. The first result for “rails slave database” still points to a Masochism-based approach.

Pros: Once-high usage means that it is the best documented of the Rails slave plugins.  Seems pretty straightforward to initially setup.

Cons: The author himself has admitted (in comments) that the project has fallen into a bit of a state of disrepair, and apparently it doesn’t play nice with Rails 2.2 and higher.  The github lists multiple monkey patches necessary to get it working.  It only appears to work with one slave DB.

master_slave_adapter

Credibility: It’s currently the most watched slave plugin-related project I can find on github (with about 90 followers).  Also got mentioned in Ruby Inside a couple months ago.  Has been updated in last six months.

Pros: Doesn’t use as much monkey patching to reach its goals, therefore theoretically more stable than other solutions as time passes.

Cons: Appears to only handle a connection to one slave DB.  I’m not sure how many sites grow to the point of needing a slave DB, but then expect to stop growing such that they won’t need multiple slave DBs in the future?  Not us.  There’s also less support here than the other choices for limited use of the slave DB.  This one assumes that you’ll want to use the slave for all SELECTs in the entire app, unless you’ve specifically wrapped it in a block that tells it to use the master.

Db Charmer

Credibility:  Used in production by Scribd.com, which has about 4m uniques.  Development is ongoing.  Builds on acts_as_readonlyable, which has been around quite awhile.

Pros:  Seems to strike a nice balance between the multiple database capabilities of SDP and the lightweight implementation of MSA.  Allows one or more slaves to be declare in a given model, or for a model to use a different database entirely (aka db sharding).  Doesn’t require any proprietary database.yml changes.  Didn’t immediately break anything when I installed it.

Cons:  In first hour of usage, it doesn’t work.  It seems to route most of its functionality through a method called #switch_connection_to, and that method doesn’t do anything (including raise an error) when I try to call it.  It just uses our existing production database rather than a slave.  The documentation for this plugin is currently bordering on “non-existent,” although that is not surprising given that the plugin was only released a couple months ago.  Emailed the plugin’s author a week ago to try to get some more details about it and never heard back.

Seamless Database Pool

Credibility:  Highest rated DB plugin on Agile Web Development plugin directory.  Has been updated in last six months.

Pros:  More advertised functionality than any other slave plugin, including failover (if one of your slaves stops working, this plugin will try to use other slaves or your master).  Documentation is comparatively pretty good amongst the slave DB choices, with rdoc available.  Supports multiple slave databases, even allowing weighting of the DBs.  And with the exception of Thinking Sphinx, it has “just worked” since dropping it in.

Cons:  Tried to index Thinking Sphinx and ran into difficulty since this plugin redefines the connection adapter used in database.yml*.  The changes needed to database.yml (which are quite proprietary), make me suspicious that this may also conflict with New Relic (which detects DB plugin in a similar manner to TS).   Would be nice if it provided a way to specify database on a per-model basis, like Db Magic.  Also, would inspire more confidence if this had a Github project to gauge number of people using this.

Conclusion

Unfortunately, working with multiple slave databases in Rails seems to be one of the “wild west” areas of development.  It’s not uninhabited, but there is no go-to solution that seems ready to drop in and work with Rails 2.2 and above.  For those running Rails 2.2+ and looking to use multiple slaves, Db Magic and Seamless Database Pool are the two clear frontrunners.  I like the simpler, model-driven style plus lack of database.yml weirdness of Db Magic.  But I really like the extra functionality of SDP.  At this point, our choice will probably boil down to which one gives us the least hassle to get working, and that appears to be SDP, which worked immediately except for Thinking Sphinx.

I’ll be sure to post updates as I get more familiar with these plugins.  Especially if it looks like there is any intelligent life out there besides me that is attempting to get this working.

Update 10/13:  The more I use SDP, the more I’m getting to like it.  Though I was initially drawn to the Db Magic model-based approach to databases, I now think that the SDP action-based approach might make more sense.  Rationale:  Most of the time when we’re rendering a page, we’ll be using data from models that are deeply connected, i.e., a user has user_settings and extend_user_info models associated with it.  We could end up in hot water if the user model used a slave, while the user_settings used the master and extended_user_info used a different slave, as would be possible with a model-based slave approach.  SDP abstracts away this by ensuring that every SELECT statement in the action will automatically use the same slave database from within your slave pool.

Also, though I didn’t notice it documented at first, SDP is smart enough to know that even if you marked an action to read from the slave pool, if you happen to call an INSERT/UPDATE/DELETE within the action, it will still use the master.

* Thinking Sphinx will still start/stop with SDP, it just won’t index.  Luckily for us, we are already indexing our TS files on a separate machine, so I’ll just setup the database.yml on the TS building machine to not use SDP, which ought to solve the problem for us.  If you know of a way to get TS to index with SDP installed, please do post to the comments below.

Bill Rails, Rants

Rails 2.2 doesn’t like Mongrel handlers.  Specifically, the Rails 2.2 connection pool doesn’t.  More specifically, the connection pool doesn’t like a bunch of random threads taking its connections and not giving them back.

After a day of head banging (yah!!  rock on!!), I devised the following monkey patch solution to get our Mongrel handlers back on Rails’ good graces:

module ActiveRecord
  module ConnectionAdapters
   class ConnectionPool
    def release_connection(conn_id = nil)
     conn_id ||= current_connection_id
     conn = @reserved_connections.delete(conn_id)
     checkin conn if conn
    end
   end

   class ConnectionHandler
    def clear_my_connection!(conn_id)
     @connection_pools.each_value {|pool| pool.release_connection(conn_id) }
    end
   end
end
end

After you paste that into a file in your initializers directory, you’ll just need to call the clear_my_connection! method whenever you exit a Mongrel handler (or other type of Rails thread) that has accessed an ActiveRecord find.  We’re doing this like so:

ActiveRecord::Base.connection_handler.clear_my_connection!(Thread.current.object_id)

Hope this saves someone else a day of unproductive Googling when they upgrade to 2.2 and their Mongrel handlers suddenly start taking 5 seconds each (the time until the Thread’s connection will naturally timeout) to execute.

If anyone else has solved this in a more elegant way, you speak up now, y’hear?

Bill Rants

Rails programmer, how long do you think these glory days will last?

I first started thinking about this while attending Railsconf and talking to programmers who were creating Rails projects within gorillas such as AOL, LinkedIn, Monster, and of course Yellowpages (my apologies to AOL, LinkedIn, and Monster if any of those projects were supposed to be secret). After watching DHH’s keynote, it sunk in further. Now I hear that EngineYard just got $15m more funding, and the picture is crystal clear: the hobgoblins from years’ past that have kept Rails away from corporate use are melting away faster than polar ice cap.

This is a bad thing for those that like the competitive advantage Rails affords. With the advantage of RoR (and two tablespoons of Firebug), right now is one of those rare times in which a motivated programmer or two can compete technologically with legacy web companies that have payrolls 100x greater.

If Bonanzle could dig up an ounce of business savvy (still TBD) to go with our technology, I like to think we could be one of the seminal examples of this. Look down the list of our technological advantages vs the gorillas (real time offer making, integration with all major IM clients, image cropper, price guessers, pretty urls, 0-page-load item creation, real time messaging built into site, item importers for eBay/Craigslist, etc. etc.), and it’s clear that we’re living in an age where the possibilities for the underdog are as rife as ever.

But how long will that be the case? With a test-driven development environment like Rails, where metaprogramming and a solid MVC architecture can cut 125,000 lines of code to 20,000 lines (like Yellowpages did in moving to Rails), suddenly gorillas are nimbler, and order is restored to the world. Eventually, the gorillas might just figure this out. The horror.

In light of these facts, I have taken to pumping up the FUD on Rails whenever possible. I like my unfair Rails advantage, and would miss it if it were gone. In the interests of helping the reader perpetuate Rails FUD amongst their own social circle, I have created the following collection of sound bites to help you desecrate Rails:

1. Rails Doesn’t Scale. C’mon, you know it’s true. I even preached this one myself. Tell them that “Ruby is the slowest programming language” ever. I mean, it’s slower than an excellent language like Python by a factor of 3x. It’s slower than C by about 70x! I can only imagine how much slower it is than x80 assembly. Visualize how screaming fast your assembly-driven site could be. If your listener happens to mention cloud computing, I recommend you retort with the thousands of dollars they’d have to spend on a server cloud for a heavily trafficked site. If they point out that those costs are a fraction of the development costs they’d incur otherwise, move on to point number two.
2. No Big Sites Use Rails. Yes… yes… yes! In Rails’ history, excluding a couple one shot wonders like YellowPages and Twitter (don’t forget: Twitter is rumored to be leaving Rails), no “big” web site is running on Rails. Point out that both Facebook and Flickr run on PHP. Or better still, perhaps your listener would like to literally be the next MySpace and build on .NET? Hopefully they do not retort that almost none of the biggest sites were built when Rails existed, or that most new sites are built on RoR, or that any kind of bad Rails juju they encountered could be monkey patched since it’s all open source. It should suffice to say that if no big site has been built on Rails by now, no big site ever will be. Still not dissuaded?
3. Google uses Python. Yes, they also use Ruby. But they use Python more. This one ought to work well when convincing a take-over-the-world CEO.
4. Other Languages have More Libraries. This works sort of like number two… point out how many libraries PHP already has. Or .Net. Or Java, or C++. You can manipulate the hell out of an image with any of these choices. Or if you decided at the last minute that you wanted to make your web site into a PS3 game, you’d be glad you chose C++ and its PS3 libraries. Only the savviest enterprise-y tech guy will be able to discern between quantity and quality: think how many underdeveloped, crap libraries they’ve become accustomed to while dealing with Java.
5. Open Source Software is Unsupported Software or Ruby on Rails Doesn’t Deploy on Windows or URLs Don’t Matter. Alright, if they still weren’t convinced after four points that terrific, you’re going to need to fire some scattershot. These arguments should close the case for the last few Windows types, and for others, hopefully they tilt in favor of Anything But RoR. But for the last few hard-to-budge listeners, you’ll need to pull out your ace in the hole…
6. The Creator is an Ass. Have you ever listened to DHH talk? What an elitist snob. Thinks he is God’s gift to programming. The way he repeatedly cut off this nice Python fellow was disrespectful. Any framework created by this guy must be an elitist, disrespectful framework to use.

And that should about do it… double bonus points for anyone who can convince eBay to give ASP .NET a whirl!

(Note to busy/dense readers:  #1-6 employ heavy use of irony)

Bill Rails, Rants Rails

After much ado, the time has finally come to get Bonanzle moved to real servers, with Capistrano and all the tricks the big boy Rails apps use. But as I started to look into the logistics of this, I ran into a quick interview with Alex Payne regarding Rails performance on Twitter that made me raise an eyebrow. A couple minutes later, I came to the realization that this “quick interview” actually represents the center of an impassioned web of controversy that has enveloped the Rails community regarding the scalability of Rails.

On one side of the argument are DHH and the programming purists, whose solution to the performance problem is to say any number of things other than, “yes, performance is an important issue to us, and we intend to make it better.” On the other side of the argument is people like Rob Conery and Joel Spolsky who write that maybe RoR developers should give some weight to these performance concerns, as they seem to be the only argument of substance against mainstream RoR love.

Judging by the responses to Rob’s article, methinks there is still quite a ways to go before the community will come to acknowledge the problem at hand. What makes me think it’s a problem? Um, how about objective data from reliable sources? Ruby is slow. Rails is slow and getting slower as time goes on. To be fair, I tend to agree with Joel that Rails can never be fast until Ruby is, so this isn’t all on DHH, as some have implied. At the same time, when some crazy Japanese guy (developer of YARV) with this web page is the supposed prophet of Ruby optimization, I am concerned. Even if the guy is crazy like a fox, the extent of what he will divulge about the future of YARV is that “YARV development is too HOT!” Better HOT! than cold, but something like an expected date of arrival would be a comforting piece of data to add to the development page.

Others data bits I’ve seen around:

* Some suggest JRuby is the answer to Ruby’s problems. But by all accounts, it isn’t the solution to Ruby’s performance problems. At least, not yet.

* A common argument I see being used to dilute the significance of performance is that “performance isn’t scalability.” What people mean when they say this is that poor performance doesn’t always mean you’re unequivocally screwed. And to the extent that you have developers that like to spend their time setting up caching and multi-database transactions, I suppose that is true. But as a programmer who knows a lot of other programmers, I can pretty confidently say that “how to implement a load balancer” is not the sort of problem that many programmers exalt to face. Esoteric details about how to implement Pound or a memcache or HTTP connections between multiple Mongrel processes and an Apache frontend — this is the punishment that Ruby on Rails developers bear for the joy that they experience programming their apps.

* Another common “solution” to the problem I see is to use something similar to RoR that makes an effort at better performance. Entries from this side of the arena include Grails and Merb. The question I’d be asking myself if I were a Rails evangelist that wanted to see the language thrive is, “why do these similar applications exist?” Partly because people are comfortable with legacy languages (in the case of Grails), but moreso because there are many practical people who love RoR as a language, but can’t stomach the performance trade-offs that go along with it.

I suspect that many Rails-evangelists may be quick to point out that if I don’t like it, I can go to hell or fix it myself. And if I won’t fix it, I am in no position to complain, blah blah blah. Whatever. The first step is admitting we have a problem. If there is any blemish upon Rails name, this is the one.  Can we agree on that?

Bill Rails, Rants

Who would have thought?  Some 5 years after Google emerged in the public consciousness, and they have done their first kind-of-evil thing.  When I logged into my Gmail this morning, there was a big, red stripe across the top of my Gmail account warning me that if I didn’t disable Firebug (web debugging software used by 99% of all web developers, 100% of all web developers in their right mind), than there could be severe performance penalties while I used Gmail.

I will admit that I was pretty disappointed that Google chose to try to make users change their habits, rather than taking the extra time (and yes, cost) to get Gmail to work with a tool so common amongst web developers.  But at the same time, it made me re-realize just how seldom Google chooses to take the low road like this.  In the pre-Google days, it was routine for applications to make me reboot my computer to install them.  Or for applications to not include an uninstaller.  And include spyware.  And pester me with waits to use them if I didn’t pay.

Of course, many applications still do these things, and I don’t think that Google alone has turned the tide away from these annoying practices, but it has certainly risen public awareness that “don’t be evil” is a viable business strategy that can create both adoring users and a profitable bottom line.  Katy recently pointed out that it should only be a matter of time until Starbucks’ insistence on charging users $6.00/hour to use the Internet could come back to hurt them.  I hope she’s right.  There is no need for these kinds of business practices, when righteous users now know to stand up to them.

Bill Rants

Data waste is an awful yet potent nemesis.

Here’s the problem: every day, every person is bombarded with 16 hours of information. This information might be ideas in your own head about what you want to say, who you want to talk to, projects you want to tackle, improvements you want to make (to yourself or at work), or… anything. It might be something as nuanced as this blog. It might be as simple as remembering who you intend to thank. But every day, there is a lot of data being generated by our head.

Meanwhile, there is as much or more information relayed to us by those we interact with. People tell us how to improve ourselves, a great hike, where to shop, how to be productive, what it will be like to grow old, how to make a million dollars, what funny TV show or web site we should visit. Or any of millions of other things.

As one receives their 16 hours daily data, there emerges three choices.

Choice number one, which I think is probably used by at least half of all people, is to sit back, listen to all that data, and trust that the really important stuff will get captured by your memory and occur to you again when it becomes applicable. If none of the data you are receiving is imperative to your well-being, then you can certainly continue to exist while you arbitrarily remember some data and forget other data. But this choice puts a great deal of faith in the subconscious mechanisms that are choosing (based on factors we largely don’t understand) what to remember and what not to remember.

Choice number two is to employ a few key systems to stay organized in things that matter most to you. Choice number two is what is used by people who keep a calendar of upcoming events and a filing cabinet of tax documents and a list of passwords and the like. Choice two is basically choice one, but for people who need a simple way to capture esoteric data that affects their well being. You’re still at the mercy of memory for 75% of the data you receive every day. Different flavors of choice number two are what I’ve employed to this point. I have slowly accumulated a sundry collection of what’s now about 15 different organizational systems, including Google Calendar, a filing cabinet, and various Gmail “drafts.”

Choice number three is to constantly quest for the Panacea to All Data Wasting (PADW). Looking at the piecemeal list of organizing systems I currently maintain, it’s clear that my ad hoc organizational network isn’t working as well as it could, nor as well as I need it to. Speaking as a computer scientist, the essence of the problem seems to be that there are gigs of incoming data available for us to learn, but we only have megs of memory in our brains to store it. If that. Off the top of my head, I think the following are the key components of PADW.

1) Figure out somewhere with the capacity to store gigs
2) Ensure that the time it takes to retrieve data from said place scales well with large amounts of data
3) Come up with an algorithm for organizing that data such that we’ll know where to look for it and
4) Make a plan for what happens if the storage medium fails.
5) Design medium such that it is accessible anytime, anywhere

It is true that I might be getting overly geeky about this, but with each day it becomes increasingly apparent to me that without PADW, I am going to be throwing away perfectly good data. For example, here’s some data I’ve received in the last 16 hours that fits in none of my systems (and is thus likely to be lost by the time I need it): Katy tells me that the REI online outlet store has great prices and delivers to Redmond REI free of charge; Ben tells me that there are monthly meetings of “lonely programmers” (programmers without projects) in Seattle that I can attend if I Google the right terms; a friend mentioned Salesforce.com, which is officially the many-eth time I’ve heard of that site without visiting it (unless I did visit it and forgot about it). Where would I file these sorts of information? Let alone information I get from people like my grandparents when I visit them and they tell me about experiences in their life that aren’t applicable to me today, but that I would do well to remember for future situations.

It breaks my heart to let this perfectly good data go to waste. It’s even worse when I visit a bookstore and read random books about Argentina or life as a single mother — lots of fascinating and someday useful data that would never fit in the 2 MB memory the human designer has outfitted me with. Anyone got a clue about how to fix this?

Bill Rants

There are a couple books (literally, two) that I find myself quoting from on a very regular basis. Today, I come to speak of the book that takes about an hour to read and years to fully assimilate.

But before I reveal the identity of this book, a question: when was the last time you started using a new application (for the sake of this blog, “applications” includes web sites) and felt like the architect of said application truly cared about your experience?

Speaking from personal experience, it never occurred to me why certain applications felt “better” and “worse” to use. Nor did I ask myself why frustrating applications had ended up being designed as they were. Now I reflect on both regularly, and the reason is Don’t Make Me Think by Steve Krug.

Before I go any further, I should probably throw in fair warning: after reading this book, my reaction to using poorly designed software has changed from a mix of frustration and confusion to simple anger. If I waste more than five minutes finding a basic piece of functionality in an application, this now generally leads to severe annoyance. There is a fair chance that you, too, will revile the authors of your poorly designed software after reading this book. Therefore, if you are a person of action with a strong sense of justice, think twice before reading a text this potent.

But if you think you can deal with the truth, here’s what you’ll learn:

The premise of the book centers around the fact that users are very busy people who have neither the time nor the will to give an application as much attention as designers think they will. Krug asserts that when encountering a new application, the human impulse is to scan a page in about 1-3 seconds, make a best guess what will get them where they want to go (in Krug’s words, “satisfice”), and muddle along from there. He points out that designers should take care not to waste users’ milliseconds through making unclear links or leave them stranded in an application without a clear sense of where they are. He goes on to do some exercises where the reader sees examples of well-organized sites (i.e., Amazon) and poorly organized sites (buy the book and see them).

What’s more, the book is chock full of pictures and great examples. As I’ve come to know other Internet entrepreneurs within the community, I have found myself repeatedly citing examples in this book, as it seems to take most applications at least an iteration or two before they can get enough user feedback to create a UI layout that makes sense. Without this book and a strong sense of responsibility to your user, an application can quite easily never get things right.

With this book explained, you can now look forward to hearing the exasperated tales of applications that drive me bonkers, like TopStyle. This application earned itself an express ticket to my bad side today when, after handily reporting files with CSS errors in them, it provides no clear path of how to fix (or even view) these errors. Clicking on a specific error in a list of errors just jumps directly to the top of the file that the error resides in, not to the error itself. Brilliant.

Bill Design, Rants, Technology, Tough Decisions, User Experience

I love being wrong. Actually, check that, I hate being wrong. But I love finding out how and why I am being wrong.

When considering whether to undertake a new type of challenge, my guess is that “being wrong” is a big component of what makes people hesitate. Why?

In school, we all had regular opportunities to be wrong. Every test you took, you would probably be wrong on at least 10% of the answers. And there was no subjectivity; no “this seems wrong but it could just be me.” You simply didn’t “get” the test question, or you misunderstood the homework instructions, and you had to learn what had caused your reasoning flaw.

Graduating to a professional environment, it seems like the opportunities to be bona fide “wrong” are few and far between. Those who are regularly told they are “wrong” are often people who become disgruntled and leave their job. The rest of us glide happily along, forgetting what it was like to get a “C” on the final.

But what more fundamental component of personal growth is there than learning, and what more fundamental component of learning is there than experiencing failures? If you haven’t been exceedingly wrong at least six times in the last six months, I’ll bet you’re becoming less than your potential.

Bill Motivation, Progress, Rants

Those who know me know that I am and have long been a zero-meetings enthusiast. I used to blame it on a short attention span, which I figured was also the reason that school became more suffocating to me every year I attended. It started in high school, when I learned how to expertly use every last one of my 12 permissible absences per semester while still maintaining passing (read: nearly perfect) grades. In college, the problem worsened to the point that during my last two years, I averaged about 10% attendance across all of my classes. Many classes I attended only on the first day and on exam days. And then I wrestled with myself over whether the first day was really necessary. I did not have a problem walking in, leaving my homework in the teacher’s hands, and walking back out of the room. As I did this, I made sure to take a deep breath of fresh air while the doors to the building swung closed behind me. My thoughts and prayers were with those countless captives now listening to the daily administrative agenda as I headed home to further my daily personal agenda.

I would imagine that nowadays, a student who approached school as I did would be stamped ADD and given the proper medications to fix it.

But the more meetings I skip at work, and the more crucial tasks I get done during those skipped meetings, the more I think that my loathing for meetings and classes is my subconscious’ not-so-subtle way of guiding me away from non-productive BS.

Now, I will readily acknowledge that there are some who learn best when they have a person standing in front of them reciting. But, for the rest of us, there is no need for classes that are graded on attendance, or meetings announced by an overzealous HR director or boss as “mandatory attendance.”

Objectively, which of these options make more sense?

Option 1 — Information communicated by word of mouth. Information is delivered at the speed the orator remembers or reads it, in the way that orator chooses to present it. Information does not exist tangibly, so listeners must take notes, and then organizer those notes, to have the data, if that data later becomes relevant. Similar to commercials on TV: many nuances bombard you, few of them resonate.

Option 2 — Information communicated by a Wiki or web page. Information is presented in visual form, with clear delineation between topics and sections. Illustrations and cross-references are provided to be accessed on demand by learner. Learner can navigate information hierarchy to jump to whatever information is relevant to them, and refer to it at any future time to verify that they understand correct details when correct details are necessary. Similar to the Internet (uh, because it is the Internet??): learn what you want, when you want, how you want.

I point this out here because I think it’s important that others fight the teacher/boss/HR person who chooses audience captivity over audience productivity. That feeling of displeasure you have during a meeting? It is your subconscious productive side pleading for the madness to stop.

And if said teacher/boss/HR person has the gumption to remind you how “important it is for you to attend their meeting, like everyone else,” respond simply: “Important to whom?”

Bill Rants