Saturday, December 01, 2018

The stubborn developer


It all started with this tweet by fellow developer (and friend) Heinz Kabutz:
"New Challenge - 15000 push-ups in 5 months. Great for programmers wanting to get into shape (well round is a shape too ...). The first months are not too bad, but February is a killer. Join here"
Sure, what's more natural than doing 15k push-ups in 5 months, right? Especially, if the last time you did push-ups was some (very) distant time in the past, plus you've never managed to do more than a dozen or so in one go.

I kind of laughed when I saw the tweet but at the same time I've got intrigued. I do try to do jogging occasionally and also try to play volleyball with friends on Thursdays, but any strength related exercise was never my thing. And it still isn't. But then again, I'm about the same age with Heinz and he's 112kg (and taller, and wider) while I'm only 74kg, and he'll manage to do that many push-ups while I sit back watching?

Bloody hell, I'm in :-)

Of course, I was quick to comment on the original tweet that there is no way for me to make it past October, clocking 1000 push-ups that month. First of all, I didn't feel much fit for the task and I usually don't have that much discipline, plus business travel & conferences always mess up my daily routine.

Or so I thought.

Because by the end of October despite the struggle of starting from very low and putting reminders to not forget to exercise, I've clocked 1040 push-ups! I just couldn't believe it. October was heavy on travel and I did miss 5 days, but for all the other 26 days I've averaged 40 push-ups, done once a day in 3 sets. Not just me but 335 other people got to Bronze status. Wow.

Then it became serious and despite the initial success there was simply no time to celebrate. It was really a struggle getting to the 1k level, so how can you double that and reach 2000 push-ups in November, which was meant to be even worse travel-wise? The numbers had to go up to reach the 67 push-ups per day average and account for any lost days.

And I did skip 4 days in November and had to come up with a strategy to cover for those, which meant that some days I would have to do push-ups twice, while increasing the sets to 4. But it did work at the end and on November 30th, I've celebrated the 2000th push-up of the month, reaching Silver status together with 217 fellow Java push-uppers.

Which brings me exactly to my point that software developers can be stubborn as hell once they set their mind onto something, be it debugging an impossible bug, developing a new app or framework, completing a project, or simply doing something seemingly stupid, like push-ups!

In this profession I've met so many capable programmers from all over the world and one of their main traits is their persistence. Being a developer requires both focus and problem solving skills, but that alone is not enough. The most successful developers exhibit an incredible ability in getting the job done, as long as it's a job challenging enough that resonates to them.

And that's exactly the job of managers and leaders: to challenge their teams and align them behind that one big worthy, seemingly impossible goal. Then let the "stubborn" developers go out and do their magic.

So, for the month of December, I am still in the game trying to reach the 3k mark by New Year's. An average of 97 push-ups per day is needed and that already seems too high and it certainly requires two session per day. But I will have a go and see how that works. I feel I've already gone too far beyond all my original expectations and I will likely want to stop at the Gold level.

Now that the number have gone up, I get the feeling that push-ups alone exercise too much the "front" upper part of the body and a more balanced method is needed. Or maybe that will be Heinz's next challenge, who knows? :-)

 /Dimitris

PS - Some Hints (from a push-up newbie)

  1. The good thing about push-ups is they require zero equipment. Non slipping shoes and a t-shirt is probably best.
  2. It usually takes less than 10 minutes to do 3 sets with 2-3 minutes rest in between.
  3. You can do them anytime in the day, but definitely *before* meals. I try to clock some push-ups while preparing my morning coffee. That gets the blood flowing and wakes you up (I am definitely not a morning person). Then try again sometime in the afternoon as a way to get away from the keyboard, or the evening before dinner.
  4. You can do push-ups anywhere. In the kitchen, the living room, your office, the bedroom. When in a hotel room I'd put one of the bathroom floor towels horizontally under my hands to avoid getting my nose too close to the carpet.
  5. I try to do 3 sets every time with decreasing difficulty. E.g. 25-20-15, that's a nice 60. For the first set do as many as you can before it starts hurting, then lower the number for the next ones. That means you may start initially with e.g. 12-10-8, or even 5-4-3, whatever works for you. If you want to check up my progress, it's here.
  6. I'm using the Garmin Vivoactive 3 watch to record the activity in the Strength category. This is really about weight lifting but it's the closest I could find. It can count the push-ups with some relative precision if you do them cleanly. After each set you can correct the count (e.g. it measured 19 but you did 20) and add 0 as weight.
  7. Forget about Heinz, this is all about you - you are competing with yourself :-)

Sunday, November 25, 2018

Βαρουφακιάδας ανάγνωσμα

Με πολύ ενδιαφέρον και καθυστέρηση έξι μηνών από τον Μάιο του 2018 που δημοσιεύτηκε διάβασα το Adults in the Room (Ενήλικες στο δωμάτιο) του Γιάνη Βαρουφάκη. (Η ρήση σχετίζεται με σχόλιο της Christine Lagarde αναφερόμενη στην ανάγκη ύπαρξης ενηλίκων στο δωμάτιο ικανών να διαχειριστούν την επίλυση μιας κρίσιμης κατάστασης.)

Ενδιαφέρον γιατί για μεγάλο διάστημα προσπαθούσαμε να αποκρυπτογραφήσουμε τί στο καλό συνέβαινε με την περίφημη διαπραγμάτευση μεταξύ κυβέρνησης του ΖΥΡΙΣΑ και τρόικας το δραματικό πρώτο εξάμηνο του 2015. Ποια ήταν αυτή η μαγική λύση που είχε υποσχεθεί ο ΣΥΡΙΖΑ που θα έβγαζε την χώρα από τα μνημόνια;

Το εκπληκτικό είναι ότι ο Βαρουφάκης είναι εξαιρετικά λεπτομερής στην αφήγηση των γεγονότων. Και αυτό ήταν δυνατό γιατί προφανώς ηχογραφούσε όλες τις συνομιλίες του, χωρίς την έγκριση των συνομιλητών του. Σε κάποιο σημείο το παραδέχεται μάλιστα. Και είναι τέτοια η ταύτιση της περιγραφής με τα αυτά που είδαμε να συμβαίνουν σαν εξωτερικοί παρατηρητές που είναι πολύ πιθανό να είναι περιγράφουν την αλήθεια. Μια αλήθεια ωραιοποιημένη (και ηρωο-ποιημένη) σε κάποιο βαθμό, αφού ο Βαρουφάκης ουσιαστικά παρουσιάζει τον εαυτό σαν μοναχικό σταυροφόρο, με τον κεντρικό κορμό του ΖΥΡΙΖΑ να τον σαμποτάρει, όμως παρόλα αυτά εξαιρετικά ενδιαφέρουσα και σχεδόν πλήρης. Είναι σαν να σου δίνουν το λυσάρι σε κάποιο δύσκολο διαγώνισμα.

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

Τα ουσιαστικά

  1. Ο Βαρουφάκης ήταν απόλυτα σωστός στην διάγνωση των αιτίων της κρίσης. Αλλά ταυτόχρονα ήταν απόλυτα αφελής στην δυνατότητα της Ελλάδας να εκβιάσει μία ριζικά καλύτερη λύση.
  2. Η μοναδική (μάλλον) ευκαιρία που είχε η χώρα να κουρέψει ένα μεγάλος μέρος του χρέους (και φυσικά να χρεοκοπήσει) χάθηκε το 2010. Ένα πολύ μεγάλο μέρος του χρέους τότε βάρυνε Γερμανικές (27.8 δις) και Γαλλικές (63.6 δις) τράπεζες και το bail-out του πρώτου προγράμματος είχε ακριβώς σκοπό να τις σώσει. Σε εκείνη την φάση θα μπορούσαμε να διαπραγματευτούμε κάτι καλύτερο (ή να χρεοκοπήσουμε κανονικά) γιατί ακριβώς θα παίρναμε μαζί μας το μισό ευρωπαϊκό τραπεζικό σύστημα. Αλλά φυσικά, ήμασταν παντελώς ανέτοιμοι χωρίς πλάνο Α αλλά ούτε πλάνο Β. Απλά κάναμε ότι μας είπαν.
  3. Μετά το πρώτο και το δεύτερο πρόγραμμα (δηλαδή μνημόνιο) το Ελληνικό πρόβλημα είχε ουσιαστικά απομονωθεί και οι Γερμανικές και Γαλλικές τράπεζες είχαν ξεφορτώσει το Ελληνικό τοξικό χρέος. Οι δυνατότητες μας να εκβιάσουμε οτιδήποτε ήταν εξαιρετικά περιορισμένες έως ανύπαρκτες.
  4. Το περίφημο αναχαιτιστικό όπλο (deterrent) του Βαρουφάκη ήταν το κούρεμα ή καθυστερημένη πληρωμή των ομολόγων κάτω από Ελληνικό δίκαιο που κατείχε η Ευρωπαϊκή Κεντρική Τράπεζα (περίπου 30 δις). Η θεωρία έλεγε ότι αυτό θα άφηνε έκθετο τον Draghi έναντι της Bundesbank που τον είχε πάει στο Ευρωπαϊκό δικαστήριο για αγορά επισφαλών ομολόγων από τα οποία μπορεί να έχανε η Ευρωζώνη, κάτι που απαγορευόταν από το καταστατικό της ΕΚΤ, και με την σειρά του (μάλλον) θα ακύρωνε το πρόγραμμα ποσοτικής χαλάρωσης (QE) που ήταν μόλις να αρχίσει. Σημειωτέον ότι το δικαστήριο έγινε το 2014 και το κέρδισε ο Ντράγκι.
  5. Η απειλή κουρέματος των Ευρωπαϊκών ομολόγων της ΕΚΤ στην πράξη δεν τρόμαξε κανένα. Οι τροϊκανοί σε καμία περίπτωση δεν έδειξαν αδυναμία και ειδικά ο Σόϊμπλε όχι μόνο δεν έκανε πίσω αλλά πρότεινε και την (προσωρινή υποτίθεται) έξοδο της Ελλάδας από την Ευρωζώνη οραματιζόμενος έναν ισχυρότερο Ευρωπαϊκό πυρήνα χωρίς κάποιες προβληματικές χώρες.
  6. Στις διάφορες διαπραγματεύσεις η Ελλάδα με την επιθετική της συμπεριφορά κατάφερε να απομονωθεί σχεδόν πλήρως. Πέρα από την Γερμανία και τους δορυφόρους της, απέναντί μας βρέθηκαν και όλες οι χώρες που ήταν σε πρόγραμμα, γιατί πολύ απλά κανένας δεν θα υποστήριζε ένα καλύτερο πρόγραμμα για τον άλλον από αυτό που είχε κατάφερε να διαπραγματευτεί για τον ίδιον.
  7. Το μόνο αντικείμενο διαπραγμάτευσης από την πλευρά της τρόικας ήταν το μείγμα μέτρων του μνημονίου και όχι οι στόχοι του. Τα ίδια νούμερα έπρεπε να βγουν με άλλο τρόπο. Η επιλογή του ακριβή συνδυασμού μέτρων ήταν πάντα στην διακριτική ευχέρεια της κυβέρνησης, με την έγκριση της τρόικας.
  8. Σε όλη την μακρόχρονη διάρκεια διαπραγμάτευσης ο χρόνος ουσιαστικά κυλούσε εναντίων μας. Οι Ευρωπαίοι το μόνο που χρειαζόταν να κάνουν ήταν να περιμένουν.
 

Τα Παραλειπόμενα

  1. Επαναλαμβάνεται συνεχώς ότι ο Ντράγκι έκλεισε τις τράπεζες, προφανώς για να μετατεθεί η ευθύνη. Είναι σαν να σου δίνουν ένα κόκκινο κουμπί και σου λένε ότι αν το πατήσεις θα ανατιναχτεί ο τοίχος απέναντι, και εσύ το πατάς και μετά κατηγορείς το κουμπί ότι φταίει!
  2. Σε μία διαπραγμάτευση δεν μπορείς να βγαίνεις και να εκθέτεις τους ανθρώπους απέναντί σου, ή να αποκαλύπτεις/διαρρέεις το περιεχόμενο της συνομιλίας. Απλά καταστρέφεις την διαπραγμάτευση και δεν σε εμπιστεύεται κανείς.
  3. O Μακρόν και το ΔΝΤ πιθανά ήταν οι καλύτεροι σύμμαχοι της Ελλάδας. Ο Γιούνκερ παρόλο που ήταν συμπαθής δεν τον άκουγε κανένας. Η Μέρκελ ήταν ο απόλυτος άρχων που φυσικά έκανε τον Τσίπρα ό,τι ήθελε.
  4. Η αριστερή πλευρά του ΖΥΡΙΖΑ (Λαφαζάνης, κτλ) πάντα ήθελε το Grexit και ακολούθησε τον ΖΥΡΙΖΑ με μοναδικό σκοπό ότι είτε αυτός θα ήταν ο τελικός προορισμός ή κάποιο κούρεμα χρέους, το οποίο ήταν από τις βασικές υποσχέσεις του Βαρουφάκη.
  5. Ο Σόϊμπλε εγκατέλειψε την υποστήριξή του στον Σαμαρά τον Ιούνιο του '14 γιατί είχε υποστεί φθορά και καθυστερούσε τις μεταρρυθμίσεις. Ο Σαμαράς ακολούθως έκανε στροφή προς το λαϊκότερο και φυσικά έχασε τις επόμενες εκλογές εφόσον ο ΣΥΡΙΖΑ δεν συναίνεσε στην εκλογή προέδρου της Δημοκρατίας.
  6. Το περίφημο πρόγραμμα της Θεσσαλονίκης το οποίο είχε επιβλέψει ο Δραγασάκης με τον Τσακαλώτο ήταν μία απόλυτη εκλογική φούσκα. Ο Παππάς παραδέχεται ότι ήταν  ένας τρόπος να κινητοποιήσουν (μετάφραση: κοροϊδέψουμε) τον κόσμο και το πραγματικό πρόγραμμα θα είναι άλλο. Ο Βαρουφάκης το περιγράφει δε σαν Τερατούργημα (σελ 90) ενάντια σε αυτό που ήθελε να διαπραγματευτεί και να υλοποιήσει.
  7. Το περίφημο παράλληλο σύστημα πληρωμών, ήταν βασισμένο στην ιδέα ότι το κράτος πληρώνει τις υποχρεώσεις του με ένα νέο ηλεκτρονικό (αποκλειστικά) νόμισμα (ή υποσχετική/IOU) πιστώνοντας μονάδες στο ΑΦΜ μίας επιχείρησης, υπαλλήλου, συνταξιούχου, κτλ. Αυτός με την σειρά του μπορεί να πληρώσει υποχρεώσεις του προς το κράτος ή κάποιον άλλον (που το αποδέχεται βέβαια) εντός της χώρας. Φυσικά κάτι τέτοιο αντιτίθεται στους κανόνες της Ευρωζώνης όπου αποκλειστική ευθύνη δημιουργίας ρευστότητας έχει η ΕΚΤ και τα παρακλάδια της (οι Εθνικές Κεντρικές Τράπεζες), και δημιουργεί ένα ντε-φάκτο υποτιμημένο εικονικό νόμισμα για εσωτερική χρήση.
  8. Για κάποιο λόγο θεωρούσαν ότι το παράλληλο σύστημα πληρωμών δεν συνιστούσε Grexit. Στην πραγματικότητα ήταν σαν να λέμε μισό Grexit, αφού η ενεργοποίηση του πάλι θα προκαλούσε bank-run και capital controls.
  9. Η συνολική πρόταση του Βαρουφάκη δεν ήταν καθόλου κακή. Απλά η πιθανότητα να συμφωνήσουν με αυτήν οι δανειστές ήταν κοντά στο μηδέν.
  10. Υπήρχε και ένα πλάνο Ζ, αλλά αυτό προέρχονταν από την ΕΚΤ - το πλάνο απόσπασης της Ελλάδας από την Ευρωζώνη με το ελάχιστο κόστος για τις υπόλοιπες χώρες.
  11. Ο Βαρουφάκης, κατά τα λεγόμενά του, είχε σκεφτεί τουλάχιστο 7 φορές να παραιτηθεί με τα αντίστοιχα σημειώματα παραίτησης έτοιμα.
  12. Κατά την διάρκεια των λεγόμενων "πολεμικών συμβουλίων" των κεντρικών στελεχών της Κυβέρνησης που μετείχαν στις διαπραγματεύσεις, από και ένα σημείο και έπειτα δεν είχαν να κάνουν με στρατηγική και τον πραγματικό αντίκτυπο των μέτρων, αλλά με την επιβίωση του ΣΥΡΙΖΑ στις επόμενες εκλογές (σελ 322).
  13. Η στρατηγική του Τσίπρα άλλαζε τόσο συχνά, φανερώνοντας ότι πολύ απλά δεν υπήρχε στρατηγική ή αλλιώς πάμε και βλέπουμε. Την μια στιγμή στέλνει τον Βαρουφάκη πασχαλιάτικα στην Αμερική να ανακοινώσει ότι θα κάνουμε default στο χρέος του IMF, και με το που προσγειώνεται ο Βαρουφάκης του ζητάει να ακυρώσει το πλάνο.
  14. Κατά τον Βαρουφάκη, η πρώτη καλύτερη επιλογή ήταν το βελτιωμένο του πρόγραμμα,  δεύτερη το Grexit, και τρίτη η υπάρχουσα κατάσταση (μνημόνιο 2). Με το τέλος της Βαρουφακιάδας καταλήξαμε στην 4η χειρότερη επιλογή: 3ο Μνημόνιο, χειρότερο από το 2ο.
  15. Πολλές φορές προς το τέλος της διαπραγμάτευσης ο Βαρουφάκης πρότεινε στον Τσίπρα ότι εφόσον δεν ακολουθούν μέχρι τέλους το πλάνο του εκβιασμού και της ρήξης, είναι προτιμότερο να παραιτηθούν σαν κυβέρνηση. Φυσικά και ο μόνος που παραιτήθηκε ήταν ο ίδιος ο Βαρουφάκης.
  16. Όταν έφτασε η ώρα για το κλείσιμο των τραπεζών, ο Βαρουφάκης θέλοντας να αποποιηθεί την ευθύνη της υπογραφής των capital controls πρότεινε την φαεινή ιδέα να αφήσει τις τράπεζες να ανοίξουν και με το επερχόμενο bank-run να μείνουν πολύ γρήγορα χωρίς χρήματα και να αναγκαστούν οι διευθυντές τους να τις κλείσουν, καθώς τα στελέχη της κυβέρνησης θα διαδηλώνουν από έξω από τις τράπεζες για το κλείσιμο των τραπεζών κατηγορώντας την τρόικα! (σελ 449)
  17. Φλαμπουράρης και Τσίπρας είπαν του Λαφαζάνη ότι θα μπορούσαν να χρησιμοποιήσουν τα 16 δις ρευστό της ΤτΕ σε περίπτωση ανάγκης. Ο Βαρουφάκης τους εξήγησε ότι αυτό θα ήταν παράνομο και η μόνη χρήση αυτών των χρημάτων σε περίπτωση Grexit θα ήταν να τα μαρκάρουν/ακυρώσουν και να τα χρησιμοποιήσουν σαν την βάση για το διάδοχο νόμισμα (λόγω απουσίας εναλλακτικού νομίσματος), πληρώνοντας πίσω στην ΕΚΤ την αξία εκτύπωσης τους. Αργότερα κυκλοφόρησε το νέο ότι ο Λαφαζάνης ήταν έτοιμος να μπουκάρει στην Τράπεζα της Ελλάδας, ενώ στην πραγματικότητα ήταν ο Φλαμπουράρης με τον Τσίπρα που το σκεφτόντουσαν (σελ. 456).
  18. Όταν βγήκε το αποτέλεσμα του δημοψηφίσματος ο Τσίπρας είπες στον Βαρουφάκη: "τα θαλασσώσαμε/μπλέξαμε". (σελ 447)
  19. Ο Τσίπρας παραδέχεται ότι δίνει στην τρόικα περισσότερα από τον Σαμαρά και παρόλα αυτά τον κυνηγάνε για να τον ρίξουν από την εξουσία. Αλλά με το αποτέλεσμα του δημοψηφίσματος τώρα δεν μπορούν να τον ακουμπήσουν (σελ. 469).

Συμπέρασμα

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

Το θέμα είναι ότι μία τέτοια κουβέντα απλά δεν μπορεί να γίνει με ανοιχτές τράπεζες. Γιατί μία από τις προφανέστερες συνέπειες του Grexit είναι η αλλαγή και η υποτίμηση του νομίσματος. Οπότε με το που ξεκινά η κουβέντα γίνεται bank-run και οι τράπεζες αδειάζουν από ρευστό. Άρα πρώτα κλείνεις τις τράπεζες, μετά εξηγείς τις επιλογές και τις συνέπειές τους και στο τέλος ζητάς από τον κόσμο με δημοψήφισμα να αποφασίσει τί θέλει.

Στην Ελλάδα το δημοψήφισμα έγινε ακριβώς την λάθος στιγμή, όταν η χώρα ήταν ήδη πεσμένη στο καναβάτσο, τοποθετώντας ένα τελείως άσχετο ερώτημα του στυλ: σας αρέσει το 3ο μνημόνιο ή όχι; Χωρίς καμία συγκεκριμένη απάντηση για το τί συνέπειες έχουν οι δύο επιλογές.

Όπως ομολόγησε και ο Δραγασάκης (σύμφωνα με το βιβλίο) το δημοψήφισμα ήταν ουσιαστικά μία "έξοδος κινδύνου" για την κυβέρνηση. Μία απέλπιδα προσπάθεια για να δικαιολογήσουν την επερχόμενη κωλοτούμπα έχοντας την προσδοκία ότι ο κόσμος θα φοβηθεί και θα ψηφίσει υπέρ του Ναι. Όταν λοιπόν κέρδισε το Όχι με 61% απλά τα έχασαν και έκαναν ακριβώς το αντίθετο από αυτό που ψήφισε ο κόσμος. Υπέγραψαν μία κάκιστη συμφωνία κάτω από τις χειρότερες συνθήκες. Για τον απλό λόγο ότι δεν είχαν καμία νομιμοποίηση από τον κόσμο για ένα άτακτο Grexit.

Μέρες πριν το δημοψήφισμα της 5ης Ιουλίου ο Βαρουφάκης παρουσιάζει στον Τσίπρα την τελική μορφή του πλάνου Χ επιστροφής στην δραχμή (Grexit). Ο Τσίπρας το βλέπει και χλομιάζει. Ρωτάει τον Βαρουφάκη πια είναι η πιθανότητα να πετύχουν μία καλύτερη συμφωνία αν ενεργοποιήσουν το πλάνο για παράλληλο σύστημα πληρωμών. Ο Βαρουφάκης του λέει 100% αν οι Ευρωπαίοι σκεφτούν λογικά - αλλά επειδή δεν ξέρω αν θα σκεφτούν λογικά θα έλεγα 50/50%. Με λίγα λόγια ο Βαρουφάκης ομολογεί ότι δεν έχει ιδέα για το αποτέλεσμα. Ένα νέο Γουδί και/ή πραξικόπημα - ο διαρκής φόβος του Τσίπρα (σελίδα 469) - ίσως να μην ήταν μακρυά. Οπότε ήρθε η συνθηκολόγηση και υπέγραψαν τα πάντα.

Στην πραγματικότητα μάλλον ποτέ δεν πίστεψαν τον Βαρουφάκη, αλλά τον χρησιμοποίησαν για να πουλήσουν το παραμύθι ενός άλλου δρόμου και για να συσπειρώσουν γύρω από τον ΖΥΡΙΖΑ τις δυνάμεις που ήθελαν ένα Grexit. Γιατί ήδη από τον Μάρτιο του '15 τον υπονόμευαν συστηματικά μέσα από το ίδιο το κόμμα, ενώ το ένα και μοναδικό πλάνο που υποτίθεται ότι είχαν (του Βαρουφάκη) ουσιαστικά δεν το εφάρμοσαν.

Προσωπικά πιστεύω ότι η μόνη ρεαλιστική λύση θα ήταν τα capital controls λίγο μετά την ανάληψη της εξουσίας, διαπραγμάτευση με την τρόικα με ταυτόχρονο διάλογο με την κοινωνία για τις συνέπειες του Grexit - και δημοψήφισμα αμέσως μετά. Αυτός θα ήταν ο μόνος τρόπος να μπορέσεις να εκβιάσεις μία καλύτερη συμφωνία με την πλήρη υποστήριξη της κοινωνίας. Αλλά πώς θα μπορούσαν να το κάνουν αυτό την στιγμή που είχαν τάξει λαγούς με πετραχήλια και σκίσιμο μνημονίων χωρίς συνέπειες; Οπότε έπρεπε να σύρουν την χώρα σε μία καταδικασμένη από την αρχή διαπραγμάτευση για να δείξουν ότι κάτι κάνουν.

Έτσι χάσαμε έξι με εννέα μήνες "διαπραγμάτευσης" και άλλα 2-3 χρόνια οικονομικής στασιμότητας, διακόψαμε μία ανάκαμψη που μόλις είχε αρχίσει δειλά να ξεκινά, πήραμε 14 δις μέτρα και χρεωθήκαμε καμιά 40-100 δις παραπάνω (ανάλογα με το πώς τα μετράς) για να μάθουμε τελικά ότι ο γάιδαρος δεν πετάει. Το email Χαρδούβελη με τα μέτρα του ενός δις προφανώς και δεν θα ήταν αρκετό, όμως σε καμία περίπτωση δεν θα ήταν χειρότερο από αυτό που ακολούθησε.

Και γιατί έπρεπε να γίνουν όλα αυτά; Μα φυσικά για την εναλλαγή της εξουσίας, όπως γίνεται πάντα.

Πάθαμε και μάθαμε - ελπίζω.

Monday, November 12, 2018

Jakarta EE action at Devoxx Belgium 2018

Devoxx Belgium 2018, my favorite Java (& more) conference in Europe is just around the corner with the Deep Dive sessions starting tomorrow (Nov/12th-13th), followed by the three main conference days (Nov/14th-16th).

I thought I should write a quick note to point out that there is a lot of Jakarta EE action happening with eight Jakarta EE sessions you can easily query for here, or let me save you a click and paste directly the results below:

JakartaEE - The New Home of Cloud Native Java by Ivar Grimstad, Dimitris Andreadis , Dmitry Kornilov, Gaël Blondelle, Kevin Sutter, Markus Eisele, Ondro Mihályi (Conference)
From Java EE to Jakarta EE by Dmitry Kornilov (Quickie)

The Jakarta EE Community BOF by Dimitris Andreadis, Ivar Grimstad , Dmitry Kornilov, Kevin Sutter (BOF)

Implementing Microservices with Jakarta EE and MicroProfile by Ivar Grimstad, Kevin Sutter (Deep Dive)

Speed Dating with Jakarta EE by Kevin Sutter (Ignite)

Jakarta EE: The Future of Cloud Native Java is Open! by Gaël Blondelle (Conference)

Java EE, Jakarta EE, MicroProfile, Or Maybe All Of Them? by Sebastian Daschner (Conference)

Jakarta EE / MicroProfile + WebStandards, On Stage Hacking #noslides by Adam Bien (Conference)



I am happy to be participating in two of those sessions:
  • The Jakarta EE Community BOF, on Wednesday evening at 20:00. An informal Jakarta EE community gathering of like minded developers, specification leads and Jakarta EE representatives from different companies. Please note that the event will be relocated(!) from the BOF 2 room to Kelly's Irish Pub downtown Antwerp, meaning we are turning the BOF into a mini symposium with free drinks to accompany great discussions! We will be tweeting details for registering for the event, so stay tuned and look for those tweets from @dandreadis, @ivar_grimstad , @m0mus, @kwsutter.
  • JakartaEE - The New Home of Cloud Native Java, on Friday at 11:40, a panel discussion on the present and future of Jakarta EE coordinated by Gaël Blondelle from the Eclipse Foundation, and representatives from Cybercom, Red Hat, Oracle, IBM, Payara & Lightbend.
 There are also other fellow Red Hatter presenting, so check out their sessions or meet us at the Red Hat booth:
The fun is about to start - see you very soon at Devoxx Belgium!


 

Wednesday, September 26, 2018

Colloquium - Making sense of enterprise open source software

The coming Friday, Sep/28th @ 2pm, I have the pleasure to be talking at the Department of Informatics of the University of Fribourg on the subject of: "Making sense of enterprise open source software".

Copying here the Abstract from the event flyer:
Red Hat is a leading enterprise software provider that has built a business model around something that is perceived as "free": open source software. In fact, last year Red Hat managed to sell about $3 billion dollars of "free" software and services to the likes of Fortune 500 companies. How can this be possible? How does an open source business model work in practice? Where does it make sense? Why open source has prevailed in so many different technology domains?

Come to this talk to discover the nuances of enterprise open source software seen from the point of view of JBoss, a popular open source application server project and a start-up company built around it that was acquired by Red Hat back in 2006 to form Red Hat's Middleware division. Also, learn the secrets of how one becomes a successful open source software developer, should you want to get involved with the open source movement, build a career out of it and have a lot of fun on the way.
The event is hosted by Prof. Philippe Cudré-Mauroux, whom I'd like to thank for the invitation. It is also perfectly timed so you can be back in Neuchâtel on time for the start of the Fête des Vendages. :)

See you there!

/Dimitris



Tuesday, September 18, 2018

Java EE CTS goes open source!

Java EE CTS stands for Java EE Compatibility Test Suite. It's the proprietary testsuite developed initially by Sun and later by Oracle that can be used to verify that a Java EE implementation is indeed compatible. Or else, it's a huge testsuite that has been enhanced over the years to ensure compliance with the latest Java EE specifications. It tests both individual APIs, as well as the platform and the provided configuration profiles (Full and Web) as a whole. For Java EE 8 the CTS contains more than 44k tests and that doesn't include some individual Test Compatibility Kits (TCKs) for a couple of specifications that were open source from the start, like CDI and Bean Validation.

Up until now getting access to the CTS involved negotiating a license with Sun/Oracle. I remember the early JBoss days and how we were (I believe) the first open source Java EE implementation that got access to the CTS in exchange of a seven figure dollar amount, which was a lot of money back then and it only became possible because JBoss had just received funding from a Venture Capital. As an open source project and without proper funding we wouldn't have any chance of getting to it.

But that was the past. As of Sep 14, 2018 you may just as well access the CTS here:

https://github.com/eclipse-ee4j/jakartaee-tck

The Java EE CTS is on it's way to be transformed into the Jakarta EE 8 CTS. The initial code drop has been done and there is some IP checking to be completed while some further massaging of the code is necessary before it can be called Jakarta EE 8 CTS. But we are not far from that milestone and that would get us a step closer into the re-incarnation of Java EE as Jakarta EE. (BTW, you can check the overall project status here).

The CTS holds a special place in my heart because that was the first (surprise!) project I was asked to work on when I was hired by JBoss back in 2004. I was a volunteer committer on JBoss when I've got the call by Mark Fleury to join the company. (For more details, check out this blog entry.) I was told I would work on "Core Development" but no one told me on what exactly. As soon as I started, Sacha Labourey (now CEO at CloudBees) broke the news to me: my first major assignment would be to help complete J2EE 1.4 certification for JBoss 4.0.

The core development team had already managed to bring the TCK up to around 80% pass rate but, as with most things, the hardest parts were left for the end. Interoperability testing was one of the toughest areas of the testsuite that involved calls between JBoss and the Reference Implementation (RI). Different types of EJBs deployed on both servers were calling each other and transaction and security context had to propagate from server to server over RMI/IIOP - which really meant CORBA underneath.

JBoss had an amazing implementation of RMI/IIOP put in place by a bunch of developers with Francisco Reverbel as component lead and committer on the JacORB project. There was even a published paper that explained the technological innovations entitled: "Dynamic Deployment of IIOP-Enabled Components in the JBoss Server". In short, while every other application server out there required you to pre-compile the RMI/IIOP Stubs, JBoss could generate them on the fly upon deployment. Not only that, but the dynamic stubs could be transported over the wire to clients accessing the server. On the flip side, the implementation was quite complex because there was a lot of classloader magic involved to pull this off.

At that point I've realized that one of the reasons I was hired was that I was the resident CORBA expert in my previous company. Which came really handy after I've found out that the interop testsuites were failing not due to some nasty bug, but simply because a whole lot of functionality was  missing  - the dreaded CSIv2 support. (Common Secure Interoperability Protocol Version 2 - a protocol implementing security features for inter-ORB communication.)

Which meant that I've had to go and read the OMG specifications and implement the missing protocols from scratch, but also spend an enormous amount of time analyzing and debugging the low level message exchanges between the different servers. Apparently not everything was described sufficiently by the spec, you've had to figure out how the different implementations actually behaved. And that was before the RI was opensourced, so I didn't even have access to the code I was testing with.

The CTS itself seemed like a monster. It was the largest testsuite I've ever worked with, consisting of something like twenty to thirty thousands tests. Not only it was challenging to setup and implement the necessary test drivers to link your implementation to the testsuite harness, but running the tests themselves took a lot of time, in the order of hours for the different parts of the testsuite and days if you wanted to run everything. We did have periodic CI-like testing for the main JBoss testsuite back then but not for the TCK.  We run the TCK on our local machines.

To make it even worse, interoperability testing was the most resource hungry part of the testsuite. A Swing GUI (jvm1) was invoking a test client (jvm2) that was accessing the JBoss server (jvm3) that was calling the Reference Implementation (jvm4) or the reverse, with both of the servers using a back end database (jvm5) to store data. Those JVMs plus your IDE of choice to step through the code could easily bring a beefed up laptop down to its knees.

Passing the TCK became pretty much an obsession. I didn't have holidays that magical summer of 2004 in which Greece won the Euro, Athens was hosting the Summer Olympic Games and I've had to earn my stripes as a Core Developer working around the clock on the coolest company on the planet next to some legendary JBoss Developers of the likes of Adrian Brock, Scott Stark, Bill Burke, Thomas Diesler and others.

As it came to be, passing the interop CSIv2 tests was the last remaining piece of the puzzle that sealed our J2EE 1.4 certification and lead to the release of JBoss 4.0 on Sep 20th, 2004, exactly 14 years ago. You can still read in the relevant What's New in JBoss 4 release notes the announcement of JBoss 4 as the industry's first officially certified J2EE 1.4 application server.

Passing the CTS was a huge boost for JBoss. It meant that we could really be in the same league with the big guys and we could start chasing competitive migrations from the other eighteen J2EE 1.4 compliant implementations. That was the power of standards in general and Java EE in particular, offering choice to the developer and this is still the reason why standards are important: so that portability is possible in this brave new Cloud Native era.

An open CTS/TCK levels the playing field, reduces the barrier to entry and allows new implementation to compete on features. It also facilitates collaboration between creators and implementers of new APIs and the broader community. It took some time for Oracle to let Java EE free but they finally did it and they should be applauded for this. It is now up to all of us to make Jakarta EE a success.




Wednesday, September 05, 2018

Let's meet at the Red Hat Forum 2018 in Zurich!

September 11th is a difficult date to forget, however, this time for a good reason: it's the day the Red Hat Forum 2018 will take place at the Arena Cinemas in Zurich. For those that have attended the RH Forum in previous years you already know it's the place to be and it's just getting better every year. For those that haven't been there, I suggest you take a look at the Agenda.

It's a full day event with keynotes and panel sessions happening before lunch. This year we are lucky to have Jim Whitehurst, Red Hat's President & CEO keynoting on Digital Transformation and how Red Hat's open culture can help you perform this journey. There are other very interesting sessions (many in English!) with leading customers and partners sharing their experiences, including Swisscom, Accenture, SBB, SAP and Microsoft (with whom we are best friends now!), as well as Kiki wearing something red and helping our Country Manager Léonard Bodmer run the show. :)

In the afternoon we split into four parallel tracks with case studies and technical presentations taking place in the cinema rooms. There are very interesting topics presented from customers and partners and I suggest you first take a look at them, but if you are more into tech stuff you may just as well join as at the Red Hat Technology Deep Dive Track that--with the help of Thomas Heute--we've organized this year, as follow:

  1.  Pavol Loffay, speaking on very practical aspects of "Observability with Istio Mess".

    In this presentation we will walk you through telemetry integration in Istio service mesh. You will learn how observability pillars like metrics and traces are nicely provided by the mesh and in addition to that how services themselves can enrich this information. We will be demoing Kiali, Prometheus and Jaeger on an OpenShift environment.
  2.  Yours Truly, on the future of Enterprise Java - "Java EE is Dead! Long Live Jakarta EE!"

    Last's year events were cataclysmic for Enterprise Java: Java EE 8 was released, the MicroProfile project produced 2 releases and 7 new microservices focused APIs, and both of them moved over to the Eclipse Foundation with Oracle choosing to open source everything! What has happened? Jakarta EE, the successor to Java EE, is alive and kicking and aims at aligning Enterprise Java to the fast pacing reality of a brave new Cloud Native world. Why this is important to you and what you can do about it? Come to this session to find out.
  3. Michael Vorburger & Erik Jan de Wit on a super fun joint presentation showcasing a way of "Teaching Programming using Minecraft on OpenShift".

    Computers used to be these "magical tinkering machines" when we were younger. Today, the challenge is to get children excited about learning programming by reducing the time to set up and get started right away in a gamified environment they already love - like Minecraft! We'll show you how with Kubernetes, OpenShift and Minecraft we can progressively do just - at first using our ScratchX extension to get started with graphical programming, and then with a push of a button go to a full development environment set up to start learning and teaching programming. We'll set up an Eclipse Che IDE with continuous builds of the modifications, and a Minecraft server with our OSGi extension that hot reload changes. All code used in the demo of this project is open source and available to anyone.
All fours presenters are based out of Switzerland, are deeply involved with Red Hat product development and would gladly meet with you (and the Geek inside you) at the technical track or the Red Hat booth, to talk about the projects/products we are working on and just about anything Open Source. We would also be very interested to listen to your concerns and experiences with them, as well as hear about any interesting projects you are working on.

We are just one week before the event so if you haven't already registered to attend the Red Hat Forum (which I should mention is free, as in beer, thanks to our beloved Partners), I suggest you do so ASAP and register now - there might still be some available slots, so hurry up!

See you in Zurich!

/Dimitris

Sunday, November 05, 2017

Conference action - from Soft-Shake in Geneva to Devoxx in Antwerp

Fall is a busy conference period and parallel to our team's ambitious WildFly and JBoss EAP release goals I always try to squeeze in a few days into my schedule for opensource advocation and meeting with our communities.

So the week before I've had the pleasure of presenting on WildFly Swarm at Soft-Shake'17 in Geneva. It's a short 1.5h ride with the train from Neuchâtel so it feels pretty much local: you can get there, present and be back for dinner. And it's also very much francophone, although, they do accept talks in English.

If you don't know about WildFly Swarm, our sister project to WildFly, I suggest you check it out. Especially if you come from the Java EE direction, WildFly Swarm facilitates the transition to developing Microservices and Cloud Native applications. It also implements the Eclipse Microprofile specification.

The latest published spec for Microprofile is version 1.2 and you can get a very nice introduction about what it includes here.  If you want to try out Microprofile v1.2 on Wildfly Swarm check out this Tech Preview.

Now within less than 12 hours I should be on my way to the annual Devoxx.be pilgrimage.

  • If you are around on Monday evening, come over to the WildFly Community BOF at 20:30. It's been an exciting year for Java EE, with the release of Java EE 8 and the announcement of the move of Java EE to the Eclipse foundation under the Eclipse Enterprise for Java project (EE4J). Coupled with the fast paced Microprofile releases and the Microprofile effort also moving to Eclipse, and we have a very different landscape carved up for Java EE going forward. So do come to this BOF to discuss the latest developments and how they are affecting the WildFly community projects. I will be co-hosting this with Edson Yanaga, Director of Developer Experience at Red Hat who also has a deep-dive session in the morning.
  • Then on Thursday evening I am participating at the Opening Up of Java EE panel discussion (room 6, 17:50) hosted by David Delabassee alongside distinguished members of the Java EE community, Mike Croft, Ivar Grimstad, Martijn Verburg and Steve Poole. If you are interested in the future of Java EE and it's re-incarnation as a completely open Eclipse project, this is the place to be.
See you all very soon at Devoxx in Antwerp!

/Dimitris