Wednesday, September 21, 2005

A day with Hibernate

I always felt I had a sound understanding of hibernate and offered "expert" advise to my friends over chat/phone. I chanced to get Hibernate in Action and wanted to try out the traditional "Hello World!" example. Immediately fired up Eclipse and started coding, what a pleasure it is to code! I soon realized that my belief is a fallacy as there were exceptions on the console. The exception was org.hibernate.HibernateException: database product name cannot be null. Wrestled with the exception for a couple of hours but in vain. Upon retrospection, I noticed that there was an unwanted line of code

configure.setProperties(System.getProperties());

This line was overriding the properties already loaded by configure() method. If hibernate.cfg.xml is used to configure hibernate, c3p0 pool then the following lines of code would suffice:

Configuration cfg = new Configuration().configure();
SessionFactory factory = cfg.buildSessionFactory();


My hibernate skills are withering and need updation, more pratice is required to keep up the pace.

Friday, September 16, 2005

Code as Design or ????

An interesting conversation with my friend brought out a point of concern - what exactly is software design? I always advocated that programming is essentially designing software, but most of my colleagues differ. I feel that programming is not just building the software but a more *disciplined* process of writing "meaningful" code. There are (increasing)instances of people trying to keep away from coding after they have been conferred august sounding designations by their employers. Unfortunately, some of friends whom I respected tremendously for their coding ability are following this band wagon concept.

One item from such species drew an illustration of Turbine Production. What an example, Duh! His argument was that there will be a separate design team (sitting in plush air conditioned rooms gazing at their monitors and building models, and doing all sorts of simulations) responsible for coming up with design documents and the shop floor uses these designs for production. This model is convincing as long as it is the production of tangible stuff. But, when it comes to software development, the model completely fails. Can Oceanography be applied in the space?

I firmly believe a well written code is a testimonial for good software design. Many seem to differ and vote for designing as an abstract intellectual exercise. I don't want to impose my belief and conclude this entry, I'll update this entry with opinions from my friends and fellow developers.

Tuesday, September 13, 2005

A thought about Spring

I started reading the book "J2EE Design and Development" by Rod Johnson. I should have read this much earlier. It is very interesting and thought provoking book. Intrigued by the reading, I wanted to try out Spring and feel the "IoC". Downloaded the spring framework and started coding my first bean. After gettimg my feet wet, I realized the power of IoC. A very cool concept. Hail Spring!!!

Friday, September 09, 2005

Role of an System Analyst

I have an impressive designation with my employer - System Analyst. Had been chatting with a friend about the roles and responsibilites of a System Analyst, the topic somehow spurred interest and we decided to come up with a summary on what is expected of a (true) System Analyst and later juxtapose it with our current roles.


We chose to explore the job sites and identify the requirements specified by the companies for a System Analyst profile. The following is the (exhaustive)summary we have come up with:
1. Domain
------------
a) Filtering final system requirements, from a free flowing discussion in business terminology.
b) Explaining constraints of technologies chosen to Business Analysts/Domainexperts.
c) Explaining constraints of business requirements to Development team.
d) Conducting process facilitation with clients to identify
organizational,information and integration requirements.
e) Capturing pertinent problem domain information from domain Expert review
sessions.
f) Reviewing system requirements for problem domain completeness.
g) Promoting interoperability of business and technology. Acts as the bridge
between the understanding of the problem domain and the technology requirements.

2. Technical
-------------
a) Developing standards, templates, and procedures to expedite the development
b) Contributing to company wide methodologies.
c) Responsibility for a collection of Use Cases.
d) Disseminating system requirements to the development team.
e) Monitoring the activity within the Online Communities, asking questions
where necessary to support the needs of the project.
f) Assisting the test team to develop test plans and test cases.
g) Has worked extensively as a developer.

3. Management
--------------
a) Assisting in developing project proposals and comprehensive project budgets.
b) Working with Technical Architect and Project Manager to balance business
requirements, technical requirements, and costs.
c) Assisting project management in the understanding and control of Scope.
d) Working independently on strategic issues with client.

Additional good to have Qualities:
----------------------------------
Broad knowledge of business issues and processes such as Strategic Planning, Business Re-Engineering as well as IT resources and enabling technologies.

After reviewing the notes, I wondered if any company hiring system analysts really provides the chaps with good challenging work or is it just an august sounding title.
I must admit that my (little) experience doesn't match the above requirements. Way to go along the long road, buddy!