|
|
||
Richard Monson-Haefel's BlogExtreme Programming ArchivesOpenEJB: The BEST way to test EJBsPosted by monsonhaefel on June 11, 2004 at 09:10 AM | Permalink | Comments (3)The server side has published an article by N. Alex Rupp on how to use OpenEJB for testing your EJB applications. Advanced EJB Testing with OpenEJB David Blevin's and I founded OpenEJB some five years ago to create a fast and lightweight EJB container system that could be easily embedded in any application (its even been used in handheld devices). I stayed with the project for the first couple of years, but haven't been very involved in it since. David Blevins, on the other hand, has kept the project going and has continuously improved it (along with a small army of volunteers). Today OpenEJB the EJB container system used with Apache Geronimo - its very powerful, fast, and best of all lightweight. The fact that OpenEJB is so lightweight and embeddable is why it actually serves as an excellent EJB testing tool. It starts up and deploys EJBs is seconds (that right I said seconds, not minutes). In addition, it provides a robust and fully compliant EJB container system - one that is used by Apache Geronimo for production enviorments. Rather than create some type of home spun "moch" container system use OpenEJB. All the hard stuff is done - you don't have to re-invent the wheel. As you'll see in Rupp's article, OpenEJB is ridiculously easy to work with and provides you with the best EJB testing framework available today.
I would go a bit further and encourage people who are using commercial products like WebLogic and WebSphere to use OpenEJB in development. A developer can deploy and redeploy his EJBs over and over again quickly, giving him time to focus on developing his EJBs rather than waiting for a server to start-up and deploy an J2EE application - a process that I believe saps as much as 80% of development time.
9 of Clubs Seeks a new Deck of CardsPosted by monsonhaefel on May 06, 2004 at 02:31 PM | Permalink | Comments (15)Recently I had the honor of being named one of the 53 most influential people in the Java industry by The Middleware Company. My card was the 9 of Clubs I have no idea how to interpret that distinction. Obviously, its a nice complement especially considering that the votes came from developers who subscribe to TheServerSide.com mailing list a resource I consult regularly even if the threads are frequently hijacked. You would think that a guy in this deck of cards is probably making gross amounts of money and living a leisurely life. I can't speak for the other people on the list, but that doesn't describe my life at all. I work really freaking hard as hard as anyone reading this blog and I don't own a yacht or drive a Lamborghini. I'm not poor by any stretch of the imagination, but I'm not going to make the Forbs list anytime soon. The truth is being an independent is hard work. I've been at it now for about five years and its never been a cake walk ok occasionally it's been easy, but most of the time its not. For the most part I'm busting my butt trying to convince companies that I'm worth what I'm worth even if John and Jane Doe charge a faction of the price. The truth is, I'm usually over qualified for most consulting gigs so the spectrum of opportunities available to me is actually less than the average developer. I heard once that winning an Oscar in Hollywood is a double edge sword. Actors who win are recognized for the quality of their work, but subsequently find it hard to find work. I even heard it descried as the Oscar "Death Knell": Its great to win, but its better to get nominated. This is probably a bit of hyperbola and I don't mean to compare my meager success to winning an Oscar, but the truth is: Success is measured in many ways and peer recognition while wonderful doesn't always translate into big bucks and loads of free time. After more than five years of going-it-alone, I finally asked for help. This Monday I decided to try my luck for the first time with the grape vine. Although I have frequently helped others find work, I've rarely asked for help myself. Why? Well I guess I felt that I should be able to find my own work. Also its a matter of pride. I dont like to ask for help. I don't want my peers to know that its hard for me to find work that fits my skills and pays well everyone seems to assume that if your well known you automatically make tones of money. Its not always true. I've been very involved in the Java industry. Two months after I started learning Java I started the Wisconsin Java User's group that was back in the spring of 1996. Since than I've volunteered for all sorts of things from open source projects to JSRs and I'm proud of what I've accomplished. The culmination of all this altruism was being voted into the JCP Executive Committee last fall an honor I've take very seriously. I've done good things for our industry, but I feel its time to step back and let others have the glory. I have a family now. My boy, Henry is about 2 1/2, and my daughter, Olivia, is just 9 months. I need to look inward toward my family and put them first. That means I need to find a stable job with some longevity and hopefully something with a lot less travel. I think I was honored with the 9 of clubs because I've donated so much of my time to the Java community people will probably laugh at that, but I can't think of any other reason. Working on expert groups, open source, and the JCP consume enormous amounts of time, but pays nothing, zip, zilch. That's ok, I knew that going into these endeavors and its expected that I should be able to leverage my contacts and name recognition into a living. I have done that to some extent, but it hasn't been easy. You still have to find work that fits your credentials and sell yourself at rates that are affordable these are usually contradictory objectives after a certain point. OK, so why this blog? Well, I'm hoping that someone will read it and say "Hey, I got just the job for this guy! What's his e-mail address?" (btw it is Richard@Monson-Haefel.com). Head hunters and other professional placement guys should not bother to contact me - you guys are evil.
There is another reason: On occasion I've had people ask me how they can manage their career to become more successful to be more like me. This always makes me wince. I've been fortunate no doubt about it but I wouldn't recommend my life style to anyone. Its a lot of work with very little pay. As I said, peer recognition is great its probably the best recognition you can have but making a living is not a bad thing either. I'm honored to be counted in that deck of cards with the likes of James Gosling, Rod Johnson, Gavin King and others but its time to join a new deck one that gives me more time with my family and actually pays a salary.
JSR-241: Groovy – A New Standard Programming Language for the Java PlatformPosted by monsonhaefel on March 16, 2004 at 05:23 AM | Permalink | Comments (41)JSR-241: The Groovy Programming Language proposes the standardization of a new programming language for the Java Platform – one that is on equal footing with the Java programming language. Groovy is an agile, dynamic programming language like Python, Perl and Ruby, but it's designed specifically for the Java Platform and is completely interoperable with conventional Java programs. Groovy is not a replacement for the Java programming language; it’s a complement to that language. It fills a niche that is in demand by developers but is currently neglected by the Java Platform. Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down. An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more. To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification – two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself. Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. It’s the recognition that the Java is more than a programming language; it’s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform. The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.
So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform.
| ||
|
|