Dip Your Toe In Open (Source) Waters

One of the qualities that TIM Group look for when filling vacancies is an interest in contributing to open source projects. We think that when a candidate gets involved in open source, it indicates a passion for software development. If you’re like me, at some point, you have wanted to join a project. Perhaps you wanted to improve your skills, try a different technology, or brighten up your CV. But alas, you didn’t know the best way to get started.

I am trying to provide that exact opportunity, in conjunction with RecWorks’ “Meet-A-Project” scheme. I have an open source project, called Mutability Detector, with issues and features waiting to be completed, specifically earmarked for newcomers to the project. I promise a helpful, friendly environment, in which to dip your toe in open (source) waters.

If you want to know more details, head over to the project blog for a description on the how and why of getting involved.

Monitorama

This is a blog post that was written in 2013, but somehow was forgotten about. So here is a bit of history!

— Andrew Parker


Last month I got the chance to attend the Monitorama conference.

This was out and out the best conference I’ve visited so far this year for learning. The conference was organised as a day of lectures by notable people in the field, followed by a day of workshops (practical ‘follow the talk on your laptop’ style sessions) on various monitoring and visualisation tools in parallel with a day of ‘Hackathon’ (working on projects).

The talks I attended covered some topics I’m already very familiar with (E.g. logstash), and some topics which I’m much less familiar with (E.g. the R workshop). The level of technical detail was generally great – not overfacing if you were a beginner, but also with something to learn if you’re a seasoned user.

In the second day, in the morning, I teamed up with Jason from TIM Group, and we were a little selfish – working on scratching our own itch. In the afternoon we broke off and attended some of the workshops, which were interesting. I was extremely surprised (and pleased!) that our project won the 3rd prize for a group project at the conference – that was unexpected given that we’d gone off and solved our own reporting issue, rather than tackling a more generic monitoring problem which would have helped a larger subset of people! We also managed to build something functional for our needs, and get it deployed into production within the 5 hours we had to work on it.

I hope that readers will forgive me if I spend a few paragraphs telling you about what we built (and why!):

We used to deploy Foreman, which we used to view / search through puppet run reports. Unfortunately, with our recent upgrade to Puppet 3.0, our Foreman installation needed upgrading too.

The version of Foreman we were running was ancient, and it’s since gained a massive number of features – however the only feature we were using from it was the report browser. This was causing us to have mysql on our monitoring machines, just to support this application, and re-packaging the latest version to our internal standards proved to be a non-trivial exercise.

We’d basically just disabled it to go ahead with the puppet 3.0 upgrade, with a plan to experiment with (try writing a proof of concept) using our logstash/Elasticsearch solution for the data transport and storage. I was able to very quickly hack up a reporting plugin for puppet, based off of some earlier work I’d found on github, and I’d been playing with the angularjs framework on the plane on the way over.

So, after about 5 hours hacking, we had bolted together Norman (excuse the bad pun).

This is, of course, still a simple and barely functional prototype; however it’s useable enough that after a couple more hours work we have unit tests (and green builds in Travis) and so that it was possible to deploy as an Elasticsearch plugin. There is still missing functionality from what we replaced in Foreman, however none of it is truely essential and we should be able to add that gradually as we have time.

Devopsdays London

This is a blog post that was written in 2013, but somehow was forgotten about. So here is a bit of history!

— Andrew Parker


Most of our Infrastructure team and a couple of developers we had seconded to the team all attended the Devopsdays London conference a couple of weeks ago.

There are a load of reviews/notes about the conference online already, however we also made a set.

I think everyone attending found the conference valuable, although for varying reasons (depending upon which sessions they had attended). Personally I found that the 2nd day was more valuable, with better talks and more interesting openspace sessions (that I attended). As I had expected (from my previous attendance at Devopsdays New York), I found the most value in networking and comparing the state of the art with what others are doing in automation / monitoring / etc.

I was very pleased that TIM Group is actually among the leading companies to have implemented devops practices. I’m well aware that what we’re doing is a long way away from perfect (as I deal with it 5 days a week), however it’s refreshing to find out that our practices are among the leaders, and that the issues we’re currently struggling with are relevant to many other people and teams.

I particularly enjoyed the discussion in the openspaces part of the conference about estimating and planning Infrastructure and Operations projects – at the time we were at the end of a large project, in which we’d tried a new planning process for the first time (and we had a number of reservations). The thoughts and ideas from the group helped us to shape our thinking about the problems we were trying to solve (both within the team, and by broadcasting progress information to the wider company).

Afterwards (in the last week) we have taken the time to step back and re-engineer our planning and estimation process. We’ve subsequently set off work on another couple of projects, with the modified planning and estimation process, and the initial feeling from the team is much more positive. Once we’ve completed the current projects and we’ve had a retrospective (and made more changes) I’ll be writing up the challenges that we’ve faced in estimating and how we’ve overcome them – as being able to deliver accurate and consistent estimates in the face of un-planned work (e.g. outages, hardware failures etc) is even more challenging than for operations projects than in an agile development organisation.

TIM Group Scala Dojo

TIM Group hosts a monthly Scala Dojo as part of the London Scala Users’ Group on Meetup (http://www.meetup.com/london-scala). The dojo is free to attend with drinks and pizza provided to the participants. The dojo always takes place on the third Thursday of the month in the TIM Group London offices.

The dojo is driven by participant in suggesting and choosing shorter programming challenges and collaboratively finding a solution in smaller groups. The atmosphere is relaxed with a focus on fun and learning. The range of scala skills range from total beginners that heard about scala to seasoned enthusiasts that work with scala. Towards the end of the meetup, the different groups present their work and discuss what they have learned.

Example of programming challenges are:

  • Secret Santa problem where the challenge is to find an algorithm for matching people giving each other gifts. No one should get left out and additionally no should be matched with their spouse.
  • finding an approximation of PI using concurrency with akka.
  • using the coursera Scala survey data to find alternatve stats such as ranking countries based on average perceived difficulty.
  • solving the Data Munging Kata from http://codekata.pragprog.com

I have taken my first steps in Scala in the dojo and found it a great learning experience. The time absolutely flies and you often end up with a great feeling of achievement by the end of the night!

The next Scala Dojo is on Thursday Jan 17th.
I hope to see you there!

Getting rid of unused code with UCDetector

Introduction

The Java code base of TIM Funds (one of our products here at TIM Group) is around seven years old and in very good shape, considering its age. (This is a highly subjective statement as I joined the company less than a year ago. I am comparing with other Java projects of similar age and size from previous work experience.)

Nevertheless, cruft inevitably builds up over the years, so constant effort is needed to keep it down to a minimum. To accommodate this, we follow the boy scout rule while developing new features – trying to check-in code that is a little cleaner than when you found it. Furthermore, we have made room for a separate ongoing track of work named Sustainability, which is intended for concentrated efforts on removing problems that we have spotted in the current code or keeping our automated tests fast and flicker-free.

A couple of weeks ago, I was working on the Sustainability track, trying to refactor CollectionUtils, an old custom utility class with lots of public static methods that we’d like to remove. While doing this, I noticed that many methods had become completely unused over time, probably because developers had replaced their calls by using Guava, our collection library of choice. I found myself repeatedly pressing Ctrl-Shift-G (the Eclipse shortcut for finding references) to be able to see what can be safely deleted. After a short while I got tired of this and assumed that somebody must already have had the same problem. As usual, Stackoverflow knew the answer – several posts around this topic mentioned UCDetector, an Eclipse plugin which detects unnecessary public Java code. It looked like what I needed, so I gave it a try.

Configuration of UCDetector

My first impressions after installing UCDetector were mixed – although I only ran it on a package structure only containing around 50 classes, it was quite slow and produced an overwhelming amount of warnings with many false positives. (For example, code only called via means of reflection cannot be detected reliably.) The default settings of the plugin are quite lenient. They try to find many possible problems at once, but this way you can’t see the wood for the trees.

Fortunately, the plugin can be configured in many ways. It is worth spending some time finding appropriate settings for your project (in Window→Preferences→UCDetector). The suggestions below should get you started:

  • Ignore all warnings for possible use of final and visibility (tab Keywords). Your mileage may vary, but this increased the number of warnings considerably and gave some false positives for me – I consider this to be a slightly different aspect of cleanup and would rather do it separately.
  • Ignore code with annotation Override (tab Ignore, section Marked code). This is a compromise that might result in some truly unused code not being detected. You may want to try leaving this out, but I got a lot of false positives when detecting code only called by tests without it. For example, we implement Guava’s Function interface quite a lot and only call its apply method directly from tests.
    • If using Guice, add Inject to the list of ignored annotations (these members are called by the Guice injector).
    • If using Jersey, add GET, Path, etc. to the list of ignored annotations (these methods are called reflectively by Jersey)
    • Same goes for other annotation based third-party libraries.
  • Refine the settings by scanning some packages, examining the warnings, deleting some code and running your tests – you may find more incorrect warnings and need to extend the configuration.
    • For example, I had to ignore all classes extending our custom class PersistableEnumeration (tab Ignore, section Classes), because methods of sub-classes will be called reflectively via Hibernate mappings.

After these initial adjustments had been made, UCDetector worked really well for me. The scanning process finished significantly faster and the number of false positives was greatly reduced. I found UCDetector’s feature to warn about code only called by tests especially useful, because these cases are even easier to overlook when checking manually. Two short usage recommendations:

  • For bigger projects, prefer scanning package by package, not everything at once. This way, you get faster feedback and can concentrate on one area of the code (different packages might even need different settings). It is a good idea to keep the check-ins small anyway – I broke the build once or twice when starting out…
  • After removing some code, scan the same package again because more code might have become unused (domino effect).

Findings

My personal “kill count” after two or three hours spent with deleting code (spread across two weeks, using the very restrictive configuration mentioned above, and only covering under 50% of the code base): over 40 complete files (classes/interfaces), over 60 public methods, and even one database table (the corresponding Hibernate entity implemented an interface whose methods were all unused).

Although the number of deleted files was surprisingly high for me, I still stand by my statement that the code base is in good shape for its age. So how come there is so much unused stuff anyway? Looking at the source control history for the findings, it seems there are three main scenarios that are likely to leave unused code around:

  • Removal of functionality: Like everywhere else, requirements for TIM Funds change over time. Some features become obsolete and need to be removed. It is easy to forget or overlook to delete some service that was only used by the obsolete feature, because you don’t get any warnings from Java or the IDE itself. The one unused database table belongs in this category.
  • Bigger refactorings: So far, I have had most “success” deleting code within our file import component. This is an area of the code that people were never completely happy with and different people had different opinions about. Consequently, several attempts to improve the code were started. Now there is a “new way of doing it”, but several “old ways of doing it” were still lying around. This was true on a smaller scale in other areas as well.
  • Introduction of new libraries/frameworks: After we introduced Guava and started replacing calls to CollectionUtils, these methods gradually became unused. Another case is replacing the functionality of a third party library (Apache Commons) with a different one (Guava), likely making the JAR unused in time. We still have to tackle this particular task for our code base. Other tools like Classpath Helper are needed to fully help us here.

In hindsight, all this might sound rather obvious, but it’s worthwhile keeping these three scenarios above in mind. They provide good opportunities to start up UCDetector and delete some unused code, which is always useful, often quite educational, and sometimes even fun.

FOSDEM 2012

Last weekend I attended FOSDEM, “the biggest free and non-commercial event organized by and for the community”. The Free and Open-Source Software Developers Meeting, held in Brussels, pulls in roughly 4000 FOSS hackers from around the world. I was one of the speakers on the schedule in the Free Java Dev Room, introducing my open source project, Mutability Detector. The lineup was pretty illustrious, including Charles Nutter, co-lead of JRuby, and Mark Reinhold, the Chief Architect of Java Development at Oracle. Here I’ll describe some of my experiences at FOSDEM, and relay some of the interesting stuff people presented. (Apologies if I misremember anything – there was a lot going on at the conference!)

Lost in Translation

First off, let this be a warning to any potential FOSDEM-goers. ULB, the University that hosts the event, has two campuses. Campus Solbosch, where the entirety of FOSDEM happens, and about 11km from that, way over on the other side of the city, Campus Erasmus, where I went. Top tip: when planning international trips to foreign countries that you’ve never visited before, don’t rely on Google Maps.

After a 1hr 30min commute, with the help of a few fellow location-impaired, and thankfully French-and-English-speaking FOSDEM attendees, I finally made it to Campus Solbosch. Unfortunately that meant missing the welcome keynote, the introduction to the Free Java Dev Room, and talks about the OpenJDK from Mark Reinhold and Dalibor Topic. Massive facepalm. Hugely embarrassing. Mothers, don’t let your children grow up to be… someone who goes to the wrong ULB campus for FOSDEM.

Lambdas and Traits and Bears, Oh My

The first talk I saw was by Jeroen Frijters, demonstrating the work he’s been doing to bring JSR292 (Invoke Dynamic) to IKVM.NET, the virtual machine that runs Java on the CLR. Next up came Remi Forax to discuss lambdas in Java. Following a clear disclaimer that design choices and syntax he discussed was still in the air, and subject to change, he showed off an expected feature for the Java language. Named “Virtual Extension Methods”, they allow adding methods to interfaces… with implementations. The motivation being that, along with lambdas, you could put a method like Iterable<T> filter(Predicate<T> predicate) onto, say, java.lang.Iterable, with an implementation, without causing compiler errors in everyone’s code. There was a bit of a collective gasp when some people in the audience assumed this meant multiple inheritance was coming to Java. However, the subtle but crucial point is that with a virtual extension method, it’s not possible to reference state, such as fields. The body of a virtual extension method must rely on the concrete implementations to supply state, with the developer resolving conflicts from inherited methods in the concrete implementation at compile time. That leaves the feature looking a lot more like traits (awesome) than C++ style multiple inheritance with the diamond problem (not awesome).

Following Remi were Raoul Gabriel Urma and Janina Voigt, two PhD students from Cambridge, who used the OpenJDK to explore the use of covariant arrays in the wild. Taking a look at lots of open-source projects, and using the novel approach of modifying the javac compiler to find the code they were interested in, they found that covariance is rarely required, and normal Java generics is usually enough to add type safety to methods employing covariance. I really liked the empirical approach taken to a language theory question, and love the idea they had of setting up some kind of open-source corpus, where those doing similar surveys could quickly get their hands on a huge amount of real-world code.

Community Is Not Just A TV Show

Then came Ben Evans and Martijn Verburg, giving a talk entitled “Politics, Positives, Paperwork and Pain: Our year to date in the JCP”. Ben and Martijn are the leaders of the London Java user group, the London Java Community (LJC), which, in the past year, has won a voting seat on the JCP (Java Community Process). They discussed some of their experiences, from the bad:

– the acronym soup that appear in most every conversation (JCP, JSR, JSPA, TCK, RI… TLA ETC – okay those last two aren’t real)
– phone conference calls with lawyers representing some of the companies involved in the JCP, discussing in minute detail whether to change “notwithstanding” to “nevertheless” in clause 27(g)
– no-show members of the JCP who only participate in discussions after decisions they don’t like have already been made

But they did have a lot of positives to recount:

– completion of the first of several reforms to the JSR (Java Specification Request) process which will make it more open and inclusive, and hopefully “prevent another EJB 2”
– the (surprising) willingness and motivation of several of the bigger JCP members to move towards being more open
– significant takeup of the LJC-led “Adopt a JSR” appeal, which gets everyday developers involved in particular JSRs, from development to evangelism (I myself am signed up to take part in JSR 353 – API for JSON Processing, as we have been building a JSON-based API for one of our products recently)
– drumming up lots of interest in contributing to the OpenJDK from LJC developers, which included a couple of ‘Warnings Cleanup’ hack sessions, where a bunch of hackers dived into the OpenJDK code to pick some low hanging fruit, fix the code, and submit patches. This is slowly pushing the OpenJDK project to make building, modifying and contributing much easier. One such event was hosted here at TIM Group, with all available spaces being taken about an hour after announcing it on meetup.com.

Overall Ben and Martijn are optimistic about the future of the OpenJDK as a community.

Open Sesame

For the rest of the afternoon, we were introduced to several open-source tools: Thermostat for monitoring performance of your Java application; GCSpy for inspecting and visualising garbage collection (here was the first time I heard the humorous quote “If Java had true garbage collection, most programs would delete themselves upon execution.” — Robert Sewell); Byteman which allows you to inject bytecode into classes at runtime, and a DSL to allow you to talk about bytecode at a higher level of abstraction; and CacioWeb, which can let you run a Swing app inside your browser, which struck me as weird thing to want to do, but it had some pretty interesting use cases (e.g. rather than people using VNC to access their own Swing app running in their own JVM, the app can be hosted by a single JVM for multiple users). Steve O’ Grady argued, with some metrics and empirical counts, that Java the language is still not dead, and it’s not only about the JVM either.

The audience were also given the fine treat of listening to me harp on about they should design their classes to be immutable, and how they should totally use Mutability Detector to keep them that way, the lucky devils. It’s not every day you get to hear me crack some lame jokes about how XML sucks (my colleagues, on the other hand…). Some good ideas and suggestions came out of the Q&A after my talk, and I also got a lot of positive feedback (like Mark Reinhold tweeting “@grundlefleck’s Java immutability detector is really cool” — after which I almost audibly squee‘d). Overall Mutability Detector was received well, and I’m really glad I applied to present.

Absinthe Makes The Heart Grow Fonder

Once Saturday’s talks were finished, I was invited to dinner with other speakers and sponsors of the Free Java Dev Room in a restaurant just off Brussel’s Grand Place. Lots of interesting code talk, nice food, and Belgian beer. Having spent a lot of Saturday suffering from Friday night’s excesses at FOSDEMs Free Beer event at a local bar named Delerium, I didn’t fancy a repeat on Sunday. So I ducked out early-ish, before Raoul, the PhD student and Belgian native, could convince me to visit a nearby absinthe bar. Judging by the ‘tender’ disposition of some of the folks on Sunday morning, it appeared to be one of the more sensible choices I made over the weekend.

Fast Ruby and ARMed Java

The first Sunday talk I attended was Charles Nutter discussing JRuby and some of the achievements they’ve made with the project. I was surprised to hear that JRuby on the JVM was (for most things) the fastest implementation of Ruby around, even including native implementations. Then came a talk on how the Eclipse project works. It was interesting to see just how big an ecosystem and community it is, and they managed to ship, on time, on the same date for the past six years. The speaker, Mike Milinkovich, emphasized the importance of predictable releases, and how the Eclipse project has and will drop features to make the scheduled release date. We then heard from Andrew Haley of RedHat, the work he’d been doing to port OpenJDK to ARM processors, and someone from the audience showed an Eclipse installation which was built, and currently running, on an ARM processor machine, which was impressive.

The next talk which (I am told) was excellent, was on a music-based Java project named Gervill. It included a musical representation of a Java program, using the Byteman project demonstrated the previous day, where every call to list.add(), was translated into a note, where the index argument became a position on the scale. I say I was told it was excellent, because I’d actually ducked out of this talk, and into one of FOSDEM’s Hack Rooms, where I introduced Martijn Verburg to the internal workings of Mutability Detector, which lead to the first bit of activity (“frsit psot”, and a patch!) on my project’s mailing list.

The day concluded with talks about IcedRobot (an Android implementation for the desktop), IcedTea and IcedTea-Web (RedHat’s repackaging of Oracle’s OpenJDK sans proprietary parts), and then a free-form discussion on Java, with the likes of Mark Reinhold, Dalibor Topic, Georges Raab (the VP of Software Development, Java Platform Group at Oracle) answering questions and discussing community issues in and around the OpenJDK project. It’s great to see this kind of discussion take place, and it’s somehow always astonishing to me to hear just how many people and projects depend on Java, and how much effort goes into releases, distribution and upgrades. I’m so glad that in my day job here at TIM Group, we generally only work in two week release cycles, developing a hosted web application — some of our problems can seem slightly trivial in comparison!

And thus ended the scheduled talks at FOSDEM. I capped off the weekend enjoying a few beers and dinner with a few of the speakers from the Free Java Dev Room.

Belgium, man! Belgium!

Overall, despite the calamitous beginning of the weekend, attending FOSDEM was a hugely rewarding experience. The speaker line-up for the Java room was impressive, and it looked to be the same for the other tracks and dev rooms, with well known names in the open-source world. The conference also gave me the chance to meet and personally thank Koshuke Kawaguchi for his and the rest of the project’s efforts on the Jenkins CI system that is used heavily at TIM Group. There was a very friendly vibe around the place, and what the organizers accomplish, without ever charging a penny for tickets, is astonishing.

So in summary, if you can make it to FOSDEM (and it definitely helps if you work for a company like TIM Group, that lets you take the time to go, and puts up the cash for travel and accommodation), you definitely should… but you should go to the correct campus.

More Thought-Provoking Lightning Talks

Five minutes per person. Every Thursday. From the practical to the theoretical, we manage to cover everything at TIM Group lightning talks. A sampling below.

Dominic on Categories and Time

Categories and Time from youdevisetech on Vimeo.

Tony on Levels of Team Maturity

Levels of Team Maturity from youdevisetech on Vimeo. Based on ideas from a course by Roy Osherove.

Joe on Continuous Integration at LMAX

Continuous Integration at Lmax from youdevisetech on Vimeo. Learn more from the LMAX blog.

Bring The Outside In at TIMGroup

Communication is a core principle of agile methodologies. It’s important for teams to disseminate information well to keep every individual in the team working effectively, and what’s true for the teams is also true for companies. As part of our dedication to learning and growing the best developers at TIMGroup, we actively seek to communicate outside of our own company with other individuals and organizations with whom we hope to exchange ideas. We’ve recently had speakers from Mozilla and Reevoo. We also do developer exchanges as another way to get some of the best ideas from outside of our company, into our company – in a developer exchange, one of us visits you for a day and works with your team, and then one of you returns the favour on another day.

So if you think you could do with a fresh infusion of ideas, and you don’t mind sharing yours, why not get in touch with us here at TIMGroup? We probably have something we can learn from each other.