I love to write blog posts because my ideal reader is a clone of me on the other end. I enjoy my writing style, and I like most of my jokes. I would probably read my blog, except that sometimes I get a little long-winded and I would need Instapaper to help me finish the job on my couch. I also write really long sentences. Somehow, I thought this great feeling would translate to my book.

Unsurprisingly, writing the book has felt much more like slow torture because… well, because I don’t actually enjoy reading it as much. For one thing, I’m not nearly as snarky or personal. I have no illusions; most readers of my book have probably not seen every episode of She Spies and don’t really care how clever I think I am with obscure references that could shame Dennis Miller. On top of that, I’m (obviously) writing mostly about junk I already know. I’ve learned a lot while writing, but I’m still pretty exhausted with TypoScript conditionals before I ever start typing that first draft. At this point, reading thirty pages on browser-checking and boolean logic sounds like hell as a reader.

Here’s my great revelation, though: It doesn’t matter. I am not the ideal reader of my own book in this case. This is my ideal reader:

A combination of Andy Ihnatko and the version of me from four years ago. Technically, my goal is to teach all the stuff that I wish I could have easily learned from one (hopefully) well-written book when I first started TYPO3. In fact, I wish I had understood a lot of this just six months ago, but I already explained that I’m researched-out and sick of this knowledge at this point. As far as my voice, I would like to entertain Andy Ihnatko. In my imaginary world, Mr. Ihnatko decides to give up his career as a freelance journalist and pursue the much less stable career of a freelance web developer. Naturally, he picks TYPO3 as a good platform (he has good taste) and goes looking for the best book on templates that he can find. When he finds out the best book is probably written in German, he buys my book instead. Obviously, he enjoys my book immensely after reading it and recommends it on MacBreak Weekly even though it has nothing to Apple. I enjoy Andy Ihnatko, and I think he would appreciate my subtle sense of humor. As a bonus, he seems generally congenial, and I don’t think he would mind too much if my book wasn’t perfect. I love John Gruber and Merlin Mann, but I would be afraid to show them my slightly-flawed writing efforts. Andy would probably at least humor me and still get something out of it to help him build his new business as a hot shot developer.

Anyway, that’s my ideal reader, and I’m learning to be okay with the fact that it isn’t me. If I have to explain something a little too much, I resolve to stop getting frustrated. I’m writing to the version of me that didn’t know TYPO3 that well and the imaginary Andy Ihnatko that is becoming a TYPO3 developer; I’m pretty sure they appreciate the extra explanation of data structures that I added to the end of that last chapter.

Aside from my attack on the bourgeoisie of TYPO3 templating, I wanted to mention my big new adventure: Vintage 56. Yes, although I may hate the escapade that was freelancing (on the side), I’m really excited about getting to form an honest-to-goodness production/design agency with some great people that I’ve worked with at Generals International for years. Basically, we’ve figured out how to make our own mark doing web, iPhone apps, graphics, video, and audio production with clients we love and help out a ministry by donating a large portion of our profits to Generals. Actually, we’re helping a lot of ministries and medium-size companies right now because they’re getting the full agency treatment without the full agency budget. Basically, I get to work with really talented people, and I wanted to brag on them. You can check out http://vin56.com to see what I’m talking about (yes, the video works on iPads, iPhones, and iPods).

p.s. – You need to check out our graphic designer’s blog…  she’s awesome.

p.p.s. – We will be launching another blog for Vintage 56 soon, but I’ve been slacking off– writing a frickin’ book. Stop pestering me. Seriously. I need to go.

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

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.

If you want to see this in action, you can just go to FulfillingDestiny.com in English or Spanish (or just go to the page and switch languages when you’re there, obviously).

[via buzz.typo3.org]

1. Design a Perfect Solution. We had a simple problem. We were going to have our first “virtual conference” where real registrations would be paid for by real credit card transactions for access to a “virtual” online conference with streaming video, forums, and chat. Our problem was that our current online registration system was designed for “real world” conferences. I had hacked it into our shopping cart a long time ago, and it worked great. It could provide us a list of attendees before the conference, and emailed them their conference information. It didn’t however, talk to our website’s backend. Our TYPO3 website already has all of the user management tools, and would take care of granting “attendees” access to the forums, chats, and video features based on group permissions. Our shopping cart just didn’t know how to add or edit users in the database. Now, some of you are already shaking your heads. What was I doing running a website where the content management system was not talking to the shopping cart? Have I not learned anything about “seamless integration” and “smooth user experience”? Well, now I need you to get off your soap box and shut up. I would have loved to integrate these two complex, perfectly independent, working systems before. It wasn’t a priority because no front-end users could tell the databases weren’t talking. It was a larger-than-life project. Seriously, you just need to drop it. Anyway, I immediately set forth working on the perfect solution. I designed the entire thing on a whiteboard. I mapped it’s user interface, functionality, and even the variables I would use. It was perfect. Using only 80% of my development time, I had designed the monster. This left me with –crap– a couple of days to actually build the whole thing. I mean, design is so important, but maybe that’s just too much time out of the total timeline. That’s what I should have thought. I didn’t think that. I thought the design was too important to reduce it down to just a day, and so I had over-designed like there was no tomorrow. Literally.
2. Build for Scalability. What did I design this little bridge for? For the 500 estimated registrants? For this one conference, and maybe the one after? No way. I decided to design a system that would work for the most amount of people and would never have to be changed. I could’ve realistically handled 10,000 registrations, and all we would have had to do for any future conference is create a new instance with a click of the mouse. Obviously, this kind of scale limited my options a little bit. I couldn’t simply modify our current registration system. If I did (and I worked this out), there was no way for the users to be automatically added to the correct group in TYPO3. The problem with designing for 10,000 people was that it all had to be automatic. We couldn’t keep up with manually approving anything, even if it only took one second per user. I also couldn’t make a system that worked just for this conference as a test. No, the entire thing had to customizable to the nth degree considering every conference we host has different demands, and it had to handle all of them (even the ones I can’t think of). The problem with this? There are probably only going to be 500 users at most this time around. If I have to manually touch each of their records for just one second, that’s only 500 seconds in the next month. That’s right, I spent days designing a system that would save me eight minutes and twenty seconds. And future conferences? Yeah, I’ll probably have to tweak the code a little bit no matter what I plan now. In my “perfect solution”, though, that code was an 800 pound gorilla of an extension instead of the 2-3 PHP files that can be edited without worry.
3. Use the Best Tool for the Job. That’s actually a bit dishonest. I didn’t, technically, try to use the best tool for the job. I tried to use the absolute perfect tool for the insane job I had over-designed. What was my tool? To do basic PHP editing on the shopping cart registration forms? No, that’s not scalable. That’s not elegant. No, my tool was going to be a fantastic TYPO3 extension that would bring the whole world together. Now, I ignored some basic facts like (1) I had never written a simple TYPO3 extension and (2) I had successfully written a hundred modifications to the shopping cart. I would not be deterred, though. Like the thousands of PHP developers who dive into a new learning curve because they know that Ruby on Rails is the best way to build a one-off blog in the afternoon, I cracked open the books. I didn’t ask myself if I was going to need this education again in the near future (probably not) or if I truly had the time to add training to the timeline (definitely not). I just started working on the perfect solution that would take me about two days just to train myself on. Don’t get me wrong, though, because I love learning new solutions. I love learning new languages, frameworks, and techniques. Maybe, though, this was a bit too much training for what could have been a half-day project. Once again, that would have been the perfect thought to have a week ago.
4. Commit to Your Decisions. Now that I had only done one complex design and started training on a solution I had never used before, I had to commit. Even when I started to fall behind, I reminded myself (and my boss) that I had to launch all or nothing. Why? Because I had conveniently left myself with no other options. I had nothing right now, and the only way to fix that was with this too-big solution. I couldn’t launch just part of it, because it was a monolith. I couldn’t go back to the easier solution because, well, it wouldn’t have all the same features and it wouldn’t be infinitely scalable and I had already read all the books and… and… I was committed.
5. Fight Through the Pain. Now that I had committed to an over-designed behemoth solution that could scale to twenty times more users than necessary using a system I didn’t know, I had to buckle down. I couldn’t stop for food or sleep. Even when I came back from SXSW exhausted, I started pulling all-nighters. Then, I got sick. So, I muscled through that. Until I got sicker. I muscled through some more. Until my boss made me rest for one day. One whole day. He made me come to our weekly prayer meeting, admonished me for making myself sick instead of asking for a few more days, had everyone pray for me, and then dismissed me to my house to rest. I was not allowed to work on registration. It was horrible. It was the worst thing that he could do. That is, until I rested for a while. I realized that I had designed the wrong solution. What was too hard to realize earlier in the week when I was hungry and sleep-deprived became self-evident. I was being a newbie project manager all over again. So I rested and sub-consciously thought of a whole new solution. I didn’t work on it that day, though. I just napped, watched movies and let it stay in the back of my head for an entire afternoon and evening.

Okay, so that’s everything I did spectacularly wrong. How did I manage to fix it? I gave up on everything I had done. I copied our registration form and modified it slightly for this event. I added in a few quick hooks that added new users to the TYPO3 database by good ol’ MySQL insert. It took me about three hours. What doesn’t it do? Well, it still doesn’t automatically add them to the correct group for approval. But, it marks them using a magical, proprietary system in the user list to show that we need to approve them. Okay, it prepends “1_” to the username. Shut up. It’s great. Once every few hours, we look at the user list in the TYPO3 backend and add everybody with a “1_” to the event group, then delete the “1_”. It takes a little less than a second per person. And now I sleep properly. The wrong design took me about a week of hard work. My next-best design took me a morning. Hopefully I learned my lesson. Maybe I can tattoo my easy steps for designing bad software on my arm for me too look at every day. If you have any more tips that nobody should be taking, you can put them in the comments or email me. Maybe I can tattoo those on my other arm…

What makes so me excited about FLOW3? First, I believe in the TYPO3 developers working on it and it really does look like a first-rate project (no hands-on with it, yet, but I have faith). I also just really love any elegant framework solution because I don’t have time or patience to invent a new wheel every three months and I really don’t need developers I’m working with to make their own octagonal, undocumented wheels in the middle of a project. Most importantly, though, I just like the idea of a common framework between my CMS (TYPO3), my CMS extensions (hopefully), and my external web applications (sometimes you can’t shoehorn an entire webapp into a TYPO3 extension, after all).

If my dreams are true, they should all be talking the same language with the same APIs and have the same basic architecture in the future. Even better than that, they will have the same “flow.” Every developer has had to do the “mash-up” before. Heck, that’s a big part of the job: make this piece of software share a database with that CMS and then dump the data into the charts for the marketing department. The biggest problem I run into isn’t the language issues (if the API doesn’t suck), but the fact that coding in one framework asks you to think one way and coding for the extension engine wants you to think a completely different way. You have to “change paradigms” at every step in the development, and it’s mostly needless. One of the goals of FLOW3 is to get developers learning the “TYPO3 5.0 way,” and that’s what I care about the most: a consistent “way” for my CMS, it’s extensions, and my external webapps.

Editor’s note: I got linked to by Robert Lemke on the TYPO3 news page here. I’m positively blushing.