Thanks to the awesome CTO and Senior Python Programmer at fotoglif.com where I worked previously, Linux has become much more then a novelty in my tool set. While working there, I made the decision that I would go forth and adopt Ubuntu as my exclusive desktop of choice in all new projects simply because of how practical and customizable the operating system is.

Since then I have picked up more then a few new tricks, and have converted 3 (that I know of) below average windows users into fully functional members of the Linux community.

Now lets get down to the features that make Linux a much more flexible desktop for solving an ever changing number of work related issues, and red tape.

1) Workspace. Better Workspace.

Upon arriving at my new job, I was less then stoked to see that every person in the place had a second LCD monitor except for me. Desktop space can be a real pain in the ass for a UI programmer because of the constant refreshing required to see changes in the browser. Albeit I am a master of the alt tab, and have been known to ninja kick my way through a few builds this way, it’s less then a good way to avoid carpel tunnel. So the answer is simple in this case. Multiple desktops, which as you can see, can be easily integrated into the compiz window manager to make a pretty awesome cubic 3 dimensional desktop experience. From the following video, you’ll be able to see the reason why I no longer care if I have a second monitor. I’m too busy flipping from desktop to desktop:

2) Software. Free Software.

This is a pretty good reason no matter what the situation is, however almost anyone who has worked in a larger company can tell you about the headache that its normally required to interface with the IT department so that you can get a piece of software that will assist you in your task. Well with Linux, the answer is as simple as sudo apt-get install software-package or if you can’t find it, build it. The later being a motto that I have adopted more and more recently.

3) Security and piece of mind

I’ve worked at a few places where management is more then aggressive about banning and prohibiting any sort of IM, or un-work-related surfing activities. This often spawns rumors of packet sniffing, and other things that are less then desirable to me. The answer to this is simply an SSH tunnel. Very simply any Linux machine can be tunneled using the following ssh command:

ssh -D port username@hostname.com

Once this is done, you can then use System -> Preference Network Proxy to point your connection to localhost:port using a SOCKS proxy.

I normally refrain from setting the proxy at this level however because it is fairly global. Instead I set the proxy in each application (mail, im, firefox) independently, allowing for better customization. For Firefox this is particularly important if you are running a localhost development environment. I suggest you use Foxy Proxy to configure patterns for host names that use the proxy and host names that do not. Now that you are tunneling through your favourite remote server, you have the piece of mind knowing that your web traffic is not open to prying eyes.

And there you have it. These are the 3 main reasons why I have decided to exlcusively use Linux/Ubuntu for any work related project. It should be kept in mind that these reasons are much more particular to Linux in a whole then Ubuntu itself, which is simply my perferred flavor of Linux. Also, there are many other great reasons, such as cron jobs, lynx, raggle and plain CLI that make Linux perfect as a work desktop, so I’d be happy to hear why you do you don’t perfer Linux.

Since I joined Blast Radius I have been introduced to a lot of new and interesting development practices, frameworks and designs that I have always read or heard about, but was never really forced or motivated to imply in my daily progression. One such framework I wrote briefly about is Mojo. Being a framework that has evolved from the Dojo Toolkit my interest peaked this morning when I read a very interesting article on Ajaxian about cross domain transport.

Originally as more of a low level technologist who only picked up ajax and interface development as a smooth view state for communicating with my middle tier controllers I found Javascript to be very much lacking the web services department. Very often the techniques that have been traditionally used consist of one of two strategies for x-domain communication;

1- A remote javascript include is served using:
This is usually a server side script that generates the file contents based on the parameters, and then either renders content locally into your DOM, or provides you with a set of methods that will allow you to manipulate the content. This is not a very secure model and does not allow you to interact with raw xml data very robustly, but as long as you trust the source that is rending the content, it is quite efficient.

2- By matter of Proxy.
This method I’ve used very often for direct communication with XML, SOAP, or REST gateways. Generally, I will develop the interface layer to communicate with a server side controller which will then use Curl to invoke the remote data, process and return as an JSON object. I find this method to be very robust, and allows you to create a very extensible gateway for your Javascript cross domain requests.

With that said, the post I read this morning is indicating that a new methodology for cross-domain scripting is emerging in the Dojo framework. By way of the property window.name one can make a remote request and retrieve data without exploiting the ever so wonderful cross domain security model that we are subject to in all our favorite browsers. This concept is very new but interesting. It opens up a whole new world of client side mash-up possibilities that are sure to get the creative juices flowing in the client side development space. Here is an example of it would be implemented: