Most of my day is spent staring at the blinking cursor of my text editor. This is true for many people nowadays as most office work happens on the computer, but for programmers – the very same individuals whose creativeness are the building blocks for software – can’t seem to find a workflow that feels right. As a developer I find myself getting frustrated every time that I have to reach across my desk for a mouse, switch to a separate application to look up some documentation, or drop into a terminal window for some quick bash kung-fu. I am a firm believer of using the proper tool for the job, but I have been writing code for over ten years now and have yet to find something that fits the purpose.
Most web and application developers that I know are using proficient in many text editors. The editor that they are using is either a result of the product that they are working on, or past experience using a particular piece of technology (extension, script, plugin, etc) that makes the daily grind a little better. I rarely find a developer who doesn’t have a problem with some facet of the text editor that they are using, and many of which feel that they are stuck for one reason or another with a particular editor because of the feature set it offers.
One thing that seems to be a common theme among these editors is that they sit somewhere between a simple text editor, providing only basic functionality of text formatting, and a full-blown suite of tools which is offered by enterprise packages such as Microsoft’s Visual Studio which costs thousands of dollars and only works on the Windows platform. Each has its specific use case, and I would never suggest creating a Visual Studio project file to edit a README file using the Markdown syntax, but every time that I have the opportunity to use Visual Studio I always walk away feeling let down the next time I drop into Emacs.
A key feature that I think is necessary in a development environment is the ability for the software package to support live documentation. This means that I want to be able pull up a quick blurb about a particular API call that I am about to make, either be it in a standard library that ships with the language of my choice, or the application project that I am working on. The discoverability of documentation needs to be in depth, but not something which clutters my code window.
The editor software needs to be able to be extended on a per project basis. There are often cases where a particular set of tools is necessary for one web project, let’s say something like CodeIgniter which uses the Sparks package management system, and another application that is written with Ruby on Rails and using the RubyGems system for extensions. And it is not merely easy just to say that all PHP applications will use the mode for PHP, and all the Rails projects will use the mode for Ruby, because often there is a frontend component which shares context between the two and is written in a language such as JavaScript (or more recently, Clojure).
Testing each project now becomes an absolute pain in the ass. I may need to manage the version of Ruby that I am running, or perhaps bounce the Apache instances so that my new configuration is picked up, or even worse the web application needs to be executed from a browser, I need to tail a log file, and pray that the browser debugging software is updated. That’s way too many context switches.
I believe that there can be a much better way of handling the day to day workflow of software development. There is a simple solution to this problem that seems to have been overlooked with fancy editors designed to be visually pleasing on the Mac. What do you think your ideal development environment would be? All developers hate writing documentation, but it is the first that we reach for when we want to understand how to work with a library or call a standard API. We cry out aloud when our text editor doesn’t index the code that I am writing and provide autocomplete. And we bitch when extending the editor becomes a chore which sometimes rivals the problems we’re trying to solve.
There is a better way to handle this.
When I started doing some serious programming about ten years ago this new buzzword started to get passed around. When I was browsing the isles at Barnes and Noble every other new-age programming book would pop up describing how a service oriented architecture would be the future of software development. How it would bridge the gaps between platform dependent code and allow us to use cheap hardware when necessary to serve enterprise clients (and other services). It promised a more modular approach to programming, encapsulating functionality in a bundled executable called a “service” which had a schema that it responded to, but it via XML, SOAP or some other protocol.
Whenever I dream up a project I tend to use it as a driver for learning a new software library or language. When reading first about the service oriented architecture paradigm the Java programming stack was usually the king of the hill when it came to discussions. Even today, after Oracle purchased Sun and basically started to put nails in the proverbial Java coffin, it still reminds a leader in enterprise service oriented design. I am a C/C++ programming, self taught and currently by trade, but I would be a fool to ignore the advantages that this platform offered. So as any good project manager I read up a lot on Java (at the time) and learned as much as I could about SOA practices.
A few years ago I started attending college for the computer science discipline and Java was the primary language that was being taught everywhere. Although, until some of my later entrepreneurial projects, I heard not a word about SOA practices in any of my programming or software engineering courses. A few years ago the topic of the “Cloud” became all the rage; people were making money off writing books, companies such as Microsoft (and even Sun) were working on Cloud projects to help developers and Amazon started selling specialized hosting geared towards metered bandwidth, CPU and memory usage. I began asking myself: what is different about software in the Cloud?
Well, the truth is, software that is written to be able to take advantage of all the regularly toted features of the Cloud such as being able to elastically adjust your application’s presence on demand, is just the service oriented architecture approach of designing software taken to the limit. The actual truth of the matter is that any piece of software that is designed to be fully “cloud compliant” is most likely some kind of service, be it a web application using the HTTP protocol or a Glassfish Java application stack using XML or SOAP as communication protocol. When designed properly a service oriented platform stack should be able to scale horizontally much more efficiently than it does vertically.
What the is the difference between scaling out vertically and horizontally? When an application scales out vertically this means adding more memory, CPU power, hard-drive space, etc, to an existing system that is servicing clients. Scaling out vertically is merely adding additional computing nodes. This means everything to a distributed architecture; as soon as the node touches the grid it should be servicing clients. But as I said earlier in this essay the idea of SOA practices have existed long before the marketing engine of Salesforce and Amazon have trademarked the word cloud.
The principle of the cloud is the ability to scale out vertically on demand. If your application is about to get hit by a swarm of geeks from Slashdot any normal application running on cheap Linux metal in a data center would likely cripple under the additional CPU, bandwidth and memory requirements put in place by this surge of new clients. An application that is able to be scaled out can elastically grow and shrink on demand, servicing the needs of its client base at any single point in time.
But what does that mean for business? You only pay a metered rate for bandwidth and CPU cycles on the amount that you’re using at any given point in time. Your traffic at 2AM in the morning on a Thursday likely is not anywhere near the traffic that you have at peak Internet browsing hours. Why should you be paying those massive hosting fees when you’re really only using your hardware to the limit about three to four hours a day?
This is the principle behind “the cloud,” and if you couple this with a logical service oriented application design (see: distributed) your business will much more agile and cost effective in both the peak and downtime hours.
I have arrived at one of the bullet points for Type Aloud where I must implement the ability for one user to follow another user, similar to being a friend on Facebook or exactly the same as becoming a follower on Twitter. But I came to a dilemma that needed to be solved: What if someone only wanted to follow one particular story from an author?
The first thing that came to mind (and ultimately stuck) was to have two different type of subscription models – the first would allow you to physically subscribe to a story and be notified when a new chapter was posted by said author. This subscription would keep track of reading point on a particular chapter as well as what chapter was the last one that you read. This may seem very trivial for web browser users but when you plan on handling Amazon Kindle traffic this becomes very important. The second subscription model would be a “Fan” and this is where you want to hear absolutely everything from the author – if they decide to post a new story, you hear about it, or if they decide to write a poem, the same deal.
When thinking through this I was trying to take into consideration user interaction. How would the button placement work for these two particular types of subscriptions? If someone wanted to cease being notified from said author, how exactly would that work? And finally, if someone subscribes to another author’s story and then becomes a fan what happens if they eventually cease the fanship – do we maintain the original state of subscription?
I would be interested what you all have to think.
My buddy, and fellow NJIT graduate, noble prize laureat, open source developer, Kenny Katzgrau wrote up a great post on How To Get A Job As A Programmer.
Anyone that may be interested in computer science as a major in college (or if you are already sitting in classes) that thinks they want to be a programmer may want to go read his little tidbit. If you’re in college to become a programmer I am personally of the opinion that you’ve already missed your calling. Switch majors immediately. You should love this craft before you decide to make it a career.
I have finally begun my five-years-in-a-making web project and I decided to throw a simple countdown splash screen to give myself a little motivation to get it finished. Something that has always ticked me off about the Internet is the fact that despite all the standardization that we attempt to put forth with the W3C, Acid, and the HTML 5 movement it is still fucking impossible to pick a decent font that you can guarantee will be on (most) platforms. As a programmer, I absolutely loathe web design, in fact that is usually the barrier to entry for most of my web projects – I can not figure out the damn design – but through trial and error I generally am able to produce something which is at least a little pleasurable to look at.
This brings me to the topic at hand. The Google Font API (and the Google Font Directory) was announced at the Google I/O conference and detailed in this Google code blog post. What Google has basically done is created a repository that makes fonts freely available to web designers (and programmers) with a simple HTML stylesheet include. Before I even finished their blog post I was immediately cursing Microsoft because Internet Explorer 6 is usually the reason why technologies such as this do not get adopted quicker, but I was amazed even more, Internet Explorer 6.0 and up are supported!
As you can see on typealoud.com it is really as simple as these two lines of HTML/CSS.
<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Reenie+Beanie"> <style> h1 { font-family:'Reenie Beanie', serif; } </style> <h1>123 days until launch.</h1>
Go take a look at Google’s blog post on the matter and start using the Font API in your own projects. Happy coding!