- Support for Windows Phone and Windows Phone Silverlight
- Support for Complex Parameters and IEnumerable for GET/POST Requests
Recently I have started working on a Nuget Package for providing a is a sleek and simple Wrapper library for providing simple access to Rest API, by hiding away the complexities of HTTPClient Class.Named EcSolvo.RestHelper it is particularly designed to work along with Xamarin PCL Projects
You can follow and contribute to the Nuget in Github : Link to GitHub Repository
Follow updates on Nuget : Link To Nuget
I am pretty new to GitHub platform and one of the first mistakes I did earlier on was to commit (unknowingly) the Debug Folders and all its binaries. It was later on i found ways to add ‘gitignore’ files, but no matter what i did, the debug files continued to be reflected in the change list.
The solution was though easy one, I had to run the following command to clear the Git Cache, and then stage-commit again. That cleans up all the mess.
git rm -r . --cached
The Open / Closed Principle focuses on one basic requirement, the classes should be Open for extensions, but closed for modification.
The better way to explain the principle would be to first express the issue in hand. Consider the below class.
The class itself looks good, but what if in future one needs to add another Shape, say Circle. This would raise need to modify our existing class which is violation of OCP.
The solution to problem lies in achieving extension by deriving from abstraction. Let’s rewrite the code.
As you can see in the above implementation, we have created an abstract class with the function we might require extension. The corresponding classes, Square and Circle, implement this abstract class and extend its functionality. So when the requirements changes, and you need to extend, you needn’t change the existing classes. This means the classes which are properly tested needn’t be touched again and thereby reduce chances of introducing bugs in existing classes.
While OOPs is rich with features like inheritance, polymorphism, encapsulation and overloading enabling developers to extract more from modern day programming languages like C#, it is equally important to understand when to use these features based on design principles.
SOLID, is a set of 5 principles which when properly applied intend to guide a programmer to make systems that is scalable and maintainable with ease.
The first of SOLID Principles, (S) – Single Responsibility Principle (SRP) demands that a class should have only a single responsibility and that responsibility should be fully encapsulated by that a class.
Consider the following class. The class is intended to Book Movie Tickets.
If you observe the class, the method BookTicket is divided into two parts. First, it books the tickets and then it notify the User about the same. That is, the class has two responsibilities – Book Tickets and Notify User, in other words, there are two reasons for which the class can be changed.
Suppose few years later, the company decides to change the notification mechanism and include SMS support as well. This would mean our MovieTicket Class needs to be altered for a reason (user notification), which has nothing to do with the core functionality of the class (booking ticket).
This is violation of SRP and the obvious solution would be to separate the responsibilities to separate classes.
This ensures that each class has only one responsibility and there would be only reason to change it.
Agile and Scrum has been ruling the Software Development industry for quite a time now, at same time, slowly, but surely, Kanban is finding itself a strong foothold in the industry. So what is Kanban and how is it different from Scrum ?
Much like Scrum, Kanban is a tool for process improvement that provides you rules and constrains to effectively improve your process in the long run. Agile Methods such as Scrum and Kanban tend to be more adaptive (less rules to follow) than being prescriptive (more rules to follow). Relatively, Kanban is more adaptive than Scrum.
One of the key requirement of using any Process Tool is to ensure you adhere to the constraints associated with the tool. Tools such as Scrum are minimalistic enough and if you were attempting to compromise on features such as Time-bound iterations and Daily Stand-ups, then it is better not to use the tool at all. These are the features/constrains which directly or indirectly makes the tool efficient.
Quite often, teams across the world end up adopting one Process Tool and adding features of others to it, while retaining the constraints of the original.
My attempt in this post would be to compare some of these constrains and it’s implementation in both Scrum and Kanban.
1. Prescribed Roles
Scrum prescribes 3 basic roles –
a) Product Owner – Responsible for setting priorities of tasks in the Product backlog
b) Team – Responsible for implementation
c) Scrum Master – Responsible for removing impediments and provide process leadership.
Kanban, on other hand doesn’t subscribe any roles. Teams can however, adopt roles, but only if they see any value to it.
2. Time Bound Iterations
Scrum roots for time-bound iterations with each sprint comprising of 3 basic phases – Planning, Implementation and Retrospective.
Planning Phase – During this phase, the forthcoming iteration is planned. Teams pulls out specific number of tasks from the product backlog based on the priority set by the product owner.
Implementation – Having defined the scope of iteration in the previous stage, the team gets cracking on the tasks in hand.
Retrospective – Team provides a demo of the work products of the sprint to the relevant stake-holders. The Product owner may choose to ship the work product to the business client. They also discusses the pros and cons of the concluded sprint and seek ways to improve.
Kanban, on other hand, doesn’t evolve around time bound iterations. The team choses its own feedback loop on when to plan, improve process and release. For example, Team could decide to release a work product every Tuesday or could very well say, we would release it only when we have something useful.
Scrum also focuses on having Daily Stand-up meetings where in, team would come together and provide an update of the tasks they are working on ( What they did previous day, What they intend to do on the day ).
Getting a feel that Kanban is more or less Ad-hoc ? Don’t worry, things are about to change.
Work Flow Task Items
Let’s have a look at the work flow of Scrum and Kanban through the representation of Progress Board – Called Scrum Board in Scrum and Kanban Board in Kanban.
The first impression on both board would give you is “they are exactly the same !!”. Well, Almost !! The difference is the number in the braces near the TODO and BUSY headers in the Kanban Board.
Scrum uses Velocity to measure the efficiency of sprint. It controls the WIP (Work in Progress) using a time based model by limiting the number of items in each sprint based on the velocity agreed by the team. On other hand, Kanban chooses to limit the WIP by limiting the number of items in each work flow state. In the example board shown, the maximum task items that can be in the busy state is 3.
Kanban uses “lead time” as a metrics for measuring and improving efficiency of the system. Lead Time is the average time taken for a task to move across the kanban board. For the purpose, teams using Kanban, tends to break down tasks to similar sizes. The feedback loop would help team in identifying and improving the lead time.
While estimation is not a forte required in Kanban System, “Lead Time” can be an efficient resource to depend on if the team is asked to estimate. Scrum uses a more formal method, called Planning Poker, for estimation.
Changes during Iterations
Scrum resists changes to spring log once team has committed to a sprint, even if the Product Owner holds a task of high value. Once the iteration has started, the only thing Product Owner can do is change the priority of the task and ensure it gets listed in the next sprint.
Since Kanban isn’t based on time bound iteration, it allows Product Owner or Customer to change the priorities at any time. The limitation comes in the form of WIP limit in the TODO list. The customer would have to take one item down to add another.
Other noticeable features which differentiate Scrum and Kanban includes Scrum’s emphasis on cross-functional teams, though one doesn’t always find it a developer testing. But the idea is, if at any time, testing becomes a bottle-neck, the developer should be able to lend a hand. This isn’t the case with Kanban, which doesn’t lay emphasis on team composition. The teams could be cross-functional or specialists for the jobs.
Another significant difference between the two tools is the way the task board is handled. Scrum resets the board after every sprint. After every sprint, all the task items are removed from the scrum board and fresh items are added to the extreme left column. Kanban, on other hand is an on-going process and doesn’t bother to reset the board at any point of time.
As one can notice, there isn’t much of the difference between Scrum and Kanban tools, though Kanban is slightly more adaptive than Scrum. It is more suitable to teams where the task priority could change frequently allowing the team to respond to customer requests within minimum time. With minimum constrains imposed, Kanban tends to become ad-hoc if not properly maintained. Scrum, on other hand, is more suitable for teams where Customer could commit to a sprint. A sudden change in priority could derail the entire sprint or would require the customer to wait for the sprint to complete. Both process tools has its own pros/cons and it is up to the teams to implement the basic rules to ensure the purpose of tool is served.
Both Scrum and Kanban is empirical in the sense, both expect the team to experiment with the process and customize it. If the scrum team has to experiment with velocity and sprint duration, the kanban team has to experiment with lead time and WIP Limits. Both tools provides the teams with the basic rules to govern the process and expects the team to improve their development process using continuous and empirical process optimization.
(1) Case Study by Mattias Skarin.