Training in ORM with Hibernate

I am offering a training course in ORM with Hibernate. The training intends to cover both conceptual and practical topics. Ideally after the training, participants should be able to develop typical J2EE applications hands-on with Hibernate, and become fairly knowledgeable of all the common issues working with ORM tools in general and Hibernate in particular.

The training will be code-intensive. Typically, it will require 15-20 hours, with two-third of time in lecture and the other in working with codes. Of course, I can tailor this course for specific needs if required.

Here is an outline of the topics I will cover in the training. If any reader of this blog thinks it useful, please feel free to drop me an email yang927@yahoo.com, and we can discuss further.

· Session One: ORM, Configuration & Basic Mapping
o The Case for ORM
o The Solution: Hibernate
o Hibernate Configuration
o Hibernate Type
o Basic Mapping
o Lab One: Hibernate Configuration

· Session Two: Advanced Mapping & CRUD
o Inheritance Mapping
o Collection Mapping
o Component Mapping
o Persistence Life Cycle
o Basic CRUD with Hibernate
o Code Walk Through: Inheritance Example & The Blueprint Application

· Session Three: Association, Transitive Persistence & Fetching
o Mapping Association
o Polymorphic Association
o Transitive Persistence
o Fetching Strategies
o Code Walk Through: The Blueprint Application & Mapping Examples

· Session Four: Transaction, Caching & Queries
o Database Transaction
o Application Transaction
o Caching Theory and Practices
o Query Mechanisms
o Join and Reporting
o Architecture Review: Admin Web with & without EJB

· Session Five: Application Architecture and Development
o Hibernate in Web Container
o Hibernate in Application Server
o Development Scenarios
o Hibernate Toolset
o Lab Two: Applying Hibernate Tools

· Appendix: Advanced Topics
o Natural and Composite Key
o Legacy Data
o Trigger and Stored Procedure
o Hibernate Interceptor
o Demonstration: Various Examples

To Be a Good Project Manager

Question: Tell me the most difficult parts about managing a product launch? Look for deep insight into and understanding of PM issues - i.e. dealing with scarce resources, feature creep, etc.

Answer: My experience is consistent with the CHAOS reports from the Standish Group. The major issues deciding software project failure and success are (1) user engagement; (2) executive support; (3) clear business objectives.

In addition to those, I also feel the knowledge gap between business people or management and technical team plays a role. The issue is either business people or management mandate technical solutions for the technical team or technical decisions are not aligned with business strategy.

While processes such as RUP or XP can help to guide development efforts, people in my opinion are the most important factor to be considered in software project management. To certain degree, software development is still an art compared to a standardized activity as in manufacture. Along the same line, the culture of the operating company plays a major role. Any specific project management activity or practice has to be fine tuned with those factors in the operational context.

As far as resources and deadline are concerned, here is my observation: the various estimation method may give a project manager some hints, but only the real-life experience, and the complete knowledge of the team profile can give a project manager the peace of mind. Only knowing the issues, knowing the options for solutions, and knowing the strengths and weaknesses of people in the team can give a project manager the precise estimation. To get rid of all the issues with scarce resources and deadline, a project manager needs to get the estimation right in the first place. Otherwise, whatever the project manager is going to do is really making up for his mistake, and what to be cautioned in this situation is not to blame the team, unreasonably push the team. Instead, the project manager should demonstrate the professional integrity and confront the reality, try to balance the various pillars: scope, resources and quality etc., or to adjust technical implementation strategy (a technically savvy project manager should know all the options available to him and should know the consequences as a result of adopting a specific strategy).

Here comes my conclusion: an ideal technical program manager should have solid technical skills, outstanding leadership, should be savvy in business. It is not enough to just have project management knowledge or general management skills.

Spring Framework: Why the Momentum?

Spring Framework is the solution to several long-existing and tough problems facing the business and technology community.

The first problem is this. J2EE particularly with technologies such as EJB and JCA was designed from the very beginning to solve problems in enterprise systems; while enterprise systems as imaged by the designers of J2EE exist in reality and are of critical importance to businesses, they are by a great deal of measures only of a small portion of development projects. For majority of the requirements, J2EE is too heavy a solution for too light a problem. The consequences are (1) qualified resources are always in short supply and (2) therefore most of the projects are failing because not many developers are in full control of the J2EE technologies. To this, Spring Framework’s answer is “let us go to basics, and there are plenty of technologies that are more than enough to solve your problems.

The second problem associated with J2EE as practiced now is more intrinsic to the technologies themselves. That is, the missing of object-oriented paradigm.
Object oriented paradigm obviously has its credentials to dominate the computing industries since 1980s, EJB’s losing of object oriented features, and its lack of a better replacement essentially render the industry into a situation of giving up too much without gaining enough compensation. It is probably the underlying reason why Spring Framework, and for this matter, the whole light weighted container movement, is securing great momentum. They have lots of goals to achieve, but to rescue the advantages of object oriented paradigm turns out to be most appealing.

To be fair with the old J2EE technologies, Spring Framework is not only building its strength upon J2EE’s shortcomings (or failures as some extremists like to claim). Spring Framework has its own contributions to Java/J2EE community. Two aspects deserve mentioning here.

One is to codify best practices of Java application development. Rod Johnson and his people are all real-life developers working on application developments themselves, comparing to those who start their careers as so-called system developer and never solve a single business problem with their systems. Real life developers are closer to the problems domain, and in Spring Framework Rod Johnson and his people share a lot of their hard-learnt lessons and experiences. It looks like their experiences are not measured by “years” as our lovely human resources people do, but by something you and I as developers care, or something the senior management should really care.

The second strength Spring Framework provides is to make into a consistent whole of all the popular and wide-used Java tool offerings in open sources. Most of those tools address particularly well for their specific concerns, it is time to combine them seamlessly together and to come up a total solution. Spring Framework tried on this and obviously has done this well. Associated with this point is that, Spring Framework is a framework that concerns with building applications, and is not one that lays at a lower layer concerning with system issues. In other words, it is an application framework, not a system framework. For most of developers, application framework is certainly more interesting.

As always, for the sake of my professional integrity, I need to make a disclaimer here. Spring Framework has its values, but it is not a solution for all application system problems; and I certainly think J2EE as advocated by the big vendors such as Sun, IBM, Bea and Oracle etc. is good and important, and for most of the high-end requirements, it is probably the only feasible solution.

Random Thoughts on Game Theory

I first met Game Theory 15 years ago as a college student majoring in applied mathematics. Back then, there were so many interesting things an ambitious young student could pursue; game theory did not have my attention for a long time.

Recently, I got some spare time to pick up the book “Thinking Strategically” by Profs. Dixit and Nalebuff. At this moment when I finish reading this book, I would say this is my most pleasant intellectual experience since I left campus.

Game theory is a major topic in economic study, and is also gaining momentums in business and management education recently. I would like to go a little bit further than most of other people would feel comfortable by claiming that, game theory is the scientific research of wisdom in its rational aspect.

I happen to read Stephen Covey new book “The 8th Habit” at the same time. It reminds me Dr. Convey’s most influential old book “The Seven Habits of Highly Effective People”. People knowing game theory can immediately put the 7 habits in the context of game theory. For example, “begin with the end in mind” is nothing but the principle of “looking ahead and reasoning back”; “Think Win/Win” appeals directly to the major topic of “Prisoners’ Dilemma” in game theory, or why co-operation is a better option than applying your dominant strategy.

There is another business bestseller for quite a while, “The Tipping Point”. It is obvious that the most rigorous explanation of tipping point is in game theory: the tipping point is the boundary beyond which one equilibrium state will collapse and the system moves to a new equilibrium state.

In business, “leverage” is a widely used term; but most of cases it is mis-used. To identify the opportunity for leverage and to catch the opportunity by making the non-intuitive right decision are everything but easy. It is in game theory that leverage is best defined and only by putting it into the context of game theory can leverage be mastered.

As a professional in software industry, I am interested in software project management. Looking from the game theory point of view, we may find lot of teachings in “conflict management”, “team building” and “motivation and incentives” etc.. need to be re-examined or more precisely explored. For example, we talk about conflict resolution methods such as “ Confronting”, “Compromising”, “Smoothing”, “Forcing” and “Avoiding”, and most of the existing literature only point out those methods and the consequence of applying them. We seldom see any discussion on what method should be used in what situation and how to avoid the non-intended consequences. But those topics are really the most important concerns to practicing project managers. I believe game theory provides a great framework to analyze and finally address those concerns efficiently.

In the book “The War for Talents”, the authors advocate an “open and trusting” workplace. This is a teaching that we can also find in all the other business books. But in most of those books, the argument, if any, is based on empirical evidence. Again, game theory can provide us with real insights here. Simply speaking, an open and trusting workplace is to remove the “prison” in the “Prisoners’ Dilemma”, therefore, people can engage in cooperation instead of always adopting their “dominant strategy”, which unfortunately is not necessarily the best for the business, or for anyone as part of the business.

In business environment, “team” is a buzz word, and nobody dares to challenge it. After seeing so many bad things are carried out under the name of “team work”, every time when I talk about “team work”, I usually add something like “in its positive sense”. Among those bad things, there certainly are purely evil actions from wrecked minds, there is one phenomenon which game theory essentially indicates as unavoidable and therefore should be tolerated: “the exploitation of the great by the small (Mancur Olson)”. In “Thinking Strategically”, the authors suggest that “find a large benefactor who act cooperatively and tolerates others cheating”. The lesson here is that complete fairness may not be a proper ultimate goal, and those great should be ready to contribute more. I guess this is what we label as “noble”.

It is just encouraging to see the fine art of wisdom becomes a science. Strategy is usually associated with experience, which actually means long enough time of “trial and error”. Once again, I am convinced that so many things that are categorized as “experience” can really be gained quickly without the prohibition of time if only you know how!

Review of Java Reflection in Action

Java Reflection in Action from Manning by Ira R. & Nate Forman is a fine book with materials of interests.

I particularly like two points.

The first one is articulating the topics with a case based approach. Case study has already been proved to be an effective way of teaching practices-related subjects, and is the standard model in business and management education. It is my personal belief, based on experience in industries, that the software architecture discipline has great similarities with business and management. Both of them have a set of generally followed principles and have a well-known set of tools for diagnosing problems and communicating ideas. However, those principles and tools are only a small portion of a practitioner’ portfolio. To be successful in real-life situation, practitioners have much more to learn, among those, the most prominent one is generally labeled as experience. The best way to learn from others’ experience in business and management is through case study. I think the same approach applies to software architecture experience learning. Design pattern is a hot topic in the community of software developers. We usually think the idea of design pattern was originated from the building architecture industry (particularly, Alexander’s book). This may be the actual case. However, design pattern is really just cases in software design, and I think looking design pattern from the case study point view can be more inspiring. At the minimal, we will benefit a lot form the experience gained in management schools for the past several decades in applying case approach of teaching. Of cause, design pattern is only the lower end of software architecture. Case approach can utilized to effectively transfer the whole spectrum of software architecture experience. While it is obvious that the publishing industry and authors are struggling to find the right approach to communicate software architecture experience, I would love to see more books on this topic to come in an explicit case study manner.

The second point I like this Java Reflection in Action book is its discussion on applying Amdahl’s Law in evaluating performance consequence of a software techniques. Frankly speaking, experienced developers all know well the ideas underlying Amdahl’s Law. But it is certainly amazing to have such a rigorous formula to help decision-making for an issue which developers face everyday. In his extreme programming book, Kent beck used Black-Schole formula in financial derivative valuation to discuss dynamics among various concerns in software project management. It was an interesting usage and appealed well to readers who are fond of mathematics. Amdahl’s Law is more essential to the performance issue discussed in this book than Black-Schole to project management.

Classloader is arguably not a topic on reflection. The authors have a chapter on classloader in the book. This chapter is weak, and a good discussion on classloader should be put in application development context, and should explore classloader issues in web and application servers, and mention its usage in JMX etc.. Also, the two chapters on class constructions are really about developing a small tool of class transformation. There are a lot of codes and explanation on codes. It will be much better if the exploration is more on issues.