- rapid release schedule:Regular file releases (even a few days from one version to the next) were the best way to keep the project bug-free and users confident that the project is active. Having working software "out there", in actual use, is the best way to discover which functionality the users really need.
- regression tests: The importance of automated unit tests should not be underestimated. A comprehensive test suite is central to the maintainability and stability of any product, as it goes through massive changes in functionality and design. The mentality should be that if there is no test for a feature, then we have absolutely no idea whether that feature works or not.
- documentation: There's no such thing as an undocumented feature. If your users don't know about a feature, its a nonfeature. Get rid of it; it's just complicating the sourcecode.
- developer responsiveness: When users have problems, which they inevitably will, the development team must be responsive and helpful. Users let you know about holes in your documentation. Users find the subtle bugs that your test suite misses. And besides, the project is a waste of time without them. Incidently, heres a funny thing about bugs: users don't mind discovering bugs in new features, as long as they are fixed quickly. "Responsiveness" means bugfixes should be ready in under a week. 24 hours is a good target for the average response time between a bug report and the CVS fix.
Monday, March 21, 2005
Development practices that could help make the software product popular quickly.
Saturday, March 19, 2005
Friday, March 11, 2005
Junit vs TestNG
Junit Cons :
1. Each Test object is instantiated over and over again for every Test method.
2. Need to use statics to maintain any sort of state across invocations.
3. Relies on a static programming model which makes it difficult to run a subset of tests.
4. Have to start all your methods with 'test' and extend a base class.
TestNG pros:
1. Runtime configuration is in a XML file rather than a java source and so you can specify test groups and other relationships between tests. This allows useful stuff like being able to have a specified test run order, dependent tests (test X requires Y and Z to be run first). So for example, if you have some kind of 'verify db connection' as the first method, you can specify that all other tests depend on it, so once the first one fails, the others are not run since we've had an early failure.
2. The grouping support is quite powerful, since you can arbitrarily slice and dice your test into whatever groupings make sense for you. So for example, you can specify that a test is part of the 'functional' group, the 'config' group, and the 'database' group. You are then able to execute all tests within a particular group.
3. It extensively uses annotations (or JDK 1.4 javadoc comments) for metadata. The annotations available are a pretty rich set of controls to customize and specify test behavior. You can for example specify a timeout on a per test basis (if this takes more than 10 seconds, warn etc.)
Test NG Cons:
Tool adoption. For example with WSAD I can point at unit test class and use debug/run as a Junit program etc. Also there is this this JUnit EE that is a web application to test EJB modules that run inside the J2EE container.
1. Each Test object is instantiated over and over again for every Test method.
2. Need to use statics to maintain any sort of state across invocations.
3. Relies on a static programming model which makes it difficult to run a subset of tests.
4. Have to start all your methods with 'test' and extend a base class.
TestNG pros:
1. Runtime configuration is in a XML file rather than a java source and so you can specify test groups and other relationships between tests. This allows useful stuff like being able to have a specified test run order, dependent tests (test X requires Y and Z to be run first). So for example, if you have some kind of 'verify db connection' as the first method, you can specify that all other tests depend on it, so once the first one fails, the others are not run since we've had an early failure.
2. The grouping support is quite powerful, since you can arbitrarily slice and dice your test into whatever groupings make sense for you. So for example, you can specify that a test is part of the 'functional' group, the 'config' group, and the 'database' group. You are then able to execute all tests within a particular group.
3. It extensively uses annotations (or JDK 1.4 javadoc comments) for metadata. The annotations available are a pretty rich set of controls to customize and specify test behavior. You can for example specify a timeout on a per test basis (if this takes more than 10 seconds, warn etc.)
Test NG Cons:
Tool adoption. For example with WSAD I can point at unit test class and use debug/run as a Junit program etc. Also there is this this JUnit EE that is a web application to test EJB modules that run inside the J2EE container.
Crappy software
Installed RAD V6 (IBM® Rational® Application Developer Version 6.0 ) today. The software should be made synonymous with crappy. They should have a warning like this :
Do not install this if you have a heart condition, suffer from asthma, are afraid of the dark, or do not like to live dangerously. Your mileage, and performance, may vary. The irony of this is -- rampant bugs in this software -- which we already paid millions for-- force us to call the "support services" arm of said company, who then get to work busily fixing the bugs in their own product for whatever cost our support contract was paid for.
Do not install this if you have a heart condition, suffer from asthma, are afraid of the dark, or do not like to live dangerously. Your mileage, and performance, may vary. The irony of this is -- rampant bugs in this software -- which we already paid millions for-- force us to call the "support services" arm of said company, who then get to work busily fixing the bugs in their own product for whatever cost our support contract was paid for.
Thursday, March 10, 2005
EJB's: reasons to avoid
http://discuss.joelonsoftware.com/default.asp?joel.3.91272.13
There is a growing sentiment in book and non-book form that EJBs don't provide enough benefits for their considerable costs. Witness projects like the Spring framework and books like Rod Johnson's 'J2EE Without EJB' and Bruce Tate's 'Better, Faster, Lighter Java'. The only place where the benefits seem to outweigh the costs is with distributed transactions.
Some of the mythical benefits of EJBs:
1) 'You get declarative transaction handling'. This can be an OK benefit if your transaction needs are simple and straightforward (for example a single method is always a single transaction). If you want to start stringing together multiple methods into transactions (I can't imagine why anyone would need to do that) you have to start using certain design patterns to get around the limitation. At that point you may as well just do the transaction handling yourself because its not really that hard and you'll never have to spend the day trying to figure out what is wrong with your deloyment descriptors.
2) 'You get scalability'. People referring to this are usually referring to object pooling and the perceived notion that J2EE includes clustering support. The J2EE spec only makes mention of clustering support as a vendor specific add on. Most of them support it and they do it to varying degrees with varying levels of effectiveness. There is nothing in EJB that makes clustering easier - in fact it usually makes it much harder (what happened to my bean? why is it on server A when I want it on server B?) In regards to object pooling the only bean type that supports pooling are stateless session beans. Since the beans are stateless I can't really figure out what you get by having more than one of them. A simple singleton is an excellent replacement with none of the pool management overhead (I seem to have a reference to a non-existent bean. I guess I'll just write a whole bunch of call re-try logic - every time I make a bean call anywhere).
3) 'You get object persistence for free! FREE!!!' Entity Beans are just an all around bad idea. And a well documented bad idea too. See Bruce Tate's 'Bitter EJB' - he has a few chapters dedicated to why it's a bad idea.
4) Security. The only thing that EJB security really does for you is allow you to declare which application roles have execution permissions on which methods. Sounds nice in principle but in my experience it doesn't justify both the runtime costs and the configuration effort (get ready to trudge through a slew of XML files every time that you add/modify/remove a method). There just aren't enough methods where you are really adding security by saying 'These kinds of users can't execute this method'. Real authorization is often more complex than that and usually involves the data itself (user A can modify account number 123 but not account number 789).Don't neglect the costs of EJB usage either. There's a reson why EJB generates all of those classes for you. They're going to get executed. Every time you make a method call. You'll also pay some of the prices of remoteness even when most deployments don't involve remote communication. Sure you can use local interfaces if you know ahead of time that the call will be local - but there is still some overhead like JNDI lookups and whatnot. Why do a JNDI lookup when a method call will do?
The development costs are considerable as well. Configuration files can be an absolute nightmare - although there are tools to mitigate some of the issues. You'll start to wonder exactly what the point is when you're apending more time digging through XML than code. Server/application load times can be horrendous if you have more than a few beans. Not so bad for production but it's a real drag for development to wait 3 minutes for a server restart every time you want to test your code. But hey it's not like you do that 50 times a day or anything ;) And everytime all of the developers are sitting in a room trying to figure out just how it is that these classloaders are working. Count the number of times that you use the word classloader in your EJB world versus pre-EJB
There is a growing sentiment in book and non-book form that EJBs don't provide enough benefits for their considerable costs. Witness projects like the Spring framework and books like Rod Johnson's 'J2EE Without EJB' and Bruce Tate's 'Better, Faster, Lighter Java'. The only place where the benefits seem to outweigh the costs is with distributed transactions.
Some of the mythical benefits of EJBs:
1) 'You get declarative transaction handling'. This can be an OK benefit if your transaction needs are simple and straightforward (for example a single method is always a single transaction). If you want to start stringing together multiple methods into transactions (I can't imagine why anyone would need to do that) you have to start using certain design patterns to get around the limitation. At that point you may as well just do the transaction handling yourself because its not really that hard and you'll never have to spend the day trying to figure out what is wrong with your deloyment descriptors.
2) 'You get scalability'. People referring to this are usually referring to object pooling and the perceived notion that J2EE includes clustering support. The J2EE spec only makes mention of clustering support as a vendor specific add on. Most of them support it and they do it to varying degrees with varying levels of effectiveness. There is nothing in EJB that makes clustering easier - in fact it usually makes it much harder (what happened to my bean? why is it on server A when I want it on server B?) In regards to object pooling the only bean type that supports pooling are stateless session beans. Since the beans are stateless I can't really figure out what you get by having more than one of them. A simple singleton is an excellent replacement with none of the pool management overhead (I seem to have a reference to a non-existent bean. I guess I'll just write a whole bunch of call re-try logic - every time I make a bean call anywhere).
3) 'You get object persistence for free! FREE!!!' Entity Beans are just an all around bad idea. And a well documented bad idea too. See Bruce Tate's 'Bitter EJB' - he has a few chapters dedicated to why it's a bad idea.
4) Security. The only thing that EJB security really does for you is allow you to declare which application roles have execution permissions on which methods. Sounds nice in principle but in my experience it doesn't justify both the runtime costs and the configuration effort (get ready to trudge through a slew of XML files every time that you add/modify/remove a method). There just aren't enough methods where you are really adding security by saying 'These kinds of users can't execute this method'. Real authorization is often more complex than that and usually involves the data itself (user A can modify account number 123 but not account number 789).Don't neglect the costs of EJB usage either. There's a reson why EJB generates all of those classes for you. They're going to get executed. Every time you make a method call. You'll also pay some of the prices of remoteness even when most deployments don't involve remote communication. Sure you can use local interfaces if you know ahead of time that the call will be local - but there is still some overhead like JNDI lookups and whatnot. Why do a JNDI lookup when a method call will do?
The development costs are considerable as well. Configuration files can be an absolute nightmare - although there are tools to mitigate some of the issues. You'll start to wonder exactly what the point is when you're apending more time digging through XML than code. Server/application load times can be horrendous if you have more than a few beans. Not so bad for production but it's a real drag for development to wait 3 minutes for a server restart every time you want to test your code. But hey it's not like you do that 50 times a day or anything ;) And everytime all of the developers are sitting in a room trying to figure out just how it is that these classloaders are working. Count the number of times that you use the word classloader in your EJB world versus pre-EJB
Tuesday, March 08, 2005
Struts check box bug
When a check box is unchecked, the form bean property associated with the checkbox never changes from "true" to "false" or from "On" to "Off" based on the property type being a boolean or String.
Apparently this is a bug in Struts:http://forum.java.sun.com/thread.jspa?threadID=242031&messageID=2946045
On further research, found out that this is not really struts issue, but an issue with the mechanism of HTML form posting of check box values.
Apparently this is a bug in Struts:http://forum.java.sun.com/thread.jspa?threadID=242031&messageID=2946045
On further research, found out that this is not really struts issue, but an issue with the mechanism of HTML form posting of check box values.
Monday, March 07, 2005
Poblem stating
To master the art of problem solving, master the art of problem stating. http://www.jroller.com/comments/njain/Weblog/to_master_the_art_problem
The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don't solve the right problem.
The problem definition defines what the problem is without any references to possible solutions.
The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don't solve the right problem.
The problem definition defines what the problem is without any references to possible solutions.
Subscribe to:
Posts (Atom)