Last Sunday I was bored and had absolutely nothing to do, mostly because I recently hurt my knee in an accident and while it’s healing I can’t move much. So I started to look for some fun random stuff to code, when I remembered that some time ago at work I made a simple function to compare Semantic Versions. It only worked for the more basic cases, it didn’t handle invalid leading 0’s, pre-releases and build metadata. So I thought “hey, gonna write a package that’s 100% compliant with the spec, that should be fun!”. It was!
Some years ago I read Masterminds of Programming: Conversations with the Creators of Major Programming Languages, an interesting book with interviews of the creators of some famous programming languages. It’s a great book, I definitely recommend it to anyone who wants to take a peek inside the head of the guys that created some of the things that we use everyday when coding. Anyway right now I wanna talk about a remarkably useful thing that I discovered while reading this book, the Aho-Corasick algorithm.
If you never heard of it before: automated acceptance testing is a form of testing where you describe with code what the interactions of a user with the application would be. You basically specify how the GUI should look like and behave, so that after every change in your codebase you can run this specification and check if the changes caused some sort of regression. For Web applications this automation is usually performed using a tool called Selenium WebDriver, which is a driver that provides an API for interacting with the browser through code.
A few days ago at work I decided to finally make the move and bring Continuous Delivery to our systems.
Code coverage helps a lot in assessing the reach of your unit tests, particularly in complex functions that span multiple execution flows. Despite being a great tool I haven’t used it much at work, and that’s mostly because I’m not fond of having to generate reports like this locally (in my development machine), instead I always try to automate this kind of repetitive task and integrate it in our automation server (jenkins). The problem is that for budget and legacy (mostly budget) reasons our jenkins is running in a semi-production server, which means that we can’t install xdebug on it, and you need xdebug in order to generate phpunit code coverage reports. At least that’s what I thought.
Design patterns are often over glorified (especially if you live in the Java world), but they have their merits and knowing some of them can greatly help you sometimes. For example: from times to times you will certainly have to deal with that old, dated, blasphemous, legacy code and also with those poorly designed external libraries. Sometimes you just have have to use the APIs of those problematic codebases for small periods of time; in these you can safely ignore the ugliness and later forget you ever saw that atrocious 10 parameters method. But in other times you will be forced to wallow on that code for time enough to slowly lose your soul, and worse, for some reason you could even not be allowed to refactor the damn thing. It is in that kind of sad situations where we find very appropriate use cases for two interesting Design Patterns: the Facade and the Fluent Interface.