This is developers thinking like engineers when they should think like VP of Sales. What does writing a blog say about you? That, given the choice between paying $50 for a Wordpress blog template or paying $5,000 for your salary for two weeks, you'd pick the second option and deliver a crappier product at a hundred times the cost in a field that the decisionmaker doesn't care about anyway.
Better to spend those two weeks working to make your online portfolio/resume/sales letter (every developer should have one) absolutely sing.
Of course, if you write a blog to learn new skills, you now have two things; new skills, and code to prove it. You are not in the top 0.001% of candidates looking for work (if you are looking for work, which most people that write their own blog aren't; they already have good work).
Well, I wrote my own blogging engine (back in 2000 and I'm still using it) and I've gotten my past two jobs because of it (or rather, what I've written for it). So I would say I've gotten my money's worth out of the code. I've also avoided every exploit dujour that seems endemic with popular blogging engines (mainly due to half-thought out features that interact badly).
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.
If your stated purpose in developing your own blog was as a demonstration of your skills (or practice) and not solely the need for a blog, then writing your own makes perfect sense.
I did this. It's taken me three revisions and 5 years and I still haven't gotten anything I like.
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 :)
I run a modest little blogging network (http://ozblogistan.com.au) and I disagree. Blogs are quite dynamic. My users want, inter alia:
* 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.
If I were writing a blog engine right now, I think I'd do something different: make the post itself static, and pull in any dynamic content via AJAX. That way old browsers still get a readable compatible page (just don't load any fancy stuff), and for everyone else the blog works like any dynamically generated one. And fine-grained caching can be had for free.
I've been thinking about using Disqus on my "blog". Which is, indeed, a bunch of HTML files built from Markdown input - using Disqus would, I imagine, consist of adding a single <script> tag.
All those sub-page widgets can be pre-computed and, thus, cached.
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.
> All those sub-page widgets can be pre-computed and, thus, cached.
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.
The best way to learn a language/framework/skill is to build something with it. A blog can be straightforward, personal, and interesting to work on. Building your own blog is a great way to advance your skills, particularly when you're new to the technology you're building it with.
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.
A corollary: The best way to learn a language or framework is to solve a problem with a known solution.
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.
The best way to learn a language/skill is to design and implement it yourself. (My problem has always been that I tend to get a little too meta... But I'm enjoying myself.)
I made one some years ago in Python, and a simple templating system for it, which "compiled" to Python too, and read/wrote article and comment data with MySQL.
Then I realized I had nothing blog-worthy to write about :-)
Instead of writing your own blogging engine, I would suggest using one of the many extensible blogging platforms as a base and building from there.
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.
Yeah, I built my blog (blog.deliciousrobots.com) in Django in my free time, importing old entries from my Wordpress blog. I'm thinking about rebuilding it in Rails or Sinatra or node.js / CoffeeScript or Common Lisp or whatever else seems fun/interesting at the moment.
I've done this. It isn't really fancy or complicated. It was the first thing I built with Django (My first web app actually!). It isn't done yet, as I still have to add syntax highlighting and better Textile support. Also, I currently add posts using a script instead of a web GUI, so that could be added. Also, I suppose I could add comments, but I just don't care much for them (on the page I mean). Maybe just a link to a Disqus thread...Defiantly do it. It isn't hard, and it is a great learning experience.
Definitely this. One of the real benefits of using Django is that the admin panel is already there. Adding items to be added by the admin panel takes minimal effort, and really simplifies things.
Once you start using the built in admin panel you'll be infinitely grateful that you don't have to roll your own anymore.
I did this once. Before the word "blog" was coined. Before there was a MySQL (there was mSQL, but it was terrible.) I ended up having to write my own datastore. (Damn kids, get off my lawn?)
I did this partly because for my needs it was much easier, at least compared to the other options I tried. I have something more like a "collection of essays" than a "blog" per se, and I don't like presenting them purely in blog format, except for the most recent few posts (for regular readers). It was actually easier to write about 100 lines of Perl than it was to track down the right combination of Wordpress plugins and configuration options to do what I wanted.
I'm not a very good programming yet, outside of html/css/jquery, but I studied up on basic application design, got some ideas, dug into document database specs (mongo), and then designed it for somebody else to code :\
Now I have more than a blog, I have a website/CMS engine that is fairly easy to customize for clients.
I did this, partly as there were no solutions to the frontpage I wanted, and partly as I wanted to implement better caching than any of the current platforms offer ... My site queries the database once per day, unless I post an update. So it's fast, (~100ms on $20 hosting).
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.
I did this for my blog[1]. I get complete control over how everything goes together, which means when I mess up the atom feed (again) and my friends complain about it (again) I can go fix it and not worry about getting patches accepted upstream.
There's arguments for doing so. There's also the arguments against it - but you should think about both side of the fence, and this side has a Star Wars reference!
I did this as one of my first things when I was learning ASP.NET. Now I absolutely hate it and intend to move to something else, something pre-built, something which I don't have to maintain.
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.
Better to spend those two weeks working to make your online portfolio/resume/sales letter (every developer should have one) absolutely sing.