• Setup is the first phase where test fixture is setup for the SUT (System under Test) to exhibit the expected behaviour as well as anything we need to put in place to be able to observe the actual outcome
• Interact with the SUT or exercise
• Verify / Determine if expected outcome is obtained
• Tear Down the test fixture

Implementation

Account.rb

class Account
  MIN_BALANCE = 100
  attr_reader :balance

  def initialize
    @balance = MIN_BALANCE
  end
end

account_test.rb

class Account_Test < Test::Unit::TestCase
  def test_there_should_be_minium_balance_when_account_is_created
    #setup
    @account = Account.new
    #exercise
    balance = @account.balance
    #verify
    assert_operator balance, :>, 0
  end

  def teardown
    @account = nil
  end
end

You can get more information about this topic here.

It’s been few sessions that I have started playing with document based storage technology, CouchDB which is *naturally* based on the REST philosophy. There is a really nice quote in CouchDB book site “Django may be built for the Web, but CouchDB is built of the Web”.

Everything was going fine until there was a command for creating database that utilizes HTTP PUT method:

$ curl -X PUT http://127.0.0.1:5984:/new_db

The response is: {"ok":true}

$ curl -X POST http://127.0.0.1:5984:/new_db

Response: {"error":"not_found", "reason": "missing"}

As usual I google on the web and was pretty happy to find that it was not only me who was confused about PUT versus POST debate

W3C has defined following functions of POST:

• Annotation of existing resources;
• Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
• Providing a block of data, such as the result of submitting a form, to a data-handling process;
• Extending a database through an append operation.

Let’s focus only on first function of POST for now. It clearly states that POST should be used for existing resources.

In my case, http://127.0.0.1:5984:/new_db has not existed yet so, using POST to create is against the specification.

But again trying to differentiate PUT and POST as: PUT for creating new resource and POST for updating existing one would be awful mistake. One can view PUT as a SQL insert operation. When a specified URI is defined, it will create resource there if the resource does not exist or replace the existing one.

But POST is quite flexible and can perform more operations as compared to PUT. POST sends data to the specified URI but how it will be processed is entirely dependent on the server. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

According to the HTTP 1.1 specification:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

Examples:

• PUT => http://mysocialapp/users/{username} => createUser
• PUT => http://mysocialapp/users/{username} => updateUser
• POST => http://mysocialapp/users/{username}/posts => createPost
• PUT => http://mysocialapp/users/{username}/posts/{post_id} => updatePost

The URI and client will be ultimately responsible for handling above requests URI. If we look at the POST example, there is no way one can map the URI for every posts being created so, POST is idempotent and non-cacheable. While first and second example shows that PUT can be used not only to create resource but also to update it. But this solely depends on who is responsible for creating the new resource’s URI: client or the server. If client is responsible, then it should response 201 (”created”) when new resource is created and when the resource URI already exists, it should use POST method. If the server is responsible, it should respond 401 (”unauthorized”). If I try to create same database “new_db” using:

$ curl -X POST http://127.0.0.1:5984:/new_db then CouchDB returns {"error": "database_already_exists", "reason":"Database "another_test_db" already exists"}

FWIW, PUT does not mean store.  I must have repeated that a million times in webdav and related lists.  HTTP defines the intended semantics of the communication — the expectations of each party. The protocol does not define how either side fulfills those expectations, and it makes damn sure it doesn’t prevent a server from having absolute authority over its own resources.  Also, resources are known to change over time, so if a server accepts an invalid Atom entry via PUT one second and then immediately thereafter decides to change it to a valid entry for later GETs, life is grand.

Some useful links + resources:

• http://www.w3.org/QA/2008/10/understanding-http-put.html
• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
• http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/
• http://www.infoq.com/articles/subbu-allamaraju-rest [Really nice article about REST- Recommended!]

Please do correct me if I am wrong

If we analyze the current events that have been taking place in this industry with the pre-mature phase of PC industry, we can find some similarities. The PC industry flourished with the introduction of GUI computers from Apple with the ability for 3rd party developers to write an application for. Prior to as well as after introduction of Apple OS, there were various vendors including Microsoft, IBM, DEC and so on offering similar services. But at last, as it normally happens in the information economy, only one emerged as the dominant force, it was Microsoft at that time. The success of Microsoft during PC battle was not just because of Microsoft Windows and/or DOS was superior to other available platforms, but Microsoft had and still have support of  wide array of hardware and software vendors. Apple and other vendors lost the PC war because of that particular reason.

Now lets come to current smart phone war. There are so many vendors offering or soon to be offering their own OS along with application platforms like Apple iPhone + AppStore, Google Android + MarketPlace, Palm Pre, Windows Mobile + Windows Marketplace, RIM + AppWorld, Nokia + Ovi and may be we will hear more in the near future. For now, as a developer it’s much easier to choose a smart phone platform to develop for (most in the US choose iPhone with Android trailing by long margin). Just imagine what will happen once all major vendors provide similar platforms after sometime. Which platform will you choose and what about interoperability? Certainly for large companies this won’t be a big issue as they have and they can afford to provide their applications for respective platforms. But what about those small developers and entrepreneurs and even for someone trying to get into mobile phone development? It will be just be crazy and/or practically impossible to offer certain services in all platforms.

I think we are going in somewhat wrong direction. With so much hype of iPhone and Android, along with other upcoming platforms especially Palm Pre, developers are forgetting about interoperability that the Internet and WWW have taught us and what Web 2.0 have delivered us. We are again going back to same PC era and writing applications for vendor specific platforms. Smart phone and as a whole mobile industry should focus providing their APIs respecting the concept of WWW. It’s true that browsers are available in almost all smart phones but which application will you choose when one is offered as a native one and while other being offered pointing to some URL like htpp://m.time.com or m.cnn.com and so on. In most of the cases, users will rightly choose former.

I am not saying platforms that enable developers to write vendor specific application is wrong but  one needs to fear that after sometime, it will be quite hard to offer applications for each and every platforms. But I am optimistic that one dominant player will emerge as victorious in the current smart phone battle and it will be the next Microsoft for PC and/or Google for Internet search.

My Bet: certainly not Apple even though iPhone + AppStore  provide the most superior platform for now

I think the video is a must watch if you a Ruby developer and/or want to jump to Ruby/Rails band wagon. There’s no doubt that Rails is one of the leading web frameworks that have embed the concept of test driven development at its core and Ruby developers have always been in the fore front adopting agile development strategies. But whenever I read some blog posts/articles and writings by Ruby enthusiasts and developers, I feel some kind of rebel and attitude of superiority in their expression which is somewhat same as mentioned in the keynote. Ironically, most of the Ruby syntax is also inspired from Smalltlk with small blend of C; that’s why Ruby is also called reincarnation of Smalltalk but lets hope Ruby won’t be next Smalltalk and as Microsoft new initiative Make Web Not War.

Cover via Amazon

Finally, I completed reading House of Cards - A Tale of Hubris and Wretched Excess on Wall Street by William D. Cohan I accept that I may not have enough background knowledge for understanding each and every terms mentioned in this book and even for writing book review but I am petty sure that now I have general knowing about the state of Wall Street and financial mess they have nurtured in the form of sub prime mortgages and other complicated financial instruments like derivatives (I swear I don’t know what the fuck is this).

Cohan is a former senior Wall Street investment banker, author of The Last Tycoons and as a whole a respected writer and/or journalist.  I am really impressed by the way this book is written. The sequence of the events and excitement of consequences produced by them is what let me to complete this book in such a short time interval.

The book describes about the whole life cycle (from the birth and impressive rise to the dramatic collapse) of once proud investment bank Bear Stearns that became the first major casualty of the global financial crisis or credit crunch and consequently triggering the global financial system in the edge of collapse. Bear Stearns was eventually acquired by JPMorgan Chase in the fire sale price for just $2, later adjusted to $10 after shareholder lawsuit (Just a month or so ago it was trading above $100).

Here are some of the major events / points from the book:

• Bear Stearns had had leverage ratio of nearly 40 times i.e. it was borrowing $40 by showing liquid asset of $1. Not only Bear Stearns, AIG (Always Investing Garbage Hmm..Did I write something wrong:) ), Lehman Brothers and most financial institutions and investment banks were leveraged in the same way.
• Confident is the name of the game in the Wall Street. Just couple of weeks before the collapse of Bear Stearns, it had $18 Billion cash in hand. But once news about its potential survival and toxic assets in its balance sheet began to leak, there was run for money by its clients and no one was ready to do business with Bear.
• Though Bear Stearns was a public company, its management and overall control was in the hand of few people namely Ace Greenberg, Jimmy Cayne and Alan D. Schwart. The failure of Bear was not only due to its business model but managerial missteps and personal rivalry about controlling the firm were also one of the causes.
• Its quite shocking to know that most of the investment banks rely on over night funding for their daily transactions.
• The rating agencies like Standard & Poor’s, Moody’s and Fitch Ratings are the bitch of Wall Street firms and also one of the major villains of this crisis.
• Ironically, the executives of the failed firms like Bear Stearns and Lehman brothers were highest paid. But overall, all Wall Street executives normally were make millions even after the crisis (Remember AIG bonus saga). Wall Street has always be known for its excessive pay and risky investments especially after the de-regulation initiated during Clinton Administration.

Certainly the above list do not fully capitalize what this book explains. I have to say, I never thought it would be so interesting to read a book about finance world. But I believe that every person in the world is being directly or indirectly affected by the current crisis should have at least rough idea about how crisis of such magnitude completely took the world by surprise. As currently I am living in New York, which being the home of Wall Street can be considered as the epicenter of the current mess and one of the most affected state so, getting to know about the financial crisis is always nice.

And I can conclude what I learn in just one statement:

Investment banking is an unregulated black magic that let you to believe you are making chunk of profit that is kinda NULL in reality.

But every time I write some code and after sometime, I personally feel that the code I wrote sometime ago is really awful and dirty. I have to admit that most of my personal projects that I did alone was kinda failure and/or bizarre and no doubt they have taught me lessons I will never ever forget in my life.

I reviewed the code I wrote just few months ago and I was able to extract so many mistakes and would be bugs that I wrote that code again. And may be after few months, I will do same again. But this cycle of writing bad code and after certain time getting to feel how erroneous me and my code does make me quite happy and I can make self comparison how am I improving as a programmer that does not just code but write clean and testable code . But I am really loving this vicious cycle of unsatisfactory code.

If you are new and kinda enthusiastic programmer then, I guess you have also experience similar and/or related cycle of dissatisfaction and are always searching to learn and implement something new. It would be really nice if you can share your experience too.

It’s about four simple rules by Kent Beck on simple design:

• Runs all the tests
• Contains no duplications
• Expresses the intent of the programmers
• Minimizes the number of classes and methods

I agree with al the three rules but the fourth one seems little difficult to follow especially if you are also following the Single Responsibility Principle. But since its is listed in the last, I assume it should be given less priority. What do you think?

Procedural code (code using data structures) makes it easy to add new features without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing features.

I think above single statement is more than enough if one wants to know the real difference between OO and procedural code. And again you gotta to have some OO experience in order to understand the depth of the statement.

So far, I have been satisfied with the book (completed around 10 chapters) and if you are interested in making your code clean (in the sense of usability and design), then I strongly recommend the book.

document.getElementsByTagName("input")[0].onkeypress = function(e)	{
	// If no event object exists, then grab the global (IE-only) one
	e = e || window.event;
	return e.keyCode != 13;		//Do nothing when Enter is pressed
}

Its just a simple tiny example but one can imagine the potential complexity that could arise in nowadays’ site with petty high use of JS.

I did know that custom event handling exist in Prototype but I believe in YAGNI and never realized its potential. But as I am working in a project with massive JS and Ajax use, finally I have seen and used how custom events can be used to invoke to control encapsulate built-in JS events and use them in quite a flexible way.

While searching on the web about thistopic I found some really nice articles.

• Creating Custom Events with JavaScript: Decoupling
• Publishing Custom Events in JavaScript

This last article has tried to explain normal and cusom events as:

When we describe normal events to our peers as a series of interactions, we generally say something like “For this tab menu, I want to swap the colors, then change the message on ‘click’ of the tab.”. Or if that sounds too awkward. We’ll say “When the user ‘clicks’ on the tab, I want to swap the colors and change the message.”

I can see it swindling in your brain already. Sure enough, the first thing that would normally come to a scripters mind is…. “I’ll assign a ‘click’ event to the tab that fires a function which will swap the colors, then change the message”. Fair enough. That totally works and that’s the way most people do it.

A custom event in this same model can be something you, yes you, get to make up. Looking at our tab/click/swapColor/changeMessage illustration, we can easily turn this into an event called onTabChange. In return, anytime our tab menu changes state, we can notify our listeners/subscribers that this event occured; then do whatever the heck we want on the fly.

Just following the above explanation, I have come with a simple example: A test scenario where a check box determines whether to enable or disable the onchange events for elements with CSS like .input. When the checkbox is enabled, particular onchange event for particular elements are also enabled and vice-versa.

Here is the HTML Code:

<fieldset>
	<legend>
		JS Custom Events
	</legend>
	<div>
		<input type="checkbox" value="1" id="enableInputEvents" />&nbsp;Enable events for text box and combo box<br/>
	</div>
	<div id="inputs_elements">
		Text Box 1:&nbsp;<input type="text" id="textbox1" value="" class="input" /><br/>
		Text Box 2:&nbsp;<input type="text" id="textbox2" value="" /><br/>
		Select Search Engine: <select id="search-engine-selector" class="input">
			<option value="">Go to</option>
			<option value="http://www.google.com">Google</option>
			<option value="http://www.yahoo.com">Yahoo!</option>
			<option value="http://www.live.com">Live</option>
		</select>
	</div>
</fieldset>

And JavaScript code for firing custom events:

Event.observe(document, 'dom:loaded', function()	{
	$('enableInputEvents').observe('click', function(e)	{
		document.fire('CheckBox:Enabled', {checked: $('enableInputEvents').checked});
	});
});

document.observe('CheckBox:Enabled', function(e)	{
	Event.stop(e);
	if (e.memo.checked)	{
		console.log("all elements with CSS class input are ENABLED");
		$$('.input').each(function(t)	{
			t.observe('change', function()	{
				alert(t.value);
			});
		});
	}
	else	{
		console.log("all elements with CSS class input are DISABLED");
		$$('.input').invoke('stopObserving');
	}
});

Custom event handling in Prototype is a bit different than other JS libraries. And CheckBox:Enabled is a special notation type for firing custom events. Prototype API call this notation as namespace:eventname o avoid custom event names conflicting with non-standard native DOM events such as mousewheel and DOMMouseScroll.

When the Checkbox is enabled

When the Checkbox is disabled

new Ajax.Request(url, {
	onSuccess: function(response)	{
		//do something
	}
	onException: function(response, exception)	{
		//do something
	}
	onFailure: function()	{
		//do something
	}
});

I have figured out that creating a method that can handle such call is certainly not so hard and in my opinion, it does provide some level of flexibility in the code.
Here is the same code:

function clickIt(options)	{
	this.message = "";
	this.afterClick = function()	{};

	for (var key in options) {
        this[key] = options[key];
    }

	this._execute = function()	{
		alert(this.message);
		this.afterClick();
	}

	this._execute();
}

The above method accepts a single object as an argument with two properties: message and afterClick and this._execute() is a kinda private method (JavaScript does not have an explicit access modifier). Now to call the above function:

Event.observe(window, 'load', function()	{
	$('iclick').observe('click', function(e)	{
		Event.stop(e);
		new clickIt({
			message: "This is some message",
			afterClick: function()	{
				if (confirm("Are you sure"))	{
					window.location.replace(this.href);
				}
			}
		});
	});
});

Since {} is regarded as object in JavaScript so one can use it to make a function/class more flexible and extensible. But since, users calling this class will have no knowledge what arguments are acceptable so, documentation plays crucial role (If you are creating an API then, the success and usability of that API heavily depends on the quality of documentation that acts as valid contract between interface and implementation code).