If you develop code in PHP or any other language take 5 minutes to read this. It raises excellent points regardless of the language you author in despite it’s focusing on PHP. I particularly liked #7 Use a PHP Framework & #8 Don’t use a PHP Framework. It harkens back to point #1 Use PHP Only When You Need It. Hammers are good at driving nails, but they make terrible screwdrivers. The same can be said of frameworks which are not the panacea that many tout them to be. There is a good tool for each job - the roll of technology folks is to accurately select and implement the correct tool for the task - because not everything is a nail.

For the last couple of weeks I’ve been developing and working completely remotely. Removed from my office, removed from my resources and often while in remote locations from the car with my family as we travel from destination to destination. It’s been enjoyable to be part of everything the family is doing but it has not been without difficulty. For example, it can be hard to debug complex problems with kids unhappy in the back seat or to read a terminal session with the sun washing out the screen. It can also be challenging to be working via SSH and have the connection drop because we travel through an area without data connectivity.

Those sorts of problems aside, the one thing I miss most is my reference library. I’ve amassed a number of books that are helpful references for obscure bits of knowledge I don’t keep locked away in my mind. Last year I travelled with my books and never used them. This year, however, I’ve found myself wanting them in a couple of instances while working. While I can use Google for the majority of the code snips and shortcuts I would need, it’s a highly inefficient, to continually switch windows. I’ve contemplated signing up for O’Reilly Safari but have found digital books don’t save any time over Google and the $22.99 or more per month seems expensive for materials generally available elsewhere and locatable through Google.

Mashable has a nice collection of 16 tools for designers and developers for plugging into Firefox. I’m personally a fan of Web Developer Toolbar and Y!Slow which are both great. The original Mashable article included the other two tools I find indispensable, ColorZilla and Firebug.

OpenSocial, a group effort to create a widget platform spear headed by Google, has a few glitches that I’d love to see fixed. They are largely comparison items from Facebook, who has recently announced that it will open source it’s own platform. Regardless of the motivation, there are a couple of items I’d like to see ported from Facebook to OpenSocial.

1. Support for FBML like syntax: “Hold on a second! Standard HTML is the benefit of OpenSocial over Facebook” folks are probably thinking. While that’s true, without an effective way to capture and store user information for more than 24 hours (pesky terms of service documentation) developers are left querying for friends pictures etc over and over and over again. While this isn’t inherently a problem, if you wanted to display a 1,000 profile pictures for some unknown reason, you need to call the API a large number of times. Then generate the HTML and pass it to the client. This makes applications painfully slow. It’s great to store the numeric id (12345678) and be able to pass it back to the pre-client for parsing. The best examples are and . These really are very handy.
2. Support for FQL like syntax: OpenSocial does a great job of providing methods for gathering most of the information you would want from the social graph, but it’s lacking in the ability to remix the data in new and interesting ways (easily). OpenSocial requires all of the heavy lifting to be done on the client (or the application backend if their API allows it). Most clients have a reasonable limit as to how big data structures can effectively be and have the application still function. Processing on the applications infrastructure negates another advantage of OpenSocial which is requiring very little in the way of hardware to operate.

There are also some learnings here for Facebook. I’d like to see a few OpenSocial conventions ported from OpenSocial to Facebook.

1. OAuth Signature: To be fair, Facebook does provide signed requests, but it would be great if they’d use a standards based signature instead of their own homegrown version.
2. External JavaScript Libraries: Facebook’s FBJS is powerful and provides most functionality that developers need. It’s even been open sourced so it can be used outside of the Facebook universe. However, developers who’ve been working with jQuery, ProtoType or any of the other numerous javascript libraries have to start at the beginning again. Additionally, they may be missing the functionality in the FBJS library that they need.

Both platforms still have a ways to go in terms of making developers life’s easier and users application experiences more robust. I think it’s great news that Facebook is opening their platform more. It’s really more symbolic than anything, because they still ultimately control what they do or do not implement on their platform. Bebo is the only other social network using Facebook’s model and it still requires some re-writing for developers because of syntax difference and lack of some features.