Professional CodeIgniter: Review (part 1)
So far, I’m done about half of Professional CodeIgniter by Thomas Myer. As you guessed, it’s about the php, MVC framework CodeIgniter. While I’ve spent a lot of time online at the documentation, tutorials, etc., I’d preferred to grab a book on it (the only one I could find that’s available) to get a more formal introduction.
In terms of how it’s written, I was very impressed by it very early on. The language is very clear and concise, and Myer does a great job of walking you through a very real world example. I was actually blown away by how well he can articulate fairly advanced concepts. However so far this was the highlight with some major let downs.
For me, I came into this expecting a book on how CodeIgniter worked, how it’s structured, it’s benefits, etc., but after having read half of it so far, it’s become much more like a basic php web development tutorial. There is a recurring tutorial that is themed throughout the book of how to setup a rudimentary e-commerce site. When the tutorial begins, some CodeIgniter specific code is presented, with outlines of the helper classes, organization of a request/mvc separation, etc., but very quickly, most things specific to the framework are forgotten, and CSS/JS/PHP becomes the focus.
Additionally, the focus seems to be targetted at a beginning. Perhaps that was the intention, but it was a real disappointment for me. This framework is exceptionally powerful, and while it’s seeming to operate much more like a library than a framework such as CakePHP, it has tons of usage, most of which doesn’t seem to come through in the first half. A lot of time is devoted to making ajax calls to a controller (understandably a notable topic, but not specific much to CI), pages and pages of CSS (at one point there was a 3 page stint of pure css code, which didn’t seem very relevant as it’s a PHP/CI book), and even JS.
I believe I understand the intention; Myer wants to take you from concept to delivery, and show you how everything in between fits together within the CI framework; however because of this, I’ve felt that the power of CI has been left behind for me to figure out in their documentation.
While CI does push convention over configuration, it does seem to come across as a very strong and powerful library rather than a framework (with some pre-req’s that push it into the latter category). This isn’t necessarily a bad thing, but since it’s the case, I would expect more of the library to be explained, and how it could be useful, rather than walking through a tutorial that is targeted much more at the new php developer delivering a larger project than they’re used to.
I’ll follow up with my second half of the book review shortly.
“Getting Real” by 37 Signals: Review
“Getting Real” by 37 Signals is a very specific read, for a very specific audience, but it does a tremendous job outlining a different approach to web application development. That approach revolves around getting something ‘real’ out, usable, and able to gain traction. This is the strongest point that is made repeatedly, very similar to a Seth Godin read which constantly reiterates the same point, over and over again, until it’s become clear.
Getting Real’s initial mission is to aide anyone involved with the deployment/development of a web application to successfully get it used. It does so by beginning with having you, the owner of the application, define it’s purpose, it’s audience, and goes through all the different life cycles of the application. These include the design process, hiring, marketing, pricing, customer feedback, and more.
While each of these sections could be very well documented and discussed, what comes through the most in Getting Real would have to be it’s optimism of a minimalist approach to web development and design. This stretches from the initial feature sets, all the way through to the number of people required to launch it, and how they market/advertise this launch. Less is more in the eyes of Getting Real, and they do an exceptional job explaining why this is.
Drawing from a professional history that includes Basecamp, the Ruby on Rails framework, Highrise, Writeboard, Campfire and more, Getting Real is able to back up their claims that less features is most of the time better than the competitor with more features, through real world examples of their success and their history.
Being a user of Highrise, a lean CRM web service, it is very clear from the onset that 37 Signals, the company behind all these services, believes firmly and practices stricltly the process of less is more. Highrise has a very limited feature set compared to other CRM systems, however the fact that it is so lean is what makes it so easy to get in, and begin working. The learning curve varies from none to very little, and it’s flexibility in a few areas (eg. tagging) make it as flexible as the user/business needs.
My contribution to this discussion is something that’s taken me a very long time to understand, and something that a lot of other people could easily disregard as a cop-out: if you are developing something that has competition (everything does), figure out the reason you want to compete, that 1 specific reason, and do that and nothing else.
So for example, back in the day I created a couple networks/sites/app’s that allowed someone to post a vacation property they owned, and I would do the SEO/SEM for them (they would pay me a yearly fee to post on my site) which would then send them inquiries. A really simple directory service. Now there were many out there, and while often a reason for creating a product or service will be to make money (which I thought about too, obviously), my reason for competing was because I hated the design. vrbo.com is one such competitor, and their site is 10 times better than it used to, but still looks horrible. It’s functional, but in my eyes, was horrible and I wanted something better.
But rather than spend 95% of my time on that one thing, the aesthetics of the service, I tried to mimic all the functionality vrbo.com had, AND improve the aesthetics. Like most businesses, it failed. I made some money, but very trivial compared to the market and in no way sustainable. But over the past little while, it’s become clearer to me that if I’m trying to compete in a specific realm, that realm should be 95% of the focus. It sounds easy and obvious, but for someone starting their own business, it’s so easy to want to do everything better. You tell yourself ‘well if i do everything better than my competitors, than the custom will have to pick me’. But all this does is lead to a lot of wasted time.
Getting Real is a great read for anyone who develops sites/applications. It will fairly radically change the way you look at feature sets, deadlines, team oriented development, and more than anything, priorities for your sites/applications.