Go Quicksort
Around when the Google programming langauge Go came out I caught wind of it and decided to try it out a little bit. I never ended up doing much with it, though I found it interesting, but thought it’s OOP model was too different for me to use. But one of the first things I did do was write a concurrent Quicksort using their concurrency natives, goroutines. I was astonished at how easy it was considering how much more difficult it is (and how much more code it takes) in C++. The performance also blew me away. Recently I’ve been getting interested in Go again, and decided to revisit my old quicksort implementation, which I still had archived on an old hard drive. I made some adjustments and came up with this:
Using the Go Sandbox I was astonished to find that this both compiled and then ran and sorted an array of 10,000 random integers in less than 2 seconds. I wouldn’t be able to get the same results in any other language (except Erlang, if I knew it better).
When I first started playing with Go a couple of years ago I was still deeply a C++ and Python programmer, and was so set in my Class-based OOP ways. Since then I’ve become something of a JavaScript Junkie and have opened up to different methods of Object Oriented Programming. Coming back to Go I find it not as frustratingly different and confusing as before. Instead I’m finding it to be an extremely satisfying way to write efficient systems. I’ve started on a simple load balancer for one of my current projects using Go, and it is surprisingly easy.
I think Go is definitely the C/C++ of the future. It keeps the safe, fast feel of C and C++, while being more modern and easier to use, and not nearly as fickle. Anyone with any experience in C-like languages or even scripting languages like Python should find Go easy to learn. They even have a tool on their home page for you to try Go without installing it, I’d encourage trying it out.
Hello, HostGator!
So this week I started training for my new job a HostGator! I’m pretty excited about it; although I won’t be doing any web development, but I will be working web servers by giving customers support. So far I like everyone I’ve met there, and it seems to be a pretty laid back place to work.
I’ll be working as a Junior Systems Administrator (Solving basic hosting issues and other questions customers and potential customers may have), and intend on working my way up to a Systems Administrator.
Naturally I won’t be doing nearly as much freelance web development, but I do intend to keep doing it on the site, although I’m mostly going to stick to ongoing, long term projects. And, of course, I’ll still be working on my various open-source project, though at a slower pace.
Speed Is Not As Important As You Think It Is
The JavaScript landscape has been changing, especially the past few years. Just like when AJAX made web developers rethink what could be done with the platform, the wave of new, fast JIT-compiled JavaScript engines has us rethinking performance. Even IE is getting on board the performance train!
For the most part, this is a good thing. However, there seems to be a lot of attention to hyper-optimizing JavaScript applications, to the point of excess. More and more I’m seeing efforts to fine tune small details – expanding simple code and making it complex – all in the name of performance, without stopping to think if they should. There’s a lot of time wasted on saving milliseconds (if even that) of execution time because unit tests reward their efforts. A unit test may show that Code A is 50% slower than Code B, but when Code A only takes a few milliseconds in the first place it’s usually irrelevant, especially when Joe User likely won’t notice or appreciate it.
JavaScript programmers (and programmers in general) need to learn that they should only optimize when forced to do so, and instead focus on writing elegant, readable, and – most importantly – maintainable code. And if it happens to be a very efficient way of doing it then great! But adding code complexity in the interest of efficiency should only be done when performance is genuinely hurting the user experience. In most cases you honestly shouldn’t need to do any optimization after the fact, as long as you follow standard practice and think your problems through before writing sloppy code.
If you do need to make adjustments to improve application latency, however, then I do have one tip: ignore the little details. It’s in fact very likely that you can go back and fine tune many places in your application where you can change a few lines and cut the execution time of that particular action in half. But that’s not where your focus should be. You should be focusing on the problem areas in question, what performance profiling tools are made to do. Figure out where most of your slowdown is: it probably isn’t in some function that gets calculated once or twice, instead it will almost always be in commonly used functions and objects or other major segments of the application architecture. In fact, it’s much more likely that the way you structured the application is the speed crutch, rather than tiny details.
I fear this obsession with micro-managing performance will drive us all insane, especially when a minor speed enhancement in one browser can mean significant performance loss in another. These things really should be left to the engine architects like Google and Mozilla, not the JavaScript developers. JavaScript programmers should pave the way towards beautiful solutions, not highly optimized ones.
NodeJS as a PHP Frontend
I had a conversation the other day with a friend of mine who is a PHP programmer about the possibility of using JavaScript (specifically, Node) as a routing front end for PHP. Recalling that Node has an API for child processes, I looked into it.
It turns out, this is extremely easy:
var http = require('http'),
spawn = require('child_process').spawn;
http.createServer(function (req, res) {
var php = spawn('php', ['foobar.php']);
php.stdout.on('data', function (data) {
res.writeHead(200, {'Content-Type' : 'text/html'});
res.end(data);
});
php.stderr.on('data', function (data) {
res.writeHead(500, {'Content-Type' : 'text/plain'});
res.end(data);
});
}).listen(8080, '127.0.0.1');
If you wanted to do URL routing, you could use a library like Express:
var express = require('express'),
spawn = require('child_process').spawn;
function route(file) {
return function (req, res) {
var php = spawn('php', [file]);
php.stdout.on('data', function (data) {
res.writeHead(200, {'Content-Type' : 'text/html'});
res.end(data);
});
php.stderr.on('data', function (data) {
res.writeHead(500, {'Content-Type' : 'text/plain'});
res.end(data);
});
};
}
var app = express.createServer();
app.get('/', route('index.php'));
app.get('/users/', route('users.php'));
app.listen(8080);
Not only can this let you use Node’s speed and the strengths of JavaScript to route URL’s for PHP, but it can be used with any language (for example, instead of running the PHP interpreter, you could run the Python interpreter). Node can easily prove itself as a routing front end for web applications, and is very well suited to create customized load balancers.
I’m toying around with a pair of libraries to spawn PHP processes from Node, using a JSON document as arguments to the PHP application, and a PHP library to handle incoming arguments. Ultimately, however, this is so trivial that it can be implemented easily by anyone.
Of course, there are drawbacks. While this would be a much more efficient and flexible method of URL routing for PHP applications, the memory usage would be intense. Many times that of a PHP application running in Apache or another traditional web server. While I haven’t looked into enough, it’s likely that this could prove to be a bottleneck that would prevent a method like this from scaling for large applications without a complex, multi-server, load-balanced server infrastructure. Although, Node lends itself rather well to that!
Nevertheless, this is an interesting experiment, it’ll be fun to see what comes of it.