Tuesday, April 19, 2016

Judo ... στο Λονδίνο..και σκέψεις πίσω στον δικό μου σύλλογο.

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

Μετά απ΄το σύντομο πέρασμα σε ένα αρκετά συμπαθές και μικρό σύλλογο στο Luxembourg, σήμερα έκανα την πρώτη μου προπόνηση στο Sobell Judo Club, στην περιοχή του Isligton (κοντά στο emirates) που έχει γίνει και μια απ' τις αγαπημένες μου περιοχές γενικά, ιδιαίτερα απ' το Angel και προς τα πάνω.

Ο sensei Σ.Σαμσών  8 νταν , με εντυπωσίασε,  πραγματικά έμεινα ευχαριστημένος  από την ευγένεια  αλλά και τον τρόπο διδασκαλίας του.  Επίσης μπορούσα να ανταλλάξω και μερικά ελληνικά μαζί του πάνω σε τεχνικές. Ιδιαίτερα φιλικοί και ευγενικοί οι αθλητές, το τμήμα είναι mixed, άνδρες, γυναίκες και μικροί Judoka,  είχα την ευκαιρία να τους γνωρίσω όλους και να με κάνουν να αισθανθώ αρκετά άνετα. Ότι περιμένεις δηλαδή σε κάθε dojo.  Οι προπονήσεις είναι 2 φορές την εβδομάδα, από 1.5-2 ώρες. Το dojo είναι μέσα σε ένα μεγαλύτερο αθλητικό κέντρο με πολλές δραστηριότητες και χώρους - μου θύμισε το γυμναστήριο του πανεπιστημίου πριν πολλά χρόνια - αλλα 3 φορές μεγαλύτερο.

Αυτή είναι η μαγεία του Judo, μια παγκόσμια οικογένεια με τις ίδιες αξίες. Δεν έχει σημασία που θα πας, όταν πατήσεις το πόδι σου σε ένα dojo, θα σε αγκαλιάσουν σαν 'brother' όπως μου είπαν σήμερα και θα προσέξουν να ενταχθείς γρήγορα. Ανεξάρτητα απο θρησκεία, χρώμα ή καταγωγή.

Μιας και το γράφω αυτά δεν ξεχνώ να βοηθάω και να συμμετέχω οσο μπορώ ηλεκτρονικά στον 'αγαπημένο΄μου σύλλογο, τον Συλλογο Judo Περιστερίου - Dojo Club. Σε πιάνει μια μελαγχολία μερικές φορές όταν βλέπεις τους δασκάλους σου και παλιούς συναθλητές σου σε φωτογραφίες, να συνεχίζουν την προσπάθεια, να κάνουν δραστηριότητες και να μεγαλώνουν τον σύλλογο. Αν είστε απ΄ τα δυτικά και θέλετε να μάθετε για το judo, κάντε μια βόλτα πάνω στον Άγ. Βασίλειο στο Περιστέρι - υπάρχει μια θερμή judo παρέα.
hajimeee λοιπόν και στο Λονδίνο! 

Sunday, April 17, 2016

Spring Async and Java's 8 CompletableFuture, a small change to the existing tutorial #spring #async #java8

It is known that I am not the biggest fan of Spring, but at the time being I work for an organization that maintains too many projects utilizing Spring (in different forms and versions). I still remain skeptic towards Spring, of course there are some very nice ideas, there are some nice (too many) abstractions, there are some very handy 'shortcuts' to bootstrap complex projects. I am not going to elaborate on the things I don't like in this post.

One thing I like on Spring's documentation, is their getting started guides. Well written and concrete. I was reading through, a short guide, for 'Async' method execution, through SpringBoot /RestApi [link] .

So this is this the implementation of the example 'asynchronous' findUser() method. Full source here.

@Async
public Future<User> findUser(String user) throws InterruptedException {
  System.out.println("Looking up " + user);
  User results = restTemplate.getForObject("https://api.github.com/users/" + user, User.class);
  // Artificial delay of 1s for demonstration purposes
  Thread.sleep(1000L);
  return new AsyncResult<User>(results);
}


I was wondering why there is still a 'Future' in the example, while we have been introduced Java8, CompletableFuture. I guess the original authors want to preserve backwards compatibility with previous versions of Java (6 / 7 ) - where this construct is not available.

It seems that someone else had the same question, and wrote a very nice example here. In one of the comments, you can see a hint that from version 4.2 and onward the Spring API, would be compatible with the use of CompletableFuture, on top of Future & AsyncResult which are already provided. I thought, `well it's a shame, why not try it or even document it, because if someone lands on this example, he/she might stay with the current implementation` - why not use something standard?. 

So I decided to make a tiny change, remove Future and replace it with CompletableFuture, also comment out the calls to Future.isDone() and replace it with the very handy CompletableFuture.allof() method.

So I changed the return type on the 'service' method



while, updating the, caller code - to sync on all 3 futures and once allof() them were done, we could print the results.

The modified, example can be found here. I found this and this blog posts from Tomasz Nirkewicz, a very nice and pragmatic walk through of CompletableFuture, rich method list. There is also a quite complete presentation by my favorite Devoxx Speaker , Jose Paumard you can find it here.

Links
  • https://spring.io/guides/gs/async-method/
  • http://geowarin.github.io/completable-futures-with-spring-async.html
  • http://www.nurkiewicz.com/2013/05/java-8-completablefuture-in-action.html
  • http://www.nurkiewicz.com/2013/05/java-8-definitive-guide-to.html
  • https://github.com/javapapo/projects-from-blog/tree/master/spring-async-complfuture

Sunday, April 10, 2016

while (true) { νοστος };

Όταν πρωτό φτάσαμε στο Λουξεμβούργο, για κάποιο καιρό σκεφτόμουν αρκετά έντονα το σπίτι μου στην Ελλάδα, το δυτικό Χαϊδάρι. Ο πραγματικά υπέροχος καιρός σε αυτό το μικρό καταπράσινο κέντρο ευρωπαϊκό χωριό δεν με βοηθούσε αρκετά. Έβλεπα καθημερινά ειδήσεις, ήταν και εκείνο το δημοψήφισμα, νιώθαμε ότι φύγαμε μάλλον την τελευταία στιγμή. Μετά από 1,2 μήνες σταμάτησα να σκέφτομαι την Ελλάδα, αυτό το αίσθημα που σου δημιουργεί ο νόστος  ξέρεις. Είχα ήδη συνειδητοποιησει ότι δεν θα έμενα για πολύ εκεί, οπότε θωράκιζα τον εαυτό μου για το επόμενο βήμα.

Τώρα που έχουμε  εγκατασταθεί στο Λονδίνο περνάω κάπως το ίδιο (σκέφτομαι το σπίτι μου), υπολογίζω ότι σε λίγο θα περάσει και αυτό. Ίσως είναι και συσσωρευμένο άγχος και ένταση που δημιουργήθηκε από το extreme relocation (2 χώρες σε  λιγότερο από ένα χρόνο).

Εδώ στο Λονδίνο, έχω πιο πολλούς γνωστούς και φίλους. Ανθρώπους που τους ήξερα και με ήξεραν απ΄ όταν πάτησα το πόδι μου εδώ για πρώτη φορά το 1999, αλλά και άλλους που περάσαμε αρκετά χρόνια μαζί στη Αθήνα, στο ίδιο γραφείο, όλη μέρα.  Μερικές φορές νιώθω ότι ζώ σε μια παράλληλη πραγματικότητα. Μαζευόμαστε για καφέ ή φαγητό, τόσα γνώριμα πρόσωπα, και μιλάμε για τα παλιά, μερικές φορές και για την Ελλάδα. Λες και έχουμε βγει για μπύρα μετά την δουλειά στην Πανόρμου. Δεν ξέρω ακόμα όλη αυτή η εικόνα μου φαίνεται παράξενη και η πλάκα είναι ότι είμαι κι εγώ μέσα σε αυτή. 

Το πιο ενδιαφέρον είναι όλα αυτά προλαβαίνω να τα σκεφτώ και να τα αισθανθώ το Σαββατοκύριακο. Δευτέρα με Παρασκευή μάλλον το μυαλό κάνει switch! Αύριο θα βάλω την τελευταία πινελιά, βρήκα σύλλογο για να συνεχίσω το Judo, είναι δίπλα απ' το γήπεδο της Arsenal. Για να δούμε. 

Συνεχίζουμε να λαμβάνουμε ερωτήσεις, από ανθρώπους που θέλουν να φύγουν. Κάποιοι με αεροπορικά έτοιμα, άλλοι τεστάρουν τις αντοχές τους, άλλοι μετράνε τα χρήματα στις προτάσεις. Νομίζω ότι η παρέα μας θα μεγαλώσει και άλλο σύντομα.  Συνεχίζω να μην έχω χωνέψει 100% ότι έγινα κι εγώ κομμάτι του μεταναστευτικού κύματος. Ίσως αυτή η συνεχής μετακίνηση να μην βοήθησε αρκετά. 

Θα δούμε, περίεργες οι εναλλαγές συναισθημάτων.


Sunday, March 27, 2016

The Java Hellenic User Group..είμαστε ακόμα εδώ - 2 April 2016 @ Orange Grove

Νομίζω δεν θα ξεπεράσω ποτέ το 'είμαστε, έχω τρέξει αρκετά (όπως και άλλοι) για την μικρή αυτή την κοινότητα στην Αθήνα και την πονάω και ενδιαφέρομαι ακόμα.  Είναι ιδιαίτερη στιγμή γιατί έχουμε ουσιαστικά το  πρώτο JHUG event το οποίο δεν το οργανώνει 100% η αρχική ομάδα του JHUG. Γι' αυτό όσοι είναι ακόμα στην Ελλάδα και συγκεκριμένα στην Αθήνα στις 2 Απριλίου, περάστε μια βόλτα απ' το Orange Grove. Πληροφορίες εδώ.

 Καλά να java-ρετε όπου κι αν είστε!

Sunday, March 20, 2016

Is your codebase smelly? Find out with the help of SonarQube and the Smells plugin!

In the project which I recently joined, I discovered a set of annotations, (part of the code) that eventually did not add any functionality but they were 'marking' classes or fields  as a potential bad implementation, or as a potential case that may need to be reworked. The original author, had created a very elegant way (imho) on annotating parts of the code, for things that needed to change or to be improved. This mechanism was mostly targeting less senior contributors so they improve and at the same time, it was marking 'smells' in the code that unfortunately were not a 5 minute fix and might need a bigger change or discussion around it.

@TechBebt ("rework this method, so that takes care this business concern")
@Refactor ("Use the proper data structure for this operation, see LinkedList");
public void doSomething(String aParam){

In the past I used to work in projects where this kind of code-review and comment process was performed using our famous following comments. You might have some of those in your project I guess.

// TODO 
// FIX-ME

I really liked the annotation approach, so since I am new, I started searching for them all over the place. When I found something that I could fix, I followed the annotation's description field, and I could provide a small bug fix. It seemed to be a bit cleaner than the long sentenced TODO items. The problem with the above annotations is you will bump into them, only if you happen to see them, or search for them in your IDE, where TODO or FIX-ME usually show up in IntelliJ's or Eclipse's task (todo) list.

At the same time, I proposed to install Sonar for the team and eventually monitor the 'health' of our code base improving the exposure of this information to a wider audience. The more you expose your code problems to the team, the easier you make this information to anyone, the more chances you have members to contribute fixes rather than dictating it as a process.

While I was configuring Sonar, I discovered the Qualinsight Smells Plugin, along with their maven library. Eventually it is a library that contains similar annotations to those I discovered in the project, so you can add it as a dependency in your project and start 'marking the smells'. These annotations then can be scanned by the related Sonar Plugin, so when you code base is scanned, in the final Sonar report, you can have a list of  all the annotated 'Smells'. You can go through the simple documentation on github. A smell annotation looks like this: 

@Smell(minutes=10,reason="This class should be redesigned in order to", 
type=SmellType.BAD_DESIGN)

You have to indicated
  • an estimate of time for a potential fix.
  • the reason, actually the description of the smell.
  • and a set of predefined types, in order to specify what kind of smell it is. The provided list is  sufficient enough to cover most of the cases.
You can find an example of project configuration here.

When the Sonar report is ready, the smells are going to be listed , as the image below illustrates.



I really liked the overall approach. Despite the fact that our ultimate goal is eventually to fix the code and only 'annotating' defects, I still think it is a very elegant idea. Especially when your team consists of less senior developers or 'devs' that they don't pay attention to things like quality and maintainability of the code base, it is a very 'constructive' and elegant way to bring forward these concerns and with the help Sonar, increase their exposure. It is also a team effort, identified Smells are not predefined rules from findbugs or PMD, they are human identified  points, there might cases where the code is fine, but it does not implement correctly the business.  Sonar enables non technical stuff to eventually have access to the 'state' of the project, so yet another way the product owners/ managers to a better understand about 'technical debt'.

So...is your code base smelly? If yes do something about it. Nobody likes smelly code.

ps) All credits to M.Pawlak  (@QualInsight) for his work on this library.