Adaptive Software Solutions

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

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

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  

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

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,

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

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

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.