SImple way to kill phising

The simple way to kill phishing is by making it harder for the phisher to make money from it. If you get phishing e-mail, go the web sites and enter false data. Make up everything -- name, sign-on name, password, credit card numbers, everything. Instead of one million messages yielding 100 good replies, now the phisher will have one million messages yielding 100,000 replies of which 100 are good, but WHICH 100?

This technique kills phishing two ways. It certainly increases the phishing labor requirement by about 10,000X. But even more importantly, if banks and e-commerce sites limit the number of failed sign-on attempts from a single IP address to, say, 10 per day, theft as an outcome of phishing becomes close to impossible.

Fundamentals of Business

From http://calacanis.weblogsinc.com/entry/1234000053039351/
Business is about three very basic things:

1. Hustle
2. Passion
3. Resiliency

You have those things it really doesn’t matter what the idea is… you can change your ideas all day long, in fact evolving is what you’re supposed to do in business. However, you can’t substitute hustle, passion, or resiliency.

You can certainly learn, and defiantly enhance, those three core attributes. People get caught up in the text book theories of business and forget reality. Serving customers, being passionate about what you do, serving more, caring more, giving more...that's what makes success. Know your customer, solve a need, and deliver value to your customer.

Good developer

A good developer need to understand the business, and as as a minimum understand that you are being hired to create solutions to business problems.

Be able to look at a business, see and understand the problems the business currently faces, innovate to solve said problems, and then are able to communicate with a non-technical audience the business benefit of the technical solution. Focus more on understanding the customer than on understanding the technology ('though you need both, of course).So, things like usability are critical.

Another crucial component of any good developers repertoire is change management, a good developer has to not just cope with change, but embrace it. When you approach a problem domain you look at it without thinking about the technology. You look at it from a business perspective, find the requirements, the end-users etc and then once you have done that you then decide on the technology. Now this may be a Java solution, but then maybe it is a .NET one or PHP or VB or whatever it has to be right for the business. I would expect any developer to be able to adapt and to pick up whatever the choice may be and become productive. The forementioned reason is why I am unimpressed with those who can recite the Java API from memory, my personal feeling on this is that you should now what is available (whether it be in Java, PHP, Perl, C/C++ whatever) from a higher level and not confine yourself to a particular technical space. However, how to use it (ie the API) you don't need to know to a great level of detail until you actually start the work.

Layered Architecture design

Taken from http://www.hibernate.org/124.html
Just to expand on the architecture I chose (and have briefly and disjunctly discussed on the forum). Let me first suggest a great book on this subject, written by Martin Fowler, entitled "Patterns of Enterprise Application Architecture". It is extremely insightful, helpful and well written.

It seems that most of the discussion that I have seen on the forums regarding this topic relate to whether the objects mapped in Hibernate should be returned as-is to the clients, or whether some form of abstraction should be used to represent that data (whether XML, DTO, Commands, etc). To me, each approach has pros and cons. In my architecture, I chose the latter using DTOs as the communication medium with the presentation. In brief, my architecture is as follows:

1. At the bottom tier is a very strong domain layer (mapped using Hibernate). By very strong, I mean that it bundles all the data elements mapped from Hibernate along with a lot of domain logic (see the section discussing business logic vs domain logic in the chapter on the "service layer" pattern in Fowler's book)...
2. A set of DAOs with static methods for various methods of locating domain objects using HQL or session.load()
3. A service layer, implemented as session beans for no other reason than for the transaction support as I have to coordinate transactions across JMS, LDAP as well as the DB. This could easily be non-ejb also, possibly using aspects to acheive transaction "cross-cuts".
4. a set of "assemblers" (again, see Fowler) which are responsible for "molding" domain objects into DTOs and "swizzling" DTO data back into domain objects.
5. a slew of DTOs which carry data to and from the clients of the service layer.

To me, there are a couple of pros to this type of approach. Number one would have to be the fact that it completely decouples the client from anything that happens behind the service layer, and vice versa. Part of this is not having to worry about things like whether lazy relationships have been loaded when adding a new column to a search result table. Another advantage is that is gives your app a much more defined API feel. The methods exposed on the service layer are the functionality provided by the system to the outside world. And because a lot of the "nitty-gritty" code is hidden away in the DAOs and the assemblers, the service code is very clean. An example would be:

public ContactDTO loadContact( Long contactId )
throws my.PersistenceException
{
prepareCall();
try
{
return ContactAssembler.buildDTO( ContactDAO.load( contactId ) );
}
catch( Exception e )
{
throw new my.PersistenceException( "Unable to load contact", e );
}
finally
{
endCall();
}
}

The cons mainly deal with the fact that that's a lot of extra classes to code. At a minimum, in a small app, you can assume about a one-to-one correspondence between the domain objects in your app and their various DTO representations; this may be even bigger for larger apps. Why? Mainly it has to do with relationships and avoiding infinite loops. Consider a ContactDTO with a relationship to a CompanyDTO, which in turn has a collection relation to its employees which are ContactDTOs. This is normally handled by having different DTO representations of data with different "loading levels" (similiar to the Lightweight pattern discussed on the Hibernate patterns page). Thus, you now would have something like ContactDTO -> CompanyDTO -> ContactListDTO. And thats not even considering specialty DTOs like report DTOs, etc. Its hopefully pretty easy to see how this can become a lot of extra classes. Luckily, all these DTOs are pretty brainless to create as they are generally very simple Java Beans.

Development practices that could help make the software product popular quickly.

• 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.

Interesting quote

If you are willing to pay only peanuts, you will get only monkeys

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.

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.

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

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.

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.

A simple basis for judging people

You can accurately judge the worth of a person or organization, even yourself, by how well these three things are done:
1. Promising only what you intend to deliver
2. Keeping your word once given
3. Following through so as to meet expectations
We trust people who do these things. People who don't do these things are untrustworthy, no matter who they are, how educated they are, or how important they may be.

Article on using the "final" java keyword

http://renaud.waldura.com/doc/java/final-keyword.shtml

Nerdiness

Citizenship day

It was the day I became a US citizen. I took the oath of allegiance and renounced my citizenship to India. Received a personal letter from the White House signed by the president. Some complex words in the oath : abjure, potentate