Pocket Revolutionary

I am officially working on my first dead-tree book. I know I technically spilled the beans on Twitter at the end of last week, but this is my official announcement. I was approached by Packt publishing a couple weeks ago to see if I would be interested in writing a book on building and pimping out (not their words) templates in TYPO3. I decided that I’ll never know how little sleep I can live on until I really push it and accepted the challenge. So, over the next six months, I will be writing, screaming, crying, and having at least a couple breakdowns just so I can officially say that I’m a published author. I can only imagine that as a published author I’ll be able to raise my hourly rates, fly first class, smoke a pipe with gusto, and generally live a life of leisure and self-imposed solitude. I haven’t decided who’s going to play me in the movie, yet, but I’m leaning towards Lyle Lovett or a very disgruntled Randy Newman.

How does this affect this blog that I’ve been trying to write in more consistently? Well, I’m forcing myself to write an extra hour a night, and at least every once in a while that has to mean something other than “the book”. In fact, in the interest of writing a clear instructional book, I will be channeling 90% of my snarkiness, obscure cultural references, and general temperament toward outlets like this and the occasional telemarketer. The remaining 10% will probably make it into the book in a much more palatable dosage. On the side of helpful effects, though, this will give me more experience writing genuinely instructive articles. I’m already planning on blogging my process a little for those who haven’t already read the thousands of blog articles covering the same topic (I promise, I’ll offer something different…  like what word processor and meth dealers I use for late night working).

Since Packt successfully owns the English-language market on TYPO3 books, I’ve defaulted to buying about a half-dozen of their books over the years. In fact, I’ve talked to them about my own book that could one day be announced. I’ve had some mixed results with their books at times (non-native English can be scary), but I was still a little giddy when they contacted me and asked if I would write a review for their newest book, TYPO3 4.3 Multimedia Cookbook by Dan Osipov. I mean, I like TYPO3, multimedia, and writing content for my site. Score! So, it got here yesterday, I dutifully read it, and I can definitely say, “yeah, it’s a cookbook.” That’s not good or bad, it just is. If you aren’t going to read this whole review or are already bored with me, here’s the snapshot review: If you have written some extensions and just need a bunch of “recipes” for integration with audio, video, Flickr, S3, and YouTube, then it’s probably not a bad thing to have this on your shelf; if you want to learn the concepts behind the code, I’d check out TYPO3 Extension Development by Dmitry Dulepov.

Now that we’ve eliminated the lazy readers, let’s get down to business. TYPO3 4.3 Multimedia Cookbook is, like you would guess, essentially 200 pages of little extensions, TypoScript tips, and server hacks for sites with audio, video, images, and pretty much everything that’s not text. It says that it’s aimed at “anyone running or starting a website with multimedia” and recommends “prior knowledge of TYPO3”. That’s pretty vague, but it kind of sounds like everybody with a TYPO3 site to me.

In reality, I think the target they hit was a lot smaller. To actually understand what’s going on, you’re going to want some extensions under your belt. One of my only real problems with the book is that it’s supposed to be targeted at people with “prior knowledge of TYPO3”, and that sounds way too broad compared to who will actually get much out of it. Honestly, I would recommend having some real extensions (with actual PHP you’ve written) under your belt before attempting almost anything in the latter half of the book. If you’re only copying and pasting you can probably make it through without a lot of experience, but— hold on, I need my soapbox for this — you should never, never, never (and I mean never) be copying and pasting code that you don’t fully understand into a real site. If you buy this book thinking that it’s going to explain everything you need to know about API integration, you will either react as a good developer or a very bad developer. If you react like a good developer, you’ll be inspired by the power you can wield with a few tricks, spend some time getting caught up and understanding every command Dan uses, setup a test area, and come back to implement some of these later when you’re wiser. If you react very, very wrong, you’ll go ahead and start pasting code with very little explanation (unfortunately) into a site that you care about. That’s the end of my rant. I think they should have specified the target audience a little more judiciously, but we will all live another day.

Now that I’ve ranted, I’ll say that the rest of the book delivers for anybody with the right experience (or willingness to read other books for understanding). Like I said, it’s very spotty on when it decides to explain more about any subject, but you really can’t expect much more from a cookbook. The first chapter explains setting up a web server from scratch, multithreaded servers, and some concepts that would probably be best studied elsewhere, but the next half of the book really explains file management, editing in the RTE (rich text editor), and basic work with audio and video in good detail. Part of the dichotomy is that those chapters are well-written and complete, but anybody with the experience to read the last few chapters probably doesn’t need help adding images. For the experienced, though, the last few chapters provide some good code for S3, Flickr, YouTube, OpenOffice, services, automation, and even geolocation.

Overall, I’ll be happy to have it on my bookshelf. I will use it to help generate some ideas, grab the occasional snippet of code, and I’ll be happy. If that’s the book you need and you’ve hacked your way through some real TYPO3 extensions before, I’d probably recommend it. It’s “bookshelf candy” for me: not general enough for my desk, but specific enough be necessary when I need to reach for it. The price seems a little high for 200 pages; but remember that, like most cookbooks, you’re paying for the fact that it’s been collected and compiled. No single chunk is worth much more than a free Google search, but a whole collection is just plain handy. You can check it out on Packt’s website (I get no kickbacks).

Packt Publishing released a new TYPO3  book, TYPO3 4.3 Multimedia Cookbook, and it looks interesting. Dan Osipov, the author, is evidently on the team for the DAM (Digital Asset Management) TYPO3 extension, so I’m looking forward to it (even though I don’t use DAM anymore). I know I’ve already solved a lot of these problems for sites I’ve worked on, but I’m interested to see somebody else’s solutions. I’ll have to wait to until my review copy gets here to dive into it, but you can check out more information at Packt.com.

Alex Payne (who I respect and read obsessively) wrote a critique of the iPad on his blog here that I recommend reading before I continue… I’ll wait.

Okay, now that you’ve read the article, I can say that I don’t really agree. I don’t see the iPad as a hit against creators or the death of tinkering. For me, personally, the iPad compares to the other “consumer” devices in my house: TV, DVD Player, Kindle, etc.; except, the iPad is more creative-friendly than any of those options. Let’s face it, I love my TV and DVD collection as a consumer, but they haven’t brought me any closer or further away from becoming a director. I consume tons of books on my Kindle, and the fact that I’m not a published author has never been a setback (although I can dream). I firmly believe that everybody is a creator in some ways (even my mechanic), and they end up being consumers in other places (like my and my TV). I think the iPad encourages creation on two levels that those never can, though; it encourages interaction, and it sets a mark that I, as a creator, can reach.

Most of the apps that that I use daily on my iPhone (Tweetie, Facebook, Wordpress, etc.) are actually built for interaction. They are not built for pure consumption. Of course, I understand that’s not really what Alex meant, but I still think it puts the iPad one step ahead of most consumer devices that it is really replacing.

More important than the apps, though, the iPad gives me a target that I can actually achieve as a creator: the web. I savor the idea that a website I build (without Flash, obviously) can be used more places than just a desk. With one deft move by Apple, all of my creations as a web developer have become mobile experiences without always having to squeeze onto a tiny screen. I understand the frustration by some developers, but I’m honestly still excited working in the most “open” development field available today: the web.

Like I said, I respect Alex Payne (and I recommend reading everything he writes), but I don’t see the iPad as a harbinger of a soul-less dystopia. Honestly, the moment that computers left the hobby clubs and entered the homes, they became consumer devices for 90% of their users. I see this as an impetus for the next generation of creatives to get out there and make something for all the single moms, non-techies, and baby boomer parents that might be using this “new class” more than traditional computers.

Finally, this has nothing to do with Alex, but I have no opinion on whether any single person can, could, or should get the iPad. Since I haven’t even seen it in person, this is obviously not a review. If the iPad doesn’t do everything you’ve ever dreamed, you don’t have to buy it. I really won’t be offended. Personally, I still dream of getting one for myself (to replace the Kindle and the practice of squeezing all my newsfeed and web reading onto the iPhone) and my wife (who has an iMac that, while powerful, has never been portable).

I am a PHP programmer. I have been a PHP programmer for most of a decade. My license plate says “PHP DEV”, and I have PHPUnit tattooed on my arm (in Kanji). It is with that overly-defensive attitude that I must admit the inevitable: my latest project is in Ruby.

Shock. Awe. I know. It was an easy decision based on the server stack we were running, our growth plans, and the fact that we needed to train intern developers with a very quick turnaround. We went with the sexy newcomer, but that’s not the interesting story. The interesting part is that it wasn’t a big deal at all. With good frameworks, it didn’t really matter what language we chose.

Part of the reason that I love frameworks so much is that dropping from CakePHP to Ruby on Rails is a syntactical change and not a process change. In a way, frameworks are just enforced design patterns (MVC, mostly, in my case). Plus, playing with a different language after all this time away has been great experience. This jaunt into the land o’ pure object-oriented madness and strict coding rules has made my PHP coding (especially CakePHP) better. I have new appreciation for fat models and thin controllers, and I throw in the ternary operator more often. On top of that, I’m getting to teach people (like my friend Neil) who have never really done web development on this level. Through teaching others about MVC architectures, I’ve gotten better.

So, I’m still a PHP developer. It’s the basis for 80% of my work projects and all of my freelancing.
I’m having fun, though, on the other side. Stretching my PHP skills, adding to my toolbox, and remembering that I was just a better programmer when I couldn’t rely on ten-year old knowledge.