tech ramblings

Despite the universe’s best efforts!  News:

1.  On Saturday, yes, I did break a rib, and yes, I did get to go to trauma via helicopter.  It’s really not that serious, I just have impressive bruises and am walking kind of slow.  (I was out of the hospital within about 2 hours, so really not that serious.)

2.  On Monday I started my new job, working for Mozilla Corporation.  It’s a great deal of fun so far and everyone has been really nice.  I’m excited to take up a whole bunch of new challenges.

3.  I’ll be speaking at the Zend Conference on Wednesday October 10th on the topic of "Premium PHP".

This was pointed out to me.  I’m happy to note my husband, co-author, and partner in crime Luke Welling is apparently one of the top 8 "sexilicious bloggers"  on the Internet.  (I also note my friend and former colleague Chris Shiflett and another contact from the web 2.0 world, Aaron Brazell, made the list.)  Congrats fellas, enjoy your notoriety.

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 )

Tutorial days.  I had planned on blogging yesterday but Typepad, my blog overlords, had kind of a bad day along with a bunch of other companies hosted by 365Main.  The root cause of this failure was of course issuing a press release earlier in the day talking about how they had 100% uptime for the previous two years.  Murphy was listening.  I believe Terry Pratchett has something to say about standing in a shallow copper basin of water on a hilltop during a thunderstorm, cursing the gods.  Anyway.  It’s up now.

I attended a couple of tutorials: on Monday Wez and Marcus on Extending and Embedding PHP, and on Tuesday Michael Schwern on Simple Ways to be a Better Programmer.  They were at absolute opposite ends of the spectrum in a lot of ways: Extending was digging into C, and Better Programmer was largely about people hacks, but both were excellent tutorials.

In the morning Luke and I gave our tutorial on PHP and MySQL Best Practices (and I uploaded the slides).  I think it went ok but a little long - we had too much material as usual.  Email me if you have any questions, particularly about the bits we didn’t get to in the time.

I love OSCON; I always feel like my brain is expanding the whole time I’m here.  This time I keep hearing about parallelism, something I haven’t spent a lot of time on since doing pthreads stuff in  my final year at college.  I have been thinking the last couple of weeks that it’s time to refresh some of the things that I have long forgotten, and acquire some new skills.  OSCON is a great place for all of that.

Yesterday I arrived in Portland for OSCON and headed straight down to the PGDay.  I missed the start, but caught part of Rob Napier’s talk on "Build a PostgreSQL Web 2.0 Application in 10 Minutes", Theo Schlossnagle on PostgreSQL with Solaris, and Chris Travers talking about LedgerSMB.

Rob’s framework allows non programmers to build RIAs fairly simply, and seems to be aiming at the Filemaker or Access market, which is a large one that when we’re thinking about big sexy databases tends to get overlooked.   Theo talked mostly about the wonders of Postgres combined with ZFS (which obviously is something I’ve heard a bit about before) - it was a good talk.  I must admit I was flagging a bit during Chris’ talk, having missed lunch, but he looked at LedgerSMB internals.

Afterwards everybody headed up to the PGParty at the Courtyard Marriott. (pictures here) Overall a good lead in day.

Monday I’m spending the morning in Wez and Marcus’ Extending PHP tutorial, and the afternoon in various phone calls and doing a video podcast…should all be fun.  I’ll be taking it easy Monday night since our tutorial is at 8.30 on Tuesday, unfortunately.

For those that haven’t heard it from me or the grapevine, I’m moving on from OmniTI.  I’ve had an exceptional amount of fun working with the good peeps over there for the last couple of years - it’s an excellent team and they do great work.  I’m still looking for my Next Big Thing.  Not sure yet what that will be but I am sure it will be fun.

I will be travelling a bit over the next week or so, will be in San Francisco next weekend and then on to Portland, Oregon on Sunday for OSCON.  I’ll be presenting the PHP and MySQL Best Practices tutorial with Luke, hope to catch up with all the usual suspects, meet some new people, learn some cool stuff, and have the general uber experience that is OSCON.  Hope to see some of you there.

By popular request, I have added my most recent talk slides to this blog.  You can get them from the side bar (over on the right side there) or on the about page.

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).

I gave my Writing Maintainable Code rant^H^H^H^Htalk this morning and have now posted the slides at http://omniti.com/resources/talks

Chris recorded it, so subject to quality I’ll post the audio soon.

This is a terrific conference - good talks, great location, and super organized - I had the feedback from my talk given to me by the organizers in summary form one hour afterwards.

Some highlights for me have been Robert Bernier’s pgpool talk and Andrei Zmievski on Vim for PHP Programmers.  Very good content in both.

I am delighted and excited to announce the launch of OmniTI Labs, a repository of Open Source software generated by OmniTI staff in the course of their work.

This is a project we’ve been talking about internally for a long time.  In the course of our work we produce a lot of bespoke code for various clients, or for internal use, or as part of our products. Some of this code consists of things that can be generalized for re-use by ourselves and others.  Given we have so many open source type people here, it seemed obvious that we should have a place to put all of those things for people to use.

The site is a launchpad to access the various Subversion repositories and Trac wikis for the various projects.  Some of the projects are things that have been around for a long while and are not new, but have a new home.  Some of the pieces are brand new code that has never seen the light of day outside the Omniplex before.  Some of the pieces are mature, and some in eXtreme alpha.

We’ll be adding more and more to this repository over the coming months, so keep your eyes open.  There’s an RSS feed of project announcements available on the site home page.

Enjoy.