Five habits of highly profitable software developers for those who might think writing code can be career limiting
Or are we doing something wrong?
Aspect Oriented Programming for me always has been something that is theoretically beautiful but in practice unfeasible to apply: A good idea that buried itself by bad examples and complex implementations. Until Google pointed me to this great article about AspectJ5 and its integration into the Spring Framework. Actually I was looking for some EJB3 related Spring material but I ended up reading probably one of the first articles that after finishing left me with a �yep, I really want to do AOP, even at home’-kind of feelings.
The whole idea is actually super simple. AspectJ has been extended with two very handy mechanisms: a run time (actually load time) weaving engine and support for aspects that are expressed in Java 5 annotations. Using AspectJ’s API we do not have to rely on a separate compiler but the process of aspect weaving can be initiated whenever we like. And that is exactly the trick Spring is using. Aspects are actually Spring managed instantiations that influence other spring managed beans. When Spring is loading bean classes, cross cutting aspects are weaved in like a breeze.So, I grabbed the latest Spring release (2.0), read some more background information and started right away. Within minutes an AspectJ based interception of a completely meaningless but spring managed hello world bean was up and running. Cool! Hello world never has been so enlighting. To make things a bit more practical, I tried to implement a typical architectural constraint like “Methods on classes belonging to the an applications data access layer may only be called through methods of classes belong to the service layer.”. Normally this constraint is written down by software designers in a plain ms-word or odf ‘thou shall not’-document, but using Spring AOP it can be expressed in a bit of xml (yep, Spring ….) and a Java class. ( I am not going to argue the semantic practicalities and implications of this constraint, for me it is just an example to express the �aha feeling’.) Okay, here are some interesting pieces of the class I wrote. Full details can be found in this posts attachment (acsa.zip). @Aspect public class SystemLayeringAspect { // ……define the pointcuts to identify different layers @Pointcut(”within(com.logicacmg..*.service.*)”) public void inServiceLayer() { }@Pointcut(”within(com.logicacmg..*.dao.*)”) public void inDataLayer() { }
add some thread local sugar for administrative purpose private static ThreadLocal tlServiceCount = new ThreadLocal() { protected Integer initialValue() { return 0; }
};
define the advice to register the usage of service method calls@Around(”inServiceLayer()”)public Object serviceUsage(ProceedingJoinPoint thisJoinPoint) throws Throwable {
tlServiceCount.set(tlServiceCount.get() + 1);
Object result = thisJoinPoint.proceed();
tlServiceCount.set(tlServiceCount.get() - 1);
return result;
}
and define the advice how to deal with data access calls @Before(”inDataLayer() && this(dao)”)public void dataUsage(Object dao) throws Throwable {
if (tlServiceCount.get() == 0) {
throw new ArchitecturalConstraintFailed(dao + ” can not be accessed directly”);
}
}
Note, the difference in the advice types. The service advice needs to work around the actual method call, the dao advice does its job only upfront.That’s it. simply plug it into your Spring application context after the and off you go. ApplicationContext context = new ClassPathXmlApplicationContext(”application-context.xml”);
ExampleService service = (ExampleService) context.getBean(”helloService”);ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
ExampleService service = (ExampleService) context.getBean(”helloService”);
ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
service.doSomething();
try { helper.helpABit();
} catch (ArchitecturalConstraintFailed afailed) {
System.out.println(”yep catched ” + afailed);
}
In the example used to test the architectural constraint, a dao is called through a helper bean. Calling the helper directly will result in a runtime failure, calling it through the service is no problem. Seems aspect orientation has finally been made easy. Although, one should be aware of the behaviour that aspects are honoured only by java classes that are loaded through Spring. So be careful with the new operator. But besides that, all I can advice is to have fun and make good use of it.
Found on Javalobby a link to Russ Olsens Web Log, having a comment that pointed me to Martin Fowler who has written a nice entry about Buildix. A bundle of essential pieces of software that form the cornerstone of agile development. According to their website everything you need to get started in one easy install. You can download it as CD, VMWare image or as binary package. And as long as you don’t care dealing with linux, it sounds like a very good deal. Have it a try I would say ….
I have a new lease car. Like many other people, I have to go through the traffic jams that block up the highways here in the Netherlands every morning and every evening.I often listen to the radio while I’m in the car. The CD player in my new car has written “mp3″ on it with small letters - it can play MP3 files from CD-ROMs. This gave me an idea: I should find out how podcasting works, I could find some interesting podcasts, put them on a CD and listen to them while I’m in the car.
Podcasting works with RSS news feeds. The news messages in the RSS feed contain links to audio files. You can use a program like Juice to subscribe to RSS feeds and download the audio files, which you can then listen to on your computer, put on your MP3 player or on a CD.
So now I wanted to find some interesting podcasts. This article on O’Reilly’s OnJava website has links to some podcasts about Java.
So far I’ve downloaded a few of the podcasts from Java Posse (RSS podcast feed). There were a few interesting interviews, one with the product manager of Google who is responsible for the Google Web Toolkit, and one with some of the guys on the Swing team at Sun. They were talking about Aerith, a cool Swing demo program that they showed on JavaOne to demonstrate that you can make great looking applications with Swing (although it wasn’t easy to make a program like Aerith).
EclipseZone currently has a series of podcasts about the Eclipse Callisto release - it’s a series of ten podcasts, in which they’re interviewing people from each of the ten projects that are in Callisto.
If you know any other interesting podcasts, let me know!
I’ve been way too busy doing probably important but not blogoductive things but today I found a few minutes to take a look at Elcipse Callisto and write some meaningful comments about it. At least, I thought …
In may, during the JavaOne, I saw callisto for the first time. The eclipse team proudly presented their plans. And during this session thay gave me the impression Callisto could be something worth to check out. Well, At the end of June, exactly like they promised (very cool, those release schedules and planning all done through IBM’s jazz), the time has come. It is Callisto time!
So Let’s go …. [quote]
[/quote]
Hummm …. so I need to download eclipse and after that I need to use the update manager to select what I want. Does not sound like a smooth download and go to me. I think the idea to combine several projects into one coordinated release cycle is a very good idea. And providing the flexability to select what you want is also a good idea. But how about the idea to productize the whole bunch in one download? I wanted to do a quick click through to write down some first impressions. Instead, I’ll restrict this blog entry by only watching the video. [offside discussion: Why does a product (yep, i know, it is not a product, wish it was a product) needs a video to tell me how to install it?? Since RoR has shown the world how convenient it is to use videos, every product that might need some better marketing, uses a video]
Well, my review can be short. Why on earth does someone wants to select the ‘XSD Schema Infoset Model 2.2.0.v2′ ?? Lunatic 
. Is there someone on this planet really planning to go the callisto way only to use this extension? Well, the eclipse team already predicted the amount of developers looking for this one feature is not worth counting so they provided the ’select required’ button. So, you select the feature you want and all depending feature are selected automatically. Great, I want Callisto to bring me all! Also possible. The selection model is tree driven. One select box, one button, some intermediate wizard screens and a restart. Well, if that is possible, why not provide that one click download?
The actual question of course is not why we need videos nor what is wrong with the exotic selection of some deep down under package. The actual question is all about software distribution. It is push versus pull. Pull, just like the eclipse way but also like the linux way of packaging, is extremely useful for those who know what they are doing. Those who really need lunatic versions of lunatic packages. The only problem with pull is the lack of control on the distribution side. And that is where push comes in.
On development teams it is sometimes important all developers are using the same tools. I especially used the word sometimes because I know this can be a delicate issue. But when you are in the situation this sometimes is a definately, pulling exotic packages from the Callisto discovery site might not be a very good idea. And that is exactly the reason why I want that one click download. (including restrictions on the update manager inside eclipse so I can throw away the video )
This years JavaOne was filled with JSF, Ajax and even more the combination of the two. On the Pavilion several commmercial vendors were selling their ajax enriched jsf components. The blueprint team showed us the petstore. Oracle showed us how to build custom ajax enabled jsf components. And so on.
In my previous post I noted the Google Web Toolkit hadn’t landed yet completely in my java wasted brain. After four days of conference my brain is still completely wasted with java (two very positive exceptions, I saw the Ruby on Rails framework running on a java VM using JRuby! and I saw some really Groovy things a java programmer can only dream about) but I found some spare time to play with google’s new toy. While the conference only had one presentation about GWT (compare it with all those ajax and jsf sessions) the rumours/facts (find out yourself) on the internet are spreading. And somehow nobody seems to write something really interesting about JSF.
Is there a reason. Yes ofcourse. First it is the hype. GWT is new so GWT should be cool! Second, al the Ajax/JSF things are actually well known already (otherwise it would be impossible to have such a huge coverage on the conference). But between the rumours/facts I could not find out when to use JSF and when to use GWT?
Using GWT you will run into two major drawbacks. The amount of javascript that need to be downloaded will increase (lineair?) with the complexity of the interface. The KitchenSink example application is relative simple but already needs a 100kb of (compiled/generated) code. The other drawback is that your UI is fully (and I really mean fully) decoupled from your server logic. It’s like a Swing or Flash app making RPC calls. And altough very beautiful (designwise) not always as handy and productive as wanted.
GWT also has a lot of advantages. And they are obvious. No more javascript hackery. No more browser problems. All is taken care of by the toolkit. Another major advantage will be the usage of bandwidth after the application has been loaded. It will be minimized to the necessary RPC calls in order to add business functionality to the application. Which at the end will increase user experience. Using this approach state can be managed on the client (and/or in the database). And finally, the support for browser history works wonderful well.
But the biggest advantage is the fact it is a one stop shop. And here the biggest disadvantage of JSF had been mentioned. JSF is just like GWT (and Echo2 and several others) a component oriented approach for building rich web applications but it will allow you to combine several techniques together. It gives you the possibility to mix javascript library x with library y. It’s like combining Swing and SWT on the desktop. Javascript libraries are becoming the assembly languages of the web. And combining assembly languages does not feel right. (By the way, using Tapestry or Wicket this same problem can occur)
So when to use JSF and when to use GWT? I can’t answer this question. When all those beautiful JSF components provided by one and the same component vendor are being used and nothing more (not even self written ones!) JSF still seems a good choice. But if you can accept the drawbacks of GWT, I probably would recommend to at least investigate the possibilities GWT is opening up. (Or take a serious look at Echo2!)
Yesterday I visited a session by Jetbrains Dmitry Jemerov about IntelliJs’ new product called teamServer (TS-5033 : IntelliJ IDEA: Integrated Team Environment) and I really was flabbergasted by the presented material. 
Everybody knows Continous Integration is a must have in your projects and everybody also knows Continuous Integration does not work or at least does not work the way we really want it to work. TeamServer might change this. They developed it to support their own development. In other words, the developed it from the perspective of the developer (they eat their own dogfood), not the perspective of a company whos only core activity is building A continuous integration product. And just as their famous IDE(A), this product is stuffed with a lot of intelligent features that make life as easy as possible. And these features are making the difference.
One of the most remarkable features is the way they treat the check-in process. Instead of just checking-in code into the underlaying revision system, the tool is performing a build and test cycle first. So only changes that pass this phase will be added to the shared code repository. It is impossible to break the build. (Question, how many times did you do a check out of the code base and figured out the build was broken and the person responsible for this has left the building?)
Other interesting features are the way Team Server integrates with your IDE. No more bloats of email messages you never are going to read but instead nice taskbar indicators and direct pointers from (your own, not someone else’s!) build problems to actual source code. As expected the integration works for their own IDE only but there are plans to make it available as Netbeans and Eclipse plugins.
Besides the continuous integration aspects, the tool is featuring collaboration between developers also. For example, It is possible to do a diff action between your code and your coworkers code who’s sitting at the other side of the room (or worse, at the other side of the world) without using cumbersome mechanisms like e-mail or even worse, check-in/check-out.
Of course I need the proof of the pudding first but I think its worth to take a look at the the Team Server early access program site and try it.
So what if you want to develop a rich portal application, let’s use the standards!
Standards are their to make live easy for you, right…..? 
I want to create a Portal application with a rich and easy to build interface, this leads me to the following standards JSR168, the portal standard and JSR127 the JavaServer Faces specification. First of all I want to find a portal that supports this standard and does not provide to much overhead. This lead me to the JSR168 Portal Jetspeed (http://portals.apache.org/jetspeed-1/). Jetspeed 1 also provides support for JSR168 under the codename Jetspeed Fusion.
Yes there are other alternatives like Exo and Liferay that do the job but these provide to much overhead for my “simple” requirementSo the most important step is done I found myself a suitable OpenSource Portal with JSR168 support. Now we need to install it and as always Apache provides a out of the box solution including Jetspeed and Tomcat 5.0.3. The next step should be easy we need to create a rich JSR168 portlet application using JSF technology. In my opinion this should be as simple as 1.2.3. We just need to include the JSF jar into your project and start developing the portlet following the JSR168 API. After that we can just create a war-file which will be automatically deployed by Jetspeed.How wrong can one be, standards are not their to work with each other out of the box one must create a bridge for these two standards to work together. In this case I need to use the Apache Portals Bridges project ( http://portals.apache.org/bridges/ ) for these two standards to work together. The bridge consists of a generic Portlet-class which forwards your actions according to your configuration in the portlet.xml. All in all it’s not the work that triggers me but the bridging method, is this also based on any standards?? Or will we have to build bridges to support bridges?? So why do we need a non-standard bridge, which by the way impacts your flexibility to code portlets, to couple two standards? Aren’t both standards all about presentation? And why isn’t the JSF standard not supported by JSR-168 (or the other way around)? JSR-286 seems to make some promises about a tighter integration but besides to late, it is still a long way to go.So, until then we’re struck with bridges and our history has learnt us how dangerous bridges can be
I’m currently standing behind a Sun terminal at the conference and due to the position one has to take to use the keyboard and see the screen, it is impossible to make this a lengthy entry describing everything I’ve seen and heard today.
The conference was opened by the General Session aka keynote of Sun themselves. And the message was pretty clear: Please join the JCP (we only have 1052 members) and please download and use Netbeans. Nothing more, nothing less except for some minor details like the birth of JEE 5 and the incredible impact it will have and the announcement that Java once will become really open source (quote : the question is not whether, but how). Openness matters but its clear Sun is still struggling with their other marketing exclamation: Compatibility matters.
About netbeans, two major statements were made. The first was coming from JBoss founding father Mark Fleury who declared that JBoss will support (and donate to?) the netbeans platform (Hey, is JBoss IDE not eclipse based?). The second was coming from Sun themselves declaring they will bring their Studio Creator to the open source community by donating it to Netbeans. It seems the IDE war has entered a new phase.
One other very small thing that caught my attention was about certification. Since we’re not talking J2EE anymore but JEE 5 (Still having problems pronouncing it fluently), we all need to recertificate to become JEE certified developers or architects. So for all who are planning to do their exams, please wait for the new certification program. And for those who already are certified, start reading books again!
