24 Dec 2013 YOW Conference – A first-timer’s experiences
As a first-time attendee I wasn’t quite sure what to expect from YOW! 2013. Seeing the range of speakers scheduled to be part of this, and having heard some good comments from previous years’ participants, I jumped at the opportunity to be there. It feels good being surrounded by peers that share similar passions to yourself. Attending regular local meetups I’ve realized how much can be learned by simply sharing knowledge gained through experiences. It was great to see some of the folks that help organize these recurrent local events getting involved and lending a hand at larger events like YOW! Kudos to them! In this post I will discuss some of the themes and talks that were of particular interest to me.
Dealing with Legacy Code
Hadi Hariri’s talk on dealing with legacy code resonated with me. He identified a number of code smells to look for when cleaning code bases, the top three being Commented-Out Code, Doing Too Much and Repetitive Code. Commented-out code simply has no place in our code base, specially given how common the use of source control tools like Git and SVN are in this day and age. If you must, there should be a special reason so be kind enough to include that reason as part of the commented lines.
The importance of not getting caught up in the No Unit Tests -> Can’t Refactor cycle trap was also discussed. If you think not having unit tests is an excuse for not refactoring and vice-versa, think again. Sure, unit testing is more difficult when it’s unclear what the intention of a particular method is (i.e. it’s doing too much and its badly named) but there are always integration tests. Knowing that a user scenario works as expected before and after refactoring may be sufficient. In fact Hadi mentioned how he values integration tests over unit tests, a point found hard to digest by some of the audience. Whether or not they are, using them as a way to start refactoring painfully inexpressive and convoluted code is certainly helpful.
The code coverage topic also came under scrutiny during the presentation. After the majority of the audience stated that they, in some way, were in fact using code coverage as part of their development practices the follow up question of ‘How much coverage do you consider good?’ rendered a silent room. Hadi’s point was that the true value of using coverage tools is often missed: using them as the means to identify unnecessary code. As mentioned, code may be fully covered and unit-tested but if the code is simply never executed under actual user interactions, it may be unnecessary code.
There’s something gratifying about hearing someone else talk about personal pain points. You know the feeling, that “Yeah that stinks… I feel your pain” :). As developers, we’ve all had to – and will most likely continue to – deal with legacy code. This made this talk both cathartic and informative, full of anecdotes and good recommendations.
Microservices
Aided by the growth of cloud adoption, microservices architectures are becoming increasingly popular. In his session, Sam Newman went through relevant good practices, while compiling a list of useful tips when considering the use of this approach. It was a well delivered and encouraging talk on one of the ‘big topics’ nowadays.
After touching on some of the advantages of microservices (such as the ability to scale or deploy individual services within a large system upon demand and adopting or trying-out new technologies with relative ease) the talk then focused on a key point: Standardizing the gaps between services but being flexible within each individual node. This general approach enables freedom within teams to select technologies and implement services as preferred, while maintaining some level of commonality to facilitate interaction and frequent tasks.
The talk also emphasized that when adopting microservices we have to Get Much Better at Monitoring. Capturing metrics on each of the nodes and maintaining these in a central repository is a way to better deal with the increase in logged data that comes from adopting a microservices approach. Thankfully, now popular tools like logstash and kibana make it easier to deal with such large quantities of information.
Additional tips mentioned include the use of correlation IDs to track down bugs, and the importance of consistency in deployments, ie abstracting out environment details and differences between platforms on each service with the aim of providing a uniform deployment mechanism. Fabric and Capistrano are examples of tools that help with this, controlling the sporadic arise of different methods of deployment that may originate from selecting different technologies when implementing each service.
JavaScript
Boom! JavaScript – and front end development in general – finally made it to the YOW! Conference. Considering I’ve dealt with JavaScript for a good part of my time over the last few years, this track of talks was very appealing. What I heard of previous years is that YOW! did not have much of a “front-end development” focus. Whether or not that was true, this year it certainly did, with talks not only specific to the language of the web (of-course we now know that JavaScript is no longer exclusive to the web) but relevant talks on topics like web/browser performance, and other web languages.
Rob has covered Douglas Crockford’s thoughts on JavaScript in detail already so I won’t iterate over those again. Following his session though, Kyle Simpson rendered an energetic talk, also on JavaScript, but in a very different format. Coincidentally, I had come across a version of this presentation’s slides on the interwebs, but it was certainly better to hear him deliver it instead of scanning through it while commuting to work.
The presentation consisted of a set of ‘New Rules for JavaScript’ compiled by Kyle, each introduced along with a description and background or samples where required. All rules may not necessarily be new to people with experience in the language but I saw them too as a good reminder of common ‘gotchas’, useful to have at hand, of the language.
My personal favorites: ‘Stop using this until you really understand how it gets assigned’ and ‘Start using == and implicit coercion’, although I would rename this also to ‘Stop using == until you understand the difference with ===’ :). As a matter or fact, I believe these two features (dynamic this keyword and comparison operators allowing or disallowing coercion) of JavaScript should be part of any 1.0.1 courses that introduce the language. They are certainly more important and useful to understand than ‘how to change text/color in a HTML page using JQuery’.
Final thoughts
We all know that technology moves fast, and development approaches are no exception. Whilst in retrospect it may seem that progress is in a single direction and with a single purpose, looking forward it can seem more like things are expanding in different directions, with a multitude of tools, languages and approaches emerging all around.
Keeping up with all this constant change is like keeping up with music; it can be hard and at times even redundant, but it can also be enjoyable if you’re that way inclined. Besides, who listens to music if they don’t like music? Even as developers we sometimes pick what we like and we stick to it, forgetting there are alternatives and that approaches evolve constantly.
YOW! conferences are a great way to further technical and professional knowledge in areas we are already familiar with, whilst also getting exposure to advances that will be driving innovation within the industry. Altogether, it was a valuable experience – hearing talks from thought leaders on traditional problems (like how to better organize our team’s workflow and deal with legacy code), passing through current buzz-topics like Functional Programming, Microservices and JavaScript, and finally seeing some forward-thinking talks on Machine Intelligence and Live Programming and Visualization. On the whole, it was food for the brain wherever you turned.
No Comments