Braches work and branching cannot be avoided if you have real life project with installed base of old releases that have to be supported.
But you must be careful with the branches and understand how branching and merging work. Good idea is to write and to rigorously follow very hands down branching guidelines for your project with all the updates and -d's and -P's in place so that even the more experienced have no excuse for not doing it right ('oops, I forgot to cvs -xyz foo -bar').
One thing I found out when doing XP (Agile nowadays?) style development was that it is good to use very short lifespan on most branches i.e. use temporary branches for each implementation unit and merge the changes to the development branch when the unit is finished.
Long lived branches should be used when updating old and developing new releases, one per release.
The temporary braches should be really temporary with lifespans as short as 30 min and never leave them hang around to the next day.
Of cource the standard XP practice of running unit tests each time you build running "make" or "ant" and passing them all before you "commit" the merge is also quite recommendable.
It is also a good idea to require all working in the same release branch to update each time a merge (or "integration" in XP) is done.
Apart from speed the more interesting thing in Prevayler is that it provides an easy and transparent way to persist objects as is. You do not need to switch programming paradigm when you store data.
If your objects map directly to relational database tables your classes most probably model some relational database and not your application domain.
The biggest problem using RDBMS to store objects is that they are designed to store data, not objects. There is big impedance mismatch between the object world and relational world. Designing object oriented applications with restrictions borrowed from RDB world creates totally un-object-oriented programming models like EJB where you end up separating data and functionality to different components. This is just the opposite to the object paradigm where data and functionality go together and are both variable from object to object ("record to record" to RDB people).
This is not to say that OO is better or worse than RDB. They just do not match well and it is quite stupid to bind them tight together when building new applications from scratch.
Since I got my IBM Thinkpad laptop with the TrackPoint pointing device (in the center of the keyboard) all my wrist pain from the right wrist has gone. If I had to start using a desktop again I would purchase a keyboard with TrackPoint (IBM has such a thing).
I find the laptop keyboard very comfortable because there is room to rest the arms unlike in normal keyboard. The only concern is that the keyboard is of cource a little bit small but I am used to that now.
Does anyone know other manufacturers of keyboards with TrackPoint like pointing devices? I do not want to sound like advertising IBM...
Slashdot Mirror
Braches work and branching cannot be avoided if you have real life project with installed base of old releases that have to be supported.
But you must be careful with the branches and understand how branching and merging work. Good idea is to write and to rigorously follow very hands down branching guidelines for your project with all the updates and -d's and -P's in place so that even the more experienced have no excuse for not doing it right ('oops, I forgot to cvs -xyz foo -bar').
One thing I found out when doing XP (Agile nowadays?) style development was that it is good to use very short lifespan on most branches i.e. use temporary branches for each implementation unit and merge the changes to the development branch when the unit is finished.
Long lived branches should be used when updating old and developing new releases, one per release.
The temporary braches should be really temporary with lifespans as short as 30 min and never leave them hang around to the next day.
Of cource the standard XP practice of running unit tests each time you build running "make" or "ant" and passing them all before you "commit" the merge is also quite recommendable.
It is also a good idea to require all working in the same release branch to update each time a merge (or "integration" in XP) is done.
Apart from speed the more interesting thing in Prevayler is that it provides an easy and transparent way to persist objects as is. You do not need to switch programming paradigm when you store data.
If your objects map directly to relational database tables your classes most probably model some relational database and not your application domain.
The biggest problem using RDBMS to store objects is that they are designed to store data, not objects. There is big impedance mismatch between the object world and relational world. Designing object oriented applications with restrictions borrowed from RDB world creates totally un-object-oriented programming models like EJB where you end up separating data and functionality to different components. This is just the opposite to the object paradigm where data and functionality go together and are both variable from object to object ("record to record" to RDB people).
This is not to say that OO is better or worse than RDB. They just do not match well and it is quite stupid to bind them tight together when building new applications from scratch.
In my experience the mouse is the killer.
Since I got my IBM Thinkpad laptop with the TrackPoint pointing device (in the center of the keyboard) all my wrist pain from the right wrist has gone. If I had to start using a desktop again I would purchase a keyboard with TrackPoint (IBM has such a thing).
I find the laptop keyboard very comfortable because there is room to rest the arms unlike in normal keyboard. The only concern is that the keyboard is of cource a little bit small but I am used to that now.
Does anyone know other manufacturers of keyboards with TrackPoint like pointing devices? I do not want to sound like advertising IBM...
See the lyrics of Experiment IV.