Or even knowing if there is one. (I could look at the web server logs, but I don’t.) I post for a hypothetical reader who is me but not me.
When choosing what to write about, I usually think “If I found this post on another site, would I think it was cool?”. And, reader, I do. So fucking cool.
I don’t want this to be a blog that is only about backpacking, or bikes, or Linux. I want to cover all of my interests – which range widely – in a way that others don’t (or can’t). I dislike it when other blogs publish long posts that only regurgitate what others wrote, or simply latch onto a popular topic without adding anything new to the discussion. I only began blogging again in September, which makes for a small selection of posts in this year’s archives to evaluate. Looking back, I’m pleased with the diversity of topics covered.
The blogroll is a standard feature of most blogs that is conspicuously absent from the current version of this website. In the past I’ve struggled to keep my blogroll up-to-date. In order to be useful, I think the blogroll should contain only blogs that I am currently reading. That list fluctuates frequently, and I have a poor track record of keeping my blogroll in sync with my feed reader. One of the problems is that I regularly read many blogs, but there are very few blogs out there whose every post I enjoy.
But I use microblogging to share links. So, why not just continue with that method? When I created the latest version of this blog I decided to do away with the blogroll entirely. Now, when I read a blog post that I particularly enjoy, I blog about it. Like here or here. When I come across a blog that is full of wonderful posts, I blog about it too – and, chances are, I’ll still end up blogging about individual articles on those websites. All of these microposts are assigned the blogroll tag.
To me this seems like a much more meaningful way to share links. Rather than maintaining a separate page with a list of not-frequently updated links, you have the blogroll tag archive. Links are timestamped and curated, which makes it more useful to my readers. And I think that linking to specific content rather than full domains makes for a more useful and rewarding metric for the owners of the linked blogs.
The web has been moving more and more towards a centralized structure. Services like Twitter, Facebook, Google and Flickr are all examples of this. To me, it is a disturbing trend. It’s bad for the internet as a whole, and on a more personal level is damaging to individual liberty and freedom. Lately, I’ve been making a stronger effort to forgo these services.
During the year that I took off from blogging, I maintained a steady presence on Twitter. When I decided to relaunch my blog, I knew I wanted to integrate Twitter-like microblogging into the site somehow. Looking over my Twitter history, it was clear that I was predominately using the service for one thing: sharing links. There’s no reason that I couldn’t do that on my blog. In fact, some of the earliest web logs were simply lists of interesting links.
I rarely participate in conversations on Twitter. I find it to be a horrible medium for that. Conversations that begin with microblog posts can be handled with any blog comment software (and I think the resulting experience is much improved over what Twitter can offer). If you use Twitter to contact people and start conversations, a blog probably won’t work for you. (But there’s a great distributed social networking platform out there that you might want to look into. It’s called email.)
Initially I considered adding a new model to vellum for microposts. When I thought about what a micropost is and what I wanted to do with them, I decided that modifying vellum was unnecessary. I’ve seen some people claim that microposts don’t have titles, but I think that’s incorrect: the primary content is the title. In addition to the title, the micropost needs a place to include the URL that is being shared. Why not just put that in the post body? The URL can simply be pasted into the field, ala Twitter, or included as an anchor tag contained within a new sentence. All that I needed was to uniquely style the microposts.
I decided to place all microposts in a new micro category. Posts in that category are then styled differently. This allows the user to quickly differentiate these short microposts from the more traditional, long-form articles. It also helps to represent the relationship of the title and the rest of the post.
With this in place, I no longer had a need for Twitter, but I still wanted to feed all of my posts into the service. I know some people use Twitter as a sort of weird feed reader, and I have no problem pumping a copy of my data into centralized services. As it turns out, there are a number of services out there that will monitor a feed and post the results to services like Twitter. I started out with FeedBurner, but this seemed like overkill as I had no intention of utilizing the other FeedBurner offerings (giving up control of the namespace of your feed is another instance of the craziness associated with the move to a centralized web). After some brief experimentation, I settled on dlvr.it.
This accomplishes everything that I was looking for. All of my blog posts, micro or not, are now on my blog (fancy that). I retain ownership and control of all my data. Everything is archived and searchable. I’m not depending on some fickle, centralized service to shorten the links that I’m trying to share. People who want to follow my updates can subscribe to my feed in their feed reader of choice. My activity can still be followed in Twitter, but I don’t have any active participation in that service.
I’ve found that not attempting to restrain myself to a character limit is like a breath of fresh air. Previously I was able to share links only. There was little-to-no space left over for commentary. Now I can include my thoughts about the link being shared, whether it be a book that I’m reading or a news article that piques my interest. This is more satisfying to me, and I think results in a more meaningful experience for those who are interested in my thoughts.
Since moving to this system, I’ve only launched my Twitter client two or three times. I’ve found that I don’t miss the stream. I never followed too many people on Twitter. Many of those whom I did follow maintain some sort of blog with a feed that I subscribe to. Some don’t. That’s unfortunate, but if your online presence exists solely within a walled garden, I’m ok with not following you.
I took a year off from blogging. That wasn’t intentional. I just didn’t have anything to say for a while. Then I did have something to say, but I was tired of how the website looked. If the design doesn’t excite me I tend not to want to blog. (Call me vain, but I want my words to look good.) And redesigning the website – well, that requires an entirely different set of motivations to tackle. It took me some time to get that motivation, and then before I knew it we were here: 10 days short of a year.
During the development process I referred to this design as “mark two”, as it was the second idea I tried out.
The website still runs on Django. The blog is still powered by Vellum, my personal blog application. I’ve been hacking in it for over a year now (even when this website was inactive) and it is much improved since the last time I mentioned it. In the past six months I’ve seen the light of CSS preprocessors. All of the styling for this design is written in SASS and uses the excellent Compass framework. The responsive layout is built with Susy.
If you’re interested in these technical details, you will also be interested to know that the entire website is now open-source. You can find it on GitHub. Fork it, hack it, or borrow some of my CSS for your website.
The other big news is that I have begun to categorize blog posts. Yeah, it’s 2012 and I’m a little late to the party on that one. You may recall that I only began to tag posts in 2008. As it stands right now, all posts are just placed in the great big ameba of a category called “General”. Eventually, they will all have more meaningful categories – I hope. But it will be a while.
Things ought to be more active around here for the foreseeable future.
You may not notice much, but this blog has been completely rewritten.
I started developing in Django last winter and quickly became smitten with both the Django framework and the Python. Most of the coding I’ve done this year has been in Python. Naturally, I had thoughts of moving this website from Wordpress over to a Django-based blog.
For a while I did nothing about it. Then I had another project come up that required some basic blog functionality be added to a Django-based site. A blog is – or, at least, can be – a fairly simple affair, but before writing my own I decided to look around and see what else was out there. There’s a number of Django-based blogs floating around (Kevin Fricovsky has a list), but few of them jumped out at me. Most were not actively developed and depended on too many stale packages for my taste, or they just had a feature set that I didn’t like.
Out of all of them, two presented themselves as possibilities: Mingus (written by the previously mentioned Kevin) and Nathan Borror’s django-basic-apps. Mingus tries to be a full-featured blogging application and was much too complex for the simple project I was then working on. But the blog application in django-basic-apps (a fork of which provides Mingus with its core blog functionality) looked like it would fit the bill. As the name implies, it is meant to be a very basic blog. I dived in to the code I discovered that, with a few modifications, it would do what I needed.
So I finished that project. But now having messed with blogging in Django I was more motivated to get started on rewriting my own site. I took another look at Mingus. Although it was too complex for the previous project, the features it provides are very similar to the features I wanted for this website. I looked at and thought about Mingus for a time, repeatedly turning it down and then coming back to it. The question centered around the project’s staleness more than anything else. Currently, Mingus is built for Django 1.1. That’s an old version. As of this writing, the current version is 1.3. Many improvements have been made in Django since 1.1 and I was not too keen to forgo them and run an old piece of code. Mingus is under active development, and will be updated for Django 1.3, but it’s a hobby-project, so the work is understandably slow.
In the end, I decided that the best thing to do was go my own route, but take some pointers and inspiration from Mingus. I would make my own fork of django-basic-apps, using that blog as the basis, and build a system on top of that. I created my fork last month and have been steadily plodding away on it in my free time. Over the course of the development I created a fewsimpleapplications to complement the core blog, and contributed code to another project.
It’s not quite done – there’s still a few things I want to improve – but it’s good enough to launch. (If you notice any kinks, let me know.) I’m quite pleased with it.
This is a notable occasion. I’ve been using Wordpress since before it was Wordpress, but it is time to move on. (Wordpress is a fork of an old piece of code called b2/cafelog. My database tables have been rocking the b2 prefix since 2002.)
As you’ve no doubt noticed, the look of the site hasn’t changed much. I tweaked a few things here and there, but for the most part just recreated the same template as what I had written for Wordpress. I am planning on a redesign eventually. For now, I wanted to spend my time developing the actual blog rather than screwing with CSS.
So, there you have it. Everything is open source. Download it, fork it, hack it (and don’t forget to send your code changes back my way). Let me know what you think. Build your own blog with it! (There’s even a script to import data from Wordpress.) I think it’s pretty sweet. The only thing lacking is documentation, and that’s my next goal.
Disqus
The biggest change for the user is probably the comments, which are now powered by Disqus. Consider it a trial. I’ve seen Disqus popping up on a number of sites the past year or so. At first it annoyed me, mostly because I use NoScript and did not want to enable JavaScript for another domain just to comment on a site. But after I got over that I found that Disqus wasn’t too bad. As a user I found it to be on par with the standard comment systems provided by Wordpress, Blogger, and the like. The extra features don’t appeal to me. But as an administrator, Disqus appeals to me more because it means that I no longer have to manage comments myself! And as a developer, I’m attracted to some of the things that Disqus has done (they’re a Python shop, and run on top of Django) and their open source contributions.
So I’m giving it a shot. Disqus will happily export comments, so if I (or you) decide that I don’t like it, it will be easy to move to another system.
Markdown
One final note: I like Markdown. That might be an understatement.
I first starting using Markdown on GitHub, which I signed up for about the same time I started with Django and Python. After learning the syntax and playing with it for a few weeks, I discovered that I had a very hard time writing prose in anything else. In fact, the desire to write blog posts in Markdown was probably the biggest factor that influenced me to get off my butt and move away from Wordpress.
So, I incorporated Markdown into the blog. But rather than just making the blog Markdown-only, I took a hint from Mingus and included django-markup, which supports rendering in many lightweight markup languages.
Because I’m still new to Markdown and occasionally cannot remember the correct syntax, I wanted to include some version of WMD. WMD is a What You See Is What You Mean editor for Markdown, a sort of alternative to WYSIWYG editors like TinyMCE. (It is my believe that WYSIWYG editors are one of the worst things to happen to the Internet.) All WMD consists of is a JavaScript library. The original was written by a guy named John Fraser, who was abducted by aliens some time in 2008. Since his disappearance from the interwebs, WMD has been forked countless times. I looked around at a few found a version that I was happy with (which happens to be a fork of a fork of a fork of a fork), and rolled it into a reusable app. While I was at it, I made some visual changes to the editing area for the post body. The result is an attractive post editing area that is simple to use and produces clean code. I think it is much better than what is offered by Wordpress.
I’ve decided that I don’t like pulling individual tweets into the blog as uniquely styled posts. For now, that behavior has been disabled. I’ve moved to a single weekly aggregate post including all the previous week’s tweets. We’ll see how that goes.
Since individual tweets are no longer being pulled in, I’ve put a list of the most recent tweets down in the footer. Next to that you’ll also find a new list of the week’s most popular posts. Fancy!
It’s been nearly two years since I last redesigned this site. Don’t let me go that long again! The web is supposed to be a dynamic place, you know. Anyway, here’s the new look.
It isn’t drastically different from the old one. I’m still keeping it clean and simple, and the base colors are the same.
You might notice the rounded corners on some things. Yeah, that’s right. Web 2.0, here I come! I think rounded corners are only acceptable if accomplished with simple CSS. CSS3 is slated to include the border-radius property to achieve rounded corners. The specifications are not yet finalized, but Mozilla browsers have implemented the property with -moz-border-radius and WebKit browsers with -webkit-border-radius. Those are the properties that I’m using. That means you’ll get rounded corners in browsers like Firefox and Safari. Opera seems to work too. Internet Explorer, not so much. (Come on, IE has a hard enough time complying with current standards. You can’t expect it to look to the future!)
If you notice any bugs or would like to suggest any changes, let me know. After all, the site is really for you, dear user.
(I did briefly look at everything on a Windows box running IE8. It seemed to work – other than the rounded corners, of course – but if you notice any bugs in that particular browser, you know the drill.)
Two of the things that really spurred this design are Readability and Clippable. For about a month now, I’ve been using these bookmarklets while reading longs articles online. They help a lot. But it’s really a problem with the design of some sites that I feel the need to use them. I decided that I wanted to redesign my site with typography in mind.
I’m also now integrating Twitter posts into the blog. We’ll see how that goes. They’re styled differently, so there is a visual distinction between a tweet and a normal post. The idea is that I’m now just using twitter as a back-end to create short posts. If I want to, I can switch to some other microblogging service and you, the user, need never know the difference. (I could even just use Wordpress to create short posts! But that might get me kicked off the interwebs…)
Tweets integrated into the blog means tweets in the RSS feed, as well. That makes my RSS mash-up a bit irrelevant. If you currently subscribe to that, I’d recommend changing your subscription back to the normal feed. For those who don’t want to change, I’ve removed the Twitter feed from the mash-up’s input. That way you won’t have to read each of my tweets twice. The mash-up feed will now only include the blog and Flickr stream.
Blueprint
This design is built upon the Blueprint CSS framework. I’ve used it a handful of times before, but never properly. My method was always to link to the three Blueprint CSS files (screen.css, print.css, and ie.css) in the header and then toss in a link to my own stylesheet underneath them. I never used the compressor.
The idea behind the compressor is pretty simple. It allows you to maintain one central instance of Blueprint and use that to generate the CSS needed for each individual project.
<ul><li>Keep a core Blueprint folder checked out with <ahref="http://git-scm.com/">Git</a> on your computer</li><li>Create a settings.yml file within the Blueprint folder with all the specifics of each project using Blueprint</li><li>Use the command line to generate <spanclass="caps">CSS</span> for a project on command
<ul><li>Incorporating any site-specific attributes
<ul><li>Namespace on all Blueprint classes</li><li>Custom grid template rather than the standard 24 columns / 30px column width / 10px gutter width</li></ul></li><li>Compressing any custom <spanclass="caps">CSS</span> and appending to the end of the Blueprint stylesheets</li><li>Appending custom semantic selectors to the end of the Blueprint stylesheets</li></ul></li></ul>
When I first head about this, I though that the compression bit was all well and good, but I’ve never been really adamant about optimizing CSS for speed in the first place. I’m more concerned about compliance with standards and readability. Maintaining a central Blueprint instance didn’t appeal to me much, either. What really stood out is the ability to have custom semantic selectors.
CSS frameworks are neat. I’ve used a handful. Like any other tool, they’re not always appropriate. When they are, they have certain advantages and disadvantages. One of the main things that I dislike about them is that they encourage you to clutter your code with framework-specific junk. If you’re using 960.gs you’re going to have elements with classes like “container_x”, “grid_x”, “omega”, and “suffix_x” all over the place. With Grids you’ll have “yui-g”, “yui-b”, “yui-main”, and the like. Readability of code is diminished and you’ll probably end up suffering from a case of div-itis. Not to mention, you can forget about a strict separation of markup and styling. Sure, you could copy the style definitions for the specific framework classes into the classes or IDs of your own elements, but how many folks actually take the time to do all that copying and pasting? I sure don’t! The appeal in a CSS framework is to save time, not make the process of building a site longer. Plus, there’s an appeal in having the framework-related styling separate from the normal site styling. Such a separation makes the framework easy to update.
This is where Blueprint’s semantic classes comes in. It allows you to tell Blueprint to take one of your classes (or IDs) and apply to it the properties of one of Blueprint’s classes. A-mazing.
As an example, the header of this page might look something like this if built on Blueprint without the compressor:
Clean as a whistle! No useless divs, all elements semantically named, and not dependent on any framework.
As great as the compressor is, I do have a couple problems with it. When using the compressor, Blueprint intends that you only have 3 final (compressed) stylesheets: screen.css, print.css, and ie.css. Wordpress, of course, requires a style.css file to define the template. That’s no problem. I just a create a style.css file that has the theme information in it and then toss in a @import url(‘blueprint/screen.css’). Then in the Wordpress header I can put a link to style.css, print.css, and ie.css. Everybody’s happy.
Styling a website basically boils down to making a small change to the stylesheet and refreshing the page to see how that looks. Running the compressor after each change to combine the custom stylesheet with the screen.css file is not productive. So for the development process I tossed a @import url(‘blueprint/custom.css’) into the main style.css file. That works fine.
Then I finish building the theme. I’m ready to compress the stylesheets, so I remove the call to the custom stylesheet in style.css. I tell the compressor where the custom stylesheet is and have it combine it with the screen.css file. I run the compressor, reload the site, and everything explodes.
Just when I thought I was done!
The problem is that in the stylesheet the compressor generates, it puts my custom styles above the semantic classes. Throughout the development process, I was calling the screen.css file (which includes the semantic classes) before the custom stylesheet. As you no doubt know, stylesheets cascade. You can’t just switch up the order of elements without breaking stuff.
Oh well, I thought. At this point I was tired working on the site and didn’t care enough to fight it. I just put the line to call the custom sheet back in style.css after Blueprint’s screen.css file. I still feel like the whole semantic classes bit is enough of a reason to use the compressor, even if I’m not actually compressing my main stylesheet!
