Slashdot Mirror

Having worked with and managed a number of programmers over the years I've had the privilege of working alongside a number of truly gifted people. But for every rock star there are far more mediocre and inept persons for the role. On the lower-end of the quality I've seen work so shoddy that it was insulting - those people don't last long in the role but might be suitable for other positions. We try our hardest to retain the top talent but sometimes they just like to wander from project to project for their own interests. Thankfully they seem to like us enough that they always consider coming back after they've had their walkabout.

Not starting a religious war here, but the only pattern I can offer is that those lacking any formal education (self-taught/hobbyist) and those whose primary skill and experience is PHP have had the most disappointing performance. Those among the best performers stay current and attend technical conferences & seminars on topics that interest them. One particular symposium that yields great results for our team and projects has been No Fluff Just Stuff YMMV.

Uh, nope. Not kidding, Cassandra

Perhaps it's an AT&T-specific issue, I certainly haven't seen the issue on australian carriers.

very useful if you know how to apply design patterns.

If we're talking about *Javascript* design patterns -- common useful Javascript idioms -- then I think this is a useful statement. If we're talking about common idioms that have filtered out from C++ and Java known as "design patterns" as applied to languages that don't need to many of them, then I'd say Javascript is pretty useful even if you don't know much about them. Possibly more useful.

http://www.nofluffjuststuff.com/show_session_view.jsp?presentationId=9542&showId=114
http://www.codinghorror.com/blog/archives/000899.html
http://steve.yegge.googlepages.com/singleton-considered-stupid

It's an amazing framework. I think that's one of the reasons it's getting so much interest.

AOP is not the answer to everything, but one of the main points of a talk I give at the NFJS show is that you can find tons of uses w/ development aspects without ever having to migrate them into production.

You can enforce (and detect violations of) various architectural decisions (i.e. no direct JDBC connectivity without going through a facade), define and enforce contracts (and leave them out of production), detect threading issues (How would you find all Swing thread abuse cases in a large, multi-threaded application?), get a sense of code coverage, etc. around any arbitrary cut of your system.

If you take the time to build around interfaces and support Object decoration via some variant of factories, you can do some of these things using Decorator and Dynamic Proxies, but you don't always have that luxury.

Tool support has been fundamentally lacking until things like recent versions of the AJDT. It still isn't perfect, but should serve to answer many of the early critics complaining about debuggability and losing track of what is going on.

I am an advocate of AOP in production systems, but you don't have to drink the whole glass to find aspects tremendously useful in development alone. With support for Ant-based builds and whatnot, it isn't even really an onerous task to give it a try.

Don't use AOP for things it isn't a good fit for, but there are quite a few things that can't be done as easily and elegantly without it (at least in Java). As others have pointed out, languages like Lisp and Objective-C have support for AOPish things built in.

I cannot give you an answer for your particular situation, but I can tell you my opinion, based on my real-world experience.

I am the chief architect for a major application developed by the U.S. State Department, and used by foreign governments for the licensing of hazardous materials.

We use J2EE, and have been since 1999. JBoss is our application server. We used to use Weblogic, and were technically happy with it, but JBoss does everything we need, and has licenses and costs more favorable for our end users.

Our application is a bunch of domain objects and custom business logic, presented by the J2EE server as a bunch of sessions beans (some stateful, some stateless). We have a swing and a web-based client. Most of the rich interaction is done with the swing client, with mostly browsing and canned searching from the web-based client.

We do NOT use Entity beans - and I don't suggest anyone use this part of the EJB specification... For data persistence we use The Versant Object-Oriented Database. For data persistence, I'd recommend this, JDO, or Hibernate talking to the relational database of your choice.

We are very happy with the choices we have made. There is a TON of information out there about J2EE, we are happy with the performance we get, the skills are readily available, and there are plenty of vendors building tools in that space. J2EE is obviously a realistic choice for the kind of work you are doing - and has been for many years.

I do not know much about .NET... only because that isn't where my career has taken me, not because of any dogmatic stance. My major concern about using it for this kind of work is that there is no 'application server'... .NET is tied to the windows platform. I know there are projects like Mono, but realistically, if you are using .NET, you are buying into Microsoft, their tools, and their solutions. With J2EE, I can upgrade my operating system and my application server independently - choose from different vendors for both, play them against each other for cost/support benefits, etc. With .NET, you just won't have these long-term options.

I am the president of the Northern Virginia Java Users Group. While some may say this makes me biased, I'm not an employee of Sun or anything... I work for a relatively small company. I am involved in the NovaJUG because I happen to know and like Java, and like to teach. I also occasionally speak at conferences such as the No Fluff, Just Stuff Software Symposiums. I'm not going to leave my email address or anything, but there is enough info in this to track me down. IF you would like to discuss this further, drop me a line.

Java isn't going anywhere. Java has at least reached the status of 'the next cobol', to quote Stu Halloway. This isn't a comment on Java's speed, quality, and such, it simply means that even if all Java development stopped today (which it won't), there has been enough investment in Java'based intfrastructure that the maintenance alone will be quite a large job market for years to come.

Java is NOT dead/dying. New, important projects start with it every day. I am the president of the Northern Virginia Java Users Group, and we have a steadily growing membership (now over 1100 members). I am also a speaker for the No Fluff Just Stuff Software Symposiums, and the discussions about Java tools, techniques, etc dominate that conference. Why? Because it sells. .NET has been gaining some momentum, and c# is undoubtedly the 'next big thing', but Java is here to stay. If you are a software engineer, Java is a 'safe place' to be for new and interesting work for the next 4+ years, at least. (That doesn't mean software engineers don't need to have diverse talent - but that is a topic for another rant).