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!