Home » 2011 » August

Archive for August, 2011

The Benefits Of RTFM(s)

6 commentsWritten on August 28th, 2011 by Davy Brion
Categories: Opinions

I've been unhappy with my hosting company for the past 2 years or so, but there was one thing that prevented me from moving somewhere else: I had no idea what i would have to do to get my site working on another host. I was using Dreamhost and they've always done everything for me. From the initial WordPress install on one of their shared servers, to the move to my first VPS, to the second, third, and fourth. They always took care of everything. And while i wanted to move, i always thought it would be a real pain in the ass to get everything working on a new host. That 'everything' is actually only Google Apps For Your Domain and Apache/PHP/MySQL/Wordpress.

This weekend i finally took the plunge. I signed up for a machine at Linode and first got started with my static company website, which is really just a placeholder at the moment until the nice-looking one is done. I knew that getting that up and running with Apache would be easy since it's just static content, but i also wanted to get URL redirection right. I have 2 domains for it: thatextramile.be and thatextramile.net. I wanted thatextramile.be to be the domain that hosts the website, and i wanted to make sure that all requests to www.thatextramile.be, www.thatextramile.net and thatextramile.net received a 301 redirect to thatextramile.be. The best way to do this is to use the mod_rewrite module of Apache, so i started reading its documentation and got that working pretty quickly. To do this, i also finally had to learn how to properly configure DNS records but that too turned out to be pretty easy.

After that i wanted to get a copy of my blog working on my new server, while still keeping DNS records pointed at the old one. So i started installing/configuring PHP and MySQL, imported a dump of my blog's MySQL Database and copied the WordPress installation from the old server to the new one. I modified my laptop's /etc/hosts file so it would resolve all requests to davybrion.com to the IP of my new server so i could properly test it. I wasted a bit of time here because of some file permissions, but once i noticed that everything just worked. And pretty fast too. I also made sure that all requests to www.davybrion.com were properly redirected to davybrion.com because Google tends to punish you in their rankings when they think you have 'duplicate content' and i don't want to reduce the traffic that Google sends my way.

At this point i was still waiting for Dreamhost to transfer the registration of my domain to DNSimple, which for whatever reason was taking a lot longer than the transfer of my thatextramile.net domain which was taken care of in just a few hours. While i was waiting i decided to compare the load times of requests to the blog on the new server with the time it took on the old server. I used YSlow and Google's Page Speed Chrome plugin for this. I was kinda hoping to get raw figures from those tools, but instead they both gave me a shitload of tips on how to improve the performance of the site. It certainly already felt faster than the previous server, but a big factor in that was probably the fact that the old server was located in California while the new one is located in the UK. But those tips got me to look into minification and combining of JavaScript and CSS files and putting it on a CDN with good future date expiration headers. That got me looking into the W3 Total Cache plugin for WordPress, in combination with using Amazon's CloudFront for static content. I haven't succeeded yet in getting every bit of JavaScript combined in one file because some plugins don't really play nice with the W3 Total Cache plugin, but in general most page-loads should cause far fewer HTTP requests and they should be dealt with more quickly than previously because of CloudFront.

So once all of that was working, i just wanted to 'turn the switch' and start using the new server for all requests, but the domain transfer still wasn't done. It then hit me that i could just change the DNS settings on the current registrar to point to the new server so i modified the A records for davybrion.com and www.davybrion.com to point to the IP of my new server. And that was all there was to it. Well, i also spent a bit of time in hardening the server but that didn't take long since i only have 2 publicly available services. Is it going to be totally secure? Of course not, but the number of ways to get in are limited enough.

So to recap: i did a lot of reading to understand what i needed to do, and i'm pretty happy with the results. I learned a lot of new things, finally moved everything to a new server that i have full control over, no longer have to deal with the shitty support from my previous host, and am paying the exact same monthly amount as i used to. Not to mention the not so unimportant part about the blog feeling a lot faster (though i'm not sure how fast it'll feel for non-european visitors). Sure, it could go down at any moment and it'll be up to me to fix it. At that point i'll read up on whatever i need to read up on and then just try to improve the situation.

The whole thing took me about 8 hours. Pretty sure it would've taken me longer if i hadn't taken my time on the reading parts because i would've spent more time troubleshooting the inevitable mistakes that i would've made.

Note: DNS changes are still propagating, so if you're reading this from a feed reader, the site may not work correctly yet for you. If you do happen to notice a problem, i'd appreciate it if you mailed me the details, preferably including the IP address that 'davybrion.com' resolves to on your machine and if possible, your local time + timezone info so i can look for matching elements in my logs

They Always Say The First Million Is The Hardest

11 commentsWritten on August 26th, 2011 by Davy Brion
Categories: About The Blog

To everyone who's been reading regularly: thanks!

Using Frameworks Doesn’t Mean You Don’t Have To Know What You’re Doing

11 commentsWritten on August 23rd, 2011 by Davy Brion
Categories: Opinions

I came across a good post yesterday titled "Are frameworks making developers dumb?". I wouldn't say frameworks make developers dumb, but i have noticed on way too many occasions that many developers don't really have a clue about what the frameworks they're using are actually doing. And it's not just within one specific developer community. I've seen it in the .NET, Java and Ruby camps and i'd expect it to be common in every single platform that becomes big enough to no longer be considered a niche.

People develop frameworks so other people don't have to deal with certain details all the time. People use frameworks so they can focus on what matters to what they're trying to do, without having to focus on lower-level stuff that's not really relevant to them. I mean, that sounds great, right? Just use the right framework to do what you want to do and you instantly become more productive! Even if you picked a good framework to use (and we all know there are plenty of bad/horrible ones to go around), you still need to know what the framework is doing. Abstraction purely for the sake of not having to know what's going on is hardly ever a good thing when it comes to software development. Does that mean you have to know every single detail? Of course not, but you should be aware of the things that might end up hurting you.

In software development, nothing is free and when something suddenly becomes easy due to a framework, you ought to figure out why it becomes easier and how that is achieved. If you get the answer to those 2 questions, you're much more likely to use the framework more responsibly instead of following blind faith or not caring about things that you simply can not just ignore. Like it or not, memory management matters. The cost of complex database operations (leaving in the middle whether you're using an RDBMS or a NoSQL solution) or the frequency of them matters. Bandwidth matters. Remote calls matter.

And there's a lot more to it than possible performance issues. Unwise usage of frameworks can also have a detrimental effect on the maintainability of your code. What might look like an improvement at first could very well lead to serious inflexibility and/or fragility in the long run.

Simply put: a lot of the things that frameworks try to hide under the carpet matter. Every benefit you get from them has a potential cost. If you want to keep enjoying those benefits, you better learn how to avoid the costs.

Advantages Of Being A Polyglot Programmer

37 commentsWritten on August 15th, 2011 by Davy Brion
Categories: Opinions

For the majority of my career, i considered myself a C# developer because that was pretty much the only language i used. I learned other languages when i was in school, but i wasn't using them anymore. If i wanted to code something, i'd do it in C# because that was the language i was most comfortable in. Then last year, i started learning Ruby. This year, it's JavaScript (both client-side and server-side). Next year, i'd like to learn a real functional language, most likely Haskell. I still do C# at work, but i no longer consider myself a C# developer. These days, i consider myself to be a polyglot programmer. I feel quite comfortable writing code in 3 languages, and am looking forward to add more languages to the mix over the next couple of years.

I used to think it was more interesting to focus on one platform/language and really strive to know it thoroughly, but i couldn't disagree more with that nowadays. I've noticed that there are quite a few advantages to learning new languages and exposing yourself to new communities, approaches and ideas. And i believe they far outweigh the benefits of sticking to just one platform/language. There are 5 advantages in particular that i'd like to discuss in more detail.

It expands your horizons

There's more to becoming productive with a new language than merely learning the syntax of the language. You're going to learn about new tricks, new libraries and new ways of solving problems that are common in the community of whatever it is that you're learning. You're basically trying to soak up knowledge that is common to others, but new to you. Depending on what you already know, there might be a lot of new stuff to learn or it might just be small tidbits here and there. If you already know a dynamic class-based language, learning another one might not expose you to a lot of new stuff. But if you're used to static class-based languages, learning a dynamic class-based language is going to be quite an interesting experience. Try to mix paradigms to get the most out of this. It'll start to influence the way you think about problems and how you can solve them.

It makes it easier to learn new things

Practice makes perfect, right? If you're routinely trying to learn new things, the very act of learning new things actually becomes easier. A lot of people have problems learning things that conflict or contradict with what they already know. The first time you learn a new language based on a paradigm that you don't quite understand yet, it might take a while to grasp it because you're likely having difficulties thinking about things outside of the structure and rules that you're used to. It'll be easier the second time, because you're already more comfortable with letting go of what you already know and not restricting the way you think about things or try to comprehend them. And it'll keep on getting easier and easier. This obviously applies to more than just programming languages.

It continuously refreshes your love of programming

This one probably depends from person to person, but when i was still just a C# developer i routinely got into stretches of time where i didn't really have fun writing code. During those stretches, writing code was just a job, and no longer something that i once considered a joy and a hobby. Those stretches could last a couple of weeks, sometimes even a month or two. Since i started learning more languages, i haven't really hit a stretch like that anymore. It remains fun, interesting and challenging because you just keep on learning new things and you keep on improving continuously.

It decreases your reliance on certain tools and introduces you to new ones

2 years ago, i couldn't imagine writing code without a strong IDE to back me up. I was so dependent on Visual Studio's (and Resharper's) Intellisense, code completion, code navigation and strong debugging features that i just couldn't believe i could be as productive without those things. Nowadays, i really just prefer to code in a strong text-editor (TextMate was my favorite, but i recently switched to Sublime Text 2) with a terminal window to run my tests. I avoid debuggers by working in small steps, with small, focused tests which also make it (relatively) easy to isolate bugs and fix them. I actually don't mind 'poor man's debugging' (putting log statements in certain parts of your code to find out where things go wrong) anymore because i'm starting to think it can often be quicker than relying on your IDE's debugger. I recently even joked that they call it poor man's debugging because it's used by people who can't afford to waste time waiting for an IDE and its debugger . Another benefit is that you'll have to get comfortable with the command line and perhaps even different operating systems. If you want to get into Ruby or Node, you're better off installing a Linux distro (or run on OS X if you happen to have a Mac) and experiment with the language/platform on that instead of trying to get things working on Windows. Getting comfortable with a *NIX shell and its tools is something that you're probably going to be able to use for a long time to come so there's no reason to shy away from it.

It makes you less emotionally attached to a language/platform

People who only work with one language/platform often have an emotional attachment to it. If you're emotionally attached, it's not always easy to remain rational during discussions or when the future of your language/platform is being threatened. If you know more than one language/platform, you know that your skills are transferable. You know that you can be a good developer no matter what you have to work with. You know that you really don't have anything to fear about how things will evolve. You just know that you can deal with it. Easily even.

Solving A Problem By Avoiding It

8 commentsWritten on August 15th, 2011 by Davy Brion
Categories: JavaScript, node.js

I spent a little time this weekend working on something that would be of use to me: a simple utility on Node.js that calls JSLint on all JavaScript files within a given path (including its subdirectories), and only produces output if errors are found. It was pretty easy to write, and you can find it here in case you're interested.

There was one problem i ran into though. On Node, all I/O calls are non-blocking. Well, there are synchronous versions of some calls available, but you should use them as little as possible because they block the Node event-loop. One of the things i needed to do was to scan a given path recursively to find all JavaScript files in that path. And i just couldn't get it working the way i wanted to. The best i could do was a function that would invoke the callback once for every folder that was found. But i really wanted one that would only invoke the callback once, once the entire tree had been searched. I actually spent a few hours trying to get it working, and even looked for some good solutions in other projects. Most solutions i found also invoked the callback multiple times, others resorted to partially synchronous implementations. For a command-line tool like this, synchronous calls aren't a big deal but i'm trying to get better at typical Node programming, so i'm trying to avoid synchronous I/O.

So i tried yet another variation on my implementation, and it too didn't work properly. I got frustrated and said to myself "how hard can this be? i just want a list of files like 'find' would give me". Then it hit me that i could completely avoid the problem by just doing this:

var exec = require('child_process').exec;

function getJsFilesRecursively(startPath, callback) {
    exec('find ' + startPath, function(err, stdout) {
        var jsFiles = [];
        stdout.split('\n').forEach(function(f) {
            if (!/node_modules\//.test(f) && /.js$/.test(f)) {
                jsFiles.push(f);
            };
        });

        callback(null, jsFiles);
    });
};

No blocking I/O on the Node event-loop, and it took about 2 minutes to write. The only downside that it has is that it's not cross-platform because it uses the 'find' command which every *NIX-based system has, but Windows doesn't. So it will fail if you run it on Windows but for now, it'll do just fine and at least it enabled me to move on to the other stuff i needed to implement to get to the goal i initially set out for this tool.

Of course, by now i'm completely obsessed with nailing the recursive asynchronous folder-walking function so i will replace this with a proper version once i finally figure it out.

« Older Entries