Here is a book which sounds different from its title: “Apprenticeship Patterns” but considering the complete title: “Guidance for the Aspiring Software Craftsman” would make some sense of what the book would be about. And then once you read the back cover of the book then I think its becomes much clearer of what you can expect in the book. So this is how I went about buying the book – I had never heard of this book before, found it in the bookstore and purchased it in no time. I did search for almost all the Computer related books on Flipkart, but didn’t find this. So someone who would want to purchase this book can go here. Ok, but I need to convince you to buy the book, so here is my attempt to do so:

I would say this book very closely resembles to Passionate Programmer by Chad Fowler – resembles to some extent the content covered, Apprenticeship Patterns is to some extent can be said as a subset of the information. It also resembles in the way each chapter is structured, but Apprenticeship Patterns is a bit more structured in the sense it starts with the context, then explains the problem, then the solution and finally action items on the reader’s part, and also lists the related patterns which can be referred. So those were few of the similarities.

Clearly Apprenticeship Patterns is for people starting out their software software development careers or for people who have been in the field for some time say 1-2 years. But as authors- Dave H. Hoover and Adewale Oshineye claim this is book is not really useful for more experienced developers. Passionate Programmer is aimed at general programmers and not really focused on entry-level programmers, but I found it useful as well. And in the former the chapters are presented as patterns.

Some of the good points of the book:

• the title clearly states that it aims at beginners to adopt and expertise the craft of software development from masters.
• lists the actions/activities one has to undertake to learn the art of software development
• quotes from different books and real life examples.
• more of a collective opinion in addition to authors opinion.
• the chapters/content has evolved as a cumulative effort by the authors and other readers (this justifies the point above).
• provides links to additional reading material related to each topic being discussed.
• the most important- 130 odd pages of content only. So its not a huge book to read and understand hundreds of pages.

I dont know if this is a valid con of the book: The font is a bit smaller, so might be a bit stressful for the reader. But this isn’t much of a concern.

I would say a must read* for all the beginners in software development. So you got to head out to Amazon or Flipkart to buy this immediately.

*must read: provided you have the dedication and interest to follow the patterns in the book

Moodle is an Open Source Course Management System (CMS), also known as a Learning Management System (LMS) or a Virtual Learning Environment (VLE). Moodle is a free, open-source PHP web application for producing modular internet-based courses that support a modern social constructionist pedagogy. To work, it needs to be installed on a web server somewhere, either on one of your own computers or one at a web hosting company. Lot more information can be obtained from here.

There’s a better chance to grab the books available to learn about this platform from Packt publications, they are providing discounts on both their eBooks as well as printed copies. So you might be interested to know more about this here.

Liskov Substitution principle (LSP) states that,

Methods that use references to the base classes must be able to use the objects of the derived classes without knowing it

This principle was written by Barbara Liskov in 1988.

The idea here is that the subtypes must be replaceable for the super type references without affecting the program execution.

This principle is very closely related to Open Closed Principle(OCP), violation of LSP in turn violates the OCP. Let me explain:

If the subtype is not replaceable for the supertype reference, then in order to support the subtype instances as well we go ahead and make changes to the existing code and add the support. This is a clear violation of OCP.

This is mostly seen in places where we do run time type identification and then cast it to appropriate reference type. And if we add a new subtype implementation then we would have to edit the code to test for instance of for the new subtype.

Let me give a subtle example:

class Bird {
  public void fly(){}
  public void eat(){}
}
class Crow extends Bird {}
class Ostrich extends Bird{
  fly(){
    throw new UnsupportedOperationException();
  }
}

public BirdTest{
  public static void main(String[] args){
    List<Bird> birdList = new ArrayList<Bird>();
    birdList.add(new Bird());
    birdList.add(new Crow());
    birdList.add(new Ostrich());
    letTheBirdsFly ( birdList );
  }
  static void letTheBirdsFly ( List<Bird> birdList ){
    for ( Bird b : birdList ) {
      b.fly();
    }
  }
}

What do you think would happen when this code is executed? As soon as an Ostrich instance is passed, it blows up!!! Here the sub type is not replaceable for the super type.

How do we fix such issues?

By using factoring. Sometimes factoring out the common features into a separate class can help in creating a hierarchy that confirms to LSP.

In the above scenario we can factor out the fly feature into- Flight and NonFlight birds.

class Bird{
  public void eat(){}
}
class FlightBird extends Bird{
  public void fly()()
}
class NonFlight extends Bird{}

So instead of dealing with Bird, we can deal with 2 categories of birds- Flight and NonFlight.

How can we identify LSP violation?

• Derived class may require less functionalities than the Base class, so some methods would be redundant.
• We might be using IS-A to check for Super-Sub relationships, but LSP doesn’t use only IS-A, but it also requires that the Sub types must be substitutable for the Super class. And one cannot decide the substitutability of sub class in isolation. One has to consider how the clients of the class hierarchy are going to use it.

A detailed paper by Robert Martin on LSP.

Open Closed Principle (OCP) states that,

Software entities (Classes, modules, functions) should be OPEN for EXTENSION, CLOSED for MODIFICATION.

Lets try to reflect on the above statement- software entities once written shouldn’t be modified to add new functionality, instead one has to extend the same to add new functionality. In otherwords you don’t touch the existing modules thereby not disturbing the existing functionality, instead you extend the modules to implement the new requirement. So your code is less rigid and fragile and also extensible.

OCP term was coined by Bertnard Meyer.

How can we confirm to OCP principle?

Its simple- Allow the modules (classes) to depend on the abstractions, there by new features can be added by creating new extensions of these abstractions.

Let me try to explain with an example:

Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
  public void approveLoan(PersonalValidator validator)<br />
  {
    if ( validator.isValid())
    {
      //Process the loan.
    }
  }
}
public class PersonalLoanValidator
{
  public boolean isValid()
  {
    //Validation logic
  }
}

So far so good. As you all know the requirements are never the same and now its required to approve vehicle loans, consumer goods loans and what not. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
  public void approvePersonalLoan (PersonalLoanValidator validator)
  {
    if ( validator.isValid())
    {
      //Process the loan.
    }
  }
  public void approveVehicleLoan (VehicleLoanValidator validator )
  {
    if ( validator.isValid())
    {
      //Process the loan.
    }
  }
  // Method for approving other loans.
}
public class PersonalLoanValidator
{
  public boolean isValid()
  {
    //Validation logic
  }
}
public class VehicleLoanValidator
{
  public boolean isValid()
  {
    //Validation logic
  }
}

We have edited the existing class to accomodate the new requirements- in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the OCP. Lets try to implement the requirement in a different way

/**
 * Abstract Validator class
 * Extended to add different
 * validators for different loan type
 */
public abstract class Validator
{
  public boolean isValid();
}
/**
 * Personal loan validator
 */
public class PersonalLoanValidator
  extends Validator
{
  public boolean isValid()
  {
    //Validation logic.
  }
}
/*
 * Similarly any new type of validation can
 * be accommodated by creating a new subclass
 * of Validator
 */

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
  public void approveLoan(Validator validator)
  {
    if ( validator.isValid())
    {
      //Process the loan.
    }
  }
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

Another example:

I was thinking of another hypothetical situation where the use of OCP principle can be of use. The situation is some thing like: “We maintain a list of students with their marks, unique identification(uid) and also name. Then we provide an option to get the percentage in the form of uid-percentage name value pairs.”

class Student
{
  String name;
  double percentage;
  int uid;
  public Student(String name, double percentage, int uid)
  {
    this.name = name;
    this.percentage = percentage;
    this.uid = uid;
  }
}

We collect the student list into a generic class-

class StudentBatch {
  private List<Student> studentList;
  public StudentBatch() {
    studentList = new ArrayList<Student>();
  }
  public void getSutdentMarkMap(Hashtable<Integer, Double> studentMarkMap) {
    if (studentMarkMap == null) {
      //Error
    } else {
      for (Student student : studentList) {
        studentMarkMap.put(student.uid, student.percentage);
      }
    }
  }
  /**
   * @param studentList the studentList to set
   */
  public void setStudentList(List<Student> studentList) {
    this.studentList = studentList;
  }
}

Suppose we need to maintain the order of elements in the Map by their insertion order, so we would have to write a new method to get the map in the insertion order and for that we would be using LinkedHashMap. Instead if the method- getStudentMarkMap() was dependent on the Map interface and not the Hashtable concrete implementation, we could have avoided changing the StudentBatch class and instead pass in an instance of LinkedHashMap.

public void getSutdentMarkMap(Map<Integer, Double> studentMarkMap) {
    if (studentMarkMap == null) {
      //Error
    } else {
      for (Student student : studentList) {
        studentMarkMap.put(student.uid, student.percentage);
      }
    }
  }

PS: I know that Hashtable is an obsolete collection and not encouraged to be use. But I thought this would make another useful example for OCP principle.

Some ways to keep your code closer to confirming OCP:

• Making all member variables private so that the other parts of the code access them via the methods (getters) and not directly.
• Avoiding typecasts at runtime- This makes the code fragile and dependent on the classes under consideration, which means any new class might require editing the method to accommodate the cast for the new class.

Really good article written by Robert Martin on OCP.

The Single Responsibility principle (SRP) states that:

There should never be more than one reason for a class to change.

We can relate the “reason to change” to “the responsibility of the class”. So each responsibility would be an axis for change. This principle is similar to designing classes which are highly cohesive. So the idea is to design a class which has one responsibility or in otherwords caters to implementing a functionality . I would like to clarify here that one responsibility doesnt mean that the class has only ONE method. A responsibility can be implemented by means of different methods in the class.

Why is that this principle is required?

Imagine designing classes with more than one responsibility/implementing more than one functionality. There’s no one stopping you to do this. But imagine the amount of dependency your class can create within itself in the due course of the development time. So when you are asked to change a certain functionality, you are not really sure how it would impact the other functionalities implemented in the class. The change might or might not impact other features, but you really can’t take risk, especially in production applications. So you end up testing all the dependent features.

You might say, we have automated tests, and the number of tests to be checked are low, but imagine the impact over time. These kind of changes get accumulate owing to the viscosity of the code making it really fragile and rigid.

One way to correct the violation of SRP is to decompose the class functionalities into different classes, each of which confirms to SRP.

An example to clarify this principle:

Suppose you are asked to implement a UserSetting service where in the user can change the settings but before that the user has to be authenticated. One way to implement this would be:

public class UserSettingService
{
  public void changeEmail(User user)
  {
    if(checkAccess(user))
    {
       //Grant option to change
    }
  }
  public boolean checkAccess(User user)
  {
    //Verify if the user is valid.
  }
}

All looks good, until you would want to reuse the checkAccess code at some other place OR you want to make changes to the way checkAccess is being done OR you want to make change to the way email changes are being approved. In all the later 2 cases you would end up changing the same class and in the first case you would have to use UserSettingService to check for access as well, which is unnecessary.
One way to correct this is to decompose the UserSettingService into UserSettingService and SecurityService. And move the checkAccess code into SecurityService.

public class UserSettingService
{
  public void changeEmail(User user)
  {
    if(SecurityService.checkAccess(user))
    {
       //Grant option to change
    }
  }
}
public class SecurityService
{
  public static boolean checkAccess(User user)
  {
    //check the access.
  }
}

Another example would be:

Suppose there is a requirement to download the file- may be in csv/json/xml format, parse the file and then update the contents into a database or file system. One approach would be to-

public class Task
{
  public void downloadFile(location)
  {
    //Download the file
  }
  public void parseTheFile(file)
  {
    //Parse the contents of the file- XML/JSON/CSV
  }
  public void persistTheData(data)
  {
    //Persist the data to Database or file system.
  }
}

Looks good, all in one place easy to understand. But what about the number of times this class has to be updated? What about the reusability of parser code? or download code? Its not good design in terms of reusabiltiy of different parts of the code, in terms of cohesiveness.
One way to decompose the Task class is to create different classes for downloading the file- Downloader, for parsing the file- Parser and for persisting to the database or file system.

Even in JDK you must have seen that Rectangle2D or other Shape classes in java.awt package dont really have information regarding how it has to be drawn on the UI. The drawing information has been embedded in the Graphics/Graphics2D package.

A detailed description can be found here.

We usually write code that is-

• Rigid – Difficult to add new features
• Fragile – Unable to identify the impact of the change
• Immobile – No reusability
• Viscous – Going with the flow of bad practices already being present in the code.

There have been lot of principles for writing good code and all these principles define how the code manages the dependency. Most of them are aware of the principles:

• Loosely coupled code – There shouldn’t be too much of dependency between the modules, even if there is a dependency it should be via the interfaces and should be minimal.
• Highly cohesive code- The code has to be very specific in its operations.
• Context independent code- So that it can be reused.
• DRY – Dont repeat yourself – Avoid copy-paste of code. Change in the code would have to be made in all the places where its been copied.

Robert C Martin took the initiative and gathered different design principles into a common acronym- SOLID Design principles (The Principles of OOD).

SOLID stands for:

Single Responsibility principle (SRP)
Open Closed principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation principle (ISP)
Dependency Inversion principle (DIP)

In subsequent posts I would be writing about the individual principles. The following presentation was prepared by me for a talk on SOLID principles:

I just happened to get to know about this book while browsing through the books on Flipkart and the book immediately caught my attention. So here’s my review of the book:

First things first:

• Really cool cover page of the book – [I know Chad Fowler's musical interest has some role to play in the designing of the cover page]
• 200 odd pages book- So you don’t feel its overdose of information
• Short chapters, lighter book. Each chapter followed by Act it! which guides you on how to implement the ideas explained.
• Nice and legible font used for the content.

Introduction:

• Author speaks about Why the book was written- Really inspiring stuff there.
• Few aspects are highlighted just to give the reader an idea of what to expect in the next 200 odd pages. This will boost your urge to complete the book in one sitting. Just for the curious readers: The author tells about fighting the fear of failure and also owning one’s career growth just as a company owns its products and inspiring from this the book has been divided into 5 parts:
• Choosing market
• Investing in your product
• Executing
• Marketing yourself
• And Keeping the edge
• This sets the tone for the rest of the book

• Importance of learning to do things rather than getting it done from someone else
• Understanding the business working
• Importance of getting mentored by more experienced people- I really support this, i have seen how things change when you are mentored or interact with someone more experienced than you.
• Sharing improves one’s knowledge and so its useful to find someone whom you can mentor- The author has given few suggestions on how one can become a mentor.
• Importance of practice. Coming out of the comfort zone and trying out new technologies, different paradigms.
• Not depending on proprietary technologies and instead adopt open source community driven technologies.

• Not procrastinating the work, doing it right now
• Monitoring the daily tasks performed
• Trying to predict the requirements or tasks – this is a tough activity but with practice one should become fairly good.
• Not trying to day dream about your promotions, hike or trying to target next levels without justifying the current position.
• Identifying the value added to the company
• Not fearing failure, taking risks and learning from failures. Keeping calm during tough situations.
• Judging one’s ability before taking up tasks- taking up all the tasks is not good and denying all the tasks is also not good.

In a previous post I had mentioned that I would be soon reviewing the Play Framework Cookbook. So here it is-

Chapter-1 Basics of Play Framework-

• Concise coverage of basic features of the Play Framework. Though you must be using the Play Framework documentation for a more detailed information. The last few sections which explain- Extensions, Suspendable requests need a bit more explanation.
• Good to have, as one can refresh the basic concepts.

Open Source has gained a lot of momentum over the past few years. I have seen it grown in popularity and the number of applications available and the growth of communities around it. Being a Sun Campus Ambassador which played a pivotal role in contributing to Open Source community, I was exposed to the Open source early on. And these days we have seen companies like Facebook, Twitter, SpringSource among others contributing to the open source community. Also there are lot of conferences (foss.in, 2011.osidays.com) being organized around these technologies. There are languages (Groovy, Scala, Ruby, JRuby), frameworks (Rails, Grails,Lift) which are growing in their feature set and popularity.

Another such initiative towards helping the open source communities grow and thrive is the Open Source Awards organized annually by Packt Publishing. The 2011 Open Source Awards was launched on the 1st week of August by Packt, inviting people to visit www.PacktPub.com and submit nominations for their favorite Open Source project.

The 2011 Awards will feature a prize fund of $24,000 with several new categories introduced and the vote of the public becoming more influential. This year all CMS projects will compete in an even tighter contest in the Open Source CMS Award category with the now defunct Hall of Fame CMS finalists re-entered into the CMS category. Projects such as Drupal and Joomla! will face off with CMS Made Simple and MODx for the first time since 2008.

While the Most Promising Open Source Project and the Open Source JavaScript Libraries categories will be back for a second year, Packt is introducing new categories for Open Source Business Applications, Open Source Multimedia Software and Open Source Mobile Toolkit and Libraries. These new categories will ensure that the Open Source Awards remain committed to providing the platform to recognise excellence within the community while supporting Open Source projects both new and old.

Packt has opened up nominations for people to submit their favorite Open Source projects for each category at www.PacktPub.com/open-source-awards-home . The top five in each category will go through to the final, which begins mid-September. For more information on the categories, read Packt’s recent announcement: www.packtpub.com/blog/2011-open-source-awards-announcement.

Voting beings from September 19th and goes on till October 31st 2011. So vote to see your favorite open source project winning. And what more you can get lucky to win a Kindle!

]]> http://blog.sanaulla.info/2011/09/08/6th-annual-open-source-awards-2011-packt-publishing/feed/ 0 http://blog.sanaulla.info/2011/08/26/play-framework-cookbook-preview/#utm_source=feed&utm_medium=feed&utm_campaign=feed http://blog.sanaulla.info/2011/08/26/play-framework-cookbook-preview/#comments Fri, 26 Aug 2011 10:31:51 +0000 Mohamed Sanaulla http://blog.sanaulla.info/?p=990 Continue reading →]]>

I had written a brief introductory post about Play! Framework and since then I havent written much about it. Not before I got an opportunity to review the Play Framework Cookbook. Before coming back to Play! I used Gaelyk for a long time and found it really useful to get started quickly on any project. But there I had to setup up lot of things myself (though its coming up with its own Plugins) and this is both Good and Bad- Good because I can configure things myself and thereby have a hold over the features configured and Bad because I had to spend a lot of time on configuring things rather than solving the problem for which the application is being developed. Moreover I had to learn Groovy for that but I could learn a lot of it while using the framework itself. To overcome the Bad things listed a few lines before I was thinking of moving to Grails- the fact that I knew workable amount of Groovy made me think of taking up Grails, but I have a account with an hosting provider which supports Rails/Php and not JVM based applications. This made me think of taking up Rails but I had to learn Ruby for that. So amidst all these confusions I got another opportunity to look back at Play and see if I can make use of the framework now ( and now that I have lot of ideas for the applications to develop).

Meanwhile over a few days (few weeks? hopefully not that much time) I will be reviewing Play Framework Cookbook and alongside see how I can leverage Play for my application development. A quick look at the contents of the book and reading through the Foreword the first 2 chapters would be helpful to understand the basics of Play Framework- it would be a quick overview as the book is not meant to teach the basics of the framework instead to give quick solutions to common use cases of the framework. The per-requisite for the book is to have read through the tutorials and worked through the sample applications using the framework.

As far as I am aware Play Framework Cookbook is one of the two books available for Play Framework. The other being http://www.the-play-book.co.uk/index.php (not sure if this is released/is in print)