In life one never stop learning, if we consider all the innovations that are coming up in these years for technology, it would take the lives of a cat to follow on everything.
In this sense, technology conferences are a good way to explore new trends in the industry thanks to experts that wear the journalist hat, filtering the news by identifying the most newsworthy topics, reminding us that we are not the only ones trying to learn new things, which is very good for relieving the impostor syndrome.
The Codemotion in Milan was a highly multidisciplinary conference, so what follows is the path that I have chosen to follow, staying close to the front end but also exploring a bit areas outside of my comfort zone.
Day 1 – 25th November
Having departed the same day in the morning from Rome with my colleagues of the team, I had to necessarily skip the opening event and the first slot of 11:30, Italo is fast however it’s not a MagLev and 3h are still required. Let’s start with the agenda of day one.
Promises Are So Passé
Tim Perry speaks of asynchronous flows handling in JavaScript, which being single is not very elegant in managing the execution of code that requires data coming from network resources, a situation that is currently managed in ES5 with promise, that we can even better approximate in ES6 with generators managing the execution of functions, but that can get even better with async & await. It is a construct in the proposal stage for ES7 that would allow an even clearer and direct syntax respect to the operation that takes place because, finally, built in in the language, always using the mechanism of the promises but in a more explicit way in the specific contexts.
Let’s skate over the next
In these events there are always many participants, which means that if they all have the same goal which is located in the same place, the situation becomes chaotic fast, as it was for lunch with a queue that you wouldn’t not even at an Apple Store the day after the presentation the latest iPhone. After 1h the room of the talk that I was interested in, “The hitchhikers guide to UXing without a UXer“, was already packed, so I folded the adjoining room, where the topic was a project about a Bud Spencer & Terence Hill game, because who does not like some spaghetti western? Too bad that the speakers have dwelt too much on Kickstarter trivia rather than sharing something interesting for the public on the technical project itself, I left off after 15 minutes of cr*p.
Understanding Angular 2
Shmuela Jacobs illustrates the main features of Angular 2, highlighting the aspects of modularity with the components, the versatility of typescript that allows to compile for different platforms, and the special relationship that we must keep with the HTML of the page using only the commands made available by Angular which acts as a level of abstraction. Also interesting is the trick suggested to remember the order of parentheses to properly execute a bind [()]: banana in the box.
Coding for Accessibility
Kamilla Khabibrakhmanova talks about a topic unjustly mistreated in the daily work of most developers, that is accessibility. It’s always good to remember the reasons why a site easily accessible by people with various kinds of limitations is really best to use for everyone, with due distinction, even in situations of particular use, such as special lighting conditions or while using a single hand, or again by splitting the content into sections to facilitate focus and attention.
Few simple rules that strictly applied can make the difference, and there are various development tools to help us to verify any critical accessibility issue on a page:
Accessibility Developer Tools (Chrome)
How to make your product awesome by building a whole community around it!
Alessio Fattorini, community manager of NethServer, debunks some myths on how to build an audience of followers around a product reversing the roles, about how the product should be born from the future followers, putting at the center inclusiveness and listening, with fast and transparent answers as pillars, then turning feedback into actions, especially negative ones because that’s where opportunities lies.
Day 2 – 26th November
Last day of fire, continental breakfast with bacon sliced mushrooms eggs ricotta cheese tart juice croissant cappuccino, and let’s go.
Having stayed at the hotel near the Polytechnic’s I can attend the opening talk this time, here’s the agenda of day two.
Coding Culture
Sven Peters talks about the kind of culture that at Atlassian leads to a fertile environment for software developers, describing culture as an intangible but alive thinghy, a series of more or less spontaneous habits and actions that create the right atmosphere in which you feel emotionally secure and encouraged to engage in constructive and stimulating discussions.
The first fifteen lives of a software engineer
Nikos Zinas, in a talk entitled after a book whose plot closely resembles Madoka Magica, following a nonlinear narrative order style like Suzumiya Haruhi, traces his career and how each role has lodged a fresh start but did not necessarily connected linearly with the previous one. As time goes by one does not grow only technical skill due to sheer amount of time spent on code, but also the personality of the individual evolves along its needs, leading to finding satisfaction and benefits from roles that we wouldn’t consider attractive or vice versa for roles that we saw fit for us but ended bad due to contingent factors.
Progressive Web Apps: trick or real magic?
Maurizio Mangione talks about performances, beginning from two closely related objective bits of data, the low amount of time that a user is willing to accept for the loading of a page and the increasing average weight of web pages with all their assets that now it is around 2.5MB. Nodding to the old techniques of optimization of large sectioned images in multiple files, speaks of the difficult balance between the actual speed and the perceived speed that comes at expense of the real one, and how to optimize the critical phase of the “first impression” with caching and service workers.
Taking the example of applications in which the dynamism of the content is very important you can opt for a flow in which first you attempt contacting the server and then invalidate the local cache and update it, or alternatively to show a copy of the old data, or for cases like Twitter where you show immediately the old cached contents and then retrieve and display new content.
Gang of Four Patterns in a Functional Light
Mario Fusco from Red Hat in his live demo introduces the lambda and other new constructs of Java 8, noting that the famous book on Patterns at the time was also too much object-oriented, as many patterns have their reason for being in the strongly object oriented nature of Java, and reviewing some of the most famous ones in a functional perspective.
https://github.com/mariofusco/from-gof-to-lambda
Thirty months of microservices. Stairway to heaven or highway to hell?
Sander Hoogendoorn exhibits strengths and weaknesses of the architectures structured in microservices, that if on one hand compared to the old monoliths facilitate scalability and use of different backend languages, on the other hand moves the management complexity in the amount of repositories to maintain and the monitoring to be carried out by devOps on all the different services which in their totality allow the system to work, and the fact that between services talking to each other via JSON there are no contracts to regulate expectations between endpoints. A road still in the early stages of exploration by companies, which have historically been refractory to the big changes, but that many are approaching.
In a transition from monolithic architecture to a distributed one the road is long, following a curve which remains stable for a long time until all of the old system components are migrated into independent services, at that point you can experience all the benefits in terms of stability and maintenance of its components.
An architecture that does not make complexity magically vanish but transforms it into different shapes, theoretically more manageable because more atomic and independent, only the future will confirm or deny whether it is actually the right way.