Skip to main content

Posts

Showing posts from 2006

TDD

Test Driven Development The importance of writing tests They force the developer to think of the class design They provide a safety harness while refactoring They ensure that the state of code is always stable New developers can make changes comfortable with the knowledge that if they break something that was working, the tests will inform them Test after development is not the same as test first development. Test after development does not reap all the benefits of test first development Writing the tests Think about the class it’s responsibilities and it’s API Write the tests to test every method and various conditions in the methods Whenever you think of writing a print statement or generate a log, it might be a scenario to include a test Write enough production code to ensure that the tests compile and fail Write production code to pass all tests one by one, while also ensuring that previous tests do not fail What not to test Database entities need not be tested Do not go overboard

Agile Timeboxing

A few days back, I was discussing Agile Timeboxing and estimation with some developers. What follows are some suggestions I gave them and thoughts that emerged from the suggestions. In the examples I have used to explain certain points, I have assumed a J2EE application which has a database, an entity layer, an application layer, Struts Action classes, and JSP's. The concepts can be extrapolated into any other type of application as well. Given a requirement we should be able to determine the amount of time it will take us to fulfill it. This is much easier said than done. Some reasons why we are not able to come up with accurate estimates are: Lack of familiarity with the code base Overestimating our capabilities Underestimating the amount of work needed to be done and it's potential ripple effects Working with gut feel without a proper process to identify the work that needs to be done In this post I will focus on a process that can be used to identify the

A very informative website

A few days back I came across a very good and informative website. Before you say to yourself... oh no not another website, and skip this post, let me tell you that this one is really good. Like all good things it is community driven. The community bring up the latest new items related to software development on the website, but the most useful content according to me is their interview series. They have interviewed several software luminaries like Joshua Bloch (on API design), Martin Fowler (on DSL's), Ron Jeffries (on Agile), Brian Goetz (on concurrency in Java), and many more. These interviews  are available for viewing on their website. The overall content quality is superlative. I'm sure I have at least got you interested enough to check it out .

MAX Memory For Your JVM

There is an interesting discussion going on the Java Posse Google Group on the maximum memory that can be allocated to a JVM. Now if you are running a 32-bit system, then 4 GB is the maximum addressable memory. Of this, the OS (Windows)  takes about 2 GB (though it can be tweaked to take less according to a post on the Java forum), leaving 2 GB for your apps. You could theoretically assign this 2 GB to your JVM, but thread stacks are allocated memory outside of the JVM. So if your application uses a lot of threads, you will have to leave some space for the thread stacks. Now if you use a 64-bit system, then you can allocate a LOT more memory to your JVM, but to do this your entire stack (CPU, OS, JVM, any other dependencies) needs to be 64-bit compliant.  If you want an unlimited heap size for your JVM, you might want to check out Azul . John Reynolds wrote an interesting blog on scaling JVM's with Azul.  By the way of you enjoy listening to podcasts and are into Java, then you a

Coding Dojo FAQ

The concept of coding dojos has been generated a lot of interest lately. Some people mailed me to learn more about coding dojos, how to conduct them, and how they can help an organization. So I decided to set up a FAQ. But before I say anything more, the credit for this concept goes to Dave Thomas who conceptualized the idea of coding katas (similar to dojos but to be done individually).   Q1. What is a coding dojo? A1. A dojo is a exercise that brings the element of practice to programming. It lets developers explore various solutions and approaches to a problem without time pressures. Just like musicians and sportsmen practice to improve their skills, these exercises help raise the bar of a programmer's skills.   Q2. How is a dojo conducted? A2. The dojo begins with the facilitator/coach explaining the problem statement to the group, followed with a quick design discussion. Once everyone has understood the problem, the first pair starts programming while the others watch o

Unconferences and open spaces

Bruce Eckel and several other people have been experimenting very successfully with unconferences and open space conferences. On the face of it "open spaces" seems to a very broad (open) ended concept, but it can be a very interesting and powerful concept if the participants are mature enough to make proper use of it. Here is the broad outline of my understanding of open spaces: Open spaces are conferences propelled by a concept or question. The driving concept could be anything from "How do we make our neighborhood cleaner" to "What is the best way to utilize web services". These are not preplanned conferences. The person or organization who wishes to explore a concept/problem will send out invitations in the community. People/companies who have similar interests will accept the invitation to attend. An invitation fee is usually charged to compensate for food, equipment, and conference room costs. The conference is a self organizing conference, which mea

Java infrequently answered questions

Peter Norvig has an excellent list of Java related IAQ's (Infrequently Answered Questions) on his website . He talks about stuff that cover various subtleties in Java. Here's an example: Q: Within a method m in a class C , isn't this.getClass() always C ? No. It's possible that for some object x that is an instance of some subclass C1 of C either there is no C1.m() method, or some method on x called super.m() . In either case, this.getClass() is C1 , not C within the body of C.m() . If C is final , then you're ok. -- Peter Norvig   Free Web Based Courses On Java Programming Best Practices and Obect Technology and Design  

Learnings from a discussion on EJB 3.0

Yesterday I had a learning discussion session with some developers on EJB 3.0 It was a very interesting discussion and we all took home some new and interesting stuff. The key learnings were: EJB 2.1 was a 300 lb gorilla that used a crane to lift a peanut. EJB 3.0 is a nimble chimpanzee :-) EJB 3.0 uses annotations instead on the xml deployment descriptors that were so hard to maintain. So beans, security constrains and everything that was earlier defined using the deployment descriptor can now be done in code using annotations. I think this is really neat, especially for small applications. We no longer need to define all the 2.1 interfaces to get an EJB working. In fact we need not define interfaces at all. A business interface will be automatically created for us by the annotation processor. I read somewhere on the net (do not remember where), that we must not generate the business interface automatically (but create it manually and have the EBJ implement it), because the automatica

Coding dojo

Last Saturday we conducted a coding dojo session for a software development company in Pune. A coding dojo is an exercise that brings the element of practice to programming. All sportspersons, musicians... practitioners of any craft, do a lot of practice, where they explore various aspects of their art, explore different techniques, tools, and solutions. But software developers never do that. The way they enhance their skills is by learning while working or traditional workshops. Workshops are a good way to bring a group of people up the learning curve on a new technology, but they fall short when we use them to improve developer's programming skills. Programming skills are best improved by practice. Practicing alone is good, but practicing with a group and a mentor is even better. This is exactly what a dojo is. A group of software developers that gets together to practice programming, to explore solutions, learn and improve their programming skills in the process. For this dojo,

Ending notes on software design series

Software design is all about decontructing a system into manageable units, identifying relationships among them and getting the units to interact to fulfill system requirements. To become a good object oriented designer, you first have to replace the "procedural mindset" with an "object oriented" one. That, however is not as simple as it sounds. The best way to get there is by practice, lot's of it. Take every opportunity to create a good design. When creating an entire system, think about the classes, their relationships, and interactions. When creating a class, think of what responsibilities it should fulfill. What should the API be like? How does it relate to other classes? When creating methods, think about the method signature and about the code in the method. Does the method do one and only one thing? What exceptions should it throw? Is is intuitive and easy to use? At whatever level you are creating the system, you can always think of design. Remember, th

Your feedback on translating requirements into system design

Please take a couple of minutes to give your feedback on this section. Would you like to see any additions, subtractions, or changes? How did you like the audio and video descriptions used in this section? I know they are not optimal, and I hope to improve them, but it will really help me if I get feedback on exactly what should be improved to make the course more effective for you. Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

What is object oriented programming - by Alan Kay

Alan Kay coined the term object oriented programming in the 60's. Even though the progression of this paradigm has been a collaborative effort, Alan Kay has played a very important part in the creation of this paradigm. In 2003 Stephan Ram could not find an authoritative source on what "object oriented" really meant, so he decided to ask Alan Kay himself. Here's a link to his reply. A must read for anyone who is interested in object oriented programming and design.

Identifying interactions

[Time 5:50 mins] In this section we will identify collaborations among the classes as they enact each use case. In this phase we may discover new classes that we had not thought of earlier, as well as new responsibilities for existing classes. We may also discard some initial classes. The process of determining the collaborations as each use case is enacted helps in refining and validating the design. CUSTOMER DETERMINES THE PRICE OF A GROUP OF ITEMS: Customer enters item codes at the UserTerminal UserTerminal creates Item objects for each item and finds out their individual prices The UserTerminal finds out all the schemes these items belong to The UserTerminal determines the Scheme price of all items belonging to a Scheme and adds the individual price of the remaining items The UserTerminal displays all the above information to the Customer   CUSTOMER CHECKS OUT ITEMS: Customer takes items to the checkout system Checkout assistant adds item codes in the CheckoutSystem

Identifying responsibilities

[Time 2:04 mins] Here I have listed classes from the previous post and associated responsibilities to them. Customer - To shop - To pay for the items Item - Holds an item code - Has a cost - Has a price Scheme - Holds a scheme code - Has a price - Contains a list of other Items Price - Holds the price (for an item) DiscountedPrice - Holds the price - Holds the discount PerUnitPrice - Hold the price - Holds the unit for the price Unit (and subclasses) - Specifies a unit - May have methods for converting between units. StoreManager - Checks the audit trail of items sold - Determines the value of current in-shop inventory CurrentStock - Contains a list of all items in the shop  Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Refine classes

[Time 6:29 mins] Now that we have identified some basic classes, some questions come to mind. Let us ponder a bit over these questions. We might identify new classes or remove some old ones at the end. Do we need different types of customers Do we need to represent simple and complex items differently? How do we represent different types of prices? Attributes vs sub classes How do we represent units? So now we have added a few classes: PriviledgedCustomer (maybe... let me ask the client) DiscountedPrice PerUnitPrice Various Unit subclasses This is by no means the final class list. As we identify responsibilities and collaborations, we will further refine this class list. Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Identify classes

[Time: 2:00 mins] Supermarket Classes  Customer Item Price Unit Scheme StoreManager CurrentStock Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Class and communication diagrams

[Time: 7:07 mins] We have identified classes, their responsibilities, and interactions among them as they enact use cases. Shown below is a class diagram and several communication diagrams that outlines important classes, their relationships, and collaborations among them. I have not shown all the classes, but only the ones that are important and have relationships with other classes. Classes that are not shown include: Customer StoreManager UserTerminal ControlPanel CheckoutSystem    Figure 1   Communication Diagrams: Customer determines the price of a group of items    Figure 2   Customer checks out items Figure 3    Store Manager valuates in-shop inventory   Figure 4  Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Translating requirements into system design - A case study

In this section we will take a requirements document for a software system and create a system design from it. The statement for the excercise has been inspired by Dave Thomas' coding kata #1 . Let's build a system for a supermarket. Here are the requirements. The supermarket has various items for selling. Each item has a price. Sometimes an item may have a discounted price, and sometimes it may be part of a scheme. Schemes could be similar to buy two get one free, or buy a certain quantity of an item and get another item free. Items may also be priced for a certain unit. For example Apples may be Rs 40/Kg, however they can be sold in a fractional unit also 500 gms. Some items may be simple, like a can of Pepsi or complex like a crate of 10 Pepsi cans. The sytem should also maintain an audit trail of all sold items for future evaluation. The store manager should be able to get a valuation of the current stock. When a shopper checks out items the system should calculate the most

Your feedback on principles of object oriented design

Please take a couple of minutes to give your feedback on this section. Would you like to see any additions, subtractions, or changes? How did you like the audio and video descriptions used in this section? I know they are not optimal, and I hope to improve them, but it will really help me if I get feedback on exactly what should be improved to make the course more effective for you. Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Using inheritance and composition

Inheritance is used for Code resuse To support polymorphism Disadvantages of inheritance Difficult to change the interaface of the subclass Superclass is always instantiated Can get complex and unmanageable Composition is used for code reuse Disadvantages of composition We cannot use polymorphism We cannot extend the system by adding subclasses May have a slight performance overhead Usage Inheritance: IS- A Composition: HAS - A Example  1 :  public class  Car  {      private  Engine engine;      public  void  start () {}      public  void  stop () {} }  public class  SUV  extends  Car {      public  void  start () {}  //overrides the start method from Car        public  void  fourByFourMode () {} } Example  2 : public  void  someMethod () {      Car c =  new  SUV () ;      c.start () ; } Example  3 : public class  Car  {      private  Engine engine;      public  void  start () {        engine.start () ;          //maybe do something more      }      pub

High Cohesion

[Time: 4 mins] Stuff that goes together, stays together Easy to discover relevant code Levels of cohesion packages classes methods    So in very simple words, cohesion is keeping related stuff together so we can find what we want without too much difficulty.      Example  1 :  public class  Student  {      //cohesive methods      public  void  registerForCourse () {}      public  void  deregisterFromCourse () {}      viewTranscripts () {}      //methods below are not in synch with the responsibilities of the Student class      //hence cohesion is broken      submit grades () {}      submitCourseSchedule () {}   }  Java2html Resources: High cohesion on Wikipedia    Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

Loose coupling

[Time: 4:32 mins] Loose (or low) coupling means (in a generic sense) that an entity can interact with another entity without being concerned with the internal implementation, and through a stable interface. Low coupling is implemented by using principles of information hiding. When two entities are loosely coupled, internal changes in one of them do not affect the other. The calling method is coupled to the called method and not it's implementation. Since we have already discussed encapsulation and information hiding in detail, I will not repeat it here. Loose coupling is achieved with information hiding And by programming to the interface rather than the implementation   Example  1 : Tightly coupled system  public  void  aMethod () {       ArrayList myList =  new  ArrayList () ;      doSomethingWithList ( list ) ;  }  private  void  doSomethingWithList ( ArrayList list ) { }  Example  2 : Loosely coupled system  public 

Don't repeat yourself

The code says everything once and only once, which is the essence of good design. -- Martin Fowler [Time: 4:44 mins] Repititive code makes maintainance more difficult There are more places to change We may forget to change some of them Increases probability of bugs Types of repitition In methods in a class Accross the entire software  Example 1: DRY violated public class  Account  {    public  void  transferFunds ( double  amt, Account dest ) {      //transfer funds      //generate email... create connection      //create message      //dispatch email    }    public  void  delete () {      //delete account      //generate email... create connection      //create message      //dispatch email    } } Java2html Example 2: DRY honoured public class  Account  {    public  void  transferFunds ( double  amt, Account dest ) {      //transfer funds      dispatchEmail ( ... ) ;    }    public  void  delete () {     

Keep it simple

width="290" height="24" id="audioplayer2"> value="playerID=2&bg=0xCDDFF3&leftbg=0x357DCE&lefticon=0xF2F2F2&rightbg=0xF06A51&rightbghove r=0xAF2910&righticon=0xF2F2F2&righticonhover=0xFFFFFF&text=0x357DCE&slider=0x357DCE&track=0x FFFFFF&border=0xFFFFFF&loader=0xAF2910&soundFile=http://www.adaptivesoftware.biz/storage/audio/swdesignprinciples-keepitsimple.mp3" /> [Time: 5:37 mins] One should not increase, beyond what is necassary, the number of entities required to explain anything - Occams Razor KISS helps keep software manageable The UNIX kernel is an example of a functionally complex software implemented in simple design Intentional complexity Enthusiasm to use design patterns Enthusiasm to make a system uber flexible Feature bloat Unintentional complexity Maintainance quick fixes Laziness in refactoring Resources: PrematureGeneralization   

Design principles

[Time: 2:20 mins] What is software design Decomposition is done at various levels of granularity We will focus on some simple principles that deal with classes, their responsibilities, and collaborations. There are some well known software design principles that serve as guideposts for us in the design process. In this section we will discuss some of the most important principles. AS OF NOW THIS SECTION COVERS SOME BASIC PRINCIPLES. OTHER PRINCIPLES LIKE THE ''OPEN CLOSED PRINCIPLE", "LISKOV SUBSTITUTION PRINCIPLE", etc, WILL BE ADDED IN THE NEXT VERSION OF THIS COURSE. Something to remember before moving ahead:  While principles, patterns, heuristics, and guidelines offer valuable advice about how to do things the right way, they don't serve as substitution for thinking on our own. Unfortunately, I think we all too often let these principles, etc. do the thinking for us. -- Kirk Knoernschild  Note: This post was originally posted on my blog at

Your feedback on goals of software design

Please take a couple of minutes to give your feedback on this section. Would you like to see any additions, subtractions, or changes? How did you like the audio and video descriptions used in this section? I know they are not optimal, and I hope to improve them, but it will really help me if I get feedback on exactly what should be improved to make the course more effective for you. Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net You will find below comments from the original post COMMENT: AUTHOR: Rashmi DATE: 10/18/2006 05:50:25 PM Sir could you please explain the difference between inheritance and composition through an example code COMMENT: AUTHOR: Parag DATE: 10/20/2006 01:16:47 PM Thanks for the suggestion. I will add an example to the blog post. Till then, here is a quick code sample. //this class uses inheritance. Guitar inherits //from MusicalInstrument public class Guitar extends MusicalInstrument { //... } //this is an example of

What about performance

OK, so there is a common myth about performance and good design being contradictory. It is said that we must often sacrifice good design for the sake of performance. Maybe so... but not always. Good design is about proper decomposition of functional requirements, about proper modularization, non repitition, simplicity, reusability, proper use of inheritance hierarchies, and about containing the functionality. There is no reason for most of the above to affect performance. However, sometimes we create good design by adding layers and indirection. This may result in extra method calls and perhaps creation of a few more classes. This may somewhat affect performance of the application, but again if the application in question is a web based one, then the performance hit will be negligible compared to the time taken by the web request and database query. However, if we are making software for an embedded device or an application with real time capabilities, then the extra method calls and o

And a few more (maybe)

While discussing goals of software design with other developers, a few more potentiall goals came up. They were, robustness, correctness, time to market, staying in tune with team capability, reusability, efficiency, and usability. After some analysis (in my opinion) only reusability passed the test of whether something is a goal of software design. I used a simple test - if we can use design principles like loose coupling, etc to enhance the candidate and if we (almost) always want it as an end result of software development, then the candidate passes the test for a software design goal. So, as of now reusability defenitely is a design goal. We achieve it by following the DRY principle. Any code that needs to be called accross methods in a class should be factored into a seperate method in that class, and any code that needs to be called accross classes, should be factored into a seperate class. This is reusability from an object oriented design perspective, but it can be taken furthe

Different aspects of software design

Yesterday while talking about goals of software design with some learning participants, we had an interesting discussion about the various aspects of software design. It is analogous to designing a housing complex. There is the macro level design of the buildings, gardens, club house, and jogging track. Then within every building we design the floor plan and the elevation. Each apartment has it's interiors designed separately. Beyond these designs, we also design the electrical systems, drainage systems, etc. The purpose of each design is different. Similarly in an enterprise software system, we have various aspects of design. Some of them are: Enterprise and deployment design Component design Class design User Interface design Each of these deals with a different aspect of the software system and has different goals. Enterprise design  addresses high level components like naming and directory servers, application server, messaging server, databases, clusters, high

Should all learning professionals be blogging?

Recently Tony Karrer asked on the learning circuits blog: Should all learning professionals be blogging? He also encouraged people to comment by posting on their own blog, a concept that Stephen Downes thinks is a huge advance . If you have been following this blog, you will remember that I have been encouraging readers to post their perspectives on the course material in the learning section, on their own blogs, and informing me about the post. Well, here is my response to the question. What learning professionals should be doing is this: Staying up the learning curve on technologies that affect them Reflect on their learnings to gain a deeper understanding Share these reflections with others to validate their ideas Have conversations with other professionals to share their knowledge and learn from others Manage the knowledge base of their reflections, resources, etc Writing works wonders for reflecting on concepts. I cannot stress enough, how useful the process of