Microsoft is making a big change in its .NET suites of technologies. The Visual studio development environment will experience additional functionalities that will make life a sweet one for all of us. An application server code named "Dublin" will be introduced to compliment IIS (Internet Information Service) . WF and WCF will experience another quantum changes, and we will all be happy.
The .NET framework is not left behind, as we will see more API changes like : dynamic (supports for COM interop and dynamic languages), Named parameters, default parameters, BigIntegers, covariance and contra variance of generic list : as IList string will now be equals to IList object , also Code contracts.
Democratizing Software Development Life Cycle
There is now a big quantum leap from programming focused development environment to software life cycle development environment.
In an Agile driven development environment, the key practices there is collaboration, software developers needs to collaborate with architects, testers, project managers and database administrators. This collaborative means ensures that products are delivered on time and risks are noted on time. The collaboration amongst team of professionals already in an agile environment leveraging the .NET platform will be a plus when the new Visual Studio 2010 finally ships.
Use case, activity, architectural diagrams are other integrated features of Rosairo, developers, architects will enjoy new ways of architectural designs because all of this forms parts of the new change in VS 2010.
Ever thought about using test data to validate the efficacy of software solution. There is an added test tool that will ensure a proper scenario based documentation which is useful to application testers.
Black box testing recorder will be integrated into the Visual studio 2010, where testers can interrogate the call stack and record debug sessions for replay later. This gives the developers to watch the replay of the black box when a bug is found.
Let us fold our arms and experience the new changes to the developers number ones platform. Derio to Microsoft, Visual Studio Bomayee!!!
Sunday, March 29, 2009
Tuesday, March 24, 2009
Time for BDD (Behavioural Driven Development)
A deep thought over why software project really fails or was built without actual concentration on the business cases will lead to the fact that the actual requirement was not being captured well, no feasibility study of any kind was taken to check the efficacy of the business case. We understand that Business Analyst, Quality Assurance and of course developers need a collaborative efforts to building software. Do we as developer really test first before writing the code. The test first approach makes for understandability of business requirements from coding and it makes us concentrate on what our requirements really are.
How YAGNI (You Aren't Gonna Need It) can help developers
YAGNI can help us to focus on our development needs, it will allow us to focus on the business/technical cases and reduces large complicated code referred to as code bloat. You really aint gonna need that sophisticated features if its just not helping the software requirements at the moment. I know we developers likes to write the best standardize code that meets with the current practices in our industry, that's cool but are we conscious of the time spent on the sophistication, do we put in mind that business requirements comes first before satisfying our hunger for fine grained development practices.
BDD complements TDD
The current methodologies in software houses is the Agile Methodology, whether it is being practiced in a full fledged manner or it is being tailored against your organization requirements, Agile methodologies favors incremental development over classic water fall approach. Agile methodology was referred to as cowboy coding because of its minimal planning approach, but it has proven to be successful in today's deliverable focused environments.
Agile methodologies encourages Test driven Development which in turn allows us as a programmer/developer/architect to focus more on testability of our code. At a point during the writing of large and complex systems, we loose our confidence in our code if we do not have an automated testing framework that gives us the confidence and boost our moral.
That said and done what is BDD?
Have you ever written a complex system with several many business scenarios. The reasons why systems fails is that we do not fully test all different scenarios that the system can find it self. An agile test driven developer should understand that testing scenarios goes beyond your test and mock passed, but its that your code/system meets the full capabilities and conform to clients needs.
It promotes common domain language between what the business analysts, quality assurance and the developers understand. Developers can save the technical detail when interacting with none technical people. This will enable everyone speaking the same language and everyone having common understand of the business case and where we are at.
A simple non BDD interactions
Business Manager : I want the new software to support staff tracking
Systems Analyst : It will results to us obtaining a tracking GPRS systems and API built around it.
Developers : We need to use a wrapper or/and abstraction, that will be make us not tight with third party tools. Yes it seems there is already a bluethoot API in the corner.
Business Manager : The goal of the system is to allow us know the time which the staff logs onto the systems, the idle time of the keyboard, and internet usage.
Systems Analyst : Ok i see, the provide us with your initial thougths and we can write a behavioural code that will clearify your thoughts.
The interaction above is just an example our understandibility is a neccessity in software development. You will not blame us developers for having a higher level mindsets its our job but we need to understand the business case, in other words we have to interrogate our code and simulate the business cases to get the clearer picture.
Note even the business managers do not know what they fully want, but the BDD will document and give a clearer picture of what the system should do.
Hence we need a user story
Recently i migrated a very complex business scenarios from code into WWF (Windows Workflow Foundation) . This would not have been possible if i do not know the user story. Although, i have to admit that i delt with a document which does not clearly structure the requirements in other of user stories or scenarios, all the same i picked up my own pen, and i wrote an interesting user stories from such document. Here is a simple example :
As a user of the online banking system
I want to loging with with my secure credentials
Then check my account details to see my balance record.
With This scenario, => check my account details
Given , the logging page is active and ready to take my details
And, suplying my real encrypted password
And, my real user name
when, i log in my details
Then, i was redirected to a new bank customer account page
And, I checked my account details.
If systems developers can write out a story out of the big and large software requirements documents, then the remaining code will be less painless because you would not be coding and asking about the story because you already know that the story line is happily ever after.
Watch out for when i display my experience with various BDD frameworks like Nbehave, Dan Norths Blog site, at http://dannorth.net/whats-in-a-story.
How YAGNI (You Aren't Gonna Need It) can help developers
YAGNI can help us to focus on our development needs, it will allow us to focus on the business/technical cases and reduces large complicated code referred to as code bloat. You really aint gonna need that sophisticated features if its just not helping the software requirements at the moment. I know we developers likes to write the best standardize code that meets with the current practices in our industry, that's cool but are we conscious of the time spent on the sophistication, do we put in mind that business requirements comes first before satisfying our hunger for fine grained development practices.
BDD complements TDD
The current methodologies in software houses is the Agile Methodology, whether it is being practiced in a full fledged manner or it is being tailored against your organization requirements, Agile methodologies favors incremental development over classic water fall approach. Agile methodology was referred to as cowboy coding because of its minimal planning approach, but it has proven to be successful in today's deliverable focused environments.
Agile methodologies encourages Test driven Development which in turn allows us as a programmer/developer/architect to focus more on testability of our code. At a point during the writing of large and complex systems, we loose our confidence in our code if we do not have an automated testing framework that gives us the confidence and boost our moral.
That said and done what is BDD?
Have you ever written a complex system with several many business scenarios. The reasons why systems fails is that we do not fully test all different scenarios that the system can find it self. An agile test driven developer should understand that testing scenarios goes beyond your test and mock passed, but its that your code/system meets the full capabilities and conform to clients needs.
It promotes common domain language between what the business analysts, quality assurance and the developers understand. Developers can save the technical detail when interacting with none technical people. This will enable everyone speaking the same language and everyone having common understand of the business case and where we are at.
A simple non BDD interactions
Business Manager : I want the new software to support staff tracking
Systems Analyst : It will results to us obtaining a tracking GPRS systems and API built around it.
Developers : We need to use a wrapper or/and abstraction, that will be make us not tight with third party tools. Yes it seems there is already a bluethoot API in the corner.
Business Manager : The goal of the system is to allow us know the time which the staff logs onto the systems, the idle time of the keyboard, and internet usage.
Systems Analyst : Ok i see, the provide us with your initial thougths and we can write a behavioural code that will clearify your thoughts.
The interaction above is just an example our understandibility is a neccessity in software development. You will not blame us developers for having a higher level mindsets its our job but we need to understand the business case, in other words we have to interrogate our code and simulate the business cases to get the clearer picture.
Note even the business managers do not know what they fully want, but the BDD will document and give a clearer picture of what the system should do.
Hence we need a user story
Recently i migrated a very complex business scenarios from code into WWF (Windows Workflow Foundation) . This would not have been possible if i do not know the user story. Although, i have to admit that i delt with a document which does not clearly structure the requirements in other of user stories or scenarios, all the same i picked up my own pen, and i wrote an interesting user stories from such document. Here is a simple example :
As a user of the online banking system
I want to loging with with my secure credentials
Then check my account details to see my balance record.
With This scenario, => check my account details
Given , the logging page is active and ready to take my details
And, suplying my real encrypted password
And, my real user name
when, i log in my details
Then, i was redirected to a new bank customer account page
And, I checked my account details.
If systems developers can write out a story out of the big and large software requirements documents, then the remaining code will be less painless because you would not be coding and asking about the story because you already know that the story line is happily ever after.
Watch out for when i display my experience with various BDD frameworks like Nbehave, Dan Norths Blog site, at http://dannorth.net/whats-in-a-story.
Friday, March 20, 2009
Simple dependency Injector class
It is apparent in todays application development that complexity starts from when we typed the first line of code. Code complexity is one of the code horrors mutilating todays application development. To ensure that we work around these developments show stoppers, many design patterns and software development standards have been built to help come over this poor development approach.
Today we develop software with components in mind, we develop so that we can easily decouple our systems and make it a pluggable system.
Systems are very difficult to decouple when we do not use a strategic and standardized ways of separating component concerns. Over the years, the development and Object Oriented community have realized that there was a need to separate application concerns because of changing business cases and requirements.
As a software developer i have made it a culture to think of software as several functional modules that are independent from one and other but dependent on one and other via a plugable means.
The following code shows an example of code coupling :
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
Person person = new Person();
There is nothing wrong with the code above really for a simple application. But for a very complex application, we tend to tight couple the Person class with the calling application. Let us assume the person class was imported from a web service proxy, that means our application is relying on the web service proxy for the Person Implementation. What then happens when we are not interested in web service proxy again but in another .dll that has its own Person implementation but with some extra fields and properties, do we start to refactor our code to comply with the new Person class? I bet that is not the easiest way ever.
Let us assume that person class now implements an interface IPerson. The following code depicts the kind of defination :
interface IPerson
{
string FirstName { get; set; }
string LastName { get; set; }
}
public class Person : IPerson
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
Hmm, now that person have implemented an interface IPerson, then we could refer to IPerson all over our code, this is fairly decoupled until the very point where we really initialised the Person class, like the following :
IPerson person = new Person();
person.FirstName = "Ahmed";
person.LastName = "Salako";
now although we ahve succesfully initialised the Person class and because it implements the IPerson interface, we can assign it to the IPerson interface. Our code is still exposed to the point where we did new Person.
A simple Dependency Injector class
The following class will serve as a repository that knows about dependencies of our application :
public static class ModelFactory
{
private static IDictionary <Type, Type> repos = new Dictionary <Type, Type>();
static ModelFactory()
{
repos.Add(typeof(IPerson), typeof(Person));
}
public static T CreateInstance < T>()
{
Type value = repos[typeof(T)] as Type;
return (T)Activator.CreateInstance(value);
}
public static T AsInterface < T>(Type type)
{
Type value = repos.Where(t => t.Value == type).FirstOrDefault().Key;
return (T)Activator.CreateInstance(value);
}
}
So with the class above, we have successfully created a dependency repository class that knows about an interface and its implementations. Here is how to use the simple dependency repository class :
IPerson person = ModelFactory.CreateInstance < IPerson>();
person.FirstName = "Ahmed";
person.LastName = "Salako";
This leaves us very happy and with code decoupling.
Today we develop software with components in mind, we develop so that we can easily decouple our systems and make it a pluggable system.
Systems are very difficult to decouple when we do not use a strategic and standardized ways of separating component concerns. Over the years, the development and Object Oriented community have realized that there was a need to separate application concerns because of changing business cases and requirements.
As a software developer i have made it a culture to think of software as several functional modules that are independent from one and other but dependent on one and other via a plugable means.
The following code shows an example of code coupling :
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
Person person = new Person();
There is nothing wrong with the code above really for a simple application. But for a very complex application, we tend to tight couple the Person class with the calling application. Let us assume the person class was imported from a web service proxy, that means our application is relying on the web service proxy for the Person Implementation. What then happens when we are not interested in web service proxy again but in another .dll that has its own Person implementation but with some extra fields and properties, do we start to refactor our code to comply with the new Person class? I bet that is not the easiest way ever.
Let us assume that person class now implements an interface IPerson. The following code depicts the kind of defination :
interface IPerson
{
string FirstName { get; set; }
string LastName { get; set; }
}
public class Person : IPerson
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
Hmm, now that person have implemented an interface IPerson, then we could refer to IPerson all over our code, this is fairly decoupled until the very point where we really initialised the Person class, like the following :
IPerson person = new Person();
person.FirstName = "Ahmed";
person.LastName = "Salako";
now although we ahve succesfully initialised the Person class and because it implements the IPerson interface, we can assign it to the IPerson interface. Our code is still exposed to the point where we did new Person.
A simple Dependency Injector class
The following class will serve as a repository that knows about dependencies of our application :
public static class ModelFactory
{
private static IDictionary <Type, Type> repos = new Dictionary <Type, Type>();
static ModelFactory()
{
repos.Add(typeof(IPerson), typeof(Person));
}
public static T CreateInstance < T>()
{
Type value = repos[typeof(T)] as Type;
return (T)Activator.CreateInstance(value);
}
public static T AsInterface < T>(Type type)
{
Type value = repos.Where(t => t.Value == type).FirstOrDefault().Key;
return (T)Activator.CreateInstance(value);
}
}
So with the class above, we have successfully created a dependency repository class that knows about an interface and its implementations. Here is how to use the simple dependency repository class :
IPerson person = ModelFactory.CreateInstance < IPerson>();
person.FirstName = "Ahmed";
person.LastName = "Salako";
This leaves us very happy and with code decoupling.
Subscribe to:
Posts (Atom)