Monday, November 17, 2014

Do you really want to speed up your Maven compile/packaging? Then takari lifecycle plugin is the answer. #maven #mvn #takari

Like many of you out there, I am working with a multi module Maven project. It is not a huge one comparing to many systems out there, it has 15 modules, with 3 different ear deployments, lots of parametrization with property files and around 100K lines of Java code. During peak development times, the code is heavily refactored, due it's legacy origins and so the need for continuous compiling/packaging and deployment, for every developer. 

Despite the steep learning curve all these years I have embraced Maven and it's philosophy. I am not saying that is perfect, but I truly believe that is a good tool, still relevant, especially while your project and team grows as you grow your project. (This post is not about Maven evangelism though). 

So, one of the problems we had on our team is that, despite switching the right flags, breaking and packaging our code into modules, using profiles and all the 'tools' maven provides, our build and packaging time was  slowly starting to increase, hitting the 1 minute threshold after a complete clean. Our main compiler was Sun/Oracle Javac and the time was monitored through packaging from the command line and not  through the IDE, where you can see different times depending on the 'Maven Integration' and internal compiler invoked by each tool. [My reference machine is my good old MacBookPro 2009, Core 2 Duo 2.5, with an Vertex 3 SSD (trim enabled)]

Recently while I was browsing Jason Van Zyl's (the father of Maven)  twitter account I discovered  the takari lifecycle plugin. Jason and his team are creating tools and plugins for the Maven ecosystem, that I hope to  bring  the much anticipated evolution  on the Maven ecosystem that the community of Maven seeks for a many years now. 

To cut a long story short, the takari lifecycle plugin, is an alternative Maven lifecycle implementation, that covers 5 different plugins into one. Once you activate it, it will take over, and invoke it's own implementation of the following 5  
  • resources plugin
  • compiler plugin
  • jar plugin
  • install plugin
  • deploy plugin
You can read about it here. The great thing at least in my case was the compiler plugin, that internally implements a incremental compilation strategy based on a mechanism that can detect changes on source files and resources!!

In order to understand the difference, when using the takari compiler plugin on your maven build compared with the classic compiler plugin and javac (which most probably many of you use), I am going to share a table from this blog post (explaining incremental compilation).

It is far more obvious that if you choose to invoke JDT instead of Javac, the results are going to be even better. Currently we stick with Javac, but the above diagram made me change the default compiler on my IntelliJ IDE, especially when I do refactoring and changes all around, JDT was anyway far better on incremental compilation comparing to Javac.

How to add takari to my build? Is it safe

Well in my case (and I guess for many of you out there), I just followed the proposed way here. I activated the plugin in my parent pom and then changed the packaging type for all my jar modules, into 'takari-jar'. 

  takari-jar

This is not, eventually the change is so easy that you can revert it back.

 The day that I pushed the takari lifecycle change on our git repo, after half an hour I started hearing 'wowss' and 'yeees' from my team members. Repated packaging on changes is very very cheap, changes on resources files and properties ensure that we will get a fresh package when needed. Our repacking times dropped to more than 50%-60%.

If you happen to have the same issues with your Maven build, I trully encourage you to try takari for a day - it will same you and your team some serious time.

I also want to note, that takari is free and despite the fact that is evolved and updated by the takari team for an unnamed 'big' client, the team is free to give it away for free and share it with the community. So thank you very much for this!!!The plugin is can be found on maven central.

The takari team is doing a weekly google hangout, information can be found here, I want to apologize that I have not managed yet to attend one, maybe soon enough.

So go Maven! go Takari!

Thursday, August 28, 2014

Problems with CDI in Websphere 8.5.5 during startup? the hidden solution... #websphere #ibm

This is not something I invented or discovered on my own, with this post I just want to raise the awareness of this 'major' missing point IMHO in standard Websphere 8.5.5 configuration (and it's fix) and post about it, so it can be indexed and people can find the solution easily, rather than spend countless hours trying to find why their code does not work!!!

Thanks to this IBM forum post, and the user bpaskin who actually spotted the solution in one of the many fixes on Websphere 8.5.5 update releases.(so yes make sure you follow the release fixes)

To cut a long story short, if you are developing towards Websphere 8.5.5 (or 8)  and you have resources like Startup EJB's or startup Servlet listeners and these resources are making use of CDI beans, then you will most probably have problems. Assuming that your deployable archive configuration and the classloading order of your deployed application is correct, make sure to edit your Webpshere's JVM settings and add the following.

Go to Application Application servers > serverX > Process definition > Java Virtual Machine >  
Custom properties and Add
Name: com.ibm.ws.cdi.immediate.ejb.start
Value: true

This will actually initialize the CDI engine soon enough so that CDI functionality is eventually available during startup!

IMHO again, this behavior should become standard when creating a new server /profile rather than making the application server admin, change it.

Sunday, August 17, 2014

My new keyboard - Realforce 87 U Silent - the best typing experience but with a high price #torpe #realforce #realforce87U

It's more than a year, that I have switched into the 'highly quality mechanical' keyboard search mode. I have to admit, considering the amount of money I have spent for more than a decade to medium or very bad overpriced conventional keyboards, that were promising some sort of quality and productivity boost during typing, I was late. 

Better late than never. For most of the people (if you exclude hard core gamers) investing in a good keyboard is some sort of, waste of money, since most of the regular keyboards seem to do the work. The thing is that if your work is about typing  a lot and when I mean a lot I am talking about hundreds of lines of code and text everyday, and you start monitoring your typing error rates, the amount of noise you produce when you hit the keys, a slight pain on your wrist or fingers after long hours of typing then you start wondering if there is a better way or tool? Anyway this post is not about, preaching the qualities and benefits of using a pro-mechanical or hybrid keyboard for intense typing jobs (like being a software developer) rather than my experiences on buying my second pro keyboard. 

I have stopped using Apple's keyboards for more than a year, my first attempt to the world of hybrid mechanical keyboards was the Matias Quiet Pro . Here is a post,  (in Greek) about my impressions and the market research I did in order to come up with it. Matias was a big change comparing to conventional keyboards, the feel was something very different for me, and I have to be honest I was more or less satisfied with this change. My typing errors were reduced, my max-out of the keyboard keys reduced even more and my keyboard stopped bumping in the air due to my hi intense (strong typing force) style. My typing rate was not increased though, due to the different feel and 'resistance' of the keys while pressing. My next priority was noise, Matias delivered, working in an office you don't want to get the blame for noise pollution due to clicking noises of your mechanical keyboard  and since I am also very 'sensitive' on noise issues at work I was looking for something 'office' friendly. I spent almost 8 months typing with Matias, and I consider it a very balanced keyboard for those who want to try the feel of a mechanical  keyboard  (actually is considered  a hybrid) in work without spending a small fortune.

During my research prior to buying the Quiet Pro, I did an extensive research on pure mechanical keyboards e.g flavors of keyboards using the CHERRY MX switches and the new kid on the block Topre. Due to the noise factor as already elaborated and while reading and listening to many youtube videos, I decided that one day I would buy a  Torpe based keyboard, something like the ultimate desitnation on the developer keyboard land. And so I did. In that post I wrote, that despite buying the Matias, my first choice would be RealFor87U, unfortunately it's price was a no go and  I did not have a prior experience on mechanical keyboards so I wanted to invest on a low risk solution.

The trial went well, I came to realize that I should have invested in a real good keyboard years before, so in my 34 birthday I decide to go the extra mile and buy the RealForce 87 U Silent, Variable Weighted press keys.

The good  things
  • It absolutely the best keyboard experience I have ever had, eventually the 45g weight keys are the perfect fit for my typing style (intest force, high rates on max-out the keys). After typing on the RealForce it seems that all the previous keyboards way behind.
  • I managed to reduce error rates, max out on keys, bumping of the keyboard was elimitated (since it is heavy and steady enough) and last but not least, managed to increase my typing rate!
  • Especially the very fist days, I was like eager to go at work and start typing, absolutely loving the feeling. (only developers would understand this I know). 
  • It is Silent!!! More silent comparing to the Matias.
The bad
  • High price, it is very expensive and  there is an extra hidden cost. Unfortunately Realforce ships from the US, considering the price, the item was picked in the customs office in my country (EU-Greece). With that price tag, you need to pay in taxes  another 100 USD dollars, and the worst thing is that the FedX delivery, is charging another 100 USD dollars for making the paper work and delivering the item to you + this extra is on top of the 60 USD you have  paid in the original price tag for FedX!. It is almost insane and I have to admit I would not recommended anyone outside of the US, buying this keyboard that way. I was so close on delivering the item back and requesting a refund. Since I decided to pay everything.. it still hurts, I can help other people avoiding my mistake.
    • Search for alternatives eg Amazon stores that, that have already a fixed tax tag for customs import.
    • Avoid FedX delivery and shipping when it involves customs, it seems for Greece UPS seems much more flexible. The amount of money requested for doing the paperwork are way too crazy.
    • if you have a friend in the states that is coming to EU, ask him/her to bring one with him as a present. 
  •  If you typing very strong I would recommend you go for the Fixed Weighted keys, this was my only mistake (but I how I could know, since you can not find them easily to test them out, especially in Greece). It seems that some of the (e.g Back space of space) that have different weight (feel) while pressing and I can max them out, while the majority of the alphanumeric keys which are on the 45g weight are ideal. So the only break in the overall silence is when I hit Back Space, and I maxing it out.

Overall, YES it is one of the best keyboards in the world, so a software developer would most probably love it. YES it is very expensive and if you order it outside of US your wallet might hurt for many months after the purchase.  I wish RealForce-EliteKeyboards and relevant Torpe Keyboard providers, reduce their price tags or start importing them in the EU so the European customers do not pay a small fortune (almost double price) for such a keyboard.