I suppose it had to happen eventually, I went and got myself a proper website with the hope that it will add a modicum on respectability to my professional endeavors. I doubt very much it will but progress is progress.
Although I want to use this space to talk about mobile generally speaking (and I have a ton of posts queued up with just that purpose in mind) given that this is the first post of a new website it makes sense to talk a bit about the process that led up to the creation of this site and some of the choices that went into it.
If you are rolling your eyes by this point I don’t blame you one bit. The world figured out static pages in 1997 right? Well yes, but it’s still a bit more complicated than that…hang on while I explain and I promise you’ll be better for the experience (or at the very least it will be too late for you to do anything about it).
Through the looking glass
So like any product guy I looked at my website like I looked at everything I build: analyze requirements and come up with the solution that meets them with the minimum amount of fuss. The trouble is that most of my background on the development side is strictly on mobile making native apps which not only use completely different programming languages but the way we structure our interfaces is totally different too. Even though HTML isn’t complex per say it does take a mindset shift to be able to think of things differently and there is a learning curve associated with that.
Worse though, web standards are nothing like frameworks such as the Android SDK or Cocoa/Objective-C. When I want to figure out how to do something in iOS for example, I pull up the Apple SDK documentation which can sometimes be a bit thick to decipher but is always comprehensive and you can be sure that when Apple tells you how to do it that’s the proper way to go. Not so with web standards…CSS, LESS, SCSS, Sass…this alphabet soup just describes the various standards for dealing with stylesheets, then you need at the very least a markup language itself (HTML5 of course, but even that isn’t so simple with the browser fragmentation thing). Technically that’s all you need for static pages but most people don’t stop there…
Too much choice?
Figuring that I would want to have some dynamic content I realized there were really three commonly accepted ways to go:
A Content Management System (CMS) which would handle easy injection of new content while giving a vast wealth of plugins to customize the site to my liking. Wordpress is the most common here but there are tons of contenders in this space with offerings that can scale from a personal blog all the way up to corporate sites with millions of users. I have a ton of respect for the need for CMS systems, but after spending some time playing with Wordpress and Drupal they both felt like colossal constructs with a ton of underlying functionality that I didn’t want or need. I wasn’t trying to build a community or a storefront and even though the hosting requirements were modest, I would have either spent a ton of time bending a CMS to my will (and thereby having to learn the ins and outs of features I would never use) or be happy with a very cookie-cutter website. These types of sites also have dependencies on a database (I’ll get to that in a second).
A full stack MVC web framework like Ruby on Rails, Django, CakePHP, etc. This was DEFINITELY overkill for what I was doing but it felt like more of an engineer’s choice and I wanted to spend more time with one of these since I knew I might have to use one of them to do a more substantial project in the future. So I leapt into Ruby on Rails via the excellent Ruby on Rails Tutorial written by Michael Hartl and got to work. At the end of the day I learned a ton and found a lot to like from the experience, but fragmentation was frankly staggering. The problem is that Rails as a community seems to be in hyperactive development mode and is constantly switching ways to do things via entirely new gems for all sorts of common tasks which makes following it a fulltime job in of itself. When making a mobile app I usually rely on a couple of 3rd party frameworks (I don’t want to think about iOS development without AFNetworking or MagicalRecord) but it’s common for even small Rails projects to include dozens of gems despite the fact that Rails has a very comprehensive base SDK to work with. Plus I found that Rails tends to include so much “syntactic sugar” that I had a very hard time figuring out what was going on and why when using the build in helpers. This is not meant as a bash against Rails at all–I totally understand why it is the way it is and I appreciate what it is trying to do. But for the casual web developer it can difficult to get going with unless you want to go whole hog on scaffolding and I have a serious problem with that approach.
A hosted cookie cutter service that is designed from templates like SquareSpace. I did this for a while because I was enamored with the mobile toolchain and the slick built in galleries but the truth is that these services are really for photographers to use for portfolio websites and it didn’t really feel like a good ideological fit for me.
No hope?
So although I certainly wasn’t devoting a serious amount of time to it, nothing was really feeling like it was the right solution to the problem for me. I was so desperate to find a programming environment that wouldn’t force me to pickup several new frameworks that have completely different documentation standards that I took a look at Cappuccino briefly but had some setup problems with it and Xcode and felt a little uneasy about destabilizing my custom Xcode configurations anyway (although it seems pretty darned fascinating as the basis for a future project…hmmm…) so I was at a bit of an impasse. But I’m a stubborn guy and I kept looking around when I had time for the thing that would solve my problems without forcing me to become a full fledged web developer.
What I really wanted was a way to build decent looking pages in a contained environment with excellent documentation but low operational costs. I finally stumbled onto what I was looking for with OctoPress and I’m happy to report it strikes exactly the balance I was looking for.
So what makes OctoPress so great? Well a few things:
Although you still layout the stylesheets and templates in HTML5/Saas, the creation of content itself is done with Markdown which is a very logical way to handle content. The separation layers are well defined with excellent structure and it emphasizes overriding an existing template then working from there. It’s a great way to grow into a more customized design without needing to do all the learning up front. Although it possesses many of the advantages of a CMS, OctoPress is meant to have content configured ahead of time and then deployed as static HTML files. Not only does this make more sense from an operational perspective (software best practices frowns on changing content directly in production unless absolutely necessary) but it also means you don’t need a full application stack with a database and the entire site can be hosted off of Amazon S3. The importance of this are legion for me for various reasons (and yes I am very well aware of PaaS offerings like Heroku and love them but they are completely overkill for this). The entire thing can be checked into source control and can even do automatic deployments to S3 upon doing a git push to Github. Version control means you never have to worry about content going up in smoke without DB backups which are even more overkill for this sort of thing.
A happy ending after all
It’s not all roses but the proof is in the pudding: I set this site up and had this article written in an evening. Sure the site is still pretty basic right now but I feel comfortable that it has everything I need to grow into whatever I want it to be without any real compromises so I feel pretty good about this decision. Time will tell though as with everything.