Personally, 2008 has been quite productive for me in the sense that I did couple of projects in MVC (using CodeIgniter) and was able to go through the basic of LINQ as my intern project was based on ASP.NET + LINQ + SQL Server (the project is still incomplete and a bit buggy as well). It was 2008 that I wrote my first unit tests and since then I have been learning and trying to follow TDD approach. And yes I have not forgot Obama got elected the same year and finally I passed my under-graduation in Information Management (though still not received my final transcript).

But 2008 was kinda nightmare for most parts of the world. Shrinking stock market, booming unemployment, near collapse of Wall Street and global financial system (financial power house like Merrill Lynch, Lehman Brothers, AIG, WaMu, Citi Group are gone or being bailed out by the US government), terrorist attack in Mumbai and overall the whole world experience slow down and recession with financial crisis as never seen the great depression of 1930′s.

My short list of resolutions for 2009

• Design Patterns, IoC, MVC
• Test Driven Development
• Developing REST based application(s)
• Ruby and/or Iron Ruby (But I am not so sure I will get enough time to learn and implement Ruby)
• Maintaining the current momentum of blogging + tweeting
• Getting Zend Certification

And here are few wish lists for 2009

• Get involved in some kind of open source project
• Want to see end of this financial crisis (very low possibility though)
• Want to see some permanent and effective solution of energy crisis in Nepal (feels like I am wishing too much)

I guess my list of new year resolutions are kinda achievable but I can’t do anything about my wish lists because it’s human nature always having desire to get extra and in fact impossible stuffs

So, folks wish me best of luck!

Finally, Happy New Year 2K9 to all!

Few days ago, I read a post (the post is a bit old) about the the design concept of fat model, skinny controller. After going through that post and this one, for few days I have been thinking and trying to analyze the implementation impact of the concept. I guess I have been petty much impressed after doing some research on the web and going through blogs of experts in this subject.

It won’t be wrong if MVC is called the de-facto pattern of developing web applications. But still, the implementation mechanism of MVC and understanding the overall logic of MVC can be different from developer to developer.
MVC, being mostly implemented in the presentation layer provide powerful mechanism to developers to reuse code (reusing could have been easy if there were only one language or platform to deal with but while developing web applications developers need to deal with many languages and technologies that may or may not integrate well with each other) and significantly apply the concept of object oriented principles and agile methodologies.
Most of the developers and their code I have encountered especially in the PHP seem to embrace the idea of putting business logic in the controller rather than in the model. They regard model as the way only to deal with CRUD operations. It is true that MVC frameworks like Cake and Symphony provide quite powerful ORM capabilities without the need of writing a single SQL query embedding the principles popularized by Rails i.e. convention over configuration, DRY and YAGNI.
But in my opinion, models should not be treated as the the component for dealing with CRUD operations. Model should be responsible for more than that. It’s also true that applying business logic only through models is almost kinda impossible. It’s something like coupling which needs to be reduced but can’t be eliminated completely.
I view controllers as a tunnel that should be responsible for accepting input from the view and passing to the model and accepting raw output from the model and passing it to the view. Making the controller petty fat could make the code difficult to re-use. In reality all these things are easier to say but making the best use of the MVC by making model responsible for most of the business logic and let controllers and views perform their native task can be quite difficult because of the complex nature of the web. Complexity in the sense that there are other languages and technologies as well in the same layer that needs to be integrated and be dealt with. For eg; Server side Flash / SilverLight components, JavaScripts and so on.
So I have been trying for few days to apply the concept of fat model and skinny controller and as expected facing some difficulties especially to make my model more responsible and controller more light or in other word more skinny. Since I was involved in that project from middle so, attaching the business logic only to the model seems quite impossible. So, I am looking forward to do some small project in MVC applying the concept of Fat Model and Skinny Controller.
Until then, I can not claim that this concept must be followed though I still believe this concept should be followed to write re-usable and loosely coupled code.
As usual it would be great if you provide comments and criticisms and I can also know if I am wrong or right.

Make modifier methods return the host object so that multiple modifiers can be invoked in a single expression. – Martin Fowler [article]

In simple terms method chaining is the way of calling a sequence of class methods where each object returns the same host object for further modification. This approach is more used by JAVA and .NET developers (as I have seen). After having a quick look at various PHP frameworks like Zend, CodeIgniter and Cake, it seems like they do support method chaining and I really love to use method chaining when possible. Enabling method chaining is quite similar in PHP as it is in C# and JAVA. By the use of $this, method chaining can be enabled for any class.

<?php
	class HardDrive
	{
		private $_capacity;
		private $_isExternal;
		private $_speed;

		//Getters and setters for _capacity
		function getCapacity()	{
			return $this->_capacity;
		}

		function setCapacity($capacity)	{
			$this->_capacity = $capacity;
			return $this;
		}

		//Getters and Setters  for _isExternal
		function getIsExternal()	{
			return $this->_isExternal;
		}

		function setIsExternal($isExternal)	{
			$this->_isExternal = $isExternal;
			return $this;
		}

		//Gettter and setter for speed
		function getSpeed()	{
			return $this->_speed;
		}

		function setSpeed($speed)	{
			$this->_speed = $speed;
			return $this;
		}
	}
?>

Using Method Chaining for above Class

<?php
	$hardDrive = new HardDrive();
	$hardDrive
		->setCapacity(200)
		->setIsExternal(false)
		->setSpeed(7200);
?>

…or using traditional way

<?php
	$hardDrive = new HardDrive();
	$hardDrive->setCapacity(200);
	$hardDrive->setIsExternal(false);
	$hardDrive->setSpeed(7200);
?>

I have seen people who really hates method chaining and also seen people that use this approach a lot. And luckily or unluckily I am also kinda supporter of method chaining. So, if you are like me I hope you want to enable method chaining in your class as well and as you saw it’s very very simple.

And finally, some considerations you need to know. I don’t think method chaining is possible in PHP 4 (but who cares about PHP 4, coz it’s kinda RIP ). The biggest problem with PHP method chaining I have felt is that IDE like Eclipse really don’t provide auto-complete feature

Can anybody please explain what is this?

In my previous post, I had posted a link about the interview with the design patterns guru Erich Gamma. After reading that article, I came to know about the concept of public and published method in a component, class or interface.

“Something can be public but that does not mean you have published it.” – Martin Fowler

For past few days, I have been trying to justify this statement. In the process, I did google the term, but I was unable to find any interesting post until I found the white paper written by Martin Fowler himself (I am damn lucky ). The white paper and two answers I got in the stackoverflow about my question regarding public and published concept has helped me a lot to understand and difference between these almost identical terms.

The scenario of public and published arises especially in the distributed environment when one has to publish his/her code in the form of API to other developers. Once the method or interface or class is published, changing it later will certainly break other’s code.

In JAVA and .NET, with release of new version number of methods, class or interface are treated as deprecated. Changing the behavior of those legacy modules means breaking the code being dependent on them. So, attributes like deprecated are used to inform the clients or service caller to updated their code. APIs are not defined by their source rather by contracts usually in the form of documentation or with the use of refactoring tools and sometimes with the help of reverse engineering with the use of Reflection (System.Reflection in .NET)

Here are the list of advices given by Fowler on publishing interfaces:

• Don’t treat interfaces as published unless they are
• Don’t publish interfaces inside a team (this one related to code ownership)
• Publish as little as you can as late as you can
• Try to make your changes additions

My Implementation

Lets suppose, Boeing‘s Dreamliner uses engine made by Rolls Royce (in reality it does use). For efficient use, there must be a contract between Boeing which call and invoke APIs and services and Rolls Royce which is responsible for designing the contract.

In this scenario, Rolls Royce’s services invoked by Boeing should be according to the contract and the interfaces provided within that contract are all published.

If the contract provides only one interface i.e. IRollsRoyceEngine as published and while other interface as public but not published then, Rolls Royce should be responsible for the change in the IRollsRoyceEngine interface only not IRollsRoyceEngineAnalyzer.

Boeing can of course use IRollsRoyceEngineAnalyzer but Roll Royce is not bind to inform the change in the interface if it happen in the future.

Conclusion

Differentiating published and public interface while designing the contract and API can be encouraging thing to do in the context that change will happen and it is inevitable and it’s just the matter of time. Updating an interface should not break the legacy interface.

Hmm…quite easy to say but certainly not so easy to implement in real projects. Now I am really eager to implement the concept of published and public interfaces and see what it is truly worth of!