Be a Good Jedi: Build Your Own Blog
blog.wekeroad.com
blog.wekeroad.com
Better to spend those two weeks working to make your online portfolio/resume/sales letter (every developer should have one) absolutely sing.
1. I'm smart enough to get designers to design (the $50 template), and
2. I'm smart enough to write this generation's version of a text editor?
The other aspect about writing your own blogging engine (if you can) is that you control every feature that goes in and are not dependent upon a third party to implement (or not). Besides, it's a learning experience.
I'm not saying that everyone should write their own blog engine, but to say that no one should because it's a waste of time is just as bad in the other direction.
A few pieces of insight that I think I'm right about:
- blogs are not dynamic. no code should run when someone visits your site. (or requests your atom feed.)
- content management is just linking. a blog is a graph. a site depends on pages. the main page depends on pages. each blog post depends on a template. the template depends on javascript, css, images, and content. the content also depends on images. once you resolve the links and generate a bunch of files that a web server can understand, you have the One True generic CMS.
Some day I will figure out the right abstraction for this. But not today :)
* Comments on stories that appear seconds after posting
* Latest-comment lists (this one is a performance nightmare for anything other than the simplest cases)
* Navigability by category, author, tag, date
* Twitter integration
And so on and so forth.
There are, basically, two platonic models of web applications. The first is the compiled, the second is the dynamic. Compiled web applications perform all computations in advance and reduce to static resources. Dynamic web applications perform all page rendering on-the-fly and only a small subset of a page is static (JS, CSS and images, mostly).
Naturally, most apps fall in between on the continuum. For example, Movable Type used to have a simplistic compilation scheme that would rebuild large portions of the site due to small changes. For a while one of the selling points of Wordpress was that it updated instantly. But that too came at a price, and now on any busy site using it, Wordpress is usually chaperoned by a bodyguard of caching systems.
My personal thinking is that the sweet spot will be in managing changes to a site through queueing and selective compilation. This is what we have in practice, but I want to move the key queue from GET -> cache -> app -> db to being POST -> db -> app -> cache.
The first web request (at worst) should initiate all those, but you shouldn't be fully computing every query, for every section of code on every page you send for each request.
That's broadly what I mean by changing the pipeline to be post-focused. When the site has a change pushed to it, the relevant parts should be re-rendered down to HTML for a fast HTTP server to dish up.
The current model works the other way. Until somebody does a GET, the system may or may not have the rendered HTML in a cache. Even if it does, it may or may not be a verifiably up-to-date copy.
This seems hit-and-miss to me.
I've sort of sketched design ideas around this area (using, for example, PostgreSQL triggers and NOTIFY to prompt rendering). Maybe I'll write a blog post, but it's basically pointless without code.
My current blog is static content generated with Clojure. My previous blog was generated with Python. It's good to have something you can tinker with in your free time. Get out there and work on something. There's nothing wrong with building your own blog. "Productivity" be damned.
When you're building a blog for the nth time, your only focus is on the language/framework features you'll be using to express your solution, not the solution itself.
Then I realized I had nothing blog-worthy to write about :-)
I personally have become a huge fan of statically-generated blogs (using Jekyll[1] for Ruby or Hyde[2] for Python) as they integrate great with version control and require little maintenance. Another benefit is speed, as nginx serves static content with ease.
Once you start using the built in admin panel you'll be infinitely grateful that you don't have to roll your own anymore.
Now I have more than a blog, I have a website/CMS engine that is fairly easy to customize for clients.
Document databases are awesome like that.
:)
What I enjoyed was making software that isn't bulletproof and distributable, but safe, secure, fast and fun to build. What personal sites should be, imho.
[1]: http://bugsplat.info
exit(1);That said: I don't regret building it as it taught me tons and tons of things which was useful when building real world applications. One of the most important things: What is marketing fluff, what can be applied in the real world and what is "easy now, hard later" vs "hard now, easy later".
So yeah. Building your own blog can be useful, but it depends on your motivation. If you have enough things to keep you occupied and you are past the need to learn the platform you are working on, I think it's more worthwhile to get something mature and spend your time on something else.