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


    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.


      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


          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. 

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

          Thursday, May 01, 2014

          Java EE7 and Maven project for newbies - part 2 - defining a simple war for our application #javaee #java #maven #juniordevs


          We have just defined, our parent pom. A special type of pom that eventually defines the libraries that our application is going to use. It also configures all the maven tools used in order to package each module of our application. You can check out the part -1 sample code here.

          So up until now in the directory where we will be developing our application we have a single folder called sample-parent and in this directory a pom.xml resides. Our parent pom!

          As we can see in the section modules, we have defined, the building blocks of our application
          • sample-ear
          • sample-web
          • sample-services
          • sample-domain
          We need to create related maven modules and add the specific pom.xml files for each one of them.

          Defining the war module

          Under the sample-parent folder we create a sub-folder called sample-web and we also add a pom.xml file. (some people do it on the same level) .

          But this just nothing, we need to be more specific on what this pom will be helping us to builld, so we need to define the packing type, a name for the module (for this war) and any dependencies.

          In case you are using an IDE (e.g  Eclipse) that supports Maven, it will automatically detect the changes on the content of your pom and will, create for you automatically folders, that conform with the Maven War packaging. It will create for you the following structure.  You can of-course do it on your own but, it is handy!

          • src
            • main
              • java (add your java code here)
              • webapp (this is where WEB-INF\web.xml is placed)
              • resources (resources, like properties)
            •  test
              • java
              • resources

          Under the webapp subfolder I have already pre-created the \WEB-INF\web.xml file . I could skip this part because the maven plugin can do it for us, but just to show case that there cases where you want to create it on your own and any custom entries

          If you are wondering what to 'put' in an empty Servlet 3.1 web.xml file, then have a look here, or download the code for this post. I have also added in the java subfolder under a simple package a very simple Servlet, that is going to be included in our application. Just a few lines of code. Again you can download all the code in the related git (bitbucket) link, at the end of the post.

          So, we have added just a few lines on our war module pom file, and then in case we have an IDE, magically the tool created a very specific folder layout for us. We have 'followed' this layout and added a very simple servlet java class and a small xml descriptor. What is the real point here.

          Well, the great thing about maven is that some of the stuff that our War module needs to built, are already defined and configured in the 'special' parent pom. But what are these stuff, and how Maven is going to use it? As we have already elaborated Maven is all about conventions. You put the right things in the 'right' way and then it does all the work for you.

          So when maven scan(s) this war packing pom it will need to
          • compile our java class, which is a servlet
          • and package everything under the sample-web folder, into a war file + any dependencies.
          Who is going to do all  of these things, since we have not added something special in our war pom( except the one dependency library). Well it is the configuration or our parent pom (see the previous post).

          The   maven-compiler-plugin is going to be 'invoked' in order to compile our sources, and since we have defined that the packaging of our maven module is 'war' then maven-war-plugin is going to invoked to package everything for us, create the appropriate descriptors.

          So in a case where our application might have several war or jar modules, if we have a parent pom and we have defined in one central place the plugins and a basic configuration for then we DO NOT have to re-define it in all or our war / jar pom (s).

          Only in case one of the war(s) or jar(s) need special treatment (e.g package something extra or have a special layout), then under the build section we could re-define the plugin and over-write or add some extra, behavior. But this not our case. We want our plugins to be defined, once, and have a common configuration that is going to be 'inherited' by all the modules of our application that re going to use it.

          Using the above hint, you can experiment and try, to create the sample-services module we have 'defined' above, or wait for the third part where we will quickly cover the rest of the concrete modules.

          You can find the code for this post here. (post2 tag)

          Continue to part 3