Getting Quarked

Quarkus has made its debut just two and half months ago on March 7th, 2019 with the release of version 0.11 and this public announcement, and since then it has made a lot of buzz in the Java universe while attracting significant developer interest. This is still early days so most people are mostly in the experimental stage getting their feet wet and having a first taste of what it means to write Supersonic Subatomic Java apps. (And just in case you haven't heard of Quarkus check out this introductory video.)

By some twist of luck the first public release of Quarkus came right out of the Red Hat Neuchâtel Office in Switzerland, the original JBoss HQ for Europe, where a large part of the very much distributed Quarkus engineering team was having a meeting that concluded with a release hackathon.

History in the making - Quarkus about to be released to the public

Of course, Quarkus was not born there. For years various people and teams at Red Hat including the WildFly/EAP team with Galleon, as well as the sister WildFly-Swarm/Thorntailv4 projects, the Drools team with Submarine, the OpenJDK team and others, were experimenting with evolutionary approaches for reducing the runtime overhead of Java applications to make them more space and time efficient for cloud native deployments.

However, at some point it became evident that evolutionary approaches wouldn't cut it for the order-of-magnitude scale improvements we were targeting so three of our most prominent architects, (alphabetically) Bob McWhirter, Emmanuel Bernard and Jason Greene came together and with our CTO's blessings started a Proof-of-Concept (initially stealth) effort that would attempt to unify the various research projects into one looking into revolutionary approaches for developing that one single Runtime to rule them all.

An interdisciplinary team of engineers (non exaustive list) was gradually formed with each one bringing along with them a ton of ideas and experience from different areas of the Middleware/Enterprise Java spectrum, from kernel design and JVM internals to networking, security and persistence, integration frameworks and performance optimizations (and more). Within 3-4 months the team put in place the base architectural elements and design abstractions and delivered a prototype that satisfied the original goals but also went way beyond. It produced  innovations that will be studied and copied over for years to come and provided justification for the project to continue, eventually leading to its public announcement.

The cool thing about Quarkus is that it works equally well in standard JVM and native compiled mode. By essentially pre-computing application and framework initialization and eliminating dead code (and performing many other optimizations) it can greatly reduce boot time, artifact size and runtime memory requirements (RSS space).

In one sense things are moving to the opposite direction from the days of early JBoss. Back them we've disrupted the application server space by moving compile time operations into deployment time. With dynamic proxies, a plugable microkernel architecture and an aspect oriented/interceptor design we could avoid precompilation steps and do things you now take for granted like hot-deployment and instant-clustering. Even the collapse of the Web and EJB layers within the same JVM was a selling point. Now we go for extreme distribution with all the benefits and challenges that come with it.

A very rough rule of thumb is that by using Quarkus in standard JVM mode you can expect your app to boot in a fifth of the time compared to most other popular runtimes and consume about half the memory. In native mode things go crazy: expect one to two orders of magnitude of reduced boot time (supersonic, in the order of tens of milliseconds) and about a fifth to a third of runtime memory consumption (subatomic).

It's funny to see people trying out Quarkus and reporting an impressive 1.65 seconds boot time for an app that would take 56 seconds to boot on Google Cloud and then the Quarkus team reacts because that looks "slow" and with DNS issues resolved the boot time should be closer to 0,015 seconds! To say it differently, beyond an awesome enabler for writing microservices, Java can now be used as a launching platform for serverless apps and cloud functions. Which in turn means that the millions of Java programmers in the world can keep using their favorite programming language, frameworks and APIs and carry forward their know-how in this brave new cloud native world, while companies can maintain their multi-year investments in Java. This is a game changer, IMO.

However, to reap the full benefits of Quarkus, frameworks needs to be enabled for it, they need to be Quarked. The team has written extensions for popular frameworks/libraries (listed here) that help provide Quarkus' opinionated programming model but our expectation is that the community will step up and provide their own extensions for popular frameworks in order to enhance the Quarkus ecosystem. With enough Quarkus extensions in place the benefits of Ahead of Time Compilation (AOT) will be offered to a larger percentage of the Java Developer base in a way that makes the production of native binaries almost transparent to the end user.

Quarkus offers a lot more than a Supersonic speed, a Subatomic footprint and a set of best of breed technologies and standards. It provides both an imperative and a reactive programming model and most importantly it brings back developer joy in the life of the programmer. I've been in a couple of Quarkus presentations already and the moment we show how a code change in the IDE is immediately picked up by Quarkus in developer mode the next time the web browser gets refreshed with the change recompiled and the whole app redeployed *instantly*, that moment, the people's reaction is simply priceless. Back in the JBoss days our motto was to"put back the developer into the driver's seat". Same thing now with Quarkus.

I hope that helps explains a bit some of the excitement behind Quarkus inside and outside Red Hat, and my own personal excitement, too, especially from the moment I was offered the opportunity to come and help run the extended Quarkus team as its Engineering Manager. I am humbled by the sheer amount of brain power behind the project, although, coming from the WildFly/EAP team this is not something new to me. I've seen a few times in my career the type of magic that can happen when you put exceptional people working together on a common stretched goal.

Being a JBoss alumni and having worked on all transformations that the JBoss Application Server project underwent since version 2.x, I've delivered my last JBoss EAP 7.2 release as Engineering Manager while I was transitioning to Quarkus and handed over the product to Tom Jenkinson with whom I've I've worked in the EAP team for many years. Tom was Engineering Manager & Project Lead of the Nayarana Transactions Engine that powers all of JBoss Middleware, a project even older than JBoss AS.

Tom in turn is supported by Brian Stansberry in the role of WildFly project lead, as well as a great team of JBoss/WildFly veterans, so I'm confident that EAP is in the best hands possible to continue evolving and thriving, tracking the latest developments in the Jakarta EE / Microprofile space.

This is all for now - stay tuned on Quarkus - and join the revolution.

/Dimitris

Ομιλία για Επιχειρηματικό Λογισμικό Ανοιχτού Κώδικα

Με την ευκαιρία μίας γρήγορης επίσκεψης στην Αθήνα, θα μιλήσω την Παρασκευή 1η Μαρτίου για την σημασία του ανοιχτού λογισμικού και τις τελευταίες τεχνολογικές εξελίξεις, πώς η Red Hat καταφέρνει να πουλάει $3δις+ το χρόνο υπηρεσίες γύρω από κάτι που θεωρείται δωρεάν, πώς στήθηκε ένα start-up γύρω από τον JBoss, και γιατί η IBM προτίθεται να πληρώσει $33δις για κάτι που θα μπορούσε να θεωρηθεί σαν αέρας κοπανιστός.

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

Αυτά και άλλα ωραία στις 3-5μμ στο Κέντρο Στήριξης Επιχειρηματικότητας και Καινοτομίας (Κεφαλληνίας 46, 2ος όροφος), με την υποστήριξη καλών φίλων και του Οικονομικού Πανεπιστημίου Αθηνών σε συνεργασία με τον Οργανισμό Ανοιχτών Τεχνολογιών - ΕΕΛΛΑΚ.

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

Για περισσότερες πληροφορίες, δείτε τις αντίστοιχες ανακοινώσεις από:

• Κέντρο υποστήριξης επιχειρηματικότητας και καινοτομίας  / ΟΠΑ
• OpenBusinessEllak.gr

 /Δημήτρης
 

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 :-)

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

Με πολύ ενδιαφέρον και καθυστέρηση έξι μηνών από τον Μάιο του 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 Χαρδούβελη με τα μέτρα του ενός δις προφανώς και δεν θα ήταν αρκετό, όμως σε καμία περίπτωση δεν θα ήταν χειρότερο από αυτό που ακολούθησε.

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

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

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:

• Alex Soto, Writers-Write! The documentation BOF
• Antoine Sabot-Durand, Microprofile, Past, Present & Future BOF
• Burr Sutter, 9 Steps to Awesome with Kubernetes & Kubernetes: your next Java Application Server
• Emmanuel Bernard, Data in a Microservices World, from Conundrum to Options, & Les Cast Codeurs Podcast
• Geoffrey De Smet, The Battle of 2 automated conference talk scheduling algorithm for Devoxx
• Madou Coulibaly, Data in a Microservices World, from Conundrum to Options
• Mario Fusco, OOP vs FP 

The fun is about to start - see you very soon at Devoxx Belgium!

/Dimitris

 

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

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.

/Dimitris