After missing out last year I made it back to the UK incarnation of Devoxx. For all of you who are not yet aware what Devoxx is: Low cost conferences, lots of talks, quite a lot of good speakers and all centered around developers. Main focus is still Java and Java based technologies but other technologies are on the uprising :-)
Day 1
Welcome to Devoxx Uk - Holly Cummins, Mark Hazel
The opening keynote was of course held by Mark Hazel himself and Holly Cummins, one of the program leads of this year. Mark goes over the usual but still important topics:
- What is Devoxx?
- Why do they do it?
- What kind of talks will be held? (Special mentioning of the Ignite talks in the evening, 5 mins 20 slides and GO!)
- The Buddy program
- and of course Devroxx the Thursday evening event with Devoxx beer!
- All videos being uploaded to Youtube
Holly focused on what she like about conferences and why she considers them important. Conferences allow to look beyond your usual scope, to interact with others and hear about new technologies. Even if those things happen in a completely different field you can adapt some of the techniques for your own work.
She drew an interesting analogy to book from the 17th century, "The Compleat Angler". A book telling people how to become a better fisher, which is the second most printed book in the English language (tells you something about the English, uh?). It taught people important virtues like patience and composure. And likewise all those things we here about at conferences can help us to become better, more well rounded as developers by not only focusing at the actual development skills but on us as a whole.
A good starting talk with the right mix of information and philosophical depth.
Java 2018: Change is the only Constant - Mark Reinhold
Being the JDK chief architect Mark has a lot of insights to give on the current and past state of the JDK as well as future plans.
Since the ecosystems around Java (node, go, swift.. ) are evolving with an impressive velocity Java has to adopt in order to keep up with this change and remain competitive.
The first step into this direction was to refactor the JDK to allow faster and more flexible development in the future. To achieve this a lot of untangling had to be done. Make sure you at least check the slides in the video to get an impression how bad it really was *shudder*.
Now the JDK is scheduled for releases every 6 months and having an LTS release every 2 years. This is a significant improvement compared to the past. I am looking forward to see how this works out.
Another interesting aspect is that Oracle made several commercial tools available as open source and also provides JDKs licensed under GPL available.
For me this looks like Java will still be going strong for a long time and it will be interesting to see how those innovations will be received by the developer community.
A Future without Servers - Danilo Poccia
In Danilo's talk we got s short overview of the history of development. Starting with Ada LoveLace over monolithic application and micro services to lambdas and serverless architectures.
In the future Danilo envisions for us developers we can all focus solely on our business logic. All platform maintenance, logging, monitoring but also stuff like validating input is done for us by the infrastructure.
The Mindful Developer: The Neuroscience of Stress Management - Matthew Renze
In my opinion this qualifies as a brave talk. Being a an IT consultant, which is a profession in which you definitely have to deal with a lot of stressful situations, and admitting that you suffer from stress related impairments could have negative consequences for you.
It is great that Matthew has the courage to speak about his experiences and how he learned to deal with them. The main technique he focused on in the talk was meditation. How it helped him but also how research underpins his subjective experiences. He even took it as far as to document his own vital signs over an extended period of time to make his progress visible.
Stress related conditions are a real threat to every one in modern society and have to be taken serious. Even though it takes courage to openly talk about it if you are the one affected.
Are you ready for Cloud-Native Java? - Graham Charters, Steve Poole
A classic two fold talk. Steve starts by talking about how moving to the cloud shifts the requirements and measurements applied to software engineering.
The main point is, once you are on platform where you only pay what you need, those needs are directly coupled to the costs. So controlling will be asking more questions about why e.g. cpu has to be increased.
Also the behavior of your application has more direct impact on it's cost. When you scale up and the new node needs a long time to be fully up and serving it creates back pressure which then results in higher starting load. And depending on your payment plan that might take you into a very costly billing range.
Focusing on these questions Steve gives a comparison of different JDK versions hosted at adoptopenjdk, like Hotspot or OpenJ9 and how those perform during scale up periods.
The second part, covered by Graham, was more or less an exhaustive introduction and demo of the eclipse microprofile project. The goal of this project is to allow developers to have enterprise features for their applications but with the least possible overhead by choosing only those components that you actually want. So if you live on the enterprise world, this is certainly worth a look.
Exploring Space: Challenges, Innovation, Management: Lessons For All - Mark Sims
Oh boy, oh boy. Space ships! Rockets!!! Awweeeesooooommmee! Man was I looking forward to this, someone who really built a space craft and launched it, telling us about who cool but also how difficult that is etc.
I am really trying not to be mean here, but somehow I have to break it to you. That was the downer of the conference. Don't get me wrong, space is still ace and yes we heard about a lot of the things that are hard and unexpected difficulties. But the talk itself was actually one of the worst I have heard on a conference. It was the typical old school university lecture held by someone who's sole interest is research. Slides cramped with bullet points, hard to read fluently. And Prof. Sims gave the impression of being rather annoyed having to give a talk, everything was more or less just read from the slides with almost no distinction between important and minor aspects.
Here is what I could take from this talk before my brain kicked into tilt mode:
There are a lot of challenges for your hardware, different levels of gravity, high amount of different radiation, huge ranges of temperature levels, massive shocks and vibrations on starting and landing.
You have to run tests, a lot of them, very very often. You definitely have to make sure your system works. You have to try to think about every possible corner case. The software needs to be redundant, built on different systems, maybe by different teams so that one error cannot crash both systems. The system has to reduce resource usage to a minimum as those are always low in space. And most importantly the system has to be flexible and adaptable. I was very impressed that the team was able to patch the software from earth while the mission was already underway.
I am sorry if I am doing injustice to Prof. Sims, but imo there was so much more that could have been done with this topic to motivate and inspire people.
Springing into Kotlin: How To Make The Magic Even More Magical - Mark Heckler
Spring AND Kotlin two really fancy things combined in one talk? Bring on the magic!!
Good, solid talk by Mark, definitely knows his stuff. But for me there was nothing new to take away actually, apart from that Spring 5 now supports Kotlin. Mark showed the basics of Spring Boot and the basics of Kotlin and how to use Spring Boot in a Kotlin application by migrating a mini app from Java to Kotlin.
I was hoping for some more in depth stuff, something the every day developer usually does not think of to leverage the powers of two powerful tools like those we have at hand here.
For those who do not know much about any of the two technologies that talk is absolutely worth a look. If, like me ,you know how to work with Spring and have at least done some basic Kotlin coding, this is probably a bit boring.
Spring Framework 5: Feature Highlights & Hidden Gems - Jürgen Höller
Ooookay, more Spring. This time by Mr. Spring Jürgen Höller himself.
Again solid talk, good to follow. Basic things I took away from this one:
- Kotlin support (hear hear ;-))
- Webflux: Reactive alternative to the standard mvc module
- Functional Web Endpoints: Instead annotations you can define routing/request mappings in a functional programming style. I don't really see why yet tbh, but there are probably people out there that go nuts about this. So if you are one of them, let me know why this is great :-)
- Can now also handle immutable classes
- Usage of NIO2
- Build-time components indexer and annotation processor: Now this got me drooling. Find errors in your bean annotations at compile time and speedup the application start as the scanning has already been done during the compile. ACE!!!
Conways Law and Microservices: A perfect match, or not? - Andy Hedges and Adrian Spender
Andy and Adrian have been working at the transformation of Tesco's software department for the last 8/5 years. In this talk they explained what steps they had to take on this long and rocky road and what their challenges and insights were.
In the beginning Tesco's software development process was the typical old school waterfall model: Conception -> Design -> Architecture -> Implementation -> Deployment
As usual the process was slow, heavy weight and had very limited flexibility. Likewise the system architecture was a big mash up with little cohesion and lots and lots of fine grained dependencies between almost all components.
The first hard task was to actually define what should be a cohesive unit, so what methods should go into a service. This did reveal some interesting and unexpected aspects. E.g. one assumption was that when ever you handle a product you also always need the product's price. But there are use cases in which a product may already be designed and is already promoted but has no price yet. So taking this into account you can defined different, smaller and maybe better service boundaries.
Another good example was how an application can contact a customer. There is a contacts service that hold e.g. an email address of a customer. There is als an email service that you can use to send an email. Now you could create an application that uses the contact service to retrieve the email and then use the email service to actually send the email to the given address. OR you could structure your services in a way that you can simply tell the contacts service to send a message to a certain customer. Then the contacts service could even use the contacts preferred messaging method (email, sms, whatsapp..).
Along with the services you also have to structure your development teams. So you have different teams maintaining the services, in Tesco's case grouped by common domains, like "customer" or "warehousing". Now all those teams are dealing with tasks that are needed in a common way across all services. So there are some guidelines all teams have to follow:
- Logs: All services/applications have to use the same log format
- Tracing Id: All services have to retain the tracing id for a transaction
- ...
Now this did sort out the regular development issues for most cases. But sometimes a project comes up that requires expertise from different departments. After trying a few approaches they ended up with a concept the call "Pop-Up Teams", which means that for such a project they are pulling members from each affected team to form a new temporary team that then takes care of the project.
All of this was of course explained in much more detail, so I recommend you check out the video, as I really enjoyed the talk. But before you do so, it might help to brush up on Conway's Law and Dunbar's Number even though both are explained in a few words.
The last thing I want to mention though are so called "Run Teams". As stated above teams are grouped in a common domain. So all have roughly similar knowledge and build similar services. Apart from that, the teams are also responsible for running them. To allow for more flexibility and knowledge transfer they came up with Run Teams. Each domain has it's own Run Team that consists of members from each team. On a regular schedule those team members are swapped back into their Home Teams and replace by other colleagues from that team. So every few weeks everyone takes care of running all services of the domain. I think this is great idea to make sure teams are still connected to each other and knowledge is shared among them. But like everything in this talk, this is was works for Tesco and you should look carefully if it really fits for you as well before adopting it.
Security In The Serverless World - Yan Cui
Most of this talk actually revolved around webapp security in general. Especially the well known OWASP list was mentioned a few times. TBH that is something I would assume everyone should know before focusing on security for Serverless applications, so I am skipping the summary here.
One big advantage when running Serverless but also in general in the Cloud is, that you do not have to patch your hardware. That is done by the service provider (e.g. AWS). So one less thing to worry about. But the software itself is still your problem. Here OWASP comes into play again and also the general advice that security vulnerabilities often lie within your dependencies and so you should update them regularly.
To illustrate this Yan showed the results of an experiment he ran. He created a malicious node module called "do-not-download-me" which got downloaded 200+ times in one month. With that he was in theory able to collect data from depending applications. Of course he did not do that in the end, but it shows how easy it is to inject dangerous code into the eco system.
Since functions/lambdas/services in the Cloud are basically accessible by anyone, you have to make sure your endpoints are secured, the privileges of each function are as restrictive as possible and transport between your functions and the client is secured. For most of these topics Yan provided examples on how to achieve them on AWS.
Something that many are not aware, providers might reuse container instances, so it is a bad idea to store sensitive data e.g. in /tmp of your EC2 instance as that might be accessible by some other application later on.
Another interesting fact that is actually obvious but you do not always think about it: When your Cloud services are attacked with a DDoS attack then the stability of your application is not your only concern. You also have to realize that each attack has direct effect on your budget, so you might be forced to take the service offline to avoid losing a lot more money than you already are.
Ignites
At my last Devoxx the Ignite talks were rather regular talks but only 5 minutes long to spark interest, pitch an idea or generate attention for something. This year this was quite different. One talk was actually prepared in the usual way, which I will cover in a minute. The others were basically impro stand ups as the speakers did not know what slides they had to present and the slides seemed to have been generated pretty randomly ;-) There were a few laughs in it but I am not totally convinced tbh, others though had a brilliant time and were laughing and giggling almost constantly.
Zero Bugs - James McGivern
Basically Zero Bugs means, either fix a bug right away, close it or declare it (or rather the fix of the bug) a feature to put in the backlog. The reasoning is that otherwise bugs just sit in your backlog and will not be fixed. In my experience this might be true in some cases, but not as often as the speaker claims. Of course this might be different in other places but so far I am not entirely sold to this idea.
Day 2
To JAR Hell And Back: A Live Migration To Java 11 - Nicolai Parlog
We have heard about JDK 9+ and the module system quite a bit on the day before, so the basics covered here were not too shocking. But it was a nice summary on why the module system was introduced, what the benefits are (encapsulation, dependencies known to the JVM...)
The main part was the actual live coding to see what kind of code might/will break if you move towards JDK9 or higher. I really recommend you check out the video as it does not make sense to describe this here.
The talk was great and a really good start in day 2.
Two things stuck in my mind though, first of the hint that you can create a maven profile that activate based on the JDK version used, which is really neat as you can just switch your java environment to toggle from between upgrade tests and regular development.
The other is the usage of jdeps to find dependencies of your jar modules, with the --summary flag you only get the dependent jar files and not all packages. That looks like a really helpful tool.
Stop reinventing the wheel with Istio - Mete Atamel
From the title it was clear that this would be a product demo, which is totally fine. Long story short, Istio sits on top of tools like kubernetes or mesos to help with stuff like service discovery, logging etc.
In this demo Mete was using Kubernetes as underlying container management tool. I also recommend you watch the video if you want to know about the details. The basic architecture looks like this: Istios uses Ingress as an API gateway to route to the different pods. In each pod is a proxy module as side car deployment that handles all incoming requests and takes care of load balancing etc.
Everything was done on then command line, first you install Istios on your system and then you add certain commands to your scripts so that the pods get enhanced with the side car proxy.
On a first glance it seemed a bit clunky compared to Rancher or Open Shift, but I don't have any hands on experience with any tool so could be wrong there.
Is Boilerplate Code Really So Bad - Trisha Gee
I must admit it, I am a fan. When ever Trisha holds a talk at conference I attend I go there. She could probably even make stamp collecting sound fascinating. So yes, I am biased but I encourage everyone to watch her talks.
Ok, back to business. The title of this talk was particularly interesting for me, as I am one of those developers who is not really bothered by boilerplate. In some cases I even consider it useful to have a more verbose code if it is more understandable then. So my hope was that Trisha would tell off all those who whine about every additional character in their code.
Weeell.. that was not totally the case ;-) Instead we saw a syntax comparison between different Java version up to Java 10 and also Kotlin. Trisha used several example, including collection instantiation, object construction and Generics.
In one case she even demonstrated how something that looked like a mere reduction of boilerplate in Kotlin was indeed a change of behavior (lazy eval of lists).
The summary about boilerplate was something like this: Reduction of boilerplate can improve readability of your code, unless you lose meaningful information or even introduce behavioral change. Both should be avoided. Writing boilerplate should not be an issue, as your IDE should take care of most of that. Not everyone has the same understanding of readability, so make sure your team is on the same page of that, if possible. And Java is not as bad as it used to be, for short tests you can even use the Java repl in JDK 10 (seems cool btw).
And if the video is not enough or you just do not like watching videos, you can check out Trisha's blog.
Avoid Noodling Through an Architecture's Foundations - Francisco Menezes
I don't know what to say here, really. I must have gotten it all wrong, because I just can't understand it.
In general this talk was about the architecture used at Francisco's company. Basically it was about proper encapsulation, lose coupling and other well known things you should consider when creating your service landscape.
One thing that I just can't get my head around is the concept of each module/domain/service/what ever you cal it to not only expose a service API but also a so called query model. From what I understood the idea is that other services can access the data of a service via the query model without having to have a dependency on the service API. But somehow you also have to expose that query model and then there is a dependency on that query model. Maybe you can abstract that model so far that for every domain it offers the same operations. But then I still don't see why you can't just add that to the service API. Maybe someone can explain that to me? Gotta watch the talk again, I guess...
Automated testing on steroids: Trick for managing test data using Docker snapshots - Lucas Jellema
Okay, time for a lunch quickie (15 minute talks during the lunch break). At first I thought this talk was going nowhere but then Lucas started the live demo. Using dockerode to programmatically start and stop containers is nice, but you can do that with many tools. What was really cool though was the leverage of the criu linux package that allows you to create a snapshot of your running machine, including RAM.
Docker supports creating those snapshots and then even restarting a container from such a snapshot. That means you could create a test database even in memory in your container, create the snapshot and then run every test against a fresh container instance created from that snapshot. The startup was almost instantly. Looks like a promising approach. Really cool! :-)
Apps are Making Us Dumber - Heather Wilde
The hardest thing about building good mobile apps is the design. If your design is too cumbersome or clunky then people will not use it, no matter how good it actually is.
In this talk Heather gave a great overview of the core design principles we should consider when building apps. I will try to sum them up briefly but I suggest you refer back to the video for a complete impression.
A good app needs easy user interactions, like the Tinder Swipe, something that is intuitive and easy to use. The layout needs to be clear, without clutter. Clear and readable fonts, pretty is not always easy to read. Colors should give good contracts.
Also very important: The app needs to be responsive, react fast to user interaction, if you need to do expensive operations use busy indicators. Try to preload data when possible, priorities requests on server side properly.
The most common tasks of the app should be the easiest to do. Rare tasks can require more clicks. Don't implement feature noone will use. Be consistent in your design, e.g. use the same icons for the same actions.
Remember that your users do not know the app like you do, always try to imagine how it feels to open the app for the first time.
There was of coure much more and it was also explained in a much better way ;-)
Keine Kommentare:
Kommentar veröffentlichen