Jekyll2022-09-07T11:11:37+00:00https://www.jhug.gr/feed.xmlJHUGJava Hellenic User GroupVoxxed Athens 20222022-09-07T10:00:00+00:002022-09-07T10:00:00+00:00https://www.jhug.gr/voxxed-athens-2022<p>Έχουμε μιλήσει αρκετές φορές στα meetups για τη σημασία που έχουν τα συνέδρια στο για εμάς τους developers. Στα συνέδρια μπορούμε να ακούσουμε για καινούριες τεχνολογίες από ανθρώπους που τις έχουν χρησιμοποιήσει στην πρώτη γραμμή. Μπορούμε να μάθουμε πώς άλλοι λύνουν προβλήματα που αντιμετωπίζουμε και εμείς με διαφορετικούς τρόπους. Μπορούμε να κάνουμε hands-on workshops και training sessions. Τέλος, μπορούμε να βρεθουμε εκ του σύνεγγυς με συναδέλφους και να τα πούμε.</p>
<p>Αυτή η ίσως αυτονόητη εισαγωγή έγινε επειδή έπειτα από τα πανδημικά χρόνια, το <a href="https://voxxeddays.com/athens/">Voxxed Athens</a> θα γίνει και πάλι στην Αθήνα από 30 Σεπτεμβρίου εως 1 Οκτωβρίου.</p>
<p>Ας μην παρεξηγηθεί το post αυτό σαν διαφημιστικό. Το Voxxed Athens και Voxxed Thess είναι παλιοί φίλοι του JHUG, και έχουμε τη χαρά που έχει κάποιος όταν ένας φίλος επιστρέφει. Το Voxxed Athens και ο <a href="https://gr.linkedin.com/in/ppapapetrou">Πάτροκλος Παπαπέτρου</a> έχουν συνεισφέρει με διάφορους τρόπους στο JHUG στο παρελθόν. Συγκεκριμένα, έχουν συνεισφέρει recording equipment και εισιτήρια για παλαιότερα συνέδρια.</p>
<p>Συνεχίζοντας αυτή την ωραία παράδοση, το Voxxed Athens προσφέρει και φέτος 2 εισιτήρια για το συνέδριο, τα οποία θα κληρωθούν στο <a href="https://jhug.slack.com/">slack</a> channel του JHUG. Για να πάρετε μέρος στην κλήρωση πρέπει να γίνετε μέλη του slack channel. Όποιος δεν έχει πρόσβαση ας ζητήσει invitation από κάποιο υπάρχον μέλος ή ας <a href="https://www.jhug.gr/about/">επικοινωνήσει</a> μαζί μας.</p>
<p>Ευχαριστούμε λοιπόν για την προσφορά, και θα τα πούμε στις 30 Σεπτεμβρίου.</p>Markos FragkakisΈχουμε μιλήσει αρκετές φορές στα meetups για τη σημασία που έχουν τα συνέδρια στο για εμάς τους developers. Στα συνέδρια μπορούμε να ακούσουμε για καινούριες τεχνολογίες από ανθρώπους που τις έχουν χρησιμοποιήσει στην πρώτη γραμμή. Μπορούμε να μάθουμε πώς άλλοι λύνουν προβλήματα που αντιμετωπίζουμε και εμείς με διαφορετικούς τρόπους. Μπορούμε να κάνουμε hands-on workshops και training sessions. Τέλος, μπορούμε να βρεθουμε εκ του σύνεγγυς με συναδέλφους και να τα πούμε.Java 17 Innovations Developer Live2021-09-19T07:00:00+00:002021-09-19T07:00:00+00:00https://www.jhug.gr/Java-17-Innovations-Developer-Live<blockquote>
<p>A post by JHUG member <a href="https://www.linkedin.com/in/ioannakatsanou/">Ioanna Katsanou</a> who attended the Java Innovations event for the release of Java 17 and sent us her impressions. Enjoy!</p>
</blockquote>
<p>I attended recently, on September 16th, the Java Innovations all day event concerning Oracle’s new java 17 version and would like to share my experience about it.</p>
<p>In the beginning a welcome panel featured a brief introduction to the new JDK, and presented a small preview to their plans for the future.
There was also an entertaining poll featuring questions about Duke -the famous Java mascot- and who is the Java Architect. (FYI Duke was created by Joe Palrang and Mark Reinhold is the Java Architect)</p>
<p>The most interesting ongoing projects that caught my attention were:</p>
<ul>
<li>Project Panama: A project for improving and enriching the connections between the Java non-Java APIs, (for example C language interfaces).</li>
<li>Project Amber: This project aims to enhance the Java SDK with new features and improve the Java programming language.</li>
<li>Project Lanai: A new Java2D graphics pipeline for macOS.</li>
</ul>
<p>The JMS (Java Management Service) - not to be confused with Java Messaging Service with the same acronyms, was also highlighted. This is a new Oracle Cloud Infrastructure Service that aims to help manage all Java applications deployed on the cloud. It is included with Java SE Subscriptions and Java SE Desktop Subscription and is free in the OCI (it does not include cost of monitoring data).
After these two sessions, I was really excited about the next session with Mala Gupta, since she is one of my favorite developers, as well as a Java Champion!</p>
<p>The session was very pleasant with a lot of fun surprises. She presented the new pattern matching for switch (this is still a preview feature of the Java language but it is going to be included in the official version soon). She also made apt code comparisons with real life scenarios. It is not surprising that her nickname is “Switchy Gupta”.</p>
<h2 id="hands-on-labs">Hands-On Labs</h2>
<p>Next in row, were the two hands-on labs.</p>
<p>The first lab was presented by David Delabassée. The goal of the lab was to explore all the new Java SDK 17 features on the Cloud. Basically you have to set up your OCI Account and environment first. Then by connecting through SSH to the cloud instance, the lab provides an initial introduction to Helidon and a beginner exposure to open-source Java-based collection of libraries that one can use to develop lightweight Microservices.
Next we downloaded a ready project from Github and experimented through some key Java 17 features such as sealed classes, records, pattern matching etc.!
I also had to write Java code in the command line using Vim or Nano for the lab purposes and as I am used to using an IDE, this alone was quite a challenge for me! I really found this lab interesting
In case anyone wants to get their hands dirty, the link for the lab is:
<a href="https://delabassee.com/odl2021-lab/">David Delabassée Lab</a>
It will be available for the next 1-2 months at least, so hurry up!</p>
<p>Lastly, the second lab, “Practical Cloud Native Skills for Java Developer” was presented by Joe Greenwald, OCI Learning Solutions Architect and Vasily Strelnikov, Senior Principal OCI Solution Specialist. The purpose of this lab was to build an app, deploy it and run it in Kubernetes.
Unfortunately I was not able to finish this one, as the time was up, but will do in the next days.
You can find instructions to this lab as well as source code in this link:
<a href="https://github.com/oustudent1/practicalcloudnativejavadev">Practical Cloud Native Skills for Java Developer</a></p>
<h2 id="other-useful-links">Other Useful Links</h2>
<ul>
<li>You can find more information about the event as well as a video in the following link:
https://developer.oracle.com/developer-live/</li>
<li>https://dev.java/ has replaced the java.sun.com</li>
<li>https://inside.java/ includes (aggregator of content developed by the java platform group)
Inside Java Newscast: Time relevant stories about new features, progress of projects
Sip of Java: Java series of one minute video shorts covering tricks and tips for better development
Inside Java podcast: Audio series with interviews of the makers of Java
Jeff café: monthly serving of Java deep diving of one particular JDK Enhancement proposal</li>
<li>https://blog.jetbrains.com/ Jetbrain’s Blog</li>
<li>https://delabassee.com/ David Delabassée’s blog</li>
</ul>Ioanna KatsanouA post by JHUG member Ioanna Katsanou who attended the Java Innovations event for the release of Java 17 and sent us her impressions. Enjoy!JHUG 22-Apr-2021 discussion on code reviews2021-05-05T12:00:00+00:002021-05-05T12:00:00+00:00https://www.jhug.gr/jhug-code-reviews<p>In our previous <a href="https://www.jhug.gr/jhug-meetup-april-22th-2021/">meetup</a> we had an open discussion about code reviews. The goal was not to mention patterns, anti-patterns or guidelines but rather to discuss the everyday life of reviewing and how engineers of all levels see the process from both sides, as authors and as reviewers. It was a very interesting session and a lot of opinions were heard. This post is a summary of that discussion.</p>
<h2 id="code-reviews">Code reviews</h2>
<p>You know the drill: An author makes some changes and then submits a PR. One or more reviewers will read it and eventually one or more will give a +1 to the PR and the author will merge it in the main code base. This process can take from a simple <a href="https://github.com/songjiayang/review-abbreviation">LGTM</a> within an hour, to days arguing around proper grammar rules of comments. Why is there such variance?</p>
<p>It is important to state explicitly what a code review is. Wikipedia defines code review as</p>
<blockquote>
<p>a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.</p>
</blockquote>
<p>Let’s explain it starting from the end.</p>
<p><em>“After implementation”</em> means that the code achieves its purpose, is debugged, the tests pass and the CI/CD bots (linters, formatters etc) are happy. The author should be confident that his work is complete and can be merged without problems. The reviewer should start by assuming that everything is OK. A PR is not the place to discuss design alternatives or debug code or propose UX approaches. All these should be handled in the corresponding parts of the software process. If a bug is found, or if the performance is not acceptable or something like this happens, the reviewer will report it. But if this happens frequently then there is something wrong with the process and must be fixed. Do not ruin the review process by moving other parts of the software process in it.</p>
<p><em>“check a program mainly by viewing and reading”</em> means exactly this. The reviewer will only read the code and infer an opinion. He is not obliged to debug it, test it, lint it or try it. He must only decide if the code passes the accepted guidelines for code quality and if the assumptions of the code about a business domain are correct.</p>
<p>It is important to note the significance of review guidelines and project documentation. If there are no guidelines then every personal statement and opinion becomes a de facto standard and code quality varies depending on the reviewer. In some organizations, there are no guidelines but the opinions of the first employees are hard wired in the code and are referred as <em>“this is how we do things here”</em>. This of course hurts progress since new ideas cannot find their way. It is very important for an organization to have clear, written guidelines for code reviews otherwise the process loses much of its value. The other important note is about documentation. An author new to a code part, does not have documents to read, makes assumptions and these prove wrong when a more experienced coworker makes a code review. If this happens the author returns back to the whiteboard and significant time is lost. Again the code review is not the place for this. Documentation must be updated. It is a mistake to assume that these errors will be caught during PRs. Things change, people come and go and eventually the domain knowledge is lost.</p>
<h2 id="organization-culture">Organization culture</h2>
<p>Everybody agrees that the reviewing process reflects the culture of an organization. If there are problems here, for sure, they will be reflected in code reviews.</p>
<p>Consider a company with a culture that advocates fast releases of new features and does not promote code quality. In this environment reviews are easy. Everybody gets a +1 just minutes after the submission of the PR and are happy until the day they face the giant technical debt that was accumulated. Now, assume that this company has some engineers that want to do decent code reviews and are not eager to give +1 easily. Because of the culture, the others will avoid them as reviewers and prefer colleagues that give +1 easily. In most cases the culture of the company will prevail and they won’t be able to change something.</p>
<p>Now let’s see a company with another type of toxic culture, this time extreme competition. Everybody wants to prove that he is the best and second to none. Sometimes they even fear for their positions. In this case reviews become hell. Nobody leaves even a single line without a comment and does not approve anything until the author conforms with everything. A PR can have multiple passes and the final approved version is in essence a rewrite according to the reviewer’s opinions. In this case we have also seen notorious comment exchanges between different reviewers until eventually one steps back and let the other dominate the review.</p>
<h2 id="organization-structure">Organization structure</h2>
<p>The structure of an organization also has a direct impact on the review process.</p>
<p>The first example is the almost flat organization. This is the usual case of OSS projects. There is a small team of maintainers that handle all the reviews. Some projects do hard reviews and some others not. In this case the dominating factor is the author type. If he is an occasional committer then an exhaustive review is frustrating for him but necessary on behalf of the project. On the other hand, if the author really wants to engage the project and do open source work, he must do most of the dirty job, learn the guidelines of the community and have patience. After an initial period of <em>“hard”</em> reviews everything becomes easier. Note that in flat organizations everybody can hack any part of the product and thus reviews have variable difficulty degrees. It is not the same to fix typos in the documentation and to fix the performance of an application.</p>
<p>Another example is the usual tree structured organization where everyone has colleagues and supervisors.The personnel is divided into teams and each team has ownership of a part of the product. In this case most PRs are reviewed by the team leader and maybe by another team member. It is the team leader’s duty to guarantee (and/or enforce) code quality and make sure that all team members understand the guidelines of the team. In this case the review process is a one man game and reflects the personality and abilities of the leader. Sometimes he has a lot of work and reviews may be late. Or there are some pending issues that make your review late or not that important. Or he may have some bad days in work (he also has supervisors). Sometimes a TL is new in a team and does not yet have knowledge of the team and the domain. What is important here is that the team is small and works on the same areas. Eventually, and only if the culture of the company is not toxic, they will find a way to cooperate smoothly and efficiently.</p>
<h2 id="mentoring">Mentoring</h2>
<p>Now, let’s discuss another important aspect of code reviews, the skills gap between an author and a reviewer. There are two cases.</p>
<p>The first and most common, is when the reviewer is more skilled than the author either because in general he is a better engineer or he is more experienced with the code base. The worst thing a reviewer can do is to emphasize his authority and intimidate the author. The keyword is mentoring. The reviewer must be willing to help the author narrow the skills gap by providing valuable help. An organization should hire persons with such mentality, this qualification is a matter of character and cannot be learned. Of course you cannot expect everyone to have it. There are some great engineers that lack this soft skill but this must be the exception and not the norm.</p>
<p>The second case of the gap is when the author is more skilled. This is done to give the reviewer a chance to see some expert code in an area he is not well acquainted with. This gives him the opportunity to study the area, the code, the techniques and learn. Moreover he learns a lot about the review process and the internal guidelines since he addresses a more skilled individual and thus he must behave accordingly. The keyword is again mentoring, this time on behalf of the author. This second case has an interesting variation. Senior engineers have a tendency to dive in complexity, many times unnecessarily. The best way to address this is to have their work reviewed by a lesser expert. A single comment like <em>“I cannot understand this, too complex”</em> or <em>“why not simplify like this”</em> is very valuable as it acts as an alarm to them that they have gone too far.</p>
<h2 id="mentality">Mentality</h2>
<p>We discuss last but not least the mentality that should govern authors and reviewers.</p>
<p>The code review is a software quality assurance tool. It is a highly subjective procedure that involves people exchanging opinions on a topic. As such it can go astray easily.</p>
<p>First of all it needs respect for the work under review. The author worked many hours on it, is pleased with the result and looks forward to merge it in the code base. As a reviewer you don’t have the right to underestimate this effort and as an author you should not present to the reviewer duct tape patches or work in progress. And remember that giving praise to good work has great value for all.</p>
<p>Then comes willingness to learn and willingness to teach. During a good review you learn a lot about API and data design, good coding practices and the domain. There will be always both better and worse engineers than you. If this does not happen then you are not evolving. You must be eager to learn from good advice and you must be ready to consult anybody who asks.</p>
<p>Finally there is the improvement culture. We do reviews to improve both as individuals and as organizations. It is of no value to exchange compliments and bypass code sins. If we are not improving then we are doing something wrong. Sometimes we must <em>“break some eggs”</em> and do some hard code reviews, by pointing bad points with a vigor and by accepting well behaved critique.</p>
<h2 id="practical-considerations">Practical considerations</h2>
<p>In the discussion we also identified some practical issues that occur frequently in the PRs. We mention them in bullets because most of them are discussed in depth in many good books and posts about code reviews.</p>
<ul>
<li>PRs must be fast. Having a PR open for many days and moving back and forth between the PR and other tasks means a lot of daily context switches and practical problems during the final merge as the fork may have been outdated.</li>
<li>Reviewers should review tests with the same care as the code. Many times a PR focuses on the code while the tests are inadequate and this stays unnoticed.</li>
<li>Focus on the essence of the PR. It is very easy to get distracted on low hanging fruits like style, comments, certain patterns etc</li>
<li>Personal opinions are not guidelines for all and an author can ignore them.</li>
<li>Multi pass PRs are very annoying. Try to make all your comments in one pass and accept when the author makes the fixes.</li>
<li>Reviews and tests go hand to hand. You should not exaggerate on reviews to hide the lack of tests and vice versa.</li>
<li>People who cause problems during reviews for sure will cause problems and in other areas. The inverse also holds. Problematic characters won’t wait for reviews to show up.</li>
</ul>
<h2 id="conclusions">Conclusions</h2>
<p>We can say that reviews are not perfect but currently it is one of the best tools in our disposal to guarantee software quality. It requires a proper mentality from all to get the best results. Remember that it involves people discussing opinions and in modern civilization there is no single domain in which people discuss and the process is useful, straightforward and smooth. Just look at forums, social media, not to mention TV panels or even the parliaments of the countries. So until AI evolves to the point where we can assign a code review to <code class="language-plaintext highlighter-rouge">codeJudge 42</code> all we should do is read each other’s code with respect and empathy.</p>Spiros AnastasopoulosIn our previous meetup we had an open discussion about code reviews. The goal was not to mention patterns, anti-patterns or guidelines but rather to discuss the everyday life of reviewing and how engineers of all levels see the process from both sides, as authors and as reviewers. It was a very interesting session and a lot of opinions were heard. This post is a summary of that discussion.JHUG 22-Apr-2021 virtual meetup2021-04-24T15:00:00+00:002021-04-24T15:00:00+00:00https://www.jhug.gr/jhug-meetup-april-22th-2021<p>This Thursday, we had another JHUG virtual meetup. It was the fifth we had during the lockdown and we are very confortable with the format, but we hope to meet and talk face to face very soon. This time around 60 members participated and watched the sessions. As always it was held on google meetup and the details and the link were published on our <a href="https://jhug.slack.com">slack channel</a>.</p>
<p>Now, lets go to the three sessions.</p>
<h2 id="an-unconventional-path-to-innovation">An unconventional path to innovation</h2>
<p>The first talk was by <a href="https://www.linkedin.com/in/makrynikolas/">Babis Makrynikolas</a> and was about some aspects of the evolution of Amazon from a startup to an internet giant. Babis worked on AWS for some years and has an inside view. The story is well known. Amazon started as an online bookshop and evolved into the biggest online marketplace and one of the biggest cloud providers. Alas, such impressive growth comes at a cost: more people, more teams, more complexity (both business and infrastructure), more coordination, all these cause slowdown. In the Amazon case, the challenge was not only to cope with the complexity but also to use the solutions both as a driving force for innovation and as products for sale. From there started a long journey during which the monolith broke into many microservices and the organization structure was constantly changing accordingly. The driving guidelines were <em>velocity</em>, <em>ownership</em> and <em>failure isolation</em>. Using this unconventional approach, Amazon succeeded to launch AWS, Amazon marketplace and Amazon prime.</p>
<p>It was a very interesting talk because it was pragmatic, all the use cases were from real life experience. There were many questions during the Q&A sessions, most of them having to do about the application of the Amazon model to smaller organizations. Of course the scale is different and not all of these can be applied, but the driving guidelines of velocity, ownership and failure isolation still apply and can be used to develop a more suitable model for your organization.</p>
<p>This talk was recorded. You can watch the video <a href="https://vimeo.com/540659777">here</a>.</p>
<h2 id="jvm-performance-tuning">JVM performance tuning</h2>
<p>The second talk was by <a href="https://www.linkedin.com/in/thomas-pliakas/">Thomas Pliakas</a> and was about JVM tuning. This is a big subject and most of us are unware about most of the capabilities of the JVM. The talk was a guided tour of the JVM tuning flags (<strong>-XX</strong>). During each stop, Thomas explained the flag and for most of them told us war stories that happened to him and how the correct/incorrect application of the flag made a difference. It was an exciting journey around the heap, the GC, the JIT the compiler and all the internals of the JVM. The Q&A session was spent mostly on discussing how modern runtime environments, like docker and kubernetes, affect the tuning strategies.</p>
<p>You can find the slides <a href="https://github.com/JHUG/JHUG-General-Resources/blob/master/presentations/2021/04-April/JVMPerformanceTuning.pdf">here</a>.</p>
<h2 id="code-reviews">Code reviews</h2>
<p>This time, instead of another talk, we decided to have an open discussion about code reviews. The trigger was <a href="https://bill.burkecentral.com/2021/03/31/anybody-else-hate-pr-reviews/">this</a> blog post by Bill Burke, in which the author argued against code reviews. We discussed it a lot in our slack channel and we decided that we can make a larger conversation, live this time, including more members.</p>
<p>We started with an open agenda. We did not want to repeat best practices or antipatterns. These you can find in many good books and blog posts. We just wanted to tell moral stories including code reviews. The participation was massive and the discussion was very lively. The topics touched covered all the spectrum of the subject. We will cover the full discussion in an upcoming blog post. But until it is published here are some teasers:</p>
<ul>
<li>I am the law</li>
<li>To test or to review? Here is the question</li>
<li>I feel like an idiot</li>
<li>We must implement an NLP bot for the code comments</li>
<li>Captain’s log, Stardate 43989.1. I make fixes for the 5th pass of the review. God please make it stop</li>
<li>Tell the newbie to shutup and listen</li>
<li>I am here to be useful, not pleasant</li>
<li>Well, i can’t give you a +1, but i know someone who can</li>
</ul>
<h2 id="thats-all-folks">That’s all folks</h2>
<p>We had a great time with the talks and the vivid Q&A sessions. You are now planning the next meetup which will be virtual again. The details will be published in our <a href="https://jhug.slack.com">slack</a> channel. You should consider joining our slack because this is our home during the lockdown and we have very interesting discussions and sometimes great flame wars. So, until our next meetup, stay well, take care of yourselves and keep coding.</p>Spiros AnastasopoulosThis Thursday, we had another JHUG virtual meetup. It was the fifth we had during the lockdown and we are very confortable with the format, but we hope to meet and talk face to face very soon. This time around 60 members participated and watched the sessions. As always it was held on google meetup and the details and the link were published on our slack channel.JHUG 11-Mar-2021 virtual meetup2021-03-12T17:00:00+00:002021-03-12T17:00:00+00:00https://www.jhug.gr/jhug-meetup-march-11th-2021<p>This Thursday 11/03 we had the first virtual meetup of 2021. We were happy to meet once again, although virtually from our homes, and discuss interesting topics about java. The covid-19 lockdown has been going on for almost a year and it will continue for some more months for sure. However JHUG is active and we keep having meetups and we would like to thank our members for their patience and eagerness to participate in the events.</p>
<p>Now, lets go to the talks. The latest meetup had 3.</p>
<h2 id="lets-talk-about-bean-mapping">Let’s talk about Bean Mapping</h2>
<p>The first talk was by <a href="https://www.linkedin.com/in/pntanasis/">Periklis Ntanasis</a> on java bean mapping. This is a frequent issue on data design. We have objects of different clases but with some common properties, and we want to map one object to the other. There are many uses cases. The most common are when we want to create DTOs for performance reasons or <em>map</em> an object to another class to take advantage of the annotations of the later. Periklis presented the problem and discussed the pros and cons of each approach: manual, reflection, code generation, byte code instrumentation. He also made a survey of almost all(!) available libraries, commented on each one and presented performance benchmarks. That was a very interesting talk not only because it was concise and up to the point but because it reminded to us that exploring a solution space even after a good solution is already presented can be fun and joyful.</p>
<p>You can find the slides <a href="https://github.com/JHUG/JHUG-General-Resources/blob/master/presentations/2021/03-March/JavaBeanMapping.pdf">here</a>. Moreover Periklis has written a blog post about the topic which you can read <a href="https://masterex.github.io/archive/2021/02/08/java-bean-mapping-in-depth.html">here</a>.</p>
<h2 id="test--commit--revert">Test && commit || revert</h2>
<p>The second talk was by <a href="https://www.linkedin.com/in/nikos-voulgaris-44455546/">Nikos Voulgaris</a> on a new programming workflow called <code class="language-plaintext highlighter-rouge">test && commit || revert</code>. That workflow was introduced by Kent Beck in this <a href="https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864">post</a> and is new and relatively untried. We can describe it as an extension of TDD to include git: If the tests pass then commit else revert. This is however a simplification that does injustice to the flow. Nikos fully explained the flow, how it relates to TDD and most importantly the state of mind that enforces to the programmer. This is in essence its value. It is not a technical pattern but a discipline that the programmer must obey to make sure he makes small, sure, steady steps while coding. The talk was very vivid and caused an interesting Q&A session. That was expected because each programmer has its own <em>accepted</em> workflow and is always at least <em>suspicious</em> when presented with something outside the <em>one-true-way</em>.</p>
<p>You can find the slides <a href="https://github.com/JHUG/JHUG-General-Resources/blob/master/presentations/2021/03-March/TestCommitRevert.pdf">here</a>. Nikos also published a blog post about the flow which you can read <a href="https://nvoulgaris.com/test--commit--revert/">here</a>.</p>
<h2 id="developing-native-cli-applications-with-quarkus-and-picocli">Developing native CLI applications with Quarkus and PicoCLI</h2>
<p>The third talk by <a href="https://www.linkedin.com/in/georgios-andrianakis/">Georgios Andrianakis</a> was about <a href="https://picocli.info/">picocli</a> a library for building rich command line applications in java. When we say rich apps we mean something like <code class="language-plaintext highlighter-rouge">git</code> which has subcommands like <code class="language-plaintext highlighter-rouge">git add</code>, <code class="language-plaintext highlighter-rouge">git commit</code> etc and not something like <code class="language-plaintext highlighter-rouge">gcc</code> which is a single command but with a lot, really a lot, of flags. Picocli, is a declarative library, that is you write properly annotated classes and the entry points for the commands and then the framework generates the app sceleton for you. This sceleton app of course should be augmented with the business logic. There are many ways to do it: plain java, spring, micronaut or any other framework. Georgios chose to present the integration with <a href="https://www.redhat.com/en/topics/cloud-native-apps/what-is-quarkus">quarkus</a> which has 2 strong points: The first is that is supports CDI (Contexts and Dependency Injection) out of the box and the second is that it can generate a GraalVM native image which offers very small startup time and fast execution times for the app. All these are provided by quarkus with minimal configuration.</p>
<p>The talk was mostly live coding but you can find a guide for setting up quarkus with picocli <a href="https://quarkus.io/guides/picocli">here</a>.</p>
<h2 id="thats-all-folks">That’s all folks</h2>
<p>We had a great time with the talks and the vivid Q&A sessions. You are now planning the next meetup which will be virtual again. The details will be published in our <a href="https://jhug.slack.com">slack</a> channel. You should consider joining our slack because this is our home during the lockdown and we have very interesting discussions and sometimes great flame wars. So, until our next meetup, stay well, take care of yourselves and keep coding.</p>Spiros AnastasopoulosThis Thursday 11/03 we had the first virtual meetup of 2021. We were happy to meet once again, although virtually from our homes, and discuss interesting topics about java. The covid-19 lockdown has been going on for almost a year and it will continue for some more months for sure. However JHUG is active and we keep having meetups and we would like to thank our members for their patience and eagerness to participate in the events.JHUG 29-Dec-2020 virtual meetup2020-12-30T16:00:00+00:002020-12-30T16:00:00+00:00https://www.jhug.gr/jhug-meetup-december-29th-2020<p>The year is coming to end and what a better way to celebrate than a meetup with a lot of java. Indeed we scheduled our last meetup for 2020 on the 29th of December and we really enjoyed it.</p>
<p>Before we go on to recap the meetup, let’s say a few words on how we organize and announce our virtual meetups. 2020 was the year of the covid-19 pandemic. All outdoor activities were suspended including conferences and meetups. Under these conditions we stayed active in our <a href="https://jhug.slack.com">slack channel</a> and we created a <a href="http://tinyletter.com/jhug">newsletter</a> for individuals who did not want to join yet another slack channel. The virtual meetups were organized exclusively in slack. From there, from the active community and the discussion threads we were <em>mining</em> speakers and subjects for presentations. Afterwards it was a simple step to setup a date, a google meet link and publish it on slack.</p>
<p>However, the meetups were not announced on a public platform like <a href="https://www.meetup.com/">meetup.com</a> and some people interested in them, may have missed them. This was a deliberate decision. Most virtual meetups do exactly this: They invite speakers, stream the talk on youtube and publish the link for every one to watch. After the talk they usually use zoom or google meet for the Q&A sessions. For our virtual meetups we wanted to preserve the important aspects of our physical meetups: networking and participation. We wanted the virtual meetups to look more like physical meetups than conferences. That’s why we decided to do the whole meetup on google meet, where everyone can talk or question during a session, and everyone can see each other. We wanted the virtual meetups to be a natural outcome of the community activity on slack not an event that comes out of the blue. So far the feedback is very good. However we are eager to adapt if there are requests to organize meetups that will be streamed on public sites.</p>
<p>And now let’s go to the interesting part, the talks. There were four, each one took about 20 minutes including the Q&A session.</p>
<p>The first one was by <a href="https://twitter.com/javapapo">Paris Apostolopoulos</a> on <a href="https://micronaut.io/">Micronaut</a> a java framework from building microservices. Paris talked about the framework, its origins and the current status. The focus was not on the API or the programming model but on maturity, documentation, community and adoption. He made a comparison, with respect to these factors, with spring boot, quarkus and other similar frameworks. The outcome is that if you are seeking a framework to build java microservices from scratch Micronaut is a good and sensible choice and withstands competition. On the other hand if you are already using a similar framework, you are not happy with it, and you are thinking of migrating, Micronaut is not a silver bullet. The problems with microservices very infrequently are caused by the framework and if you have such problems, start by checking your processes and your microservices practices than the framework. Paris’s talk was very interesting and up to the point. You can find the slides <a href="https://github.com/JHUG/JHUG-General-Resources/blob/master/presentations/2020/12-December/Micronaut%20in%2015%20minutes.pdf">here</a>.</p>
<p>The second talk was by <a href="https://twitter.com/iocanel">Ioannis Canellos</a> who talked about his experience using emacs as his development environment for java. Ioannis was using emacs for some secondary tasks like presentations, email, note taking etc, he liked the tool and was very productive with it. So, why not try it for java development instead of IDEA or Eclipse? Initially the support was not very good but eventually it became mature enough to support the busy days of a full time senior java developer. He made a live demo and showed the plugins he is using for writing and editing code, committing to git and even doing code reviews and PRs on github. He has also written a plugin <a href="https://github.com/iocanel/idee">idee</a> that boosts the emacs experience even more. The question of course was: Ok that was impressive, should we adopt emacs? The point of the talk was not to answer this with a yes or no but to point out that you should invest time to tailor your development environment to your needs and find and tune the tools that make you happy. This is an investment that will pay off as you become more productive by using them. The emacs demo was indeed impressive and made us wonder why we are using the other IDEs. You can find the slides <a href="https://github.com/iocanel/presentations/tree/master/2020-jhug-emacs-for-java-developers">here</a></p>
<p>The third talk was by <a href="https://twitter.com/geoand86">Georgios Andrianakis</a> who talked about an engineering subject, <em>IO Thread vs Worker thread demystified</em>. Georgios has been working lately on <a href="https://quarkus.io/blog/resteasy-reactive/">RESTEasy Reactive</a> a fully reactive new JAX-RS implementation tightly integrated with <a href="https://www.redhat.com/en/topics/cloud-native-apps/what-is-quarkus">Quarkus</a> and as you can assume the words event, event-driven, thread, worker, blocking, non-blocking, IO, reactive etc were spinning in his head for days. In his talk he tried to give us a glimpse of the issues that arise in the development of such a framework and more specifically the differences between two architectures, the one using an event loop and the one using a thread pool. He presented the implementation of a concurrent server using both architectures and for each one measured the resource usage (memory, IO bandwidth) and the maximum QPS it could handle. The clear winner was the one with the event loop but this does not mean that threads should be avoided altogether. Giorgos promised to elaborate on a future talk. For now you can check the demo code <a href="https://github.com/geoand/jhug-12-2020">here</a>.</p>
<p>The fourth and last talk was by <a href="https://twitter.com/anastasop">Spyros Anastasopoulos</a>. Spyros participated in this year’s <a href="https://adventofcode.com/">Advent Of Code</a> an annual online event that involves solving programming puzzles and he used Java to solve them. He presented his experience with Java in this context, in writing small, self-contained programs where the algorithm matters a lot. Well, java is not as succinct or elegant as python or clojure, but it is reliable and gets the job done. It has a very good readability vs writability ratio and as the program size increases, the static type features help a lot to keep the code manageable and to retain the insights into the problem and the solution. You can find the slides <a href="https://speakerdeck.com/anastasop/advent-of-code-in-java">here</a>.</p>
<p>The meetup lasted 2 hours, a bit more than scheduled, because of the extensive Q&A sessions. It seems the subjects interested the attendants a lot and they had interesting comments and questions.</p>
<p>We renewed our meeting for the next year. Very probably it will be a virtual meetup again as we are not expecting to be able to do physical meetups soon, the pandemic is not over yet.</p>
<p>We wish to all of you a happy new year with a lot of Java. Stay safe, stay strong and keep coding.</p>Spiros AnastasopoulosThe year is coming to end and what a better way to celebrate than a meetup with a lot of java. Indeed we scheduled our last meetup for 2020 on the 29th of December and we really enjoyed it.JHUG works from home2020-11-23T08:00:00+00:002020-11-23T08:00:00+00:00https://www.jhug.gr/jhug-works-from-home<p>The covid-19 pandemic has changed the way we work. Where feasible every activity has transferred online and this involves work from home (WFH), telecommuting, work from anywhere (WFA), remote working and smart working. Some countries, like Italy, have gone one step further and are talking about the phenomenon of south working, people are leaving the big cities and are moving to the provinces where life is better and cheaper but they keep their jobs and continue to work remotely.</p>
<p>Of course remote working is not something new. Especially in the IT domain, many companies had already embraced it. Many companies allow their employees to work from home some days a month and some others allow an unlimited number of days. There are also cases of organisations that have aggressively embraced it and their employees work exclusively from their homes, coffee houses or co-working spaces, or are even based on other cities than the premises of the company. These companies reflected on the pros and cons of remote working and decided that it is beneficial for them to adopt it.</p>
<p>Alas, this was not the case with most companies during the COVID-19 pandemic. Most companies were obliged or forced to move online for public safety reasons. Crowded trains and crowded offices are considered hotspots for the virus and experts recommend strongly against them. This transition to remote working was neither instant nor smooth. Working remotely during the pandemic is definitely not the same as working remotely in general.</p>
<p>To get a glimpse on the situation we have asked our members to share their experiences for almost a year of working from home. We have gathered the feedback and positioned it using 4 axes: <em>psychology</em>, <em>office</em>, <em>time</em> and <em>processes</em>.</p>
<h2 id="psychology">Psychology</h2>
<p>Definitely not the best. There is a pandemic out there and all activities have paused. Most people are worried for their family, friends and beloved persons. Then come productivity concerns and the uncertainty about the future. This adds additional stress which cannot be handled equally well by everyone. Some can cope with it, some not. A lot of empathy is needed for other people, and we should not assume everyone can handle the situation in the same way as we do. We should not blame ourselves if we are having difficulties. We should not expect perfection from others if we are doing fine. During the pandemic, assessments, reviews and performance metrics can wait. Over-performers and under-performers should be judged judiciously.</p>
<h2 id="office">Office</h2>
<p>Offices are full of distractions and interruptions. You cannot start working on something and hope that you will manage to stay concentrated for some hours to finish it. Someone will interrupt you soon, with reason being anything, from an urgent bug in production to a needless meeting that could have been an email, to a question like “where Peter sits? There is a courier at the door”. Working from home certainly does not have that many interruptions.</p>
<p>One of the reasons offices are full of interruptions is because they are full of people that are socializing. This is what people miss the most when working from home. They talk to colleagues not for FOO-242 but for TV shows and football. To say and hear a good joke or story. To suggest good restaurants. To say and hear some well hearted good mornings before work.</p>
<p>Some companies try to compensate by using channels for socializing. This does not seem to work. It is very artificial. Good socializing is spontaneous. You see John and you want to tease him because his team lost 4-0 yesterday. But scheduling a meeting with John on Friday 15:00 UTC to troll him feels fake. It is not the same as the everyday contact at the office.</p>
<p>Of course saying homes have no distractions this period is not true. It is not as pre-covid19 when your kids went to school, your other half went to work, then you could turn the music on, disconnect from the chat and start coding like when you were a student. Now the whole family is at home. There is no longer a clear separation between work, family and fun. Everything is rather mixed. A bit of everything all day long. And this means a lot of distractions, interruptions and noise. If at all feasible, a dedicated room is very helpful for work, the living room is no longer adequate.</p>
<p>Another issue is equipment. Offices usually have better internet connections, better computers and they also have a support team to fix issues immediately. At home, if a problem of this kind happens, then it will take some time to be solved at the expense of work.</p>
<p>The biggest loss in leaving the office is the lack of random talks and encounters and the relaxation of team bonding. It is a great deal to be able to discuss your work with your colleagues. They can give you interesting ideas, well-meaning critique, reliable feedback. Socializing and brainstorming promotes creativity and productivity. This is the most difficult part to move online as it is a result of timing, mood and inspiration. All these are more or less instantaneous and unpredictable and cannot be moved with the same effect to scheduled meetings let alone online. It happens many times that we cannot find a solution to a problem after 3 or 4 intense meetings and we find it when we discuss it over a cup of coffee in the lobby. The best compensation so far is to allow people to initiate random video calls without an agenda or expected deliverables. This of course is part of the organization’s processes.</p>
<h2 id="time-and-schedule">Time and schedule</h2>
<p>One immediate advantage is that there is no commuting. In Greece, the distances are small but the traffic is intense and thus the commuting time is considerable. Remote work saves on the average an hour a day that is spent on other more useful activities.</p>
<p>The next point is the flexibility of schedule, if your employer permits it. You can wake up a bit later, take your breakfast, work 10-14, then take a nap and continue in the afternoon. Or you can start your day with your kids or your hobbies and do your daily work at noon. Of course during the day you can take some longer breaks to go for groceries or to the post office or cook a special dish to eat.</p>
<p>Under these conditions you can be more productive because you manage your own time but is it also easier to waste your time in other activities or get distracted a lot and in the end underperform. For this reason, some companies do not allow it. They require employees to be online 9-5, always available and that their AFKs be small and predictable.</p>
<p>This flexibility and the lack of commuting unfortunately has led to stretching of the work schedule for some. There are 10 hours work days, DMs and emails outside the work schedule and attempts (deliberate or not) to exploit the fact that people are home and can answer 24x7. Of course this is unacceptable and at best it shows the immaturity of an organization’s processes.</p>
<p>There is no verdict as to whether flexibility is an advantage or not. It is very tightly coupled with how well the other processes of a company have migrated remotely.</p>
<h2 id="processes">Processes</h2>
<p>At the organization level, how different is working at the premises than working from home? Initially almost all companies moved their processes online without changes. A meeting in a room became a zoom call. A need for help from a colleague became a DM. The morning catchup became a slack thread or a zoom meeting. Work continued as usual but you used an online tool for everything.</p>
<p>Soon it became clear that this was not the way for effective remote working. The issue was communication overhead. The on-premises processes were designed with physical communication in mind which is straightforward, terse and concise. For most organizations the transition resulted in a lot of meetings to say the same things over and over again. Meetings are now easier (and abused) because there is no need for a meeting room. Imagine an edge case, an organization without a process at all. To resolve a bug you do: grep logs, git blame, talk to Maria. This is tedious but works. Moving this online is a nightmare. You end up losing a lot of time just to coordinate people. It is not only the issue of telling someone what to do. You must also make sure that they fully understand it otherwise they will lose time on dealing with the wrong problem or, even worse, over engineer a simple task. That needs a second round of communications and maybe a third.</p>
<p>For effective remote working the keyword is asynchronous communication. Everything should be written as concise and unambiguously as possible and posted in the right channels for the teams to find it and take actions. The teams will also communicate the same way and in the same channels to request help or resources and to put the deliverables of the tasks. This is not as simple as it looks, it needs work and commitment on behalf of the organizations. In respect to this, there are two types of organizations:</p>
<p>The first type does not like remote work and prefers to have the stuff on premises. These organizations consider this remote period as transient and expect the people to return to their offices when it ends. It does not invest on improving the processes for remote as they don’t expect to use it intensively in the future. For now they decided to tolerate the remote overhead.</p>
<p>The second type realizes that remote working is a game changer regarding operational costs, overall performance and talent acquisition. It uses the current pandemic period as a testbed for improvisation of the processes, to select the proper tools and learn to use them effectively in the future.</p>
<p>Two processes deserve special mention: hiring and onboarding. How to evaluate candidates? How to prepare new employees to start work smoothly? Admittedly these can be done better on premises with physical communication. Even full remote companies do it that way. Doing it remotely was not exactly difficult but it was challenging. Online tools work well here because there is no shortage of meeting rooms or schedule conflicts or interview stereotypes or dress codes. You have just to talk with each other. Also evaluation forms or coding exercises can be fulfilled online with ease. But physical contact in these cases certainly adds value. In some cases, when the lockdown measures were relaxed, a candidate or a new hire could go to the premises and have a discussion with the colleagues. In many cases this was not possible and thus started working remotely immediately. The issue now is again the team bonding. You are cooperating for months with a person you have only seen on screen. This is getting worse because of the lack of socializing. Even before the pandemic it takes some time to feel at home with new members in your team. Now it takes a bit longer and there is always the question how things will be from near.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The general impression is that remote working delivers. People have adapted to it and now they feel more comfortable and they are more productive. Of course things are still under constant revision and are improving. The point is that from now on, even after the pandemic ends, we are expecting remote working to be a more common case than an exception.</p>Spiros AnastasopoulosThe covid-19 pandemic has changed the way we work. Where feasible every activity has transferred online and this involves work from home (WFH), telecommuting, work from anywhere (WFA), remote working and smart working. Some countries, like Italy, have gone one step further and are talking about the phenomenon of south working, people are leaving the big cities and are moving to the provinces where life is better and cheaper but they keep their jobs and continue to work remotely.JHUG meetup November 11th 20192019-11-17T18:46:28+00:002019-11-17T18:46:28+00:00https://www.jhug.gr/jhug-meetup-november-11th-2019<p>Την περασμένη Δευτέρα κάναμε τη δεύτερη μας εκδήλωση για φέτος που ήταν και το πρώτο meetup εφόσον η πρώτη εκδήλωση ένα workshop για το <a href="https://www.jhug.gr/kai-tora-kati-entelos-diaforetiko/">quarkus</a>.</p>
<p>Το meetup έγινε στην πολύ όμορφη αίθουσα του <a href="https://www.codehub.gr/">Code.Hub</a> στη Λεωφόρο Αλεξάνδρας. Αυτή τη φορά είχαμε χορηγούς την <a href="https://www.nokia.com/networks/">Nokia</a> και το <a href="https://www.codehub.gr/">Code.Hub</a> που μας βοήθησαν με την προβολή του meetup, την αίθουσα, το networking και πρόσφεραν και τα κεράσματα σε όσους έλαβαν μέρος.</p>
<p>Η προσέλευση ήταν ικανοποιητική. Δυστυχώς λόγω της επίσκεψης του προέδρου της Κίνας και αναταραχών στην ΑΣΟΕΕ η κατάσταση στους δρόμους ήταν δύσκολη και υπήρχε κόσμος που δεν ρίσκαρε να κατέβει στο κέντρο. Αρκετοί από αυτούς θα σκέφτηκαν ότι δεν πειράζει, θα δουν τις ομιλίες όταν ανέβουν τα βίντεο αλλά δυστυχώς σε αυτό το meetup δεν είχαμε βίντεο λόγω υποχρεώσεων του κάμεραμαν(sic!) εκτός Αθηνών. Αυτά τα απρόοπτα δυστυχώς συμβαίνουν. Δεν είναι τα πάντα προβλέψιμα, στρωτά και εύκολα όπως όταν γράφουμε κώδικα σε java.</p>
<p>Ο Θωμάς καλωσόρισε τον κόσμο εκ μέρους του JHUG και για μια ακόμα φορά ζήτηση περισσότερες συμμετοχές για ομιλίες.</p>
<p>Ο <a href="https://www.linkedin.com/in/daivatoglou/">Δημήτρης Αϊβάτογλου</a> από τη Nokia μίλησε για την εταιρεία, την πορεία της και τα απαιτητικά έργα που φέρνει σε πέρας και πως η java αποτελεί το πιο αξιόπιστο εργαλείο της.</p>
<p>Στη συνέχεια ο <a href="https://www.linkedin.com/in/inikolakopoulos/">Γιάννης Νικολακόπουλος</a> από το Code.Hub μίλησε για τη σημασία που έχει σήμερα η γνώση προγραμματισμού, για τις υπηρεσίες που προσφέρουν και για τη στήριξη που παρέχουν στα meetups της Αθήνας και όχι μόνο.</p>
<p>Μετά από αυτές τις απαραίτητες αναφορές, το λόγο πήραν οι ομιλητές.</p>
<h2 id="java-memory-management-bedtime-stories-από-την-εύη-χατζιδάκη">Java Memory Management, Bedtime Stories από την Εύη Χατζιδάκη</h2>
<p>Η Εύη, senior software engineer στη Nokia, με αυτή την ομιλία έσπασε μια άσχημη παράδοση που μας στεναχωρούσε, ότι σε κανένα meetup δεν είχε κάνει παρουσίαση γυναίκα μηχανικός.</p>
<p>Διάλεξε ένα θέμα με το οποίο είχε ασχοληθεί αρκετά όπως είπε, το java memory management. Το project στο οποίο συμμετέχει περιλαμβάνει ένα server από τον οποίο περνάει πολύ μεγάλη κίνηση και άρα τα memory leaks και ο χρόνος που τρέχει ο garbage collector έχουν μεγάλο αντίκτυπο στο performance του.</p>
<p>Η παρουσίαση της είχε πολύ υλικό, νομίζω άνετα μπορούν να βγούνε ακόμα 2-3 ομιλίες από όσα είπε για τα επόμενα meetups. Η Εύη έκανε ένα overview του πως διαχειρίζεται τη μνήμη η JVM, έδειξε σχετικά patterns και anti-patterns και παρουσίασε εργαλεία για monitoring και debugging θεμάτων σχετικών με μνήμη. Για τα περισσότερα από αυτά έδειξε και ένα live demo όπου φαινόταν καθαρά το πρόβλημα και η λύση.</p>
<p>Η παρουσίαση ήταν πολύ πυκνή με πολύ υλικό αλλά απλή και κατανοητή. Έβαλε σε τάξη πολλές ερωτήσεις σχετικά με τη JVM και τη μνήμη και σίγουρα έδωσε ιδέες για ομιλίες που θα εξειδικεύουν τα θέματα που έθεσε.</p>
<h2 id="quiz-pizza-and-beer">Quiz, pizza and beer</h2>
<p>Ανάμεσα στις δυο ομιλίες ο Γιώργος Καλφόπουλος βλ <a href="https://www.meetup.com/Ministry-of-Testing-Athens/about/">Ministry Of Testing</a> έκανε ένα quiz με ερωτήσεις java και στους νικητές δώθηκαν δύο βιβλία και μια προσωπική άδεια intellij προσφορά της <a href="https://www.jetbrains.com/">JetBrains</a></p>
<p>Μετά απο αυτή την ευχάριστη νότα έγινε διάλειμμα για pizza και networking, πριν συνεχίσουμε με τη δεύτερη ομιλία.</p>
<h2 id="faster-cheaper-leaner-horizontally-scaling-a-ci-pipeline-από-τον-γιώργο-σασλή">Faster, Cheaper, Leaner: Horizontally Scaling a CI Pipeline από τον Γιώργο Σασλή</h2>
<p>Ο <a href="https://www.linkedin.com/in/gsaslis/">Γιώργος</a> είναι software delivery engineer στη RedHat και είναι γνωστός στο Ελληνικό ΙΤ σαν ένα από τα κινητήρια γρανάζια πίσω από το IT οικοσύστημα της Κρήτης και από τη διοργάνωση των <a href="https://agilecrete.org/">AgileCrete</a> και <a href="http://www.jcrete.org/">JCrete</a>.</p>
<p>Στην Αθήνα βρέθηκε ταξιδεύοντας για το DevConf της Ρουμανίας όπου και θα έκανε μια παρουσίαση με το ίδιο θέμα. Με αυτή την ευκαιρία προθυμοποιήθηκε να μας παρουσιάσει το υλικό του και τον ευχαριστούμε.</p>
<p>Η παρουσίαση είχε 2 μέρη.</p>
<p>Το πρώτο θα μπορούσε να έχει τίτλο “Όλα όσα θέλατε να μάθετε για το CI pipeline”. Πραγματικά παρουσίασε το ιστορικό της εξέλιξης του, την αναγκαιότητα του και πολλά patterns καλής χρήσης και ομοίως anti-patterns κακής. Έκανε αναφορά σε όλα τα σχεδιαστικά θέματα ενός CI pipeline όπως κόστος VMs, χρόνος εκτέλεσης, παράλληλη εκτέλεση των tests, αξιοπιστία των αποτελεσμάτων, flaky tests και πολλά άλλα.</p>
<p>Το δεύτερο μέρος περιείχε τη λύση που δώσανε στα παραπάνω θέματα στα projects που συμμετέχει. Παρουσίασε το CI pipeline της <a href="https://www.3scale.net/">3scale</a> και έδειξε τα πλεονεκτήματα και τα μειονεκτήματα του.</p>
<p>Ο Γιώργος ανέβασε τις διαφάνειες του <a href="https://speakerdeck.com/gsaslis/faster-cheaper-leaner-horizontally-scaling-a-ci-pipeline-1ac8963b-22ed-4149-9047-7a7d192312d3">εδώ</a> ενώ τα projects της 3scale είναι open source και βρίσκεται <a href="https://github.com/3scale/porta">εδώ</a></p>
<h2 id="το-επόμενο">Το επόμενο;</h2>
<p>Το ραντεβού ανανεώθηκε για την επόμενη φορά με περισσότερη java. Επειδή όμως το meetup.com έχει ένα θέμα με τα RSVP αν θέλετε κοιτάζεται και τα υπόλοιπα κανάλια για να μην χάσετε την ημέρα.</p>
<h2 id="join-jhug">Join JHUG</h2>
<p>Μπορείτε να μαθαίνετε τα νέα του JHUG, να συμμετέχετε και να ανταλλάξετε ιδέες μέσα από τα κανάλια μας:</p>
<ul>
<li><a href="https://jhug.slack.com">Slack</a></li>
<li><a href="https://twitter.com/jhug">Twitter</a></li>
<li><a href="https://www.meetup.com/Java-Hellenic-User-Group">Meetup</a></li>
<li><a href="https://www.jhug.gr">Blog</a></li>
<li><a href="https://vimeo.com/javahellenicusergroup">Vimeo</a></li>
</ul>
<p>Τα νέα για τα meetup και τις άλλες εκδηλώσεις δημοσιεύονται σε όλα τα κανάλια αλλά οι ενδιαφέρουσες συζητήσεις είναι στο slack. Αν δεν είσαστε εκεί, ζητήστε πρόσκληση.</p>Spiros AnastasopoulosΤην περασμένη Δευτέρα κάναμε τη δεύτερη μας εκδήλωση για φέτος που ήταν και το πρώτο meetup εφόσον η πρώτη εκδήλωση ένα workshop για το quarkus.Και τώρα κάτι εντελώς διαφορετικό2019-10-23T21:03:57+00:002019-10-23T21:03:57+00:00https://www.jhug.gr/kai-tora-kati-entelos-diaforetiko<p>Το περασμένο Σάββατο έγινε το πρώτο meetup του JHUG για τη νέα σεζόν και ήταν διαφορετικό από τα προηγούμενα. Ας πάρουμε όμως τα πράγματα από την αρχή.</p>
<p>Εδώ και καιρό θέλαμε να δοκιμάσουμε κάτι διαφορετικό στα meetups και να ξεφύγουμε λιγάκι από τη δομή με τις 2 ομιλίες. Η ευκαιρία μας δόθηκε σε συνεργασία με τον <a href="https://twitter.com/geoand86">Γιώργο Ανδριανάκη</a> ο οποίος πρότεινε, αλλά και προθυμοποιήθηκε να βοηθήσει, στη διοργάνωση ενός workshop σχετικό με τα <a href="https://quarkus.io/guides/spring-web-guide">Quarkus extensions για τo spring web API</a>. Το <a href="https://quarkus.io">Quarkus</a> είναι η νέα, πολλά υποσχόμενη πρόταση της <a href="https://www.redhat.com">Red Hat</a> για την ανάπτυξη εφαρμογών για microservices, cloud native και serverless εφαρμογές και φυσικά είναι σε java. Για αυτή τη νέα πλατφόρμα έχουν γίνει ομιλίες και στο <a href="https://vimeo.com/339715440">JHUG</a> και στο <a href="https://www.youtube.com/watch?v=UWETnSFB0WA">Voxxed Days Athens</a>. Ο Γιώργος θα κάνει και μια ομιλία στο προσεχές <a href="https://devoxx.be/speaker-details/?id=124451">Devoxx</a> για Quarkus και spring οπότε το JHUG ήταν ταυτόχρονα αποκλειστικότητα για τα μέλη και πρόβα generale για τον Γιώργο.</p>
<p>Για την διοργάνωση του workshop είχαμε για άλλη μια φορά τη βοήθεια της <a href="http://www.afse.eu/">Advantage FSE</a> η οποία παραχώρησε την αίθουσα της και τα κεράσματα στους συμμετέχοντες. Η εταιρεία στέκεται πάντα πολύ κοντά στο JHUG και μας βοηθάει στις εκδηλώσεις μας. Με αυτή την ευκαιρία να ευχαριστήσουμε για άλλη μια φορά την εταιρεία και το <a href="https://www.linkedin.com/in/peggytheodorou/">HR τμήμα</a> για τη προσφορά και τη συνεργασία τους.</p>
<p>Η εκδήλωση ξεκίνησε με το καλωσόρισμα του JHUG στους παρευρισκόμενους με την ευχή να έχουμε καλή νέα σεζόν και να ευχαριστηθούμε java. Η συμμετοχή, περίπου 30 άτομα με το laptop τους, κρίνεται πολύ ικανοποιητική για το πρώτο μας workshop.</p>
<p>Στη συνέχεια η Αdvantage έκανε μια παρουσίαση για το προφίλ της, τις ψηφιακές υπηρεσίες και τα προϊόντα που παρέχει στον οικονομικό τομέα και τη καλή σχέση που έχει με τα IT communities. Επιθυμία της είναι αυτή η σχέση να ισχυροποιηθεί περισσότερο και με συμμετοχή της σε προσεχείς εκδηλώσεις αλλά και ανοίγοντας <a href="http://www.afse.eu/gr/Why-Work-Here">θέσεις εργασίας</a>.</p>
<p>Μετά σειρά είχε το κύριο πιάτο, ο κώδικας. Ο Γιώργος ξεκίνησε με μια πάρα πολύ σύντομη εισαγωγή στο Quarkus και μετά μίλησε για τα spring web API extensions. Το δεύτερο κομμάτι προτίμησε να το κάνει με τη μορφή live coding. Διάλεξε μια σειρά από μικρές spring εφαρμογές και κάθε μια την έγραφε, την τέσταρε και την έτρεχε live. Οι εφαρμογές αυτές περιείχαν μεγάλη γκάμα από spring features σχετικών με web apps όπως configuration, validation, serialization, routing κτλ. Στα <a href="https://github.com/quarkusio/quarkus-quickstarts">παραδείγματα του Quarkus</a> μπορείτε να βρείτε τον κώδικα για παρόμοιες εφαρμογές με αυτές που παρουσιάστηκαν.</p>
<p>Το live coding ήταν ένας πάρα πολύ καλός τρόπος να παρουσιαστούν αυτά τα features γιατί φάνηκαν όλα τα καθημερινά θέματα του development:</p>
<ol>
<li>τι πρέπει να γράψουμε εμείς και τι θα κάνει το framework αυτόματα</li>
<li>τι υποστηρίζεται πλήρως, τι μερικώς και τι καθόλου</li>
<li>πως γίνεται το debugging</li>
<li>πως κάνουμε monitor μια εφαρμογή που τρέχει</li>
</ol>
<p>Επιπλέον οι περισσότερες ερωτήσεις μπορούσαν να απαντηθούν και λεκτικά αλλά και live με μερικές γραμμές κώδικα όπου φαινόταν τα σημεία της ερώτησης και της απάντησης.</p>
<p>Το live coding τελείωσε μετά από ένα demo για deployment των <a href="https://quarkus.io/guides/building-native-image-guide">native images</a> μιας Quarkus εφαρμογής σε kubernetes όπου φάνηκε πως η εφαρμογή κάνει scale ανάλογα και με το traffic πως προσαρμόζεται στα traffic bursts.</p>
<p>Μετά από ένα διάλειμμα για καφέ, ακολούθησε το workshop. Σε αυτό η κάθε ομάδα θα δοκίμαζε να φτιάξει μια εφαρμογή με το Quarkus με ελεύθερο θέμα. Μπορούσε είτε να κάνει ένα toy project για να δει πως δουλεύει το framework, είτε να δοκιμάσει ένα έτοιμο tutorial, είτε να δοκιμάσει να κάνει port μια υπάρχουσα spring εφαρμογή είτε να δοκιμάσει να φτιάξει μια νέα από την αρχή.</p>
<p>Σε όλη τη διάρκεια του coding, είχαμε ελεύθερη συζήτηση ανάμεσα στους παρευρισκόμενους. Ήταν μια χαλαρή κουβέντα από αυτές τις ωραίες που γίνονται όταν οι developers έχουν όρεξη για κώδικα και πάρλα. Μιλήσαμε για πάρα πολλά θέματα σχετικά με το Quarkus και το java οικοσύστημα αλλά και γενικότερα για διάφορα επαγγελματικά θέματα του κλάδου. Φυσικά σε όλη τη διάρκεια λύθηκαν απορίες σχετικά με τις εφαρμογές που αναπτύσσονταν εκείνη την ώρα και όλες οι ομάδες είπαν την άποψη τους για το framework και τις εντυπώσεις τους από την χρήση του.</p>
<p>Στο τέλος του workshop ακολούθησε pizza και networking και κληρώθηκαν δύο άδειες για το IntelliJ προσφορά της <a href="https://www.jetbrains.com">Jetbrains</a>. Το ραντεβού ανανεώθηκε για την επόμενη φορά με περισσότερη java.</p>
<h2 id="join-jhug">Join JHUG</h2>
<p>Μπορείτε να μαθαίνετε τα νέα του JHUG, να συμμετέχετε και να ανταλλάξετε ιδέες μέσα από τα κανάλια μας:</p>
<ul>
<li><a href="https://jhug.slack.com">Slack</a></li>
<li><a href="https://twitter.com/jhug">Twitter</a></li>
<li><a href="https://www.meetup.com/Java-Hellenic-User-Group/">Meetup</a></li>
<li><a href="https://www.jhug.gr">Blog</a></li>
<li><a href="https://vimeo.com/javahellenicusergroup">Vimeo</a></li>
</ul>
<p>Τα νέα για τα meetup και τις άλλες εκδηλώσεις δημοσιεύονται σε όλα τα κανάλια αλλά οι ενδιαφέρουσες συζητήσεις είναι στο slack. Αν δεν είσαστε εκεί, ζητήστε πρόσκληση.</p>
<h2 id="και-μετά-και-μετά">Και μετά και μετά;</h2>
<p>Το επόμενο meetup μας θα γίνει στις <a href="https://www.meetup.com/Java-Hellenic-User-Group/events/265867977">11 Νοεμβρίου</a>. Έχουμε διαλέξει 2 πρακτικά θέματα και οι ομιλίες προβλέπονται πολύ ενδιαφέρουσες. Μέχρι τότε, keep coding.</p>Spiros AnastasopoulosΤο περασμένο Σάββατο έγινε το πρώτο meetup του JHUG για τη νέα σεζόν και ήταν διαφορετικό από τα προηγούμενα. Ας πάρουμε όμως τα πράγματα από την αρχή.new Season(“2019-2020”)2019-09-23T14:37:23+00:002019-09-23T14:37:23+00:00https://www.jhug.gr/new-season2019-2020<p>Τώρα που ετοιμαζόμαστε για τη νέα σεζόν, είναι μια καλή στιγμή για να δούμε τι έγινε την περασμένη σεζόν και να βγάλουμε χρήσιμα συμπεράσματα για τη συνέχεια.</p>
<p>Την σεζόν 2018-2019 καταφέραμε να διοργανώσουμε 5 meetups πάντα με τη βοήθεια των μελών μας και την ευγενή χορηγία εταιριών που αγαπούν την java. Τα meetups αυτά, με τους τίτλους των ομιλιών, τον χορηγό και link στο blog post ήταν:</p>
<ol>
<li><a href="https://www.jhug.gr/new-meetupsep-2018/" rel="noopener" target="_blank">Σεπτέμβριος 2018</a> με τη χορηγία της <strong>Accenture</strong>
<ul>
<li>An overview of IntelliJ IDEA</li>
<li>Microservices architecture in action</li>
</ul>
</li>
<li><a href="https://www.jhug.gr/jhug-meetup-october-30th-2018/" rel="noopener" target="_blank">Οκτώβριος 2018</a> με τη χορηγία της <strong>Eurobank</strong>
<ul>
<li>Getting (a bit) familiar with Data Science</li>
<li>Java is still free</li>
<li>Notes on Java security</li>
</ul>
</li>
<li><a href="https://www.jhug.gr/jhug-meetup-december-3rd-2018/" rel="noopener" target="_blank">Δεκέμβριος 2018</a> με τη χορηγία της <strong>Intralot</strong>
<ul>
<li>High performance asynchronous transaction orchestration with Java Reactive frameworks</li>
<li>Java puzzlers</li>
<li>JUnit 5</li>
</ul>
</li>
<li><a href="https://www.meetup.com/Java-Hellenic-User-Group/events/258620920/" rel="noopener" target="_blank">Φεβρουάριος 2019</a> με τη χορηγία της <strong>Atos</strong>
<ul>
<li>Hands-on TDD</li>
<li>Improve the quality of your software in 6 steps</li>
</ul>
</li>
<li><a href="https://www.jhug.gr/jhug-meetup-april-9th-2019/" rel="noopener" target="_blank">Απρίλιος 2019</a> με τη χορηγία της <strong>Blueground</strong>
<ul>
<li>Testing Anti-patterns</li>
<li>Introduction to Quarkus</li>
</ul>
</li>
</ol>
<p>Σε αριθμούς η χρονιά μεταφράζεται σε 13 ομιλίες, περίπου 13 ώρες <a href="https://vimeo.com/javahellenicusergroup" rel="noopener" target="_blank">βίντεο</a> — πολλά ευχαριστώ για άλλη μια φορά στον Κωστή Καπελώνη για την εθελοντική και ποιοτική δουλειά του — και αν προσθέσουμε socializing, blog posts κτλ έχουμε κοντά στις 16 ώρες γεμάτες java που τις παρακολούθησαν κοντά στα 500 άτομα. Τα meetups φαίνεται να άρεσαν στο κόσμο τόσο για το περιεχόμενο τους όσο και για την παρουσίαση. Δεν είχαμε αρνητικό feedback για κανένα ομιλητή ή θέμα. Για μερικές ομιλίες είχαμε και πάρα πολύ θετικά σχόλια και μάλιστα ειπώθηκε ότι ήταν καλύτερες από αντίστοιχες ομιλίες σε δυνατά συνέδρια.</p>
<p>Στα highlights της σεζόν ανήκουν σίγουρα η παρουσίαση του Quarkus σχεδόν ταυτόχρονα με την επίσημη ανακοίνωση του, η ζωηρή κουβέντα που έγινε μετά την ομιλία για τα testing anti-patterns, η ωραία χαλαρή διάθεση όταν λύναμε τα java puzzles και η αμηχανία που νιώσαμε όταν καταλάβαμε απο τη σχετική ομιλία πως το security δεν είναι καθόλου δεδομένο ακόμα και στο ασφαλές(?) περιβάλλον της java.</p>
<p>Τα αποτελέσματα είναι σίγουρα ικανοποιητικά αλλά υπάρχει η αίσθηση ότι το jhug έχει μεγαλύτερο δυναμικό που δεν αξιοποιείται. Ας δούμε πιο αναλυτικά μερικά σημεία και να προσπαθήσουμε να βγάλουμε συμπεράσματα και ιδέες για τη νέα σεζόν.</p>
<p>Ένα μεγάλο οργανωτικό πρόβλημα είναι σίγουρα η <em>αίθουσα</em>. Επειδή λειτουργούμε 100% εθελοντικά δεν διαθέτουμε σταθερή αίθουσα και βασιζόμαστε σε δωρεές και χορηγίες για να βρούμε χώρο για το εκάστοτε meetup. Ο τρόπος που οργανώνεται είναι ο εξής: βρισκόμαστε σε επικοινωνία με εταιρείες που θέλουν να βοηθήσουν και για κάθε meetup συμφωνούμε με μια από αυτές για την διοργάνωση. Η εταιρεία αναλαμβάνει να ρυθμίσει τα της αιθούσης και μόλις βρει μια καλή λύση, τότε ανακοινώνουμε ημερομηνία για το meetup και ζητάμε ενδιαφέρον από υποψήφιους ομιλητές. Αυτή η διαδικασία δεν λειτουργεί πάντα τόσο στρωτά όσο ακούγεται. Οι παράγοντες που πρέπει να ρυθμιστούν είναι:</p>
<ol>
<li>οι ημερομηνίες να βολεύουν την χορηγό εταιρεία ανάλογα με τις άλλες δραστηριότητες της</li>
<li>διαθεσιμότητα μεγάλης αίθουσας γιατί συμμετέχουν περίπου 100 άτομα σε κάθε meetup</li>
<li>διαθεσιμότητα ομιλητών για την παραπάνω ημερομηνία</li>
</ol>
<p>Αν στα παραπάνω προστεθεί και το overhead του χρόνου επικοινωνίας τότε υπάρχει περίπτωση να μην καταφέρουμε να κάνουμε meetup κάποιο μήνα. Αυτό φαίνεται και στο <a href="https://www.meetup.com/Java-Hellenic-User-Group/" rel="noopener" target="_blank">ημερολόγιο </a> όπου σε περιόδους που υπάρχουν γιορτές όπως χριστούγεννα και πάσχα δεν έγινε meetup επειδή ήταν δύσκολο να ταυτιστούν οι διαθεσιμότητες όλων.</p>
<p>Μια λύση θα ήταν να “βολευτούμε” με μικρότερες αίθουσες 30-40 ατόμων. Πολλές εταιρείες μπορούν να διοργανώσουν στα γραφεία τους τέτοια meetup και είναι πολύ πιο ευέλικτες στις ημερομηνίες. Αυτή τη λύση δεν την υποστηρίξαμε γιατί αν και η αίθουσα είναι μεγάλο πρόβλημα εντούτοις δεν είναι το μεγαλύτερο οργανωτικό πρόβλημα!</p>
<p>Την περασμένη σεζόν είχαμε ενδιαφέρον από πάρα πολλές εταιρείες και δυστυχώς μερικές δεν προχώρησαν επειδή το μεγαλύτερο πρόβλημα του jhug είναι η διαθεσιμότητα ομιλητών. Αυτό ακριβώς είναι το σημείο που αισθανόμαστε ότι το jhug έχει μεγαλύτερο δυναμικό. Με βάση το πλήθος των java developers στην Αθήνα αλλά και το status και τη δημοφιλία της java σαν πλατφόρμα θα έπρεπε να έχουμε κάθε σεζόν 20-30 προτάσεις για ομιλίες, αλλά πρακτικά είναι κοντά στις 10.</p>
<p>Το πρόβλημα αυτό το έχουν και όλα τα άλλα meetups. Η εύκολη εξήγηση θα ήταν να πούμε ότι οφείλεται στον ορισμό των ημερομηνιών, στις μέρες, στα εργασιακά ωράρια κτλ. Αυτό δεν ισχύει γενικά παρά μόνο κατά περίπτωση. Ο σημαντικότερος λόγος είναι πως ο περισσότερος κόσμος βλέπει τα meetups σαν συνέδρια και αυτό είναι μια εντελώς λανθασμένη θεώρηση. Για παράδειγμα μερικοί λένε ότι όλη ή σεζόν του jhug ισοδυναμεί με 1-2 μέρες στο devoxx ή στη fossdem. Γιατί να ασχοληθώ αφού θα πάω σε αυτά τα δύο συνέδρια; Για ποιό λόγο να δω το vimeo κανάλι σας όταν όλα τα συνέδρια ανεβάζουν τις ομιλίες;</p>
<p>Μπορούν να ειπωθούν πολλά πάνω στις διαφορές τους αλλά ας μείνουμε στη μία και σημαντικότερη: το συνέδριο έχει συγκεκριμένο πλαίσιο λειτουργίας που το θέτουν οι διοργανωτές: Ποιός θα μιλήσει, τι θα πεί, πως θα το πεί, ποιός θα το παρακολουθήσει, ποιός δεν θα το παρακολουθήσει και άλλα πολλά. Το meetup αντιθέτως δεν έχει κανένα τέτοιο κλισέ και αυτό τους δίνει μια άλλη δυναμική. Για να φανεί καλύτερα ας το οριοθετήσουμε με τα κλασσικά 5W της δημοσιογραφίας:</p>
<ol>
<li><strong>Who</strong> όποιος έχει ενδιαφέρον για κάποιο θέμα μπορεί να ετοιμάσει μια ομιλία. Δεν είναι απαραίτητο να είναι expert στο θέμα, ούτε να έχει εμπειρία με αυτό. Η εμπειρία στο αντικείμενο δεν εξασφαλίζει πάντα μια καλή ομιλία και το αντίθετο.</li>
<li><strong>What</strong> όποιο αντικείμενο θέλει. Δεν είναι απαραίτητο ούτε να είναι buzzword, ούτε να πουλάει, ούτε καν να είναι χρήσιμο. Μερικές ιδέες
<ul>
<li>παρουσίαση ενός δημοφιλούς framework</li>
<li>evaluation μιας νέας τεχνολογίας</li>
<li>παρουσίαση ενός προσωπικού github project</li>
<li>παρουσίαση ενός βιβλίου, ενός blog post, ενός youtube βίντεο απο μια ενδιαφέρουσα ομιλία</li>
<li>advanced tutorial για μια τεχνολογία</li>
<li>java fun, puzzles, snippets, pitfalls</li>
<li>java vs go, ruby, js, python, scala etc</li>
<li>community matters όπως license, πτώση της java στο tiobe index, microsoft and java κτλ</li>
<li>γενικά θέματα όπως open source, licenses, privacy, remote working κτλ</li>
<li>τρόπος οργάνωσης της ομάδας του στην εταιρεία που δουλεύει</li>
</ul>
</li>
<li><strong>When</strong> μακάρι να μπορούσαμε να κάναμε meetup και κάθε εβδομάδα</li>
<li><strong>Where</strong> η αίθουσα είναι μεγάλο πρόβλημα του jhug</li>
<li><strong>Why</strong> γιατί η συμμετοχή και η προσφορά είναι θεμέλια της προόδου. Υπάρχουν μηχανικοί που κάνουν και τα 2 απο την εργασία τους ή απο συνέδρια ή απο προσωπικά sites ή με κάποιο άλλο τρόπο. Αλλά σε κάθε περίπτωση για να υπάρξει πρόοδος και για κάθενα ξεχωριστά αλλά και για το community χρειάζεται και συμμετοχή και προσφορά. Είναι πολύ πιο δύσκολο αλλά και ωφέλιμο να ετοιμάζεις μια παρουσίαση για ένα θέμα από το να παρακολουθήσεις 4. Το ίδιο ισχύει για γράψιμο vs διάβασμα και για κάθε είδος και τρόπο δημιουργίας.</li>
</ol>
<p>Με αυτές τις σκέψεις ξεκινάμε τη νέα σεζόν με ακόμα περισσότερη java. Σύντομα θα ανακοινωθούν οι ημερομηνίες για τα πρώτα meetup και οι πρώτες ομιλίες. Ελπίζουμε να περάσουμε καλά, να ευχαριστηθούμε java και να ανταλλάξουμε ωραίες ιδέες και θετικά vibes.</p>
<h1 id="join-jhug">Join JHUG</h1>
<p>Μπορείτε να μαθαίνετε νέα, να συμμετέχετε και να ανταλλάσετε ιδέες και σχόλια στα κανάλια μας:</p>
<ul>
<li><a href="https://jhug.slack.com">Slack</a></li>
<li><a href="https://twitter.com/jhug">Twitter</a></li>
<li><a href="https://www.meetup.com/Java-Hellenic-User-Group/">Meetup</a></li>
<li><a href="https://www.jhug.gr">Blog</a></li>
<li><a href="https://vimeo.com/javahellenicusergroup">Vimeo</a></li>
</ul>
<p>Τα νέα για τα meetups και τα διάφορα events δημοσιεύονται σε όλα τα κανάλια αλλά οι ενδιαφέρουσες συζητήσεις είναι στο slack.</p>Spiros AnastasopoulosΤώρα που ετοιμαζόμαστε για τη νέα σεζόν, είναι μια καλή στιγμή για να δούμε τι έγινε την περασμένη σεζόν και να βγάλουμε χρήσιμα συμπεράσματα για τη συνέχεια.