tech ramblings

The interview I did with Bruce Byfield at OpenWeb Vancouver has been posted on linux.com.  In it, I talk about why Free and Open Source Software makes for better programmers, how to make developers happy, and explain why all the passionate people at Mozilla make it a cool place to live.

Recently I have been the recipient of a number of incidents of abysmal customer service and I really need to vent.

The worst of all is Bank of America.  They are as extraordinarily polite as they are incompetent.

On a number of occasions they have stopped my card.  Reasons for this have included:
  - You were spending a lot of money (it was Christmas Eve)
  - Someone used your card in another state (I live in Maryland, 20 minutes drive from Virginia malls).
  - You spent money in another country.

The last seems reasonable in some sense, so I have now taken to calling them before travel and advising of travel.   I have also on several occasions asked them to cease this practice as I travel a lot.  They always agree that this is fine and that they have made a note on my record, but it has never had any noticeable effect.  On my last trip home to Australia in September they stopped my card again.  After calling them - at least half an hour on the phone, at international rates - they assured me it had been unblocked.  I went out shopping and found it still blocked.  I repeated this process AGAIN and it was still blocked.  It was not until the third call that I managed to get the card unblocked.  On each occasion they assured me the problem was solved.  Overall I spent about three hours on the phone at international rates. 

I wrote an email to complain and was told they would send a physical letter to explain what had happened.  Such a letter never arrived.

Last Monday, 11/26, while en route to California, I misplaced my card.  Believing I had lost it in the airport, I rang to report it lost.   I spent 25 minutes on the phone and spoke to three different individuals.  The final one told me she could not suspend the card for some reason that she didn’t mention and that I would have to call back some other time.

I did not call back, hoping the card would turn up.  It did, on Friday 11/30, and then they promptly suspended it.  I emailed them to ask if it could be unsuspended, and was told that a new card had been issued and that I would receive it by mail 12/3.  Today 12/5 it had still not turned up, so I emailed again and they told me it was *mailed* 12/3.

On some level it is my own fault for continuing to bank with them, a problem which I will shortly remedy.

However, I am particularly grumpy with customer service assistants this week.

Number 2 was the gate agent at United in SJC on Friday afternoon.  After she twice stopped serving me to help someone else - and gave us each the wrong boarding passes - I politely asked if she could finish serving me before moving on.  She threw the boarding pass at me and it hit me in the face.  Charming.  I said nothing but took my pass and walked away.

Number 3, today I was on the phone to a doctor’s secretary.  She could not find me in the computer and then gave me a lecture on the fact that I was mispronouncing my own name.  If I would only pronounce it the way she did, instead of the way my entire family does, then people would be better able to assist me!

Vent over.  Will resume normal programming shortly.

You’re over at a friend’s house – let’s call him Bob - and after opening a beer he invites you out to the garage to see something.  On the wall hangs a reciprocating saw.  You notice that there are no other tools visible, which seems kind of weird.  Bob says “You like it?  That reciprocating saw is the best tool ever.  When I got it, I really liked it, and I joined the local reciprocating saw users’ group.  They showed me all the cool things I could do with it, and I realized I didn’t need any other cutting tools.  I even use it to slice my cheese!”

What’s wrong with us? 

I am frequently irritated with the mindset that there’s One True Way of solving any kind of software problem, be it web platform, database choice, operating system, or methodological approach.  It’s been irritating me since I was an academic and I would present two different algorithms (let’s call them A and B) to solve problem X.  There would always be a student who wanted to know "which is better?"  Typically I would respond "In a situation such as […] A is better, but if you are looking at something more like […] B is better."  Most people would be happy with that but there are always people who insist that one must just be The Best Way.

So, reasons for choosing, or sticking with, a particular technology/methodology/whatever:
- It solves the problem you need to solve.
- You have a lot invested in it and there is not a sufficient business case to switch.
- It’s easier to hire people with the appropriate skills / your staff have this set of skills and you can’t just fire them all
- It matches your mindset, or, to go back to the hardware analogy, it fits your hand.
- It has good community / support .

There are very very few absolutes in choosing tools, save that whatever tool you choose should be of basically decent quality.  I have my biases like everybody else, but it’s important to realize when you have a bias and acknowledge the effect that has on your decision making.

In particular, telling another engineer that all their problems would be solved if they would just switch from technology A to technology B is often the worst kind of cultish thinking.  I’m talking about the kind of discussion you see on mailing lists, on IRC, or from some people in person where you say "I have this problem.  I’m using technology A and…" at which point someone butts in and says "Switch to B." when they know nothing about your problem.

(Having said this of course, there are some exceptions, in particular to do with upgrading versions and using basically dead technologies.  So sue me )

Ahem.  So anybody that’s known me for a while has likely heard me say something similar to what is quoted in Cal’s article about OSCON.  I should clarify because I hear jokes about "Tell us what you really think".

Choosing a framework to implement your web app is a trade off like any other design decision.  Let’s focus in on specifics and talk about what the trade off is that you make when you choose a framework.  Specifically, I’m talking about MVC frameworks in PHP.

Good things

• Frameworks provide a common method of code organization, so developers can both a) get up to speed fast, and b) don’t have to think hard about how to architect an app.  They are effectively a standard for application architecture.  This is particularly useful when working with large dev teams or junior devs.
• Frameworks encourage the separation of the presentation layer from the business logic, avoiding a frequent PHP worst practice where stuff is all mixed in together.
• A framework can encourage secure coding through the use of dispatch architectures.
• In general, frameworks avoid spaghetti coding.

Bad things

• MVC is a design pattern.  As frequently mentioned by the good ol’ Gang of Four, every implementation of a design pattern is different, depending on the specific viewpoint of the implementor, and the specific application we are trying to produce.  This causes two problems.  One is that the implementor’s viewpoint is not necessarily the same as mine.  The second is that trying to shoehorn every app into the MVC structure isn’t always appropriate.
• Most MVC frameworks have an intentionally flat design - models, views, controllers - and when codebases grow, you need to modularize for maintainability.  There are different ways to do this, but many frameworks don’t lend themselves well to this.
• In the world of PHP, as with Perl, there is More Than One Way To Do It.  Specifically with frameworks, I believe Luke has been known to say there are 2.3 frameworks per PHP developer.  They are like content management systems or blogging systems.  We’ve all done it, sad to say.  The downside of this is that you lose a lot of the programmer speedup if programmers have to learn a new framework on every project.
• Bloat is a problem in a lot of frameworks.  That’s what "makes the magic happen", but typically using a framework means lots of files getting opened (required/included) behind the scenes.  This slows down your app.  See for example Paul M. Jones’ (updated) benchmarks.  (That, by the way, is an excellent, excellent article that displays a good methodology for researching design decisions.)  I’ll also refer here to what I sometimes jokingly call Thomson’s first rule of software design: First, do the simplest thing that could possibly work.
• It’s virtually impossible to retrofit an MVC framework on to existing code.  A lot of us spend most of our careers dealing with existing applications.

In summary:
Let’s be clear here: I am not recommending people write spaghetti code, or that they embed HTML willy- nilly in their PHP.  My recommendation in making any kind of architectural decision is to know what tradeoffs you are making and make an educated decision.  It’s important to remember that you can follow some of the basic rules of MVC and get a good number of the benefits without the bloat.  It’s equally important to remember that there is more than one way to architect a web app.

I’ll try and blog in future about a couple of other related topics: MVC in Rails compared to MVC frameworks in PHP, and templating systems.  (Unlike frameworks, all templating systems really do suck )

I think I must be the only person in the PHP blogosphere who hasn’t said something about Ruby On Rails.  It seemed about time

We’ve been working for a while on a RoR project.  Originally it came in as a really high concept idea - the spec was more like a film treatment than a functional spec.  It came from the mind of an old friend of one of our biggest clients - he’s a high concept guy, who’s been amazingly successful with his out there ideas in the past.

So we set out to build a prototype in six weeks.  We are known as a PHP shop, although of our web dev, about half is in PHP and the other half in Perl.  At the time we had working for us a very talented Rails guru, so we thought we’d give it a try. 

Times change: the prototype turned into a production website, our Rails guru moved on to a pure Rails shop, and we now support this Rails app (served from lighttpd against PostgreSQL on Solaris).

Things I have learned about Rails:
- It makes getting started easy.  This is what it’s famous for.
- We had to do quite a bit of work to get everything working happily on Solaris (as part of our migration to doing most of our web dev in ZFS zones).  This included building custom packages of Ruby 1.8 on Solaris 10 resulting in numerous patches to Ruby’s build and configuration processes and building custom lighttpd for Linux and then Solaris 10.  We developed numerous patches addressing unexplained crashes, errors on large file uploads, and improper use of timezone localization.

- As things get more complicated, the ideal of convention over configuration starts to get in your way.  In several cases we have obtained huge performance improvements (up to twenty times) by hacking around the conventions.
- The documentation sucks.  This is however, improving.  I remember when I first started learning the language and platform there was an initiative on the Rails website to pay someone to write some, "because all the people that really know Rails are busy building apps or writing books about it".  This is indicative of another issue, namely:
- The community support is really immature.  Something I know as a long time user of lots of different Open Source technologies is that a good community can make or break a product.  For example, for a long time the MySQL community was much more supportive of new users than the PostgreSQL community.  I love Postgres and have been using it for years, long before I ever touched MySQL or wrote any books about it (although I have tech edited a Postgres book).  I am really pleased to say that the Postgres community has become seriously good in the last year or so.
- Learning to debug apps is really really hard to begin with.  All the magic that goes on makes it hard for the newbie to figure out what went wrong.  How I wish I had known more about script/console at the beginning. 
- Because of the state of the documentation, I bought a few Rails and Ruby books.  The first one I read was the Agile guide.  I found it interesting how this book is aimed at Java programmers.  All the arguments for switching to RoR are arguments for switching from Java.  It never occurred to me that people would be doing that.  This is a very readable book but I need more depth.
- What I want is a book on debugging, maintaining, and scaling RoR apps.  Recommendations welcome.  Worst comes to worst I guess we might have to write one.

The project is possibly the weirdest thing that’s ever been built with Rails - the functionality at its most basic is very very straightforward, but as my colleague put it "This site violates pretty much every rule of web UI design. The content
on the site is not information as much as it is a bunch of people
arguing about current events and the righteousness of public opinion….if you can survive the outright attack on the senses, it is clever and punchy on both the concept level and technical level".   That sums it up pretty well.

It’s been and continues to be an interesting journey.  The site is visible at http://www.ctoads.com/

Footnote: Just as a note on the design - it’s entirely true to the client’s original vision and has been an interesting challenge for the UI designers (who have also been responsible for sites such as http://www.slash7.com/ (our original designer, Amy Hoy) and  http://labs.omniti.com (today’s designer, Dai Swengler).

Warning: This post contains many occurrences of the word "arse".  ("ass" if you are American)  If you’ll be offended, you should stop reading now.

So, in my talk at kiwifoo I talked about hiring and keeping good staff.  I had a slide that read:
1.  Don’t be an arseclown.
2.  Don’t hire arseclowns.

I was really stealing from George, who said once that the best thing about OmniTI was that we didn’t employ any asshats.  I have always preferred the term arseclown myself, from first having heard it in Office Space to Roy and HG’s telephone poll on The Dream ("Is Arseclown A Real Word?  Vote Yes or No") and their then nomination of the Arseclown of the Day.

I wandered into Borders and what should I see but this: "The No Asshole Rule: Building a Civilized Workplace and Surviving one that isn’t." by Bob Sutton.  You can even take the Am I an Asshole? quiz online via Guy Kawasaki’s blog.

P.S. Don’t worry, one of the first things in the book is a note that different cultures use different words: asshole == arsehole == arseclown. 

If there are any repeat readers (hi! and welcome back!) you might remember my post on the T-shirt index.

I finally got around to reading Freakonomics, which was recommended to me by somebody who read that blog post.  It was damn entertaining, and had me nodding my head and grinning most of the way through, even though I was trapped on a 14 hour flight at the time.

I realized there are other indicators that I use as a mental barometer of Where Things Stand.  I’ll try and blog about these on a more regular basis.  The first of these, which I was discussing with Wez on Friday, is the Little Notes Indicator.

The Little Notes Indicator can be seen in action in any place where a largish group of people must share communal space.  I have seen it in the following places: shared houses and apartments, workplaces, community spaces, and agistment (livery for the English and boarding for the Americans) places for horses.

In all of these places you will find a note or two that one person has left for other people.  We have one in the kitchen at work.  It says, "Please put your dishes in the dishwasher."  This is completely reasonable and similar signs are found in virtually every shared kitchen I have ever used.    A single Little Note is normal.

When Little Notes proliferate, it is a sign that communication has broken down.  If each day is greeted with a new little note (and possibly a new rule for sharing space to go with it) it shows that people have stopped speaking and just entered a period of resentment.  In shared houses this is usually an indicator of the imminent demise of the sharing; in workplaces an indicator of low morale among staff.

When Little Notes start having phrases added to them such as "or else" or when they begin to appear in capitals ("OR YOU’RE OUT") you know you are in trouble.  Other signs of trouble are increase in frequency, the use of colored ink, bigger signs, signs on top of signs, or people writing addendums to printed signs.

One place I used to visit had new signs each day which were circulated so that each individual had their own copy.  They were written in ALL CAPS, and always peppered with phrases such as ‘OR YOU WILL BE EVICTED’ etc.  Each sign inevitably followed somebody doing something not even particularly annoying that was previously not against the rules.  Once things start to snowball, there’s no going back.

Please God let me never be the author of such a missive. </rant>

So I’m relatively new to Skype.  Love it, great free service, blah yada blah.  Great for talking to the family at home.

It never occurred to me that when Apache started complaining that it couldn’t bind to port 80 that Skype had hijacked the port for its own foul purposes.  ("In Skype, we don’t share ours with anyone" for anyone that is familiar with that joke.)   Anyway, problem is now solved (quit Skype, apache -k install, start Skype).