So I wrote a blogging framework…

A little while ago I wrote a post about an idea I had for a version control-backed blogging system. Here is an early version in action.

I wrote a post over there that has a bit more information, if that kind of thing tickles your nerdy fancy.

Enjoy, and let me know what you think!

An image placement problem to watch out for in Google Chrome

Google Chrome has an interesting little thing that it does, where it decides how the page will be laid out before it knows the dimensions of all the elements. For example, if you create a <div> tag with a large image in it, Chrome will calculate the height of the div before the image has loaded. That’s right – it figures out the height of the image’s container without necessarily knowing the size of the image.

So who cares? What does this mean?

Well, if you have elements styled as position: absolute in your page, you might find that they start out correctly placed, but they don’t move with the rest of the page when the image loads. This means that you have badly placed images sitting around in your page, making the whole thing a horrible mess.

Alternatively, you might have a set of images that are meant to sit in a nice little row inside a <div>, but they end up wrapping onto an extra line because Chrome didn’t wait until they’d loaded before it figured out how wide to make the <div>.

And what can you do about it? Here are a couple of options:

  • Specify the dimensions of your images in code. Don’t leave it to the image to tell the browser what size it is, because by the time the browser finds out, it may well be too late.
    You can do this in a couple of ways:

    • Use the width and height attributes of the <img> tag. This is not very good in terms of separation of concerns, but it will get the job done.
    • Use CSS to specify the width and height of your image, or alternatively the size of its container. This is better separation of concerns, and CSS should load early enough in the rendering process that you don’t get the same problem you’ve been having with your images.
  • Use CSS image sprites instead of individual image files. This is basically the same as using CSS to specify your image dimensions, or rather it includes same. Image sprites force you to specify the size of the image, otherwise it won’t display correctly. This means that you will notice while you’re working on the page if something is not quite right, and be able to fix it there and then. You won’t have to waste time later on, coming back to somewhere you’ve already been.

Hopefully this helps you figure out a problem some time. If not, just remember it was here.

Presenting my linkblog

With some small trepidation, I present to you a couple of items.

Firstly, my linkblog, in which I point to internet objects of all sorts which I have found interesting, amusing, informative, scary or otherwise worth reading.

Secondly, Grabbit, the web application I have made which runs the aforementioned linkblog. It also forms the centre of a couple of other useful RSS-related applications I use.

I’m a little bit excited about this app, particularly this iteration, because it has shown itself to have uses beyond what I originally anticipated. To me, that’s a shadow on the wall that signals the possibility of versatility and enduring usefulness.

Grabbit is an application which consumes RSS feeds, then stores the links in each feed for use by some other app. Each feed subscription can have text tags attached to it, and each item that is created will automatically have the same tags as the subscription it came from.

Here’s one way you can use it: you subscribe to several feeds using Grabbit (just give Grabbit the address of the feed and a couple of other details) and tag them all as ‘podcast’. Then run a script that makes a request to Grabbit, asking for all items tagged ‘podcast’. That script might then download all the URLs it receives onto your mp3 player, ready for you to listen to.

Please go and have a look at the source code if that kind of thing interests you. Then fork it and have a play. I’d be happy to hear what you think.

I love having my own domain name

About half an hour ago, I decided I was unhappy with MyOpenID as my OpenID provider. They have been down quite a lot of late (or so it seems to me), and this evening I finally had enough.

I’m really glad that I decided to use OpenID delegation from my own domain name. It means that I can give the same URL as my OpenID when I log in to websites, no matter which provider I’m using. The website I’m logging into doesn’t even care whether I’ve changed providers in the meantime (because that’s none of its business)!

What’s OpenID, I hear you ask? Here’s a quick summary.

You can do the same sort of thing with your email provider, or with your blog or website hosting, as long as you own the domain name, and tell those services to use it (and also tell your domain registrar to point to those services).

What’s that? The gentleman up the back? How could you get one of these domain name thingies? Well, you need to register it, and there’s typically some sort of annual fee. A good registrar is not easy to find (I’ve never used one myself), but I’m told Hover is very good.

Happy Internetsing, until next time!

Building a blog atop a version control platform

Most blogging platforms are database-backed: they run with a relational database storing all your posts, and then query the database when it needs to present a post on a web page. You create posts by making INSERT commands, and edit with UPDATEs.

This model has some great aspects: it’s pretty fast (though not the fastest), it allows many users to run blogs on the one server (by adding a foreign key named blog_id to the posts table, for example), and it’s easy to query and search, just by using SQL (the web app you’re using to run your blog generally takes care of that for you). You can blog from anywhere, as long has you have a web browser.

But there are some weaknesses to this setup as well. For example, it’s hard to track changes (resulting in paragraphs at the end of posts starting with UPDATE: or EDIT:). And unless you work directly on the server (which is risky), you’ll have to use that web app to write your posts. Not a huge burden, unless you happen to be on dialup, or spotty 3G. It’s also hard to back up.

So how do we get around these problems, without getting rid of too many of the advantages that a web app-based blog gives us?

Of course, I wouldn’t be writing this if I didn’t think I had an answer.

A Version Control System (VCS) is a tool often used by programmers to keep track of the changes they make their code. If I introduce a bug to my code (it happens), then I can use my VCS to revert to the version of the code that didn’t contain the bug, and give it another shot. Or if somebody else introduces a bug, I can use the VCS we both use to find out who they are, and … umm… provide them with constructive feedback.

Although VCSs are used mainly for software development, that’s not their only use.

If we make a blog that uses a VCS for storage instead of a relational DB, and treat each post as a document, we immediately get some awesome benefits:

  • You can track your edits. Writing an UPDATE: paragraph is no longer the only way to indicate that you’ve made a change since your original post. You might still choose to do it if your readers are in the habit of reading your blog that way, but it’s not the only way. For example, you could point to a list of edits on a site like Github.
  • You can serve up posts blazingly fast. Because most VCSs track files living in folders on your hard drive, the most convenient way to use a VCS to track your posts is to store your posts as files. It just so happens that the fastest way to serve information over the internet is from files stored in exactly that form. And what that means for you is that you can use a less powerful, less expensive server to host your blog.
  • Uploading images and videos is taken care of automatically. When you save your files to a VCS (a step known in the software business as “committing your changes”), everything you’ve saved in the VCS gets uploaded automatically. All you have to do is save it into your version-contolled folder, then link to it from your post. Simple.
  • You don’t need specialised publishing software. If you’re hardcore, you can create your posts with just a text editor and a VCS tool. If you’re less hardcore, then I’m planning to make the software that will do this for you. It’s a “someday” goal at the moment though, so no promises.

Now, this hypothetical software isn’t going to work miracles. There are some things you might miss. For example, the “post from anywhere” concept becomes a bit more work for your friendly software developer, so that might not be there from the word “go”. I’m envisioning a desktop app as the first editor for this guy, with your VCS of choice running in the background. I really haven’t thought yet about the whole “theme” thing either. It’s a work in progress, people.

*lightbulb*

Although I guess you could do something like a build process, the step in programming where code is compiled and tested, ready for deployment. I guess that’s the step where you apply your layouts, assemble your RSS document, and whatever else you need to do to make your blog functional and amazing.

Mobile accessibility might also be a bit tricky – as far as I know, nobody’s found a good enough reason to write a mobile VCS client yet (please let me know if I’m wrong!), and that’s kind of a necessary component. Again, there’d be ways of getting around that limitation, but they’re not simple, and they’re not necessarily easy.

Anyway, that’s the idea. Feel free to take it and run with it – or point out who has done it already.

Rubber duck debugging

Art, sharing and copyright

There are some things that Western society usually encourages. Not that other societies don’t, but the West is the one I know. Art is held up as a sign of civilised life. Sharing is considered one of the most basic social skills. The rule of law is something we have set up enormous governing entities to try to preserve. Yet we are at a point in our development as a culture where a sharp conflict exists between these three principles: create art and cultural works, share what you have and obey the law.

The conflict arises out of a set of laws that were intended to give artists protection against other people passing of the artist’s work as their own. I am referring, of course, to copyright law. Copyright law allows the creator of a work to control who copies it, and under what conditions. The law says that we are forbidden from copying a work unless the creator gives us permission.

This rule gave artists an easy way to make money: I, the artist, make many copies of my work, and sell them to you. That works as long as I have control over the creation and distribution of copies. Which, in turn, works as long as copies are hard to make.

The problem that has arisen lately is that many works of art and cultural works (e.g. music, movies and TV shows) have been getting easier and easier to copy, now that we use computers so much. Copyright law has become unenforceable, because copying is so deeply embedded in the way we get data from one place to another. Copying had to become cheap, because we rely on it so much that we had to make it cheap. And now that it’s cheap, anybody can do it.

That means that the creator of any work that can be converted to digital form is no longer in control of its distribution. Well, legally speaking they are, but in practical terms that control is so easily broken that it’s easier to say it doesn’t exist.

Not only that, but as the number of copies of a work explodes, the value of each copy collapses. When record labels only distributed copies of songs on tapes, making illegal copies was a lot harder. The only people who did a lot of it had special equipment that cost a lot of money. Those people generally considered that cost an investment; they were selling their illegal copies for a profit. We bought them because we couldn’t afford to make them ourselves. Now that we can, the “bootleg” recording trade is dead and gone. We swap songs with each other for free, and because everyone can do it, there’s no profit to be made from illegal copies.

So is there any profit to be made from authentic copies?

As with so many seemingly straight-forward questions, the answer is "well, it depends." If authentic copies of your work are easily distinguished from unauthorised copies, then yes. You still have something scarce enough that you might be able to make money by selling copies. Paintings, sculptures or films on celluloid might qualify here. But if your work is easily copied with little to no loss (say, a movie on DVD), then you’re going to have to find a different way to make money from it. Public performances (like at the cinema) and merchandise are popular options, and convenience is a good one too (think of the iTunes store). But as long as you’re selling something that can be reduced to bits, you’d better be selling something other than just the bits themselves.

Some copyright owners choose to use the legal system as a way to make money from their works. Mostly these copyright owners are not the creators of works, but instead have made an agreement with the creator that allows them to make copies of the work, sell them, and sue others who do the same without permission. The most common practice is to use a court order to get the contact details of someone whom you suspect has been making illegal copies of your work, then get in contact with that person and threaten to sue them, unless they pay you an amount of money that is just a bit less than the cost of going to court. Because going to court would cost you more money, and there’s a chance you might lose.

What this means is that you’re using the court to get money out of someone, and not to start a court case. And the legality of such a move is … blurry. (I am not a lawyer. This is not legal advice.) It’s pretty hard to prove that someone is threatening to litigate without intending to go to court. But the strategy has been compared to extortion; it certainly has a “pay up or else” ring to it.

Anyway, the practical upshot of everything I’ve been saying is that we have some strong community values that are in conflict, and the balance between them won’t be restored easily. In the meantime, if you are creating works that can be made digital (and the number of things that can’t is going down steadily), you might have to be a bit more clever in order to make money. Not because you don’t have the right to make money from your work. You do. It’s just not going to be as easy as it was. You’ll need a model that’s more than just “copies for cash.” Because that’s going away. Piracy, sadly, is not.

A word on website hosting

I’ve had a few people and groups ask me about setting up their own website. After having this conversation a few times, I thought perhaps I should distill the common elements here. So here goes.

When choosing website hosting, most of us have 3 basic options:

A static website (i.e. no content management tools) is a simple way to host unchanging information. This solution costs the least money. The trade-off is that the content takes some effort and savvy (e.g. knowledge of HTML, CSS and FTP) to set up and to change. Problems such as “dead links” (links that go nowhere) can be a real pain point for readers and for the site maintainer, especially if the structure of the site changes during its life. You won’t need to worry about the inner workings of this website, because there really won’t be any.

A more complex and powerful option is a hosted content management system (CMS), e.g. Tumblr, Blogger or WordPress. The most important difference from the first option is that this solution allows you to change things easily. These solutions usually have a “freemium” model, in which the basic offering has no cost, but extra options (such as using your own template or your own domain name) attract a modest fee. Such solutions are aimed to meet the needs of those whose website is a tool to raise awareness of their offering, rather than being the offering itself. Hosted systems usually include basic support to help you along the way, meaning that while you need a little bit of tech savvy, you don’t need to be a guru to manage it. The basics are easily learnt by anyone who can use the web, and the inner workings are taken care of by the people you’re paying.

A self-hosted system (e.g. a virtual private server (VPS) or dedicated server) is best for those with complex needs, or those who want to host a web app that they have developed themselves. This solution will give you all the complexity and all the power. But be aware that when things break, there’s nobody to help you. These solutions also have a higher financial cost than the other solutions mentioned here, as well as needing more time to monitor, maintain and support. If you’re going with this, you definitely want to be a geek, or at the very least have a geek on hand who owes you several large favours.

I hope that this is useful to you. If questions arise, please comment.

URL Shortening Sucks When Bandwidth Is Scarce

There’s plenty of people on various blogs telling us that URL shorteners like bit.ly or tinyurl break the web, because they create an arbitrary dependency on themselves. For example, if you hit a URL on the bit.ly domain and bit.ly is down, you’re out of luck. But not only do URL shorteners break the when they go down, they make it slower even when they are working as designed.

Here’s why: when you click on a link from bit.ly (or ow.ly, or ur1.ca, or arseh.at) your browser has to go and make a request to the server that runs the URL shortener before it can do anything else – before it can even think about loading what you actually want to see. So every short link you click is slower than the unshortened link would be.

And that’s just for starters. URL shorteners also mess up most of the fancy things that browsers – especially mobile browsers – do to make pages load faster. I’m talking about techniques like DNS prefetching and HTML prefetching and… well, mostly different kinds of prefetching. But they rely on knowing which URL you’re likely to look at next, and if someone has put a mask over the URL you’re heading to (say, by using a URL shortening service), those optimisations can’t do you any good.

“Sure, that’s fine,” you might well be thinking, “but why mention it now?” Well, sir or madam or neuter, I’m glad you asked. The reason I’ve embarked on this particular rant at this particular point in time is that mobile web usage is only going up. That goes double if you include the use of apps that link, like Twitter, Facebook, Google+ and all the rest. The mobile web is becoming so prevalent that it’s almost difficult to get a new mobile phone that doesn’thave a built-in browser. So ubiquitous, in fact, that I am starting to use it rather a lot. And, as a consequence, get mightily annoyed at how bloody slow it is.

We don’t need more things that slow the web down. Please keep those links long. Because let’s face it: it’s not like we’re doing anyone but Twitter any favours.

Where baby HTTP 404s come from

DISCLAIMER: I maintain the code that I refer to in this post, but I didn’t write the code.

I’ve been hunting HTTP 404 errors (that’s the “File Not Found” variety), and today I came across a bit of a puzzler. The non-existent image files were being referred to by a stylesheet as part of a CSS background: instruction, but the rule that contained the instruction was never invoked. That is, the rule was for a class name that was never used.

How the hell  was I getting these image requests if the code that started the requests was never being used?

Then I noticed that the errors were coming from just a few different user agents. And they all had something about them…

  • LG-GW305/V100 Obigo/WAP2.0 Profile/MIDP-2.1 Configuration/CLDC-1.1 UNTRUSTED/1.0 lg-gw305
  • Nokia2730c-1/2.0 (10.47) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokia2730c-1/UC Browser7.7.1.88/70/352
  • Nokia5130c-2/2.0 (07.95) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokia5130c-2/UC Browser7.6.1.82/70/352 UNTRUSTED/1.0
  • Nokia5330-1d/5.0 (06.85) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokia5330-1d
  • Nokia5530/UC Browser7.6.1.82/50/352
  • Nokia5800 XpressMusic/UC Browser7.7.1.88/50/352
  • NokiaC3-00/5.0 (04.45) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokiac3-00/UC Browser7.7.1.88/69/352 UNTRUSTED/1.0
  • NokiaC3-00/5.0 (04.45) Profile/MIDP-2.1 Configuration/CLDC-1.1 Opera/9.60 (J2ME/MIDP;Opera Mini/4.2.13337Mod.by.CHIZZY/503; U; en)Presto/2.2.0 UNTRUSTED/1.0
  • NokiaC3-00/5.0 (04.60) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokiac3-00 UNTRUSTED/1.0
  • NokiaC3-00/5.0 (07.20) Profile/MIDP-2.1 Configuration/CLDC-1.1 nokiac3-00 UNTRUSTED/1.0

See it? That’s right, they all come from mobile browsers. This puzzled me a bit, until I realised that it might be something you’d do to speed up the user experience if you knew they’d be on a slow connection (and you didn’t care if they downloaded heaps of data they didn’t need).

So here’s the piece of knowledge I want to add to the internet (he said, arrogantly assuming it wasn’t there already): Mobile browsers prefetch images from stylesheets as an optimisation in the face of low speed connections.

You’re welcome.

Follow

Get every new post delivered to your Inbox.