Why is having more than one responsibility bad?

I had written about SRP in this post. In that post, I had given an example of Customer class which has multiple responsibilities. Now what is bad with a class having multiple responsibilities?

When a class has more than one responsibility, they become coupled. Coupling leads to problems such as when there is some change in one responsibility it affects the other responsibilities in unexpected ways. Now someone might ask what is wrong with that? The problem here is that, you are intentionally changing code for one responsibility and there is an unintentional effect on the code for some other responsibility. Whenever you modify code there are chances that bugs will creep in and hence your changes should be such that they only affect the responsibility you want to modify/extend. The lesser code you touch, lesser are the chances of you introducing a bug.

What is Visual Studio LightSwitch?

Considering that Visual Studio LightSwitch (referred to as just LightSwitch) beta1 was released in August last year,  I am a bit late to catch on. So, this post is going to be on what LightSwitch is and how to get started with development of  LightSwitch apps?

What is LightSwitch?

It is a version of Visual Studio, which allows you to develop LightSwith applications using LightSwitch project templates in VS IDE.

So, with LightSwitch installed you can develop a host of business applications without writing a lot of code.

What does that mean?

In a typical small sized business application, your user will perform CRUD operations. To achieve this you need a UI. On the UI you want to display data, validate user input, allow drill-down of data,  facilitate search, sort and filter data, export data to excel and finally save modified data. To allow these operations, you want to connect to a datastore – a database or a service. Now, providing these features requires writing a lot of code over and over again. You need to design screens, write code to validate inputs and write a data access layer. That is a lot of code. With LightSwitch, you just need to write code for your custom business logic and rest of the application development is taken care of by LightSwitch. So, with LightSwitch the only part of application you write is something that is very specific to your business.  There are a lot of applications which are candidates for app development using LightSwitch. In a typical small shop instead of using office to maintain your business, you can use LightSwitch apps.

The default UI for LightSwitch apps have a ribbon like interface giving them a look similar to office applications. The default styling of the application can be changed. You can use different screen templates like a search screen, a navigation screen , an editable screen, etc..

LightSwitch apps are by default Silverlight-OOB application. You can also host these in a browser.

Getting Started

• Go ahead and download the beta 1
• Visit the LightSwitch development center
• LightSwitch team blog
• Beth Messi’s LightSwitch posts
• LightSwitch tutorial
• Ask questions on the LightSwitch forums
• LightSwitch on MSDN
• LightSwitch questions on StackOverflow
• A beginners tutorial on LightSwitch

Dilbert - Cloud Computing

Observations:

• Another buzz word which is seducing PHBs. Look how excited PHB is.
• Dogbert who gets paid for his gibberish.

Debugging a control at design time in Expression Blend

If on opening a user control or custom control in Expression Blend, you get an error which isn’t easy to decipher, chances are that at design time some code is getting executed which is throwing an exception. The quickest way to find the error is to open the same solution in Blend and Visual Studio. Then, in Visual Studio go to Debug>Attach To Process and select Blend.

Now, try opening the control in Blend. The point where the exception is being thrown will be hit in Visual Studio and you will realize what is going wrong.

Steve Yegge and his essays

Steve Yegge

One of my resolutions this year is to write more of original posts than just posting some link. Seven days have passed and I have just written one. And in this post too, I am going to do the same. But, you are not going to be disappointed.

I stumbled on to this voluminous work of Steve Yegge. I have read two of his random posts and I am more than impressed. The two I have read are not really blog posts, but more of essays. They teach you something. They drive a point honestly. They motivate you. They keep you engaged. They are more of a conversation with you. And most of all, they provoke you to think.  I am very disappointed that I didn’t know about Steve Yegge and his work till now. Hopefully, by end of 2011 I will be a better programmer by reading all his blog entries.

Two essays : Practicing Programming and You should write blogs

A carpenter practices on different kinds of wood, with different kind of tools. So, does a musician, who  practices day in and day out. Both, these craftsmen want to constantly improve their craft. But, why do we programmers never practice? We learn a programming language/technology and never think that we need to keep sharpening our tools. Do some of us even considers us as craftsmen? Do we think that programming is a craft? This is a very long essay on the same topic – Practicing Programming.

In another of Steve’s essay – You should write blogs, he says,

Kurt Vonnegut Jr., one of my all-time favorite authors, says that to be successful in writing, you should pick one person and write just for that person. Forget for the moment that other people will be reading what you write, and just write as if you're talking to that one person. It seems like good advice to me.

I like to write. But, writing is something that doesn’t come naturally to me. And I intend to follow the above advice.

Professionals vs Laborer - another organization same conversation

I believe in the philosophy that 90% of conversations that take place at an IT shop have already taken place at some other IT shop. Okay, I made up the previous statement to start this post.
Yesterday, at a meeting we digressed to have a conversation on whether we all are laborers. With tongue in cheek, I then emailed this article to all those who thought that they were laborers.