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.

Saturday, July 19, 2014

Cosmos - a spacetime odyssey...κάτι που πρέπει να δεις



Δεν ξέρω πόσοι από εσάς σαν παιδιά πρόλαβαν την σειρά Cosmos του Carl Sagan είτε την χρονιά που ξεκινήσε (1980) , είτε λίγα χρόνια μετά στις αμέτρτητες επαναλήψεις. Θυμάμαι να την βλέπω σαν παιδί στην τότε ΕΡΤ. Ο Carl Sagan μιλήσε για το σύμπαν, το διάστημα, τον πλανητη μας, τα διάφορα φυσικά φαινόμενα, υπήρξε σήμειο αναφοράς για πολλές γενιές αργότερα. Λοιπόν αν σας ξέφυγε η αρχική σειρά έχετε μια δεύτερη ευκαιρία, επίσης αν εχετε και παιδιά σε  ηλικία που μπορούν να καταλάβουν πράγματα τότε η δευτερη ευκαιρίας σας γινεται πιο σημαντική, είναι υποχρέωση να την δείτε μαζί τους.

Μόλις σήμερα κατάφερα να ολοκληρώσω το remake της σειράς (2014), από έναν μαθητή του Sagan τον Neal deGrasse Tyson, που ακούει στο όνομα Cosmos - a Spacetime Odyseey. Πάλι στο ίδιο μοτίβο ο Tyson μας εξηγεί την ιστορία του σύμπαντος, του πλανήτη μας, φανερώνει τις ιστορίες μεγάλων επιστημών, μας προηδοποιεί για τις κλιματικές αλλαγές και την καταστροφή στον πλανήτη μας. Τα 2 αγαπημένα μου επεισόδια ήταν η ιστορία του μολύβδου και η δουλειά/έρευνα του C.C Patterson κατά των εταιριών παρασκευής βενζίνης και το πως φτάσαμε στην χρήση της αμόλυβδης, και το προτελευταίο όπου ο Tyson δίνει πολυ απλά και χαρακτηριστικά παραδείγματα για την κατακόρυφη άυξηση CO2 στον πλανήτη μας κάθε χρόνο και πως αυτή μεταβάλλει το κλίμα και κάνει τη Γη αρκετά πιο θερμή χρόνο με το χρόνο.. 

Σε πολλά επεισόδια έχει επιλεχθεί η εξιστόρηση με χρήση cartoon κάτι το οποίο κάνει την σειρά πιο φιλική και σε μικρές ηλικίες, ενώ τα γραφικά και οι εικόνες από το διάστημα ή απο κόσμους που δεν έχουμε μπορέσει ακόμα να επισκεφθούμε θα σας καθηλώσουν.

Αξίζει τον χρόνο σας, αν είστε εκπαδευτικός μην διστάσετε με την πρώτη ευκαιρία να  κάνετε προβολές και στα σχετικά μαθήματα.


Tuesday, July 01, 2014

Java EE7 and Maven project for newbies - part 7 - #jpa2 and Unit testing using #arquillian / #WildflyAs 8.1 #maven #jboss - using a real Datasource (#postgresql)

Series

Previous Post, Next Post

In the previous post (num 6) we discovered how we can unit test our JPA2 domain model, using Arquillian and Wildfly 8.1 In the previous post we made a simple configuration decision, we used the internal H2 database that is bundled with Wildfly 8.1 and the already configured Datasource (called ExampleDS). But what about a real DBMS? In this post we are going to extend a bit the previous work, use the same principles and 
  • test towards a running PostgreSQL in our localhost
  • use some of the really nice features of the ShrinkWrap API, Arquillian Offers.

Pre-requisites

You need to install locally a PostgreSQL RBDMS, my example is based on a server running on localhost and the Database name is papodb.

Adding some more dependencies

Eventually we will need to add some more dependencies in our sample-parent (pom). Some of the arem related to Arquillian and specifically the ShrinkWrap Resolvers feature (more on this later).

So our we need to add to the parent pom. xml the following


Some notes on the above change:
  •  In order to avoid any potential conflicts between dependencies, make sure to define the ShrinkWrap BOM on top of Arquillian BOM
Now on the sample-services (pom.xml) , the project that hosts are simple tests, we need to reference some of these dependencies.


Restructuring our test code

In the previous example, our test was simple, we we only used a certain test configuration. That resulted to single test-persistence.xml file and no web.xml file, since we were packaging our test application as a jar. Now we will upgrade our testing archive to a war. War packaging in JavaEE7 has become a first level citizen when it comes to bundling and deploying an enterprise application. The main difference with the previous example is that we would like to keep both the previous settings, meaning test using the internal H2 on wildfly, and the new setting testing towards a real RDBMS server. So we need to maintain 2 set of configuration files, and making use of the Maven Profiles feature, package them accordingly depending our mode. If you are new to Maven make sure to look on the concepts of profiles.

Adding separate configurations per profiles

So our test resources (watch out these are under src/test/resources) are now as illustrated below.


There are differences in both cases. The test-persistence.xml of h2 is pointing to the ExampleDS datasource, where the one on postgre is pointing to a new datasource that we have defined in the web.xml! Please have a look on the actual code, from the git link down below.

This how we define a datasource in web.xml


Notes on the above
  • the standard naming in the JNDI name java:jboss/datasources/datasourceName
  • the application server, once it reads the contents of the web.xml file, will automatically deploy and configure a new Datasource.
This our persistence.xml


Notes on the above
  • Make sure the 2 JNDI entries are the same both in the datasource definition and in the persistence.xml
  • Of course the Hibernate Dialect used for postGresql is different
  • The line that is highlighted is a special setting that is required for Wildfly 8.1 in cases that you want to deploy with one go, the datasource, the jdbc driver and the code. It hints the application server to initialize and configure first the datasource and then initialize the EntityManager. In cases that you have already deployed /configured the datasource this setting is not needed.

Define the profiles in our pom

In the sample-services pom.xml we add the following section. This our profile definition.


Depending on the profile actived, we instruct Maven to include and work with the xml files under a specific subfolder. So if we apply the following command

mvn clean test -Pdb2

Then maven will include the persistence.xml and web.xml under the resource-h2 folder and our tests will make use of the interall H2 DB. If we issue though

mvn clean test -Ppostgre 

Then our test web archive will be packaged with data source definition specific to our local postgresql server.

Writting a simple test

Eventually our new JUnit test is not very different from the previous one. Here is a screenshot indicating some key points.


Some notes on the code above:

  • The Junit test and basic annotations are the same with the previous post.
  • The init() method is again the same, we just create and persist a new SimpleUser Entity
  • The first major different is the use of ShrinkWrap Api, that makes use of our test dependencies in our pom, and we can locate the JBDC driver as a jar. Once located ShrinkWrap makes sure to package it along with the rest of resources and code in our test.war. 
  • Packaging only the jdbc driver though is NOT enough, in order this to work, we need a datasource to be present (configured) in the server. We would like this to be automatic, meaning we dont want to preconfigure anything on our test Wildfly Server. We make use of the feature to define a datasource on web.xml. (open it up in the code). 

  • The application server, once it scans the web.xml will pick up the entry and will configure a datasource under the java:jboss/datasources/testpostgre name. 
  • So we have bundled the driver, the datasource definition, we have a persistence.xml pointing to the correct datasourc. we are ready to test
  • Our test method is similar with the previous one.
We have modified a bit the resources for the H2 profile so that we package the same war structure every time. That means if we run the test using the -Ph2 profile, the web.xml included is empty, because we actually we don't need to define a datasource there, since the datasource is already deployed by Wildfly. The persistence.xml though is different, because in one case the dialect defined is specific to H2 and in the other is specific to Postgre.

You can follow the same principle and add a new resource subfolder, configure a Datasource for another RDBMS eg MySQL, add the appropriate code to fetch the the driver and package it along. 

You can get the code for this post on this bitbucket repo-tag.

Reference


Saturday, June 28, 2014

The JBoss/RedHat stack... a dream for many javaee developers :( #redhat #jboss #wildfly #arquillian

(postd as is in LinkedIn as well)

I strongly believe that the JavaEE spec and the JavaEE stack is going through an excellent phase. It is the summer of JavaEE as a fellow friend suggests. So in summer you always feel e bit more enthusiastic and happy etc. I have been experimenting a lot lately with JavaEE7 (and 6) technologies, especially with all the goodies that come from the RedHat /JBoss stack. Application server, Hibernate 4, Infinispan, Rest-Easy, Arquillian & ShrinkWrap, OpenShift. It's been a long time since I felt that I actually have tools and technologies in my hands that actually work, are mature and I can rely on.

But...then here comes the reality. This is an old and long running whine of me, from the early start of my career. I always wanted to work and build solutions using 'things' that came out of the JBoss house, but 9 to 10 times, I got the reply, 'the client has a big contract with this shop and the other shop' so we have to go with 'their' tool. And most of the times their tool was 2-4 years behind in terms of maturity on spec implementation. And most of the times we had to re-invent the wheel or cannibalize actually the application because their tool was not delivering, making a worse mess that using right from the beginning something that is actually working.

The good news? These recent years, most of the technologies that I was dreaming of to have in my deployment path :), became a standard! No I don't have to use your 5 year old, left over JPA implementation, i need to make your server work with the standard. I don't have to use this outdated REST implementation of yours, I need to wire something that is working. No I don't have to use your specific plugin, in order to deploy something that is considered standard, I want to use Maven or Gradle and I will be expecting to work.

Unfortunately, I still have to work and develop with tools, picked by others , due to some contract . Unfortunately still my stack of choice ...will be 9 out of 10 times, out of the scope.
I guess the only time this will change is when I will be able to control what tools to be used, using my developer experience from the past, in my own company :)

Friday, June 27, 2014

Dealing with IBAN / BIC in Java? ...check iban4j #iban #java #iban4j

This post is mostly targeted to Java developers working on the financial sector, especially with systems that need to do payments and specifically using the IBAN/BIC standard.

So today I was browsing through some 'legacy' code, that was performing some sort of validations on String representations of IBAN accounts. I wrote a simple JUnit  test, in order to check if the validations performed from this very very old JAVA 1.4 (or older) style of code, were eventually correct.

 To my surprise I realized that a few bugs or missing cases were floating around. I started digging further, missing empty/null string or formatting exceptions, specific formatting decisions based on specific countries and many other issues led to starting asking myself how I can efficiently correct the code and eventually 'secure' this part of the system that was relying on such error prone validations. 

After some more digging around, I found that there are actually 2 good candidates, for my case
I reviewed the API and functionality offered by both. To be fair IBANCheckDigit from Apache is some sort of utility class, while iban4j is a complete mini library that covers, creating, formating and checking of IBAN and BIC literals.

I re-used my unit test, replacing the legacy code with calls to ibanj, after including the dependency on my pom. All test passed, all validations and exceptions caught. I had a clear winner.

Many thanks to the developer, for sharing such a handy library. The API is clean and simple and the functionality conforms to the standards. At least it passed my legacy compatibility tests.

So in case you find yourself in a similar situation...give iban4j a go!


Monday, June 23, 2014

Java EE7 and Maven project for newbies - part 6 - #jpa2 and Unit testing using #arquillian / #WildflyAs 8.1 #maven #jboss

Series 

    Previous Post, Next Post

    In the previous post (part 5), we discovered how we can unit test using Arquillian, our EJB services, deploying them in a 'real' instance of Wildfly8.1 application server. Extending the previous example we will add some more configuration and code, so that we can add unit tests that involve our JPA2 Entities. Creating, saving and retrieving information from the database is a very fundamental task of many JavaEE applications. We need to make sure that our domain model and the logic coded on top of,  is as much tested as possible. I am going to use the 'simplest' form of configuration and related libraries. Since we already test towards Wildfly 8.1, we will be using an internal H2 in-memory database that is bundled with the server, and the pre-configured ExampleDS datasource

    Watch out, this is just for testing and demo, in real life you will want to test under a  production based RDBMS, so most probably you would be needing:
    • create a test DB schema in your DB server (e.g Oracle, MySQL, DB2...)
    • Add appropriate Datasource configuration to the application server, so that it connects to to the above DB server.
    We have already setup Arquillian, and is already leveraging the capabilities of a standalone Wildfly 8.1 server. In the previous post (part 5), we have been testing a simple Stateless EJB, that was not retrieving or saving information on the database. On the sample-domain module we have already defined a simple JPA2 Entity Bean. We would like to test some basic stuff, like save the entity on a database, retrieving the entity etc. It is a common pattern even nowdays, for many projects, to create stateless sessions beans that are actually implementing this code for each entity. You might have heard of them as 'DAO' classes. In our case there is no DAO implementation but the same principles would apply.

    Defining a test-persistence.xml

    As we have already defined a standard persistence.xml under the sample-domain module (jar), that is configuring actually our Entity Manager, we need a similar confinguration. Eventually a very similar persistence xml but this time is going to be placed in the /src/test/resources folder, because it is going to cofigure for us, an Entity Manager that is going to be picked during our tests, from our Arquillian/Wildfly test combo.



    This how it looks

    Some notes on the above file


    • We are defining the ExampleDatasource that is pre-configured on Wildly 8.1
    • WildFly 8.1 comes bundled with Hibernate 4.x, so we are using 'safely' properties of Hibernate configuration.
    • We are using the 'create-drop' strategy so that means that every time we run the test (s), hibernate is going to drop the tables in the underlying database and recreate them. That will help us in cases where we are experimenting and we are constantly changing our domain model.  
    • The emb. database that Wildly offers is H2, so we are configuring Hibernate to use this 'dialect'.

    Creating an Arquillian Test

    This is how our test look like (you can check out the source, on the git link at the end of the post)



    Some notes on the above code

    Point 0: This is one of the most important parts of every Arquillian based test. This is where we create the in memory  'war', our deploy-able that will contain the classes under test and any other resources needed by the supporting frameworks. All the wiring is done using an Arquillian based framework called ShrinkWrap. In our case the 'createDeployment' method, will package our single JPA entity called 'User' and a persistence.xml file, which is actually the test-persistence.xml under our test resources , configuring an Entity Manager that is working with the default Wildly Datasource. 

    Point 1: This is a special annotation, very handy on more complex tests, by using this annotation we are actually injecting by default JTA (transactional) support on our test methods, in this particular test is not heavy used. Make note of the ROLLBACK setting. It indicates that whatever this test method does within a transaction at the end all the insertions/deletes/updates are going to be rollbacked, so we leave no garbage behind.

    Point 2:We need to annotate our test with the appropriate RunWith annotation, indicating that we want the Junit/Arquillian mechanism enabled

    Point 3: We are injecting an entity manager, like we would have done in a regular EJB /resource. The name of the persistence manager must much with the one defined in the test-persistence.xml , so watch out.

    Point 4: The @Before Annotation is indicating that the init() method, will run before every test. This is a great place to initialize any data,and prepare our test domain environment.

    Point 5: As you can see within the init() method, we are persisting a User entity, similar to what we would have done in our product / real code!

    Point 6: The actual test method, we are trying to query for the object, persisted later on.

    Finally

    The fact that we have already configured and prepared our project structure and configuration in order to use Arquillian, is actually the most important thing. Once you have the basic blocks ready, then it is a matter of writting more test and experimenting with your code. Right click on the test and as you can see , we have the green light of succes, a clear pass. Happy testing!



    You can find the complete code for this post under the post6 tag on my bitbucket repository.

    Move on to Part 7?

    Monday, June 09, 2014

    Java EE7 and Maven project for newbies - part 5 - Unit testing using Arquillian / Wildfly 8 #maven #jboss #wildfly #arquillian

    Series  

      This is the first 'extra' post, based on the  maven JavaEE7 demo project I am 'building' on this series of blog posts. We have already defined a solid structure and some modules. One very common case in an application like this, is to use Arquillian (+JUnit), a god sent framework, that enable us to unit test our EJB services using a 'real' application server, most probably the same that we are going to deploy to. I am actually following the basic setup guide as it can be found here, the difference is that I am going to setup Wildfly 8.1 as my embedded container to host my unit tests. Widlfy 8.1 is a fully blown JavvaEE7 container, so I can safely test all my features.

       

       

      Arquillian mind set and Maven

      One of the basic things you need to understand in order to adopt Arquillian in your Maven-ized project is the following  terms (ideas) that are actually implemented as dependencies.
      • You need the Arquillian framework/library of course, imagine that it is a new car but is missing it's engine. The front part it's empty.
      • You need an Arquillian Container Adapter, imagine that you need to install some kind of placeholders in the front part of your car, something like a frame that is going to be used so that an engine can be 'installed'.
      • You need a real container (application server), this is the engine that we are going to fit into our car.
      • You need JUnit, this is the 'test track' that your car is going to run and be tested.
      • You need your code (your EJB(s)), these are the passengers that are going to be placed in the car and test a ride on the Junit track.

       

       

      Defining the dependencies on the parent pom

      As we have already elaborated in the previous 4 posts, the parent pom is the place to define the dependencies and their versions of libraries to be used in our application.  Have in mind the above list of terms let's get started and update the dependencyManagement section  of our parent pom.


      Some tips on the above fragment:
      • Some of the dependencies are of type pom, and scope import. This is actually a special case on defining group of dependencies all together. A pom type dependency, means that this is a group of individual libraries grouped together under this definition. You only need to define this uber pom  and you will inherit the individual dependencies within it. In the Maven terminology this grouping of dependencies are called 'BOM' or also known as Bill of Materials. Arquillian is consisted of several concrete libraries and dependencies, instead of defining each one of the, one by one, we have the same result if we define the arquillian-bom.
      • The 'arquillian-transaction-bom' is an optional dependency, you may not define it, it adds extra features to the arquillian engine and in your tests. One of the most famous 'extra' features is the '@Transactional' arquillian annotation. See details here or here.
      • A special case, for Wildfly and JBoss. You will notice the dependency, 'wildfly-embedded', you will assume that this is a 'embedded' uber jar version of the Wildfly application server, like the one for Glassfish. Eventually this is not, and this is a common mistake that people make when trying to setup Arquillian with Wildfly. In order to make the whole thing work you need to download the 'real' application server. Have a look on the following section, where will will tackle this special case.

       

       

      Configuring our ejb module for Arquillian and tests

      In our demo applications we have 'coded' most of our EJB services on the module called sample-ejb. So we need to add extra configuration to it's pom in order to 'fire'  junit+arquillian tests during the test phase of this module.

      Most of the configuration will do on this pom, is to cover this 'special' case of Widlfly not being offered as a fully blown embedded container. So in order to make the whole mechanism work we need, to tell Maven, during our test phase, to download the Wildfly.zip (as we would do using a browser for example) unzip it somewhere, and the point Arquillian to the path. Once that is done, rAquillian will take over.

       

      Downloading the wildfly server, before hand

      The configuration below is written in the sample-services pom, our 'EJB services' module


      Some tips on the above fragment:
      • We use the maven-dependency-plugin
      • We instruct the plugin to kick in during the 'process-test-classes' phase of the Maven lifecycle, and when it kicks in to execute the 'unpack' goal. So before Maven starts running the tests the above part of the configuration will have downloaded and unpacked Wildfly 8.1 to the class path.

       Running the tests, using maven - surfire plugin

      Again the code below is part of the sample-services.pom. We actually configure Maven Surefire Plugin, which is the plugin that executes the Junit-Arquilian tests.




      Some tips on the above fragment:
      • Surefire provides the execution environment for the unit tests. In our case we have Junit-Arquillian powered tests. In order Arquillian to correctly initialize itself and to identify the container we need to pass as system parameters, the path of the download application server. Remember that wildfly / jboss is a special case.  The container will already be downloaded on out /target folder. 

      Add the required dependencies on the sample-services module





       Create a sample Test



      We are done

      Under the sample-parent folder level, type

      mvn clean package


      The complete code for this example can be found on the following bitbucket tag.

      Move on to Part 6?

      Saturday, May 31, 2014

      Using IntelliJ..for 2 weeks, so far so good. #intellij #idea #java


      It's been almost 2 weeks that I have completely switched over to  IntelliJ as my main Java IDE at home and at work. So far so good, here are my  initial findings.
      • Migration: I took me a couple of hours to migrated my projects over. Eventually if your project is already Mavenized, things are simple, no risk involved.
      • Maven: As many people say, IntelliJ currently treats Maven-ized projects better, comparing to Eclipse Kepler and its internal plugin. The integration is not perfect, but I don't thing there is such a thing. Profiles work , maven options work, the IDE seems to 're-fresh' it's state along with the 'Maven' one, especially during clean and package. This is what I wanted, so I am very happy about it.
      • Key Bindings : At first I had selected the Eclipse Key Map, but soon realized that most of the examples out there were based on the intelliJ key bindings (especially when you were browsing help stuff). At the same time, some of the most exotic and clever functionality was not by default 'configured' to an eclipse combo. So I was feeling, I was missing some magic. During the second week, decided to change my settings to IntelliJ defaults and I was surprised that after a a day or so  with the help of the documentation and the Cmd+Shift+A, I found my way around.
      •  Crashes : No crashes, ooh yes, this is so good. No crashes.
      • Enterprise Features / Facets : I tried the Enterprise Version with all the extra features. It makes sense if you are a JavaEE developer BUT, like Eclipse, when the IDE activates all these Enteprise Wizards and facets it becomes slow. So I think I can live without them, despite the fact that they might save you some time in a configuration or special annotation. Maybe for less experienced developers these wizard can save you some time, at the time being I can still work with no JavaEE /JSF wizard
      • Java Refactorings : It seems that the tool is more 'clever' java way, it spots on the fly common programming errors and provides on the spot suggestions. I have never seen a tool, doing so correct suggestions and scanning. Well done jetbrains team, well done .
      • Searching stuff: Most of the time in fairly large project, finding a class, a resource something is a major repetitve time consuming task. I think that IntelliJ builts on top of the Ecipse legacy, which introduced back in the day fast and smart searching, and does it better. Ohh yes I loved the (Shift+Shift) combo.
      • Quality: As I've already said the built in java lang scanning is very good, that means that the tool helps you write better code. The standard 'Analyze' functionality provides a variety of suggestions, most of them to the point. I have also installed the PMD, Findbugs, Checkstyle plugins, so I am very happy there is already integration with these very very important tools for ever Java Developer.
      • Text editor:  Smart cursors, each renames and smart support for many different files, things I am not slowly trying to use and explore.
      • App server support: Currently I am using Websphere (bliah) eventually the standard plugin is quite good, I can not fully evaluate it though since Websphere can not run on MacOSX so most of the stuff are just no use for me. Others in the team  though, are successfully using 'hot swap' and local deploy with no problem. I guess the tool supports all the major app servers, if it managed to do it properly with Websphere then the others must have been easier :P .
      • Arquillian + JUnit : This is the one thing that I have not managed to make it work. The JUnit runner in Eclipse was most probaly capable on understanding my configuration and successfuly start Arquillian  with  GlassFish on JUnit tests. At the time being when I try to do the same on IntelliJ I fail miserably, maybe it is missing configuration from my side , dont know, this is the only reason I have eclipse on standy by, sometimes I like to debug while I unit test and currently i can not do it on IntelliJ.
      •  
        So far so good, with some small problems that I can live with though. It seems that our small team at work is slowly migrating over to intelliJ (Community Edition). 

      Thursday, May 29, 2014

      Java EE7 and Maven project for newbies - part 4 - defining the ear module #javaee #java #maven #juniordevs

      Series 

        Previous Post , Next Post

          We are resuming for the 4th part, our simple project currently has 
          • a web maven module (a war)
          • an ejb module (ejb)  holding our stateless session beans (EJB 3.1)
          • and a second (ejb) module holding our entity beans (JPA2) 
          but we are still missing the one to package them all, archive, which will be of 'ear' type  (aka Enterprise Archive)

           Defining our ear maven module

          As you can see in the image below, we create emtpy folder called sample-ear under the sample-parent. This folder needs to have a pom.xml file. Our new module needs to be correctly referenced in the  'modules'  section of the sample-parent\pom.xml.



          The main purpose of our ear maven module is to 'configure' the famous maven-ear-plugin, which is going to be invoked by maven and is going to produce our final deployable application.

          There 2 simple things we need to do, add configuration for the maven-ear-plugin, and add our 'internal' application dependencies on the ear module, so that it 'knows' which modules should look up. Let's have a look

          Inside the ear pom.xml



          This is the build, section make note on the following things
          • Remember as we did other modules, we have defined some basic common configuration for our plugin, in the 'parent' pom. Go back and have a look what is already there for you.
          • Watch out the 'defaultJavaBundleDir' this where we define where all the libraries (apart from the top-level modules that will reside in our ear, usually is  a sub-folder in the ear called 'lib'
          • What is a top level module? It is actually, the  jar(s), and wars that are going to be packaged in the ear, and are considered first level citizens,as you can see we define 2, the sample-web and the sample-services.
          • Watch out the 'skinnyWars' property. With this switch enabled, we enforce a certain pattern on packaging our third party libs, referenced from our war project. Simply put, our war archives are NOT going to include any external libraries we might define as dependencies under their WEB-INF\lib folder, instead all those libs,they are going to be packaged in the 'defaultJavaBundleDir' path on the ear level.

          The above configuration is not going to work, if we dont add the 'dependencies' section of our ear-pom.

          Make note of the following
          • the dependency element in this pom, needs the 'type' attribute.

          One good question you may have is, where the sample-domain (jar) module?


          Well this module, is not promoted as a top level element in our ear, because we are going to add it as a dependency on the sample-services module. So our services will hold a dependency on the module of the entity beans. (Sounds fair). So we need to update the pom.xml of our sample-services module.


          By doing that, the sample-services.jar is going to 'fetch' along the sample-domain.jar. By default (remember Maven is all about conventions), when we define a top level module to an ear,l ike the sample-services, it's dependencies are bundled automatically under the defaultJavaBundleDir lib of the ear! So when we package our ear, we will be expecting to see the sample-domain jar packaged.

          One more missing dependency

          After our first ' in app dependency between the services module and the entities module, we need another one. Our war module, (web layer) is going to use some of our services, but in order to being able to do it needs to have a dependency on the 'services' module. So we need to the pom.xml on the sample-web project, accordingly.



          Let's package our war.

          We are ready for now, our basic dependencies are set, our ear is configured, we just need to package. Under the sample-parent folder level on command line we just need to type

          mvn clean package

          We are done, let's check under the 'target' folder of the sample-ear module. Our final ear is ready, maven also creates the 'exploded' version of the ear, (it is, expanded in the image below). Notice our 2 top level ear elements, and how the sample-domain.jar is under the 'lib' folder of our ear. Also notice that some basic libraries like the javaee-api.jar are not included in the lib folder. Since we have added the provided in the pom. (see the final version of the xml).



          One last thing...skinny war(s) and MANIFEST.MF files

          Eventually, we could stop here, our final ear is ok and is going to work, but with all the above configuration, especially with our preference to create, skinny wars , we need to pay attention to a small detail. MANIFEST files are special descriptors within jars and wars, that are used by application servers on locating and class loading 'dependent' jars in the class path, within the ear.

          Our small problem resides in the MANIFEST.MF file of the sample-web.war. If we unpack the generated war file and we open with a text editor the MANIFEST.MF we will see is something like that.


           Can you spot the mistake? By default the MANIFEST.MF generated, is indicating a wrong path for one of our top-level ejb jars(sample-services). Our sample-services.jar is not place under the \lib within the ear, but is a top level element. So how are we going to create a correct MANIFEST?
          Eventually we need to fine tune a bit the maven-war plugin. We need to overwrite the default behaviour as specified in the parent pom, and specify a correct entry for this particular dependency. If you happen to have more than one, then you need to append all the jars that are top level elements in the configuration (make sure you do it properly, use a space between entries).So in the sample-war pom we need to add some configuration (extra) on top of the one applied. See the image below.



          There is an interesting stackoverflow issue, that you can read more about this, little trick or other potential workarounds in case you use skinny-wars.

          That's it, our ear is ready.

          Summary

          You can find the final version for this post in this Git Tag.With this post, we are completing a first series of posts, starting from scratch, applying basic maven principles and creating some basic maven modules for a java enterprise application. Feel free to re-use this example and extend it in order to meet your own needs. It is by far complete in terms of covering all your needs, but it is a solid example on getting starting, thinking and configuring in Maven.

          I am going to expand on this example, adding more modules and using more features of maven in future posts.

          Monday, May 26, 2014

          Οι καρφωτούρες, παίζει με καρφωμένες τιμές, α τι ωραία βρήκα ένα magic number... α τι ωραίο σκουπίδι που είναι ο κώδικας και το project μου



          Λοιπόν, να πω ότι τα φαινόμενα που θα περιγράψω παρακάτω δεν είναι αρνητικό προνόμιο μόνο της ελληνικής αγοράς και των Ελλήνων developer (εμείς είμαστε αυτοί), αλλά παγκόσμιο. 

          Παρόλα αυτά επειδή θα γράψω στα Ελληνικά θα το 'ζωγραφίσω' με την δική μας κατάσταση.

          Εσύ συνάδελφε ή συναδέλφισα που τυχαίνει να με διαβάσεις, πες μου πόσες φορές ακούς την ημέρα, (όχι την εβδομάδα ή το μήνα) την ημέρα, τις εξής  εκφράσεις
          • παίζει αλλά είναι με καρφωμένες τιμές.
          • εντάξει δεν ξέρω πως θα το κάνω και του κάρφωσα μερικές συνθήκες στην υλοποίηση.
          • με πιέζουν αρκετά και το θέλουν αύριο, δεν μπορώ να κάνω κάτι καλύτερο από το να 'καρφώσω' με τιμές που θα παίξουν.
          • ...από μέσα του όχι φωναχτά 'έλα μωρέ ποιος θα το δει τώρα ότι πήγα και το έφτιαξα τσαπατσούλικα, εδώ μέσα γίνεται χαμός, σιγά μην σκάσω εγώ για τον μ...ακα'
          • από μέσα του ' δεν πληρώνομαι αρκετά ρε φίλε για να το φτιάξω σωστά, σιγά τόσα που μου δίνουν και με αυτές τις συνθήκες, θα καρφώσω την υλοποίηση και ότι γίνει'.
          Καρφωτούρες, καρφωμένες τιμές, υποθέσεις χωρίς εξήγηση, αφημένες στην τύχη τους, μια βόμβα έτοιμη να σκάσει
          • ακριβώς μόλις βγει σε παραγωγή στο σύστημα
          • την αμέσως επόμενη μέρα που θα χρειαστούμε να κάνουμε αλλαγές στην πρώτη έκδοση
          • την αμέσως επόμενη μέρα που θα συνειδητοποιήσουμε ότι πρέπει να αλλάξουμε την λύση μας
          • τα αμέσως επόμενα χρόνια που κάποιος κακόμοιρος θα προσπαθήσει να διορθώσει την δική μας απόφαση (διάλεξε πάνω από τα bullet ποια είναι η δικαιολογία σου).
          Το φαινόμενο προφανέστατα είναι μια ακόμα όψη του ίδιου νομίσματος που ονομάζεται 'technical debt'. O Π.Παπαπέτρου περιγράφει πολύ εύστοχα σε αυτή του την παρουσίαση, το technical debt ως τον 'βαθμό δυσκολίας που θα έχει, μια οποιαδήποτε ομάδα λογισμικού για προσθέσει  added value σε ένα λογισμικό΄ χωρίς να το διαλύσει ή να εκφυλίσει την αρχιτεκτονική του (θα προσθέσω σιωπηλά).  Tο technical debt στην Ελλάδα κατά την ταπεινή μου άποψη οφείλεται στους εξής λόγους.

          • Το λεγόμενο technical , IT management είναι σχεδόν ανύπαρκτο και εξασκείται από ανθρώπους στην πλειοψηφία μέτριων ή με σχεδόν καθόλου γνώσεις πάνω στην διαδικασία της σχεδίασης, υλοποίησης και διαχείρισης έργων πληροφορικής. Είναι οι ίδιοι άνθρωποι που θα θυσιάσουν την λογική 'για' εξωπραγματικά estimates, θα εθιστούν στο overpromise στον πελάτη, θα θεωρήσουν ότι 'ξέρουν' καλύτερα, θα αποσυντοντίσουν την ομάδα, στις δύσκολες στιγμές θα πιέσουν ή θα απειλήσουν. Είναι οι άνθρωποι που θα κομπάσουν ότι ξέρουν το business αλλά αυτό δεν σημαίνει ότι ξέρουν πως να οργανώσουν μια ομάδα λογισμικού. Οι ομάδες πληροφορικής πρέπει να οργανωθούν από τεχνικούς ανθρώπους και όχι busines expert και wannabe πωλητές. Κακό management σημαίνει κακό λογισμικό.
          • Δεν διδάσκουμε, εγχώρια την ανάπτυξη λογισμικού σαν μια επιστήμη από μόνη της, ταπεινή μου άποψη είναι ότι έχουμε ανάγκη από ακόμα πιο πολλές σχολές σε πανεπιστήμια και ΤΕΙ που θα ετοιμασουν προγραμματιστές και όχι hybrid τα ξέρω λίγο απ' όλα, βασικά θέλω να γίνω admin αλλά τελικά αναγκάζομαι να γράψω php κτλ κτλ. Τα τελευταία χρόνια στην Ελλάδα από αυτά που ακούω υπάρχουν πια σχολές στοχευμένες στο Software Engineering και θέλω να ελπίζω ότι θα γίνουν mainstream. Η υλοποίηση λογισμικού δεν είναι μόνο α) ξέρω θεωρητικά ένα αλγόριθμο τέλεια ή ξέρω πολύ καλά μόνο μία γλώσσα. Είναι μια σύνθετη διαδικασία, που φέρνει τον προγραμματιστή αντιμέτωπο με τεχνικά αλλά και διαχειριστικά challenges, τα οποία πολλές φορές τα αγνοούμε. Δεν είναι δυνατόν το 2014 να βλέπεις παιδιά που βγαίνουν τώρα από τα πανεπιστήμια πληροφορικής και να μην κατανοούν την έννοια του unit test, του documentation, της δομημένης λογικής. Ο προγραμματιστής είναι και αυτά..όχι μόνο 2 γραμμές δυσνόητου κώδικα και φύγαμε. Η αγορά δεν έχει ανάγκη μόνο από hacker αλλά πραγματιστικά από ανθρώπους που θα υλοποιήσουν και θα λύσουν προβλήματα, με απλό και ευέλικτο τρόπο. Αυτοί είναι για μένα οι πιο χρήσιμοι και άξιοι συνάδελφοι.
          • Η εγχώρια αγορά πληροφορικής δεν είναι τόσο ανταγωνιστική έτσι ώστε να  δημιουργήσει τις συνθήκες  έτσι πελάτες και εταιρίες να δώσουν έμφαση στην ποιότητα του παραγόμενου λογισμικού. Δεν φταίει μόνο η κακή εταιρία που δίνει μία τσαπατσούλικη λύση, φταίει και αυτός που την αποδέχεται, που δεν τον νοιάζει ίσως η ποιότητα γιατί τελικά δεν έχει επίδραση στον αριθμό των πωλήσεων του. Τα συστήματα πληροφορικής στην χώρα μας τώρα δειλά δειλά, αρχίζουν θα παίρνουν την θέση που τους αξίζει σε ότι έχει να κάνει το business value. Ποιότητα σε ένα έργο πληροφορικής δεν είναι ότι δεν 'έσκασε' την πρώτη μέρα σε παραγωγή ή δεν έμειναν οι server από μνήμη. Ποιότητα σημαίνει ότι παρέλαβα ένα σύστημα, το οποίο, δεν έχει αρκετά παιδικά προβλήματα, δεν παρουσιάζει προβλήματα με τον χρόνο, είναι σχετικά εύκολο να χτίσω πάνω του χωρίς να το διαλύω τέλος μπορώ να το θεωρήσω σαν μια τεχνολογική επένδυση που περιμένω να μου κάνει απόσβεση και όχι να το 'ξανα-αγοράσω' μετά από 1 χρόνο. Το σύστημα κάνει 'deliver' to business promise αλλά δεν μου τρώει λεφτά η τεχνική του πολυπλοκότητα και αδυναμία.
          • Εμείς, μας άφησα τελευταίους. Ναι εμείς οι developer, η έλλειψη επαγγελματισμού. Νομίζω ότι είναι γενικό φαινόμενο της χώρας μας, όπως και η ποιότητα παροχής υπηρεσιών. Κάθε φορά που βάζουμε μια μαγική τιμή κάπου, κάθε φορά που είτε μας πίεσαν είτε όχι, γράψαμε μερικές γραμμές κώδικα και στην συνείδηση μας δεν το καταλαβαίνουμε ότι αυτό που κάνουμε είναι αντί-επαγγλεματικό ή δεν το επικοινωνούμε καθόλου, φταίμε και έχουμε μεγάλο μερίδιο ευθύνης
          Θα ρωτήσει κάποιος και πως θα αλλάξει, προφανέστατα αύριο που θα πας στην δουλειά, ή τώρα που με διαβάζεις, δεν θα αλλάξει προς το λογικό και ευέλικτο το management, δεν θα γεμίσει η αγορά με καταρτισμένους developer  και φυσικά ο συνάδελφος σου δίπλα που ξέρεις ότι slack-άρει ή βαριέται δεν θα αποκτήσει συνείδηση για να κάνει σωστά την δουλειά του. Το στοίχημα λοιπόν είσαι εσύ, ο καθένας μας, από τον ρόλο που υπηρετεί στο τέλος της ημέρας να είναι περήφανος για την δουλειά του και να ξέρει ότι έδωσε το 100% των δυνατοτήτων του, όχι το 70% ούτε το 110%, αρκεί όλοι μας να δώσουμε το 100% και μέρα με την μέρα ακόμα και τα πιο μικρά πράγματα σαν developer θα βελτιώσουν την ζωή των δίπλα μας. Μπορεί κάποια στιγμή κάποιος manager να το εκτιμήσει αντίστοιχα, μπορεί και όχι.  Μιλάμε μιλάμε αρκετά για τις ελληνική επιχειρηματική εξωστρέφεια και τις ελληνικές start-up και την μεγάλη ελπίδα όλων. 

          Κύριοι και κυρίες αν δεν αλλάξουμε επαγγελματικές συνήθειες δεν αποκτήσουμε πιο υψηλά standard, για τους ίδιους μας τους εαυτούς, δεν θα μπορέσουμε να κάνουμε κάτι τόσο διαφορετικό. Γιατί μεταξύ μας ναι όλοι έχουμε δει κώδικα από τις φάρμες 'Ινδων' σε κάποιο project πολυεθνικής αλλά μήπως εμείς είμαστε καλύτεροι όταν πάμε και γεμίζουμε τσαπατσούλικες λύσεις τα συστήματα εδώ κι εκεί. Λίγο αυτοκριτική λοιπόν.

          Ο προγραμματισμός είναι χαρά, είναι δημιουργία, είναι δύναμη, αλλά όταν δεν το πάρεις στα σοβαρά ή δεν έχει διάθεση γίνεται ένα καθημερινό βάσανο για σένα αλλά και τους υπόλοιπους που θα λουστούν την δουλειά σου μετά από λίγο.

          Αν μόλις ξεκίνησες την ημέρα, προσπάθησε να βγάλεις μια 'καρφωτούρα' από τον κώδικα σου, σίγουρα θα έχεις κάνει κάτι καλύτερο! 

          Αν είσαι γεμάτος καρφωτούρες ή δεν ξέρεις πως να τις βγάλεις, ή δεν μπορείς να κατανοήσεις το πρόβλημα σου, μην διστάσεις να μου στείλεις ένα email.

          Saturday, May 24, 2014

          The vigilante...night #planetofzeus

          Παλιότερα είχα μάλλον τον χρόνο και την διάθεση να γράφω μακρόσυρτα review για την κάθε συναυλία που πήγαινα.  Πολλές φορές, ιδιαίτερα όταν έβλεπα νέες προσπάθειες, το έκανα για να βοηθήσω κι εγώ σαν απλός fan να ακουστεί το group. Θα ήθελα να έχω ακόμα την διάθεση, αλλά και τον χρόνο. Απ΄το ολότελα όμως :) .

          Για τους Planet of Zeus έχω γράψει αρκετές φορές ,θεωρώ ότι είναι από τα πιο αξιόλογα stoner/hard rock σχήματα τα οποία θα πρέπει να κάνουν και καριέρα στο εξωτερικό (τους το εύχομαι). Χθες στο Gagarin 205, εκτός ότι είχα μια ευκαιρία να μοιραστώ ένα live με τους καλύτερους μου φίλους, στιγμή που σπανίζει πια στην ηλικία μας και με τις υποχρεώσεις μας, άκουσα παλιά και νέα κομμάτια τους live. Support your local groups ρε, αν σας αρέσει η μουσική αυτή. (bandcamp)

          Κλέβω την group selfie, είμαστε κι εμείς μέσα δεξιά, κάτω από το πράσινο φωτάκι. Είναι ωραία η μουσική απ' τον πλανήτη Δία!

          via GnP

          Sunday, May 18, 2014

          Java EE7 and Maven project for newbies - part 3 - defining the ejb services and jpa entities modules #javaee #java #maven #juniordevs

          Series 



              We are resuming for the third part, we already have a parent pom and we have already defined the pom for our war module. In our original setup we have defined that our application is going to include a services jar, in the form of an ejb jar. This where our Enterprise Java Beans are going to be, specifically the Session Beans. We had also defined another module (layer) that is going to host the Entity Beans (Database representation beans), the so called domain model.

              Defining the services (ejb) module

              Under the parent pom folder, we create a new sub-folder, like we did with the war module. In this folder we create a pom.xml file with the following contents.The name of the folder is sample-services. The pom looks like this. Eventually this pretty much it, for now. 


              Remember that we have already defined in the dependency management section of our parent pom, the version of the javaee-api jar and there is also in the plugin management section a maven plugin that is going to take care of the specific packaging our ejb.jar requires. It is the maven-ejb-plugin. Go back to the parent pom and search for the 2 above points. Because of all these elements defined in the parent pom , our ejb service pom looks very minimal. Maven by convention is going to take care most of the stuff. The maven ejb plugin is going to kick in since we have defined that the packaging required for this module is 'ejb'.

              Our project structure looks like this


              Defining the entity beans (ejb) module

               Under the parent pom folder, we create a new sub-folder, like we did with the previous ejb module. We will name it sample-domain. This is the module that we will code our Database representation beans, the so called Entity beans, following the JPA2 specification. 

              The pom looks fairly simple.




              The packaging is still ejb, since it is going to host EJB classes, the so called Entity Beans

              There is another thing we need to package along, since this module is going to 'host' our domain objects, this is an XML descriptor called persistence.xml, which defines the Data source that our application is going to connect to. In Java EE 7, this file has been simplified a lot and we can even skip the the definition of the datasource, since there already one default. Have a look here. From the packing point of view, which we are more interested right now, what you need to do, is under the folder src/main/resources to create a new folder called META-INF and in there to place the persistence.xml  file, like in the image below.


              The contents of the persistence.xml at this point are not relevant (we will focus on the on the next posts), you can look up a sample on this post(s) git branch.

              A note here regarding folder creations, if you add Maven modules using an IDE e.g Eclipse or IntelliJ, once you create a new Module and you define a POM the IDE automatically creates the standard layout folders that your module is supposed to have, according to the Maven conventions. If you follow theses post and you write your code using with a simper tool e.g a simple text editor, then you need to create the src / main  folder structures on your own.

              That is all for this post, we have added 2 more modules for our application, but we are still missing the one that is going to package them all, this is the ear module. We have also not covered the 'inter-dependencies' of our modules this is something we are going to do, in the next 'ear' dedicated post, where all come together.

              The code for these simple poms can be found on bitbucket project, under the tag post3.

              Continue to part 4



              Wednesday, May 14, 2014

              OpenShift, the Java EE cloud platform that every Java EE developer will love. #openshift #redhat #wildfly #jboss

              I can remember this constant argument of many developers advocating other platforms in the past. 

              'Yes you may use Java which is generally ok, but even if you develop an app using your frameworks, nobody is offering hosting for your application servers , there are simply not a lot JVMs in the cloud that you could easily code something and show off'.

              I think I am not the only Java developer in the world who has rented a linux box from a data center far away, spent hours and hours trying to patch it update it, then install his/her java environment then fire up the server and finally try some code etc. It did not work for me. I just wanted to write code and use the technologies I know best, I don't want to become an expert on configuring machines based on the specific setup of an internet provider or a cloud platform.

              Then we have tried some early cloud offerings, but there were not so flexible enough. You could either get a servlet container and that's it. If you wanted something extra, a library, a framework, either you could not eventually set it up or it was prohibited or there was not enough access and flexibility. 

              Then I tried google app engine, which is not bad, as long as you code using the libraries and technologies the app engine supports. There is some  sort of flexibility but, what I really wanted is to make use of the new JavaEE stuff I read everyday, make use of my JPA / EJB / CDI  skills, test new JSF libraries and experiment with them. Code and show something. 

              After some time, while lots of people are already deploying and coding, I have finally spent some time reading about openshift (RedHat's cloud service). It took me 5 minutes to start a 'gear' with the latest Jboss Application Server (Wildfly) yaaaay, following the latest JavaEE 7 spec, bundled with most of the libraries I use everyday.

              For a Java EE developer Openshift feels like the 'cloud' home we have been waiting for many many years.  The extra cool thing about it, is that I am not forced to use any 'specific' tools in order to push my code to their cloud. Git/ Maven and Java API(s), eventually what almost everybody uses everyday at work. 

              I think it tool me more time to write this small post, comparing to firing up my 'simple' rest service'.

              Well done RedHat/JBoss!

              More experiments to come I guess.
               



              Switching to IntelliJ..maybe? #intellij #eclipse #java

              I am a regular Eclipse user, for almost 10 years now, it is not bad but in these recent years I feel like, I code towards a tool that is insisting on doing it's thing, maintaining it's state, invoking and running stuff that I can not control, on a daily basis.

              I have been spending more and more time trying to find, where to disable a validation , an error view or project face.t. My build tool of choice, actually the build tool of choice for many Java projects Maven, was a consistent nightmare when it comes to integration. It was only the latest Kepler release that Maven support was sort of working, even though now I feel like Eclipse, is trying to balance between two worlds. I've stopped using most of the intelligent stuff it offers since it makes almost unusable to work with (specific project facets). Some times (not always) an attempt to install a plugin may result in bringing down the whole IDE, corrupting it's internal property files. Then I have to delete my workspace, the famous .metadata or whatever internal thing and start all over.

              So I ended up disabling almost everything, do a quick compile check but when I want to build/deploy etc I switch to command line, fire a couple of mvn commands with profiles and that's it.

              A new release is coming out, code name Luna, and to be honest I am following already the M pre-releases, is it going to bring the Eclipse back on track, the track of being fast, reliable and consistent as a Java Development tool? I don't know, I hope so eventually.

              At the same time even more people are switching to IntelliJ, they talk about great Java refactoring features and very strong Maven support. So, I think about it.What I want is to write code and if the tools works well with Maven and respects my poms, to invoke it on the fly rather than switching to shell screens. If the tool is smart enough, along with Maven support and can do all these intelligent things without requiring me to search stackoverflow every week, then it might be even better.

              I am not asking for smart application server plugins, I have actually stopped believing in these tools a decade ago, I think they are evil and they tie you with the tool more that you should have been. It is sad that even now days many development teams out there do not know to how deploy their app, without any wizard or special menu in their IDE. The reality is that when you go live, in a production environment you can't tell you client 'oops sorry mate, I need to install this version of the IDE along with this server plugin, so I can deploy properly'.

              So I think I will give IntelliJ, a try. I can not switch in one day, I will start with my pet projects at home and then  I will use it at work. I don't think I can afford 450$ for a Pro License (even though that this the corporate price, for individuals is 180, thanks Marko.F for the tip), but anyway anyhow I just need to write Java and use the Maven integration, so I think I will be fine with the community one. If this get serious enough, I will pay the price. At the same time I will still keep an eye on the new release of Eclipse..maybe things will change..who knows.

              Sunday, May 11, 2014

              Εβδομάδα αφιερωμένη στην Java

              Στην ζωή μου έχω αφιερώσει αρκετές μέρες και εβδομάδες στην Java, ελπίζω να υπάρξουν ακόμα πιο πολλές.

              Την Τετάρτη βρέθηκα κι εγώ μαζί με παλιούς γνωστούς από την αγορά εργασίας αλλά και πολλά νέα παιδιά στο Java Day της Oracle Hellas, σε ένα πολύ όμορφο χώρο δίπλα στην Γεννάδιο σχολή.  Αρκετός κόσμος, δεν περίμενα τόσο, ιδιαίτερα παιδιά απ' τα πανεπιστήμια. Είναι το μεγάλο μας μαράζι στο JHUG ότι δεν καταφέραμε ποτέ να έχουμε μεγάλο αριθμό ενεργών φοιτητών, στην κοινότητα μας. Είχαμε προσπαθήσει τα πρώτα χρόνια αρκετά δυναμικά αλλά φάγαμε κάποιες πόρτες όταν μας έστελνα στον Χ, Υ κομματικό σύμβουλο ή γραμματέα κάποιας φοιτητικής οργάνωσης για να πάμε δωρεάν και απ' τον ελεύθερο μας χρόνο να μιλήσουμε για τεχνολογίες. Αφήσαμε το ελληνικό πανεπιστημιακό σύστημα με την ιδέα, ότι ήταν γενικά 10 χρόνια πίσω σε ότι έχει να κάνει την σχέση των ιδρυμάτων με την αγορά εργασίας σε όλα τα επίπεδα, μαθησιακό αλλά και θέμα mentality.
              Ίσως η κρίση να έχει ξεβολέψει αρκετούς, ίσως και τα παιδιά πια να καταλαβαίνουν ότι πρέπει να έχουν μια σχέση με την πραγματική ελληνική ή παγκόσμια αγορά αν θέλουν να βρουν δουλειά και να μην είναι 'κοιμισμένοι' στο πανεπιστημιακό 'buble'  το οποίο δεν μπορεί να τους χωρέσει όλους. 

              Η παγκόσμια αγορά πληροφορικής αναζητα developers, όχι μόνο Java, το θέμα είναι αν στην Ελλάδα θα υπάρχει μια τέτοια σχετική κίνηση απο την ακαδημία. 2 στους 3 φοιτητές πριν 10 χρόνια που ρώταγα αν θα ασχοληθούν με τον προγραμματισμό, μου έλεγαν 'όχι θα κάνω δίκτυα'. Μου θύμιζαν γνωστούς σε σχολές εμποροπλοιάρχων που ως παιδί ναυτικού τους ρώταγα, παιδιά σίγουρα σας αρέσει είναι σκληρό επάγγελμα, και μου απαντούσαν, 'οχι ρε χαζός είσαι 1 χρόνο και μετά θα βολευτώ στο Λιμενικό'.

              Όπως και να έχει ελπίζω να υπάρχει μια στροφή και στο μυαλό των νέων, πιστεύω ότι έχουμε  λαμπρά μυαλά που μπορούν να γίνουν άριστοι επαγγελματίες σε παγκόσμιο επίπεδο. Θλίβομαι να βλέπω κομματικές οργανώσεις, φανατισμό και ωχαδερφισμό μέσα σε ιδρύματα που  πρέπει να προετοιμάζουν νέους για την αγορά εργασίας αλλά και την έρευνα (όχι μόνο το ένα ή το άλλο, για να είμαστε δίκαιοι).

               Χάρηκα ιδιαίτερα την Τετάρτη μιας και συναντήθηκα με παλιούς μου συναδέλφους τους, με τους οποίους έχουμε περάσει αρκετά ενδιαφέρουσες επαγγελματικές στιγμές. Μερικούς από αυτούς δεν έχω καταφέρει να τους βρώ σε άλλες δουλειές και χώρους, ίσως τελικά στην καριέρα σου θα είναι λίγες οι στιγμές και οι ευκαιρίες που θα βρεθείς σε έναν χώρο με πολύ αξιόλογους επαγγελματίες, όπου θα μάθεις αλλά και θα μοιραστείς γνώσεις.

              Ελπίζω η παρουσίαση μου να ήταν τουλάχιστον ενδιαφέρουσα. Μπορείτε να την βρείτε εδώ

              Χθες, Σάββατο, μαζί με τον Πάνο, πήγαμε στα ΙΕΚ Δέλτα, προσκεκλημένοι σε μια μικρή ημερίδα για την τεχνολογία. Βοήθησα τον Πάνο (μιας και έχει και την μεγαλύτερη γνώση στο θέμα), σε μια εισαγωγή στο Android, και προσπαθήσαμε μέσα σε 1- 1.30 να κάνουμε τους σπουδαστές εκεί να ασχοληθούν με το Android ή τουλάχιστον να δοκιμάσουν. Η παρουσίαση μας είναι εδώ, είναι ουσιαστικά σαν σημειώσεις παράλληλα με το coding session του Πάνου.

              Το επόμενο Σάββατο στο JHUG, θα βρεθούμε να ακούσουμε για Groovy, τα λέμε εκεί.

              Μέχρι τότε καλά  να Java-ρετε.

              Sunday, May 04, 2014

              Ομιλίες Java την επόμενη εβδομάδα.

              Η εβδομάδα που μας έρχεται (5-10 / 5 ) είναι αρκετά γεμάτη με Java για μένα.

              Την Τετάρτη (7/5) θα έχω την τιμή να είμαι στο lineup των παρουσιαστών του Athens Java Day που διοργανώνει η Oracle Hellas. Η συμμετοχή είναι ΔΩΡΕΑΝ, registration εδώ. Θα υπάρχει ένα πλούσιο πρόγραμμα από το πρωί μεχρι τις 5-6 το απόγευμα.  Ομιλητές από την Oracle,  από τον πανεπιστημιακό χωρό, αλλά και το JHUG πχ η προσπαθεια του Adopt a JSR με τον. Θ.Πλιάκα και τέλος ο γνωστός μας Heinz Kabutz με μια ομιλία για την Java 8.
               Όσοι μείνετε μεχρι το τέλος θα με προλάβετε με μια παρουσίαση γύρω από το JSF 2, και τις εμπειίες μέσα από ένα project το οποίο ολοκλήρωσαμε πρόσφατα μαζί με 2 άλλους συναδέφλφους, το status του web development στην Java, τις δυσκολίες και ανυσηχίες που είχαμε αλλά και την γενικότερη εξέλικη του JSF σαν framework. 
              Θα είμαι εκεί από το πρωί, ελπίζω να δω γνώριμο κόσμο αλλά και νέες φάτσες.

              Το Σάββατο (10/5) το απόγευμα, μαζί με τον φίλο μου και συναγωνιστή  στο JHUG, Πάνο Κων/νιδη, είμαστε καλεσμένοι  του ΙΕΚ Δελτα, στα πλαίσια μιας ημερίδας αφιερωμένη στον προγραμματισμό. Στις 4 το απόγευμα θα μιλήσουμε για Android Development, και θα προσπαθήσουμε σε 2 ώρες να φιάξουμε μια demo εφαρμογή, όπου θα προσπαθήσουμε να καλύψουμε βασικά στάδια ανάπτυξης και να παρέχουμε μια γρήγορη εισαγωγή στον κόσμο των android based mobile εφαρμογών και φυσικά στην Java. 

              Τα λέμε από κοντά λοιπόν!