Dealing with code can be a pretty taxing business simply because you are constantly focused on the job at hand and you are likely to face long hours at the screen doing nothing but work. However, you need to know when to tell yourself to relax and start enjoying being at the screen in between periods of work.
If you get some spare time at your screen then you might want to start getting involved in online bingo. There are a lot of different online bingo sites out there and their main aim is to help you have fun while giving you a hope of winning some excellent cash prizes.
If you play Cheeky Bingo, for instance, you could put yourself in with a shout of winning jackpots every single day just by signing up. The site offers free games with cash prizes as well as games that you have to pay to enter, but which offer more lucrative prizes.
Take your mind off some of that troublesome and complicated code by enjoying the entertainment you can tap into online. For a better idea of the kind of promotions that appear on some of the best bingo sites online, have a look at ohmybingo.com.
As a long-time Windows user, there was always something which confused me when it came to learning my trade on Linux based systems – the sheer amount of choice in apps on offer to fulfill a single task. Which leads me on to the next thing – the nigh-on-religious wars which have erupted around these apps.
Case in point: text editors. When I first went to edit a file in a pure Linux text console, I thought I would try out vi. When I found my head spinning after just a few minutes of trying to edit one line of a config file, I gave up and tried emacs. When I got overwhelmed by the sheer amount of stuff bolted into the text editor, I thought that I would go for the Linux text mode equivalent of Notepad, nano. I edited the file and moved onto the next thing I had to do.
But it really got me thinking. There is always a place for an alternative application in a given area – vi and emacs both do the same thing (edit plain text) but offer 2 very different ways of doing this, and both are highly configurable and so on and so forth. But what this doesn’t explain is the vitriolic debate which springs up around the users of each.
You don’t see this on other platforms – Windows users typically have to put up with Notepad until they discover something like Notepad++ and OS X users have Textmate (which seems to be very popular on that platform). However, you don’t get the users of UltraEdit insulting the entire families of those who use Notepad++. You don’t get arguments which have raged for 20+ years. In short, its all a bit more civilized.
So I get to my point – out of all these text editors on Linux, which one do you use and why? Functionality? The way the app looks? The price (or lack of it)?
Google Code has turned the grand old age of 5 today, having been launched on the 17th March 2005. I’d like to say well done!
While some people may think Google Code is yet another SourceForge clone, they’re only half right. What Google Code brought to the table was more than just project hosting, it was a whole ethos of development which is now sweeping the world as if it were a brand new concept: open source.
With the Summer of Code schemes run by Google to promote open source development in universities, hosting of all of their own APIs on the service (going from a handful to a few dozen by now), along with the code for all their open source projects (now numbering in the hundreds), Google Code has shown off the more ethical side of the advertising giant.
So happy birthday Google Code, long may you prosper and others follow in your path!
“Parallel loading” is what I like to call the feature of all modern web browsers – to request multiple files at the same time. For instance, when you load this web page the first thing to be grabbed is the raw HTML file. The HTML file then links over to a variety of files such as CSS files, JavaScript code and images used in the design. In the old days, a browser would have pretty much lined each one of these up and waited until one had finished before requesting the next. Not now though!
No, modern browsers are better behaved. They tend to begin requesting CSS files before the HTML file has finished loading, grabbing images left, right and centre and a whole lot more. Sounds great, doesn’t it ? Well, kinda.
One big pitfall of this is that you could be dealing with a lot of overhead from the raw HTTP requests in themselves. They are composed of data too, and take resources to manage (both client- and server-side). If you have dozens of images on one page, a CSS file or two and maybe a few JavaScript files, this can quickly bring a server to it’s knees with heavy traffic.
Lots of techniques exist to optimise your page load experience which are beyond the scope of this quick post. However, I would recommend reading up on the following:
- CSS sprites
You may well have heard of these – a CSS sprite just means putting multiple images into one image file and using background positioning tricks to display each individual image. The benefit is great here since you make less HTTP requests and your file sizes will drop (less image header info).
- Compiling multiple CSS and JavaScript files into one file
This is pretty simple. Just whack all your JavaScript into one file (if possible) and the same with your CSS. This is more difficult to implement if you have a defined build and deployment system, but well worth trying.
- Reduce the keep-alive on your HTTP server
If you are serving lots of files, try to reduce the keep-alive timeout of HTTP connections. Keeping a connection alive for 15 seconds after it was opened may sound like it would reduce overhead (less connections need to be opened) but just thing of how a few dozen connections sitting around idle will sap your server resources. Better to kill ‘em early!
- Don’t serve content from domains with cookie data
Every time you make a request to a file on a web server which has cookie data associated with it, that cookie data gets sent in the request too. Chances are you don’t need to know if the user was logged in just to retrieve your site’s logo, so try running was is known as a “CDN” – Content Delivery Network. Google it and see!
- Utilise caching well
Caching is awesome. Well, if you don’t mess up. Try setting far-future expires times (such as 1st Jan 2038) on unchanging content such as CSS files, JavaScript files and images. The browser won’t even make the request in the first place, then! If you do need to change one of these pieces of content, a simple trick can avoid the cache not updating: append a query string to the URL. So for http://www.example.com/cssfile.css, change it to http://www.example.com/cssfile.css?v=1. When you update it, update the links to it to say http://www.example.com/cssfile.css?v=2 – that way the caching will not interfere.
That should be enough to be going on with!
In case you missed the news, a few months ago Facebook announced on their developer blog that they were releasing a piece of software to the wider community. That piece of software is called ‘HipHop’ and is one of the many technologies Facebook run behind the scenes to keep one of the world’s most popular sites up and running.
But what does it do? In short, HipHop translates PHP code into C++ code, which can then be compiled into native machine code. This, in theory, should remove a bottleneck or two from PHP itself – namely the interpreter – as a good deal of slow, interpreted code can be compiled into uber-fast native code. Well, in theory.
While there is a performance increase (just Google for benchmarks, there are bound to be dozens by now) I think that it simply does not justify the end for most PHP driven sites. The added complexity of ensuring all your PHP code can be understood by HipHop would be enough to drive me mad, in particular. Adding to that is the number of issues I have seen people encountering whilst trying to compile HipHop on anything other than Facebook’s own platform of choice… Not pretty.
It isn’t just that though. I believe the only real increase in performance is in processing-limited scenarios which just aren’t that common in real life. Sure, Facebook need it, but they serve hundreds of millions of pageviews each day. For Joe Bloggs’ e-commerce store the benefit of having slightly faster C++ code would quickly evaporate when it came to any code changes needing to be first done in PHP, passed through HipHop before being compiled and then debugged for a second time as C++ code.
Stability isn’t really an issue due to the above reason (it has apparently been powering Facebook for a while) and apparently HipHop supports ‘most’ PHP code, but I really do not think you should consider it for your next project. Well, unless you’re re-coding MySpace…
Recent Comments