Hibernate3 Tip#3: Methods You Should Override

Just some general best practices that have saved me considerable development time as I've worked with Hibernate3:

• Always override equals(). Objects that are equal as plain Java objects are often not equal in Hibernate3 because of the identity problem. Hibernate considers the object's persistent state, database identity, and other factors to determine if two objects are equal. By overriding equals(), you set a standard of equality both Hibernate and Java can use.
• It is a bad idea to override equals() in subclasses. Hibernate does not behave well.
• Always override hashCode() and provide your own implementation based on the class's attributes that are expected to change rarely. I use the class identifier commonly. Actually, overriding equals() almost always requires overriding hashCode().
• When you implement equals() and hashCode(), always use property accessors - getXX()/setXX(), POJO style. Hibernate allows the use of proxy classes or references that may no contain actual data if you call their properties directly. Believe me, this is a pain to debug!
• Always make classes Comparable in case objects of the class end up in collections that require this feature (such as SortedSet or other collections that use a class-dependent Comparator). This gives you the flexibility to switch collection types whenever (e.g. from List to Set) without further base code changes.
• I also always override toString() because I hate seeing memory addresses as representations of objects. I use it for debug information that I can print out and understand, and that uniquely identifies the object for me.

Pretty much every OOP project I've worked on, these are some of the first tasks that get done. If developers would just get in the habit of these best practices, I wouldn't dread inheriting their projects so much.

Hibernate3 Tip#2: Enable Automatic Dirty Checking

In database parlance, when you read a record from a table and update some of its fields in memory, the record is considered dirty. Dirty checking avoids unnecessary database write actions by performing SQL updates only on the modified fields of persistent objects. Hibernate3 JPA can do automatic dirty-checking for you via an annotation to the entity:

@org.hibernate.annotations.Entity(
    dynamicInsert=true, dynamicUpdate=true
)

The dynamicInsert property is really only necessary to prevent writing NULL values to database fields. But if the changes involve setting NULL values (bad practice), you should probably turn it off.
I can think of three possible implementations for dirty checking:

1. Caching a clean copy of the record and maintaining an edit copy of the persistent object. When an SQL update is due, the copies are compared and changes extracted from the edit copy for update. Obviously memory-intensive as 2 copies of a record are maintained at all times.
   
2. Keeping track of which fields changed.
3. Doing a SQL query just before updating and doing the necessary reductions to determine what changed.

I do not know which strategy Hibernate3 uses. Either way, the performance hit is minimal compared to rewriting whole table rows in the database - depending on how many fields each record has. It is recommended when you have more than 50 fields where any given update affects less than 25% of the fields (if you want hard numbers).

Hibernate3 Tip#1: Persistent Lifecycles

For application developers that use the Hibernate3 JPA, it is crucial that you learn the different persistent states an object can be and what methods/functions cause them to transition to what other states. The states are: transient, persistent, detached, and removed. You must also know how a persistent context works, the ACID (atomicity, consistency, isolation, durability) principles for database transactions, and basics of object identity (Java's equality is NOT the same as database record equality).

You can find out more about Hibernate3 at https://www.hibernate.org/.

TimeTrak: The Webserver

Whenever you do web development, you will inevitably have to use a web server. I use the term 'web server' to generally mean HTTP servers, webservers, and application servers. If your website only dishes out HTML and other static content without server-side processing, you probably just need an HTTP server. If you expect dynamic content and server-side processing, perhaps a webserver is what you need. If you'll be running (web-oriented) programs and services, heavyweight back-end processing, or on vendor-specific stacks, etc, you should research application servers. Application servers can do everything webservers do, and webservers can do everything HTTP servers do.

The choice of a web server depends on the programming language that will be used to implement the business layer (applications, data processing, business rules, generation of content, etc). Don't forget that some web servers might be supported on specific operating system platforms as well e.g. IIS is a Microsoft-only deal. Others can be vendor-specific, requiring you to use their database programs or hardware. Web servers can cost anywhere from free/open-source (e.g. Apache Tomcat) to very expensive enterprise class subscriptions (e.g. Microsoft Web server). The cost is usually for value-added services and features beyond basic web-serving such as multi-processor support, load balancing, clustering, security, availability/redundancy, technical support, or other vendor-specific bells-and-whistles.
The web server is where your application architecture is implemented. The web application will depend heavily on the services provided by the web server, including database access and security.

TimeTrak shall be implemented in Java, and will only need a webserver such as Apache Tomcat. With this setup, I can use the JSP/Servlet container to generate dynamic content, and a JDBC-compliant driver to access the database. I can use the full power of the Java programming language to implement the web application. The business layer shall be implemented with Spring MVC, and data layer with Hibernate. Your choice of web server must support your architecture decisions squarely. This is why some businesses prefer stacks such as those from JBOSS, IBM, or Oracle. Other decisions you must consider before choosing a web server include: how you will be building and deploying the application, testing strategy, and security. Make sure your customer is on-board with the decision, as it is potentially the most expensive if you had to change things completely.

A note about security: after installing a web server, take time to lock it down, as it is the gateway to the outside world. A lot of website security breaches take advantage of web server default settings and other vulnerabilities for which patches and best practices would have saved the day. Make sure you are aware which ports the web server opens, or operating system services it depends on, and secure them accordingly.

Other reading:
http://www.sun.com/bigadmin/content/developer/howtos/webserver_part1.html
http://tools.devshed.com/c/a/How-To/How-To-Choose-The-Web-Server-For-You/
http://webdesign.about.com/cs/webservers/bb/abwebservers.htm

TimeTrak: The Database

I love free things, and I love good free things. When it comes to software development, there are tons of free options for most pieces you will need to build your applications, and building TimeTrak will be no exception. I'm choosing to use the MySQL database server for this project because I am familiar with its reliability, scalability, performance, and simplicity (all awesome). They also provide a Java connection driver and a bunch of other free tools to manage the database.

To be impartial, I've also checked out, used, or heard of these other free database applications that some might find more appealing than MySQL. Heck, I'll use any database that is relational, is SQL-compliant, has a driver for my programming language, is known-good in the industry for the kind of application I am developing, and is (almost) free - unless the project requires using a specific product.

The free database applications:

1. PostgreSQL: Extremely scalable, open-source, object-relational.
2. Firebird: ANSI SQL-99 features, Open-source, freeware, based on Interbase.
3. Apache Derby: Open-source, implemented in Java.
4. H2 Database Engine: Open-source, Java SQL database engine with embedded, server and cluster modes.
5. Hypersonic SQL: Open-source, created in Java, small. No longer being developed, but existing versions work well.
6. SQLLite: Self-contained, embeddable, zero-configuration SQL database engine. Great for desktop applications.
7. Microsoft SQLServer Express: Lightweight version of Microsoft's commercial SQL Server database.
8. Oracle Database 10g Express: Freeware edition of Oracle's high-grade 10g database.
   

Additionally, I always have DBVisualizer installed alongside database applications, mainly to visually inspect the schema. The free edition allows running only one SQL statement at a time. To run .sql files, I just use the MySQL command line console. Each database application will have a different set of management tools, so do your research.

Finally, perhaps it's nothing to worry about, but the future of MySQL long term is uncertain. The company was bought by Oracle, and I suspect they will want to monetize the acquisition. They make expensive and enterprise-grade databases already, and I do not see a huge incentive to keep a (good enough, production-grade) free database around. Time will tell.

TimeTrak: The Requirements

This web application will be very simple. My goals lean more towards using the technologies of interest, namely, Google Web Toolkit + Spring MVC + Hibernate. Nonetheless, every project must start with a set of requirements.

Timetrak will be a multiuser application targeted at independent contractors that regularly participate in others' projects and desire to keep track of their tasks and hours spent doing project work. I'm one such software developer.

The application will support the following roles: an administrator, project supervisors, developers, and clients.
The administrator is charged with creating and managing user accounts, and resolving access/rights issues.
The project supervisor creates projects and assigns developers to the projects' tasks. He also sets the various hourly rates or contract terms for the project, and is responsible for inviting the project's client to participate. Supervisors also approve invoices posted by developers, at which point they are visible to clients.
The developer performs actions according to the tasks assigned to him, keeping track of hours worked. A developer can create new tasks in the projects he has access to (which will automatically be assigned to him). At any time, a developer can generate a bill for a particular project on completed tasks.
The client can review projects and see progress reports. Project details (such as task activity and which developer did what) are hidden from him. The client can review and pay invoices online, posted by managers.

Whenever a task gets some action, a daily email is sent to the client detailing what was done, and how long it took. If the client has multiple projects, only one email will be sent.
When a task is included on an invoice (billed), it cannot be modified. It can never be modified again after the invoice is paid, but can be activated again if the invoice is cancelled for whatever reason.
Tasks will have status that depict which development stages they are at: ready (not assigned to a developer), assigned (no actions done on task), in progress (some actions posted), and completed. Only completed tasks are billable.

I'm sure there are a lot more requirements that could be discussed, but the above are the crux of the project. It's cumbersome to try to adapt traditional SRS documents for a web application, and Agile methodologies will not provide the kind of documentation needed for a typical SRS, so the best strategy is to marry the two. I use a stripped down IEEE-recommended SRS with all kinds of web-specific sections depending on the project.

Write SRS's to focus on what the application will do only, who is involved, and the definition of the various entities you mention (for the benefit of the database developer). From this one document, system designers should have no questions about what to do. Even for web environments, you want to avoid discussing technologies in the requirements doc, unless the customer requires it (the document should be technology- and language- agnostic = a design or implementation decision). For this application, my SRS is only 11 pages long front-to-back - that's how simple it should be.
Typically, solicitation of information and clearing up ambiguities, and finally writing the document takes 2-3 days, depending on how quickly people are responding to emails or returning calls, or how often requirements meetings are held.
Requirements gathering is a billable activity: a lot of clients assume that you do it for free. I think that as long as they can use the specific information and your interpretation of their needs to develop a product, you should be paid for it. You may choose to charge a different rate - this activity is typically done by a consultant.

TimeTrak: How To Start A Project

Before you write the first line of code for any project, you better have a plan! Better still, you should have full documentation for the project, including requirements documents, design documents, and most importantly a contract that defines the project scope. To me, defining a project scope includes finalizing how you will be paid, how much, what you will do, what the project encompasses, and perhaps a schedule that's subject to change. How do you get there?

I usually start by understanding the project scope. Through emails and coffee shop meetings, I seek to understand what the product from the project is expected to acheive (the goals) from a non-technical perspective. Usually, it is business-minded people you will encounter first, and most are good at expressing their ideas and what they want. Take good notes because it's your job to translate all their blurb into something that makes sense technically. The results of this analysis will tell you whether (a) you have the skills and resources for the project (b) what is involved so you can adjust your price, or (c) whether the project can be successful at all. This has to last a short period because you are doing it for free.

Next you draw up a requirements document that explains what you understand and how you intend to acheive the solution/product. I use a modified IEEE-recommended software requirements specification (SRS) template, providing an overview of the project, breakdown of the project into phases, cost analysis, and a contract. Before you start the first phase, this has to be agreed to by all parties, because it locks down the scope.

As soon as the project spec is agreed to, you may now start paid work. I usually prepare by setting up my development enviroment (laptop, libraries I'll need, tools - including IDEs and analysis and test tools, test bays, and brand new notes book). The first day is spent testing a development process I'll use: I prefer end-to-end agile-like development of features including requirements analysis, design, implementation, and test/integration. You build documentation as you go along. The foundation infrastructure in place, you are ready for the first phase.

TimeTrak: GWT+Spring+Hibernate = Awesome

I'm starting a new series about developing interactive web applications using the Google Web Toolkit (GWT), Spring MVC, and the Hibernate persistence libraries. When I started researching these technologies, I could not find adequate and straighforward information about this combination: at best, books I considered from local bookstores were outdated by 2 years or more!
So I've been digging around on my own, looking at forums, and figuring out things myself.

The series will consider all issues involved in developing a web application the way I do it, which may be different from best practices and other industry standards. This is simply how it works for me currently. The goal is to share knowledge and lessons learned. I am still learning these technologies myself, but I know this information will be useful to someone out there just getting started.

You will need: pretty good Java programming skills, good web design skills (for the presentation layer, that is, HTML/CSS), a mind of a software developer (to design applications and how the various components interact), an understanding of relational database concepts (especially object-oriented models - ORM), and good IDE (I use Eclipse a lot, but I'll write the segments for using NetBeans for the benefit of their documentation project), and lots of time. This will be an AJAX application, but you surprisingly don't need Javascript and a whole lot of XML skills to get it working.

The application I will build in this series is a solution to a current need of mine: it'll be a small scale project management application suitable for contract software developers to manage their tasks, invoices, and clients. That's it! Developers can set up projects and define tasks under the projects, give access to clients, and bill clients through the system. Clients can review projects and their progress, view status reports, get a daily email of work done on their projects, and pay their invoices online. Look ma, no papers.
Now I know there might be some super duper commercial product on the market that does these things, but the goal here is to learn to write one myself using these technologies. The whole project is built in Java. I'm calling this project TimeTrak, after an existing project I already have with the same name. This is like a 2.0 version of it.

NetBeans IDE Delivers For C/C++ Development

For more than a couple of years, I haven't done any serious C/C++ development work - until now. After a brief search and test of various compilers, debuggers, make utilities, and editors, I think the NetBeans 6.5 IDE delivers best in a centralized integrated environment. I also considered both the current Microsoft and Borland offerings (they are unnecessarily too huge and cost money - and these two conflict e.g. debugging with DLLs built in Turbo C++ will not work when using the MS version), CodeBlocks, and DevC++ (both are good). When I last tried the NetBeans IDE, C/C++ support was serious lacking and I was gravely disappointed.

This time around, the people at Sun have built a separate NetBeans IDE for C/C++ development. It integrates with Cygwin tools much better than I remember. It can't be easier than this.
After installing the NetBeans IDE, you only need to download the Cygwin installer and install (at a minimum) the following tools from the Devel node: binutils, gcc-core (C compiler), gcc-g++ (C++ compiler), gcc-mingw-core (MingW32 support headers/libs for GCC), gcc-mingw-c++ (MingW32 support headers/libs for C++), gdb (GNU debugger), make (GCC version of the make utility), makedepend (makefile dependency tool), and mingw-runtime.
Finally set the system environment variable "Path" to include the location of the Cygwin binaries (usually %cygwin_install_dir%\bin) and restart the NetBeans IDE. It picks up on the tools it needs, and off you go.
The memory footstamp is minimal, unlike the Java-focused NetBeans IDEs I have tried in the past. It starts up quickly and is quite intuitive and straightforward. Only bit of inconvenience is that even simple programs must be developed as part of a project. Good practice but not necessary to be enforced that way.