JDD 2017

The order of life is that things come and go just before we have formed our attachments and are more than sorry to let them go away. This is the case with JDD. This year edition is over. I would love to attend such lectures every day but now its time get myself together and sum up all pros and cons of the conference.

The conference begun with opening conducted by @j_palka. His dream of being a rockstar started a mexican weave that put everbody in the best possible mood. But does being a programmer have something in common with a rocker profession? In my opinion it DOES! This was proved by all presenters who had spoke at JDD this year. Let me describe my favourites.

Comarch

NOTE: Content of this post was fully inspired by my own my JDD impression and lectures that I attended to. I am not claiming authorship of the ideas presented in the post. Each lecture description has its author linked. Having said what follows is only my own interpretation and not the actual presentations. Mind the original presentations as foundation for your own opinions and interpretation.

Refactoring your code to Java 9 modules - @rgransberger

First presentation that I attended to was about refactoring pre JDK 9 code to modules introduced in the latest Java release. Most of Java Developers probably know OSGI, which is often compared to Java modules (see this link for OSGI alliance letter issued after JDK release). There are many pros that come from using modules in your project. If you had been following the subject you are probably familiar with Jigsaw Project knowing why to use or not the use new modularity functionality. Otherwise do a quick follow-up. @rgransberger presented a simple example that explained the essence of modular components. The presentation remidend me how to organize project components to clearly distinct cross-cutting concerns from business logic.

Another wisdom that I earned from the presentation was the way of visualizing application components structure with the help of such tools like ‘Jigsaw Dependency Visualizer’ or ‘Degraph’. Previously I had been just using IntelliJ tools for class diagram visualization. Now I have 2 more tools to use in the time of need. But tell Rabea what you feel about modules after checking out her repo on github.

Chatbots - the future that starts today - @przemeck

If you are a little bit into AI and DevOps like me, you probaboly thought about connecting those two together. Imagine a world where you could talk to your ci bot for example to have the newest changes served to all environments. Well other people already have thought about it and implemented Hubot. However that kind of thinking made me interested in @przemeck talk. AS you probably realize bots are very common these days. It a nice way of resolving some of your customers needs for Call Center support. @przemeck has made his audiance amused with recipe on how to combine natural language processing services like Wit.ai and dialog composers called Chatfuel that together enable developers to implement bots integrating facebook messanger with your application’s API. As stated by the presenter beyond giving a chance to enhance your business, intelligent agents will probably lead to creation of new jobs as chatbots programmers or chatbot dialogs designers so it is a great route to take in the near future.

Pragmatic approach to writing and maintaining tests - @marekdominiak

The next long awaited presentation for me was ‘Pragmatic approach to writing and maintaining tests’ done by @marekdominiak. Based on the concept of test piramid (more info here) he explained the importance of all test kinds from UT to E2E suites. As the project expands in time tests maintenance gets harder and harder. The presentation made me thinking about a typical apporach to writing UT. At the beginning of a new project, developers, full of good intentions, promise each other to care about UT and quality of their code. Then they implement first functionality. Everything looks quite good until there are many more features on their way and the project starts to take up some momentum. Not thinking about good code structure people just add new code fragments to existing methods making first tests fail. And what to do now? Not so wise approach would be to change UT test, maybe put Mockito into play to satisfy alwazs growing dependencies. What I got from authors’s presentation is that in such case we should stop and think about how to restructure tested code in order to make it more maintainable, less complicated and satisfy requirements presented by failing tests. So from now on I would be even more carefull about a thin boundry between UT and integration tests. The golden rule is to establish a solid foundation based on simple unit tests. When a number of unit tests in relation to other tests is too big we know that something is not going the way it should.

Documentation, it is alive! - @tsskowronski

Another interesting presentation was the one done by @tsskowronski about his approach to writing and maintaining clean documentation. Long gone are the days when we have been using Microsoft Word as the only sensible word processor out there. Nowadays it is possible to write documentation in markdown and use a separate tools for rendering the actual documentation (e.g. Pandoc or Asciidoc), which is perfect for developers who wants to quickly write overall documentaion for their projects. But for someone more specific there are still plain old javadocs available at our disposal. However, in this case it is important to remember that documentation should not speak for the code. It is always better to use tools given by the language itself in order to write code that is easy to be read (e.g. avoid copying method names in the javadoc because it just simple duplication). Bellow are the pros and cons for using markdown in your project.

Pros: version control with git, easy conversion between output documents format, clear separation between content and output styles, possibility to combine it with Gitlab or Github pages or just serve as static content on http server for easy access.

Cons: writing documents in Microsoft Word is easier than doing it in markdown, there is some learning curve in case of markdown.

If somebody decides that pros presented above make it worth the effort to implemented given solution in your company, here are some interesting links from @tsskowronski to follow:

For starting with a simple readme file: Art of Readme

For documentation guidlines: Write the Docs

Quick intro to markdow: Markdown introduction

For Learning event more about markdown: Markdown tutorial

Guides for writing documentaion from Zolando: Zalando-howto-open-source

Even more readme templates: readme-template, standard-readme

Arc42 document templates in multiple formats (including markdown and asciidoc): arc42

For IntelliJ: Markdown Navigator and Markdown support

Write NOW, Run Anytime - @neilcsmith_net

I have to confess… Before the conference I thought that playing some beeping sounds in Assembler is fun but then I saw what @neilcsmith_net can do with his Praxis LIVE. This was amazing. Outstanding music performance, programming and math. Is there anything cooler then combining those 3 fields together. I do not thinks so. Now, give AMEN $ Mother Function a listen.

Organization

In terms of organization there is nothing to complain about. News about the conference progress were easy to access through Eventory application. There we could find conference agenda with all lectures descriptions. Additionaly the app provided a social stream where people could easily read what was going on at the given time, forms to fill surveys and detailed info about event including location, how to get there etc. If you had not downloaded the app I would highly recommend doing so next year.

JDD crowd

After the last year edition I had complained about venue size. This time the new location had got a boost up in the form of additional volume so there was a lot of space for everyone.

Beside that worth mentioning is a JUGmajster competition where presenters who are members of local Java Users Groups in Poland are judged by their audiance to find out who is taking JUGmajster title home. This year winner was @grzegorzdyrda with his presentation “Introduction to Kotlin” (unfortunately I did not attend his lecture).

Comarch exhibition

This year I have been able to participate in the conference because of Comarch. At our exihibition we were open to answer any questions about work at Comarch and listenning about work at other places. This was an interesting way of exchanging our experience with other conference participants. During the first day we held a Java contest to give out a voucher for a training at Comarch Training Center. There were also other gadgets to give away of which my favourite were puzzles for impatient people.

Comarch

Comarch

Comarch

Summary

At the beginning I promised to write about pros and cons of the conference. Actually I do not see any drawbacks. The conference was held in great location. The presenters had been prepared for their presentation which were interesting and useful. It was fun to hang out and talk to other developers, learning new facts about our profession. To sum up: I cannot wait till the next year edition so If you are also planning to visit Cracow then stay tuned and make sure to find me there.