15 Mar 2016
| Jeremy Olliver
LoyaltyNZ open sourced our first major project Hoodoo back in December last year, and we’ve just relased our next big major installment of the Open Source technology that powers our business - Alchemy Framework.
This release is both the architecture of our API services as well as multiple software libraries for working with this architecture, and includes detailed documentation on how our micro-services are run. It includes AWS CloudFormation templates, as well as equivalent docker-compose, and Vagrant definitions too - so that readers can easily get a demo infrastructure running. Alongside the actual framework - we have open sourced Node.js and Ruby interfaces for the framework, as well as a working example http router, and a Node.js resources abstraction layer to wrap some of the boilerplate for writing services in Node.js
This site now holds an index of the major Open Source projects by LoyaltyNZ.
07 Mar 2016
| Jeremy Olliver
Recently Loyalty NZ sent some of it’s developers to RubyConf AU 2016. Loyalty NZ make heavy use of ruby in the technology that we build, and as part of developing the knowledge and careers of our staff, RubyConf is an ideal event to attend.
RubyConf AU was a fun-packed 2 day event, with a great speaker line-up. We appreciate the schedule line up this year featuring a single track the entire conference, and most presentations in 20-30 minute slots rather than a schedule we’ve seen at many events of multi-track 1 hour slots. This ensured presentations were succinct and high impact - what we at LoyaltyNZ call “crunchy”, which is one of our companies core values.
It’d be impossible to fit everything we learned into a blog post, but some of our favourite talks were:
Making Mistakes - Jeff Casimir
Jeff was the opening Keynote for the conference, and despite most of the talks being technical focussed, Jeff’s talk was a great walkthrough of some mistake’s he’s made in his career, and things he would do differently. Perhaps no suprise then, that often the biggest mistakes we make are not technical related, but interpersonal, and our failure to correctly asses situations, and other peoples motivations. As amusing as it is to hear when things go wrong, it was also refreshing to hear (contrary to a large amount of industry discussion and PR) that things do go wrong, and it can really help to talk about those times.
Building and Maintaining Large Ruby Applications - Enrico Tiotti
Any team that’s worked on the same ruby application under heavy development for more than a few years will have growth and maintenance pains to tell you about. Being in such a position ourselves, naturally we were interested in this, and particularly so when we discovered that Enrico encouraged a pattern we’ve tried before - modularizing functionality with private ruby gems.
Enrico proposes that long term maintenance can be achieved primarily with 3 main components:
- Robust Test Suite
- Private Ruby Gems (modularizing components)
- Team Diligence
We’ve often used the approach of modularizing functionality when it becomes apparent the feature in question can be astracted into a generic component, and have indeed also used private ruby gems to achieve this - the primary pain points we’ve come across when using this approach are:
- Poorly defined abstraction boundary
- Increased release friction
The increased release friction can come about when you split functionality into a separate gem, and then find that every change to that gem requires changes in the super project as well (and syncing of releases). This can be remedied somewhat with Enrico’s suggested approach of having the modular gems live inside the same source code repository as the parent project (though with their own distinct test suite).
There’s no real cure for an incorrect boundary, other than to improve our code design skills to ensure we do not fall into this trap again. This has cropped up before for us when an abstraction has been chosen named after the technology of a piece of remote code the module called, instead of the feature set it provided which led to functions relating to the technology but completely unrelated to the rest of the relevant feature using and becoming dependent on the external gem - as well as making refactoring the underlying components difficult when the namespace they belong to is suddenly irrelevant.
One Undo - Katrina Owen
Katrina has long been a fountain of knowledge when it comes to good application design, and the application of sound object oriented patterns. Her presentation on code refactoring was no exception, taking us through an entertaining refactoring session based around a program that prints the lyrics to the childrens song “I know an old lady who swallowed a fly”. You can find the source code used for the refactoring changes here discussions on code patterns are always more impactful when accompanied by actual code samples, as it’s much easier to see the benefits, and abstract concepts written out in front of you.
Diversity in Technology
It was also great to see multiple presentations discussing the topic of diversity in technology. These conversations can often be awkward - because the reality is that the entire industry has a pretty poor record on this front. Many presentations discussed this from multiple angles including job interview techniques to eliminate hiring bias, and ways to ensure our culture is inclusive of people from a wider variety of backgrounds. We aim to ensure we have a welcoming and inclusive culture built on respect, so it was good to see some focus in this area.