Who better to tell their engineering stories than them? So…

What does engineering mean to you?

Engineering to me means building a solution to serve a purpose

Jo Amarlapudi, Mobile QA Engineer

What I love in engineering is the intellectual challenge it poses to me and the opportunity to be creative and solve problems that can impact people in real life.

Marta Ludovico, Agile Developer

Being empowered to help create something valuable every day

Karen Parish, Agile Business Analyst

Engineering = curiosity. It is the way you see the world. The need to figure out what’s hidden behind each and every object, how it works and noticing how awesome it is

Aleksandra Koloczek, Platform Operations Engineer

Problem solving, building things our users love and learning new things every day

Natalie Akam, Agile UI Developer

Solving new challenges with creativity and passion…and working my butt off to understand my job!

Xuan-Thi Nguyen, Software Engineer

Being an artisan or “craftwoman” of our times, as people in the iron age used to make beautiful and useful tools with iron, we now make beautiful and useful things with code.

Teresa Jimenez Arreola, Agile Mobile Developer Android

What being an engineer means to me? It puts my creativity and imagination at the world’s service by evolving and improving people’s lives through technology

Nisha Chaganlal, Agile Developer

To be an engineer is to join a culture dedicated to being open-minded, creative and wanting to continuously learn and adapt.

Laura Willis, IT Support Engineer

To me, it’s looking for efficient solutions to any kind of problem you face in your day.

Marion Mère, Software Engineer

Promote diversity, show that amazing things can happen when we are involved in this “majority male” domain.

Audrey Sobgou, iOS Engineer

Trainline celebrates International Women in Engineering Day was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve been growing at an incredible rate here at Trainline. While it’s been amazing to see the constant stream of fresh, enthusiastic faces, it’s really put our engineering practices — and culture — through its paces.

However, complete autonomy that is easy to manage in small, nimble teams becomes unmanageable across hundreds of hard-working, creative engineers.

Culture first

Once you get past a certain organisational size (normally 50–150) — you really start to feel these “growing pains”, so it’s important to build a strong culture.

Notice the key word there — “build”.

It’s easy to propose a culture, socialising how you want people to “feel free” and “innovate”. But, when it comes down to sacrificing time, money, energy or “all of the above” to make it work — it starts to lose the fight and becomes nothing but a “good idea”.

Good culture is hard. Like anything worth having — it takes real commitment, energy and enthusiasm to make it work.

However, the payoff is worth it — you end up with an army of incredible people, who become far more than the sum of their parts. The organisation takes on a life of its own, life (and business) is good.

Introducing “Build.Better Days”

“Build.Better Days” (or BBD) are one of a series of initiatives that we’ve deployed to help us cultivate a great culture here at the big @TrainlineTeam.

Simply, these are a fortnightly “mini, internal hackathon”. They are a key component of — and our commitment to — “aligned autonomy”.

“Aligned autonomy”?

If there was a bar where great engineering companies hang out — Spotify is certainly one Trainline would like to grab a beer with. We’ve been inspired by much of their work — especially the principle of “aligned autonomy”.

In a nutshell — it could be described as “focused freedom”.

It’s obvious that complete freedom (“yes, trains — BUT — we could build a robot to train my cat army because YOLO”) is damaging to a business/product roadmap — but less known is that it’s equally damaging psychologically. Often, those that can really do anything end up feeling lost and do nothing.

“Aligned autonomy” is about putting a few constraints and a dash of vision to the freedom to help give people a sense of direction.

Let’s get down to how Build.Better Days work.

Freedom first

First and foremost — you’ve got to give the freedom. We’ve got a company-wide, fortnightly meeting in the calendar on Friday that says “Build.Better Day”. That means:

• Engineers have the time/space to get away from “day to day” development and focus.
• Engineering teams may not be available or at 100% capacity.
• There’s going to be a lot of hackers in our “collaboration space” (an open, flexible area of our office).
• There’s going some stuff to go “oh that’s cool” at by the end of the day.

BBD is about giving people the time and space to innovate, while surrounding them with people with the talent to get it done.

Everyone has a voice

On our internal Wiki — there’s a button that everyone has access to. Clicking this button will open a JIRA “issue collector” that take whatever they put and place it into our BBD backlog for triage.

Everyone can raise ideas, from any team, no questions asked.

Triage of BBD backlog

Every week all of those that have items “to triage” in the BBD backlog get together with a few of the senior/principal engineers to review.

The goal of this session is to really “groom” the items in triage to help make the actual day productive — so we help each other:

• Build a great user story around the idea.
• Help with scoping to ensure it’s going to deliver something at the end of the day.
• Make sure we’re “aligned” — proposed technologies are core to our stack, contribute to our company vision etc.
• We’re not building robot drill instructors to train cat armies.

We’ll also review items that are “in progress” and clarify “what’s next” to help them move closer to completion.

Pre-day preparation

With a relatively large number of hackers descending on a single space — it’s important to have a basic pre-flight checklist to ensure things are in order:

• Food requirements (did I mention we order food?)
• Work space is free, no clashes of meetings.
• Do we have enough power extension cables, display adapters etc?
• Usual consumables — whiteboards, pens, post-its, etc.

On the day

We keep the format of the day loose:

• 09:30 — People gather in the workspace, caffeinate and converse.
• 10:00 — Recap of “the rules” and pitches from idea creators.
• 10:30 — Hacking — teams self-organise.
• 13:00 — Lunch.
• 13:30 — More hacking!
• 16:30 — “Show and tell” to the rest of the business.
• 17:00 — Laptops closed, beers open.

The “rules”

We try very, very hard to keep this list short.

1. Only work on “triaged” items — this ensures that people are only picking up things that are well-defined and “actionable”. A whole day is short than it sounds!
2. Every team does a “show and tell” — it’s important that we demonstrate progress to each other. We might get working code, or “we tried, couldn’t get it to work, but learned X for next time”. Both are “success”.
3. Stay in the BBD space — this is to reduce disruptions for all concerned. It’s easy for non-participants to ask “what are you working on”. Repeated 2–3 times and you’ve lost over an hour of focused development time.
4. Have fun — it’s still a hackathon. 😊 Progress over stress.

Outcomes

We’ve had 5 BBD’s so far, and we’ve seen a wide range of awesome output — including:

• Incredible development/improvement of our build/deployment pipelines.
• Slack bots to help people find their way around the office.
• Libraries to help engineers “do the right thing” easily — e.g. the “circuit breaker” pattern.
• Clean-up of legacy code/libraries to both boost performance of our applications and maintain sanity of engineers.
• Better integration of our deployment pipelines to APM tools such as New Relic.

For me personally, I think the greatest outcome so far is:

People “get it”. They are getting involved and improving things for each other.

To close…

I’m really enjoying seeing Build.Better Days grow and evolve.

It’s (unfortunately) rare to see real commitment to initiatives such as these in our industry (even the famous “20% time” from Google is struggling). BBD has full support from the leadership team, and we work hard to keep the “rules” and bureaucracy minimal.

So, will you take the plunge and give your team the time, space and energy to Build.Better?

Happy hacking!

Links

• “Spotify Engineering Culture — Part 1 and Part 2” — mandatory viewing for new Trainliners.
• “Enabling Autonomy at Spotify” — great talk from Jason Yip (@jchyip) at Spotify.

Introducing Build.Better Days was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part one of this series describes my journey towards discovering this way of working and the foundations of evolutionary management. Here in part two, I detail what we learned from experiments designed to create breakthroughs in self-management and wholeness — the good, the bad, and the beautiful.

Self-Management Practices

The Advice Process

Experiment:

When our team was still small (<20), we agreed a new decision-making policy called the advice process. The advice process is simple — any person can make any decision after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter. This means that every decision has a responsible owner accountable to the group, but this person can be anyone within the team — not just those at the top of a pyramid.

Results:

Our team agreed to this policy because, as one developer put it, “it makes everyone empowered,” and indeed it seemed to boost engagement. However, we learned it was insufficient to ensure code quality and consistency, as our team members had differing understandings with our tech stack and standards. Particularly as the team grew, we realised that we needed someone in charge — but not an autocratic team lead. We simply had to define more stable decision-making accountabilities, particularly over code quality, without diminishing the power of team members. We found a solution in what I call the three-layer cake of accountabilities.

The Three-Layer Cake of Accountabilities

Experiment:

When the team grew past 25 (and eventually to over 50) people, we broke it down into five squads, each owning a different area of the application. The tech leads along with each squad’s developer in test ensured quality through the stack. To ensure consistency across the stack, we created a parallel guild structure with guild leads, inspired by Spotify’s org structure. However, we went beyond the Spotify template and defined a third set of roles, which we called the Champions of Excellence. The Champion of Excellence role evangelises for a particular aspect of product quality we care about, learning about and educating other team members on subjects like accessibility, performance, and security. While myself and our development manager suggested these roles, the team expanded and filled them voluntarily.

Results:

These new accountabilities remain in place, and the team is rolling. Code quality is high thanks to leadership from the squad leads and guild leads, but vesting more power in these roles has not disempowered others because there remain other accountabilities with power. Indeed, the great majority of team members now have meaningful opportunities for leadership and accountability beyond their day to day functional specialties. More importantly, the three-layer cake management structure was agreed and implemented by the team and therefore reflects our best efforts to self-organise around the challenges we face.

Wholeness Practices

Check-ins

Experiment:

We began by starting team ceremonies with a minute of silence as detailed in part one of this series. We then naturally moved to a verbal check-in practice whereby we’d go around the room, each team member sharing how they were feeling at that moment in a few words. This practice took about a minute and rarely finished without a round of knowing laughter. Each said what was really there for them, whether that was being excited for the week or hungover from last night.

Results:

Both these practices had the same effect — everyone got present. Laptops shut, eyes came up, and the group became intensely focused on the conversation. Our meetings became not only more efficient but also more enjoyable. We ended up sticking with verbal check ins longer. By speaking a small emotional truth, we were licensed to speak larger truths and get to the heart of the matter. And in doing so, we could simply be ourselves.

Words of Gratitude, Praise, and Acknowledgment

Experiment:

It is traditional in Scrum to have a demo day at the end of the sprint where the team shares their accomplishments. We certainly didn’t skip this. Indeed, we had somewhat decadent weekly wrap-ups with tons of sweets and snacks to celebrate. Adding to that tradition, we set aside time to honour not just works of achievement but also acts of cooperation. After demos were done, I asked the team a question — “Who would like to share words of gratitude, praise, or acknowledgment with your colleagues?” Team members then spontaneously addressed one another.

Results:

I always looked forward to asking this question. Team members have acknowledged each other for providing training, for responding quickly to crises, and for simply being there for each other on tough days. It is in these conversations in which the team has created who we are through our expectations for one another — we are generous, we are resilient, we are compassionate. I’ve found the practice remarkably powerful.

Performance Evaluations from Wholeness

Experiment:

Performance evaluations in the Achievement-Orange paradigm can be dispiriting conversations. While intended to be objective and dispassionate, they’re in reality often tinged with fear and anxiety.

I tried something different with one of my direct reports, Janie (not her real name). I gathered Janie and her closest colleagues in a well-lit meeting room, arranging the group in a rough semicircle around her. We began with a minute of silence, during which I asked the group to hold Janie in their hearts. Then, one by one, each of Janie’s colleagues offered her two gifts from a place of love and connection. These two gifts were the answers to the questions, What is the one thing I value most about working with you? and What is one area where I sense you could change or grow? While they spoke, I transcribed the answers on a whiteboard behind Janie, and I gave a photo of these answers to her after everyone had spoken. I then followed up with Janie to discuss what she discovered about herself and how she sensed she wanted to grow next.

Results:

There was an incredible love and generosity in the room throughout this process. Were it not for British norms against expressing emotion in the workplace, I felt there might have been tears. The results were not only moving but also useful. Valued traits were deep acknowledgments of strengths, some of which Janie had not fully appreciated, while suggestions for growth got right to the root her challenges. Those who participated from different teams requested that they receive such an evaluation, saying how it wasn’t fair that their teams didn’t do the same.

Handovers from Wholeness

Experiment:

I adapted the above format to bring wholeness to handing over my role as product owner for the web team. After 15 months of product leadership, I chose to hand over this role and pick up a new one as product owner for the data science team. I wanted to set up my successor for success, but I also wanted to acknowledge and celebrate what I brought to the team so that I could fully let go. When it came time to hand over accountability to my successor (who was Janie, in fact) for the mobile web squad, I gathered the group together in a semicircle around the two of us. After a minute of silence, each team member shared the answers to the questions, What is the one thing I valued most about working with you, Ian? and What is one wish I have for Janie for the future?

Results:

The team showed up as generous and authentic, sharing moving words for both of us about what they loved and what they hoped for. I felt complete and ready to move on, while Janie said she felt a new relationship with the team starting to grow. I look forward to trying this again for my next role transition.

In part three (coming soon), discover what we learned from experimenting with practices designed to evoke evolutionary purpose, including what I consider the most powerful evolutionary management practice.

About the author

Ian is a senior product owner at Trainline passionate about building great products, teams, and organisations. Born and raised in the San Francisco Bay Area, he has been working and learning proper English in London for the past six years. Ian has an MSc in Decision Sciences from the London School of Economics and a BA in Cognitive Science from Yale University.

<< Part 1: Practicing Evolutionary Management at Trainline: The Journey to Evolutionary-Teal and Beyond…

Is your development backlog too big? Do you to find yourself having two backlogs without realising it? One which is high priority items, recent defects and tasks to be completed in the next few weeks, and one which is full of nice-to-haves, low priority defects and legacy requests? I think we all know what gets the focus and what is just muddying the waters.

This is a common problem I’ve found with pretty much every project I’ve ever worked on, and I’ve found a few steps that have really helped to get your backlog looking in a much healthier and more manageable state.

You can only focus on so much at once, and not being able to see the wood for the trees, as it were, can cause a team to lose focus. We can only take in so much information at once, and there’s no way a Product Owner can efficiently prioritise a hundred items or more.

Out with the old

A good rule of thumb, is that if something is over a year old, and hasn’t been done, then GET RID OF IT.

If it’s a product request: it obviously isn’t important enough to have been prioritised up to now, and therefore it is pretty unlikely that it will get done in the next year. Unless your business stagnates and you are struggling to find things to do, in which case, you’ve probably got bigger problems.

If it’s a defect: it was that much of an issue, it would have been fixed. And if something changes which causes this defect to crop up again (perhaps more severely) then a new ticket can be raised, probably with much more relevant and accurate information than a year ago.

If you’ve ever moved house and had a massive clear-out of things you don’t need, hopefully you can relate to the following question:

How many times have you missed the items that were gone?

It’s normally pretty rare that you will, as if you haven’t used something in 5 years, you are unlikely to need it again in the next year or two. The same is true of development, especially as you are theoretically buying new products on a daily basis! Once you’ve done this initial clear out, you’ll find it a lot easier to do the next step.

Looking too far forward

Again, if there are stories/requests in there for functionality which is not in line with the business priorities for the next 6 months or year, then there is probably no need to have it in your backlog. In a tech company, it is very difficult to predict what the future will be like, and there is no point trying to work out the details of these stories now or wasting your time on something which may never happen. So if you honestly can’t see it getting done within the next year, GET RID OF IT! This will allow you to focus on the main business priorities. These things should be kept elsewhere, as part of a Product Owner roadmap or at an epic level with no stories.

Timeboxed small defect clear out

There always seem to be these little requests/tasks/defects which are very small changes, and they need to be done. At some point. The issue with these is that they are generally not the most exciting things to work on, and are likely to be the last thing someone will pick up, especially when there is something much more appetising on the backlog. I’ve found that a great way to tackle these is to have a timeboxed “Defect Attack Week”. Although this doesn’t have to be a week, maybe it could just be two or three days:

• Decide on the top 5–10 bugs that have been lingering (or more if you’re feeling ambitious)
• Write each on a post-it and place on the wall near the team
• Every time someone fixes one, move the post-it, throw it away/up in the air in celebration
• See how many you can fix in the timebox and if the team clears them all, have some treats to recognise it

This approach can also work leading up to a big release or project closure when you’re discovering lots of defects.

Once your backlog is relevant, minimalist and focused, you’ll hopefully find planning and prioritising much easier.

Happy Spring Cleaning!

About the Author

Karen is a Business Analyst at Trainline. She has a passion for agile development, continuous improvement, and eating and drinking her way around London (Instagramming wherever possible!)

Spring-clean your backlog was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous post I discussed some questions around UI automation testing for iOS applications. I looked into questions regarding stability and the use of stubbing data as a base for most UI tests.

Choosing the right tools

The most important part of doing automation is to choose the right tools. There is plenty of choice on the market for UI automation testing tools for iOS. Appium, Calabash, KIF — these are just some of the big players you can choose from, not to mention a large number of smaller ones and one native tool — Apple UI Automation. All of these tools have some benefits but also some disadvantages.

The main challenge is this: there is no ideal solution.

Below, I will share with you my thoughts and conclusions about some of them — and I really hope this will help you choose the most appropriate tool for your team when the time comes. To keep these learnings manageable, I will focus on some key, well-known tools as well as the native Apple solution — not, for obvious reasons, the Apple legacy JavaScript implementation, but rather the modern Xcode UI Tests framework based on Swift (you guys know what I’m talking about, right?).

Also, I really must emphasise that all of the points and thoughts below are based on empirical evidence: we have actually used all of these solutions at Trainline at various times. All of this is real experience and learning.

Appium

This is a really good tool that has a lot of benefits and good thinking behind it. It’s open-source, free to use and quite easy to setup. A huge benefit of this tool is its cross-platform nature. So, if you have iOS and Android apps, with similar features and UI, and you want to use one tool to write automation for both of the apps, then Appium could be for you.

Here are some of the other benefits:

• tagging for tests scenarios
• abstraction level for Scenarios using Gurkin
• quite easy to setup
• cross-platform
• black-box approach, completely external to project.

Here are couple of issues which we found to be drawbacks:

• very slow after the latest iOS release.
• Java based — so it’s not native for iOS developers

Calabash

Here are some plus points:

• tagging for tests scenarios
• abstraction level for Scenarios using Gurkin
• easy to setup
• have cross platform capability
• able to run tests on Real devices
• relatively fast for tests run

But here are some unfortunate minuses:

• requires recompiling the project specifically for tests to run
• invasive as it requires the injection of the Cucumber library with HTTP Server in order to implement communication with the Ruby part
• Ruby-based — so, again, it’s not native for iOS developers

KIF

This is quite an old tool which is, by nature, much closer to Xcode UI Tests rather then to the Appium or Calabash approach.

Pros:

• very close to development, as it uses Objective-C as the main language
• fast to run
• easy to setup

Cons:

• very invasive as it literally runs inside your app
• no cross-platform capabilities

Also I need to mention that this tool uses UnityTests style, more commonly known as JUnit test style, for writing tests. This could be a pro or a con depending on your point of view.

Xcode UI Tests

This is the native solution from Apple. More precisely, the second generation native solution. The first implementation from Apple was based on JavaScript and didn’t integrate properly with the IDE. Instead, you had to use the Instruments application to access those scripts without any syntax highlighting or auto-completion. So it was a really messy, unstable and unmanageable way of writing UI automation for iOS.

Xcode UI Tests, on other hand, is quite a mature and thought-through tool. With some references to the past JavaScript UI automation in its structures, you can use, or access, elements and search controls, but they have been rewritten in Swift and propositioned by Apple as the main tool for UI automation on iOS.

Like the previous tool, Xcode UI Tests uses JUnit style for test writing and works as set of unit tests by adding a new bundle to your project, and it integrates perfectly with Xcode and Xcode Bots.

Pros:

• fast — it’s actually really fast.
• no need to integrate anything or do any additional setup — works out of the box
• uses Swift as its base language - perfect for native developers.
• great integration with Xcode from writing tests to getting feedback from test runs.
• black-box testing, as test runs on top of a sand-boxed app instance
• stability: from my experience tests run more stably and more predictably in comparison with other tools.

Cons:

• no tagging, harder implementation for CI to run a specific subset of tests.
• no cross-platform capabilities

Requirements and choice problem

So, once we had evaluated all the available tools and listed the key pros and cons, in order to actually choose the right tool, we really needed to think about our specific requirements: what were the significant factors which would impact most on us? This is what we identified:

1. A team approach: We wanted to have developers closer to UI automation. As I mentioned in my previous article — UI automation is a team effort, all team members should contribute to it.
2. Performance: We needed something fast, in order to connect test runs into the continuous delivery pipeline. This is very important for the overall quality of the product. If you have your test runs before you ship anything to customers, you significantly reduce the risk of shipping something bad.
3. Stability: We needed something reliable, something that would not fall apart with the next iOS release or stop working if Xcode were to update to new version.
4. Smooth integration: We needed something that integrates natively and smoothly into the development environment with the minimum of setup and overhead.

We decided not to restrict ourselves to a cross-platform solution, but rather, take something really optimal and specific for iOS and make the best out of it.

Taking all of this into account, it was quite obvious that Xcode UI Tests — was the one and that we should try to incorporate it in our development practices more heavily. It is based on a native for the team language — Swift, allowing a black-box testing approach to a sandboxed app with the minimum of impact on our main app code. It’s the fastest available tool on a market that integrates natively with no context switching for developers. It uses the same tools we use day-to-day: - Xcode, showing you the output of your tests in the same IDE you use for coding and in the same style with which we were already familiar from unit tests.

Although it doesn’t have a tagging system or natural language support for writing tests scenarios, it is still the best available tool that the team can use. And, as you will see below, those disadvantages could be mitigated with the use of certain techniques.

Performance boosting tips

OK, so we chose Xcode UI Tests. Now for some more details around how it’s all set up here at Trainline.

The basics, such as Xcode setup or adding UI Test targets to the application, can be found in the Apple documentation, and there is also a handful of tutorials online. So this post will instead focus on some aspects related to the performance of the tests.

Here are some tips, based on the experiences of our team, for using Xcode UI Automation on a real app over some period of time, which will help to speed tests up and improve the stability of test runs:

• log out any active users between test runs and clear data. This makes all tests run independently on a fresh setup of the application, so you eliminate any possibility of failures caused by some garbage being left over by a prior test
• use stubbing data for most of the tests. This will allow you to minimise any slowness with real service latency of responses and potential variations in responses
• write tests “wisely”, meaning that it may be prudent to combine a few scenarios in one in order to reduce the amount of runs with the same coverage
• do not over-complicate your tests. Tests should be quite deterministic and not do too much. You really need to find some middle ground on what tests should look like
• split tests into groups. This will allow you to do more careful selections if needed on CI to run a group of tests in a specific area, such as a payment system, for example — it should just be a matter of pointing your CI to specific folder
• select some sanity tests to run on each commit on CI. Do not try to run everything every time as it will take a long time and not really bring a lot of value
• use expectations to make sure you are interacting with elements that exist - this will minimise occurrences of false failures of tests

Another trick worth considering is to disable any animations within the app. You will be surprised how much time you gain by doing this! The downside of this, of course, is that there becomes a point when you can argue that this is not really running the real app and you will be testing modified code and I would agree with this. However, generally speaking, this is not as bad as it may sound, as we are only disabling UIView animations and so no functionality is being changed. So if you are ready to compromise a little bit on that in order to gain a performance boost for your tests, this is a neat trick!

CI integration

Another important question is how to integrate tests into the delivery pipeline. If a test suite is not integrated and, instead, left on a manual execution cycle, it gets forgotten and starts to rust, so they end up being a complete waste of effort and time. So in order to really benefit from UI automation tests, they have to be included in the continuous delivery pipeline and in the development process overall. And really importantly to understand why we do that, the main reason being to minimise the possibility of delivering a broken product. Making sure that automated tests are running constantly on any change we do should guarantee better stability and minimise any possibility of some simple, but costly, error slipping through. Also UI automation is the perfect tool to offload manual testing overhead to free up some valuable QA time to do exploratory testing.

Taking into account all of the above, we began with a simple setup of running all tests we have on anything we were about to merge to the development branch. This proved to be a good step to start from: while there were not many tests to start with, it made sense to have them all running often, so we could see how stable they were and what performance was like. We agreed that to get anything merged into the development branch, it should have UnitTests and UI Automation passed.

But with your test suite growing, it is inevitable that it will at some point take too long to run all of the tests every time. And this is where the idea of splitting the tests into multiple suites came to the fore.

Ideally you want to have a selective run when working on a feature or are fixing some issue and you just need to make sure that the area you are affecting is not broken, or that the feature you are implementing works as expected. But as you will see, there are certain limitations and problems around this. So for some time we decided to implement a simple solution of having two tests bundles: one with some sanity tests to cover most of the app functionality in a few tests on the most important key areas; and the second — all of the tests. With this, we can run a small subset of tests on every commit and before merging to development, and a large set of tests to run over night on the main development branch to check if all the work done during the day is still stable.

Although the Xcode UI Tests tool does not have a tagging system to define a group of tests, unlike Calabash, for instance, we still have few options to implement such functionality.

Using Schemes

The simplest way is to set up different schemes inside your project. Basically, for a specific scheme you can choose what to run, specify tests, bundle of the tests or suite to run on CI. And this is quite simple to do, you do not need to duplicate code or targets.

You just need to add new scheme in the “Manage schemes…” menu or duplicate existing one with tests. And you will be able to specify what tests to run when this scheme is selected. It should be dead simple to configure CI job to run this custom scheme. And you will have just subset of tests that got run there with results for them.

This setup lead to one complication though — this is all manual process, and in case you need to change anything when number of tests grown up significant, it will be really easy to lose context there. So maintainability cost will be quite significant with such approach.

Using the command line

Luckily, Apple introduced a different way of doing that with the new Xcode 8 on the last WWDC. It’s a slightly more complex way that requires some more setup on CI and some work with scripts, but it gives a more automatic and flexible way of doing that.

I’m talking about two new console commands that allow us to split builds from the test run.

One is build-for-testing which allows us to do only a build of a project and produce some resources that could be shared across a few build agents to run tests.

xcodebuild build-for-testing -workspace 
                 -scheme 
                 -destination

And another one: test-without-building. This command allows you to only run the test if the application was already built with the previous command and we have the generated resources.

xcodebuild test-without-building -workspace 
                 -scheme 
                 -destination

Also, there is one more new addition to the family of commands for console runs of the tests or, rather, an addition to the normal xcodebuild one.

xcodebuild test -workspace 
        -scheme 
        -destination 
        -only-testing:TestBundleA/TestSuiteA/TestCaseA
        -only-testing:TestBundleB/TestSuiteB
        -only-testing:TestBundleC
        -skip-testing:TestBundleD/TestSuiteD/TestCaseD

So, by using -only-testing and -skip-testing we are able to set up more flexible and targeted ways of running a subset of tests on CI and it could be done per feature, or just to achieve some parallelisation for running tests which will become quite important, at some stage, as the test bundle grows and thus the time it takes to run all the tests becomes bigger.

Summary

In conclusion, I would like to say that, at Trainline, we as a team went on quite a long journey trying different variations of tools and setups before ending up with Xcode UI Tests. In short, our journey looked like this:

KIF -> Calabash -> Appium -> Calabash -> Xcode UI Tests

Yes, we even tried to implement Calabash more than once. The second attempt was more successful and we used it for some time. What we learned here is to continue searching and trying. It’s impossible to achieve something without trying. We failed a few times, but we kept looking and trying and now we have a highly maintainable, stable, performing solution for our UI automation requirements which we keep improving.

<< Previous: Stubbing for UI Automation on the Trainline App

UI Automation for the Trainline iOS App: Tooling and Performance was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The gong went off with a humming twang.

Around the table, 20 people sat staring. Our agile web team had kicked off many sprint planning meetings, but none like this. As the sound of the Tibetan meditation bowl receded into silence, nervous impulse rushed to fill the space — fidgeting, murmuring, exchanging glances. After 30 seconds or so, this noise died down too, settling into a deeper silence still. Once another half-minute had passed, I rang the gong again.

We then proceeded to have one of our most efficient sprint planning sessions in weeks. We even finished 15 minutes early. Not a bad return on investment for one minute of silence.

This practice was an experiment in management, one of many we’ve tried within Trainline’s web team. Now looking back at our journey, I’d like to share why we risked breaking with the orthodox agile formula and what we’ve learned from 15 months of testing.

Seeking a Simpler Way

As a product manager, I started experimenting with unconventional management methods out of a longing for a simpler, more soulful way to work.

When I first discovered Scrum from gurus like Jeff Sutherland and Roman Pichler, I thought I’d found the answer to all the ills of traditional management. Scrum offered a complete solution to so many of the frustrations I had with waterfall-style planning, and I bought into the new system wholeheartedly. I prioritised backlogs, estimated work, and produced nice burndown charts which made me feel like our team was making progress.

However, I soon found that Scrum’s playbook was missing some pages. Its ceremonies and techniques created lots of velocity but not a lot of meaning. I’d fallen into the trap of getting fixated on accelerating output, which ultimately distracted from the real work — solving problems for people. Working this way ultimately made me feel I was running a Fordian feature factory — productive yet somehow empty.

When I joined Trainline in October 2015 as the product manager for the web, I was looking for a more soulful way to manage a team. This led me to discovering with what I like to call evolutionary management.

Discovering Evolutionary Management

In his 2014 book, Reinventing Organisations, author Frederick Laloux documents 12 organisations around the world operating from radically new management principles — and what makes these teams’ practices an evolutionary leap beyond inherited management philosophies.

As detailed in his research, most modern corporations operate from what Laloux calls Achievement-Orange, a worldview which sees organisations (and people) as machines designed to maximise economic output. This mechanical metaphor permeates everyday business language through phrases like “pulling levers,” “resourcing initiatives,” and “optimising productivity.” Words like these define the relationship between people and their work as mechanical parts with functions to be predicted and controlled.

While Achievement-Orange practices succeed at getting results, these results often come at the expense of the individual, who can often feel like a replaceable cog in an impersonal machine.

Beyond Achievement-Orange, there is Pluralistic-Green, a worldview which builds on Orange’s foundations but adds three breakthroughs — employee empowerment, a values-driven culture, and stakeholder value. Pluralistic-Green organisations feel less like a machine and more like a family. These organisations include industry leaders like Southwest Airlines and Ben and Jerry’s, companies characterised by extraordinary employee engagement and customer satisfaction.

While Pluralistic-Green organisations are among the most successful in the world, they retain a pyramidal management hierarchy at odds with their “empowered” culture. This contradiction creates tension which limits individuals from bringing their full intelligence and initiative to work.

What lies beyond Pluralistic-Green?

Laloux discovered many companies operating in a way which integrates and expands on the previous stages, a model he calls Evolutionary-Teal. These organisations see themselves not as machines or families but as living systems, organisms which are internally integrated yet always growing with respect to their environment. Three breakthroughs characterise this stage of development:

1) Self-management. Teams operate with fluid systems of distributed authority in which each person has the power to make meaningful decisions. Rather than concentrating power and control at the top of a pyramid, self-managed teams have agreements in place which make everyone powerful.

2) Wholeness. Teams have practices in place which allow each person to drop the masks they wear at work and be completely themselves. Letting go of the ego not only releases enormous energy for individuals; it also creates a safe space which leaves room for extraordinary innovation. When people feel free to say what they truly feel, they bring their full intelligence to work and generate the best ideas.

3) Evolutionary Purpose. Teams tend not to work from rigid strategy or planning documents, artefacts symptomatic of an Achievement-Orange predict and control management philosophy. Instead, they align to a shared purpose and adjust every day to move toward that purpose, a sense and respond way of operating.

The promises of Evolutionary-Teal seemed to address many of my problems with conventional agile methodologies. So with that hope, the web team and I stepped into the unknown and tried installing practices from this new model.

In next week’s blog, discover what we found…

About the author

Ian is a senior product owner at Trainline passionate about building great products, teams, and organisations. Born and raised in the San Francisco Bay Area, he has been working and learning proper English in London for the past six years. Ian has an MSc in Decision Sciences from the London School of Economics and a BA in Cognitive Science from Yale University.

Part 2: Practicing Evolutionary Management at Trainline: Experiments in Self-Management and Wholeness >>

Practicing Evolutionary Management at Trainline: The Journey to Evolutionary-Teal and Beyond… was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Other teams within Trainline have had some success creating JSON-API-based services in Ruby, and we saw no reason why our C# implementation would be any less successful. This blog post is an attempt to tell the story of the journey we took and where we ended up.

For a full explanation of what JSON API is, see the project site (http://jsonapi.org)

Why join such a fellowship?

Firstly, why would we consider JSON API for responses when, surely, standard JSON representation of our classes is simple and ‘just works’?

1. We simply don’t want to spend time discussing the structure of our response and how best to optimise it. JSON API gives us a way of having a defined response for each endpoint without having to re-invent the wheel
2. Resource objects. JSON API provides a way of linking primary resources. These can be displayed within the ‘included’ section of the response, to minimise requests, or just linked in order to minimise payload size. Given the data we are representing had numerous external resources, this appealed to us more than any other aspect of JSON API
3. At the end of the day, it’s just another way of serializing data. We figured we can switch serialization methods easily enough and so why not try…

As with all these things, there are of course trade-offs that need to be made for these advantages

1. Readability: There’s no other way to say it, but compared to a nice readable standard JSON output, JSON API is ugly! It feels like we are turning JSON into SOAP…
2. Performance: Essentially, outputting JSON API requires mapping from nice C# objects to the objects in the correct formatting before serializing. That means that the whole mapping step is additional processing that needs to happen, which has a knock-on effect on performance. Here is some benchmarking we did, serializing a very simplified version of our model:

Implementation

The project site has a list of .NET server libraries which can be used to implement JSON API, so we started a spike to consider which option would work best for our scenario:

(http://jsonapi.org/implementations)

What quickly became apparent, is that most of these libraries would not support the JSON API output we were attempting to create. We believe that this is due to that fact that JSON API started as a group of guidelines and then evolved into a strict specification by version 1. The libraries are still catching up with these updates. Some common issues were:

• Top level ‘included’ node not supported
• Resource objects with external links not supported
• Complex types are not always supported as an ‘attribute’

NJsonApi

Eventually, we discovered that NJsonApi provided the best option for us as it created the desired output with simple setup, integration into ASP.NET WebApi and extensibility. We were able to set up the mapping details and bootstrapping in the WebApiConfig, so any reflection needed by NJsonApi to map to JSON API would be done on initialisation of the service.

As we set up the more complex object, we discovered the need for these extensions / workarounds:

• Every custom object requires mapping configuration which gets quite verbose and has a lot of duplication in our case, given that we want to handle all resource objects in the same way. We resolved this with a set of extensions to the NJsonApi ConfigurationBuilder to allow automated configuration when classes implement a specific interface or attribute
• To specify serialization options (case, enums etc), we had to override the default serializer
• Unable to serialize IEnumerable<T> types. There is an issue in the GetItemType method here which means that only collection interfaces that implement IEnumerable<T> are supported rather than the IEnumerable<T> itself. We worked around this by using ICollection<T> or something similar, but if we moved forward with NJsonApi it could be fixed with a simple pull request
• The JsonApiActionFilter swallows any exceptions so and then falls back to the standard JSON serialization — which makes debugging a little trickier

Deserialization

Now we had our objects serializing nicely into JSON API, surely, it’s a simple case to deserialize back to those objects you say? Sadly, this is not the case. The NJsonApi deserialization did not seem to support the compound documents with included resources. Fortunately, there is a library available that only does deserialization and supports all these things: JsonApiNet

Sadly, JsonApiNet, whilst excellent at deserializing from our JSON API to C# objects, provided new and exciting challenges:

• Because we now had a separate library for serialization and deserialization we had to create a new formatter for deserialization which needs to be at the top of the formatter collection, then the NJsonApi formatter needs to be the next in the list followed by the standard JSON formatter.
• Performance: JsonApiNet uses reflection at deserialization time and the performance benchmarks we got were much slower than standard JSON:

• GNU Licence: The limitations of the GNU licence mean it is better for us to not use open source software under this licence for commercial application

In the end, we implemented a custom solution for deserialization which involved deserializing to a ‘jsonapi’ C# object and then mapping from that to our original objects. Whilst this is very performant as there is no reflection necessary, it does make for tedious and hard to maintain code so a more performant reflection version would have to be created at some point.

The Return of the (James Newton) King

At this point, we took stock of the situation in the end-of-sprint retro and re-assessed the viability of JSON API. We decided that, whilst our service response did indeed provide a good candidate for the advantages of JSON API, we would not pursue it at this point for the following reasons

• We were spending longer on the JSON API serialization than we were on solving the engineering problems that our project is trying to address
• We already supported JSON as well as JSON API to demo work in progress in a more readable way
• Removing the JSON API work would not take very long at all and not much work had been done to consume it yet
• It was looking more and more likely that we would need to create our own JSON API library, but there is no reason that it would need to be done before the project work. The library can be built in isolation and then we can always switch back to JSON API at a later date — it’s just serialization after all…
• JSON is simple and just works

About the author

Mike Reeves is a Software Engineer at Trainline working mainly with C# on back-end services. He likes good whisky, good books and good enough code!

There and back again: a {json:api} tale at Trainline was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was selected for the Trainline graduate scheme right after university and the first few weeks here have been a new chapter in my life. It might be somewhat confusing for most people how an Aerospace Engineering graduate finds himself starting out at a tech company that deals with trains. Software was always a key part of my work in engineering and I have always wanted to learn the tricks of the trade in this sector. What better way for me to achieve these goals than to join one of the most innovative e-commerce companies in Europe? And, more specifically, in a team which is responsible for so much interaction with the trains on the ground?

Welcome to Trainline

My first week at Trainline was quite a blur, as might be expected when you want to get up to speed on the functioning of a very fast-moving organisation. They really helped by arranging induction sessions for the new joiners, each dealing with a specific aspect of the company. I found these to be very valuable in giving me a bird’s eye view of the company structure and how the various systems interact with each other. One of the most engaging was the Q&A with our CEO where she shared her vision for Trainline, as it grows globally making it easier for everybody to travel. This really made me excited to be here.

Routemaster: the most sensibly named team at Trainline

The Routemaster team deals with those bits of Trainline that integrate right into the UK’s rail network, most importantly, journey searches. The work here involves an overlap of software and trains. This is also the most aptly-named team, as I found out on my first day when I went to collect my equipment from the IT support team named “Jedi”.

I found myself straight in at the deep end from day one as I paired with other team members working on actual product development. New joiners are encouraged to deploy something to production in their first week, whether it’s a comment or a line of code. Deploying my first two pieces of work into production in my first week substantially boosted my confidence and made me enjoy the learning experience.

What we do

As an engineer, I have found the work environment very engaging. I spend every day collaborating with some of the brightest individuals to solve problems and translate these solutions into good code. Programming itself is often not the majority of the work, a key aspect is to ensure all the different pieces fit well together. Often, you might find yourself concentrating on issues conceptually. Every day is different here at Trainline.

Besides the programming, the work in Routemaster also requires domain-specific knowledge about the rail network. An induction session dedicated to the UK’s rail network was very helpful. This ‘rail’ side of things is particularly exciting when you realise how close you are to the real-world implications of the problems that you solve on a day-to-day basis.

Supported Learning

As exciting as all this is, there is a lot to learn and my team leader was very supportive in helping me set my objectives and organising all the additional training that I needed to fill the gaps in my IT skills. This has added a real structure to everything and makes everything a lot easier.

Besides this, all the fresh grads are also appointed a mentor. Mentors are purposely selected from other teams to help you to meet people from outside your immediate circle and allow you to be more open. Personally, my mentor is from a team called “Vulcan”, which as the name very intuitively indicates, deals with marketing :-) Furthermore, mentors are usually people who have themselves joined fairly recently and so the experience of being a new starter is fresh in their minds. There are regular mentor-mentee get-togethers, but you can just approach them whenever you want to ask anything related to work or otherwise. A great way to make some friends right from the get-go!

All work, no play?

It is not all work at Trainline, this is frankly one of the coolest places to work. Much like a university, there are clubs for you to get involved in. Yoga, salsa (as in doing not eating), board games or you can start your own! Trainline does have a great sense of community. And what a diverse community it is, with people from all over the world working at the company. They also encourage you to take part in Hackathons which is great for honing your skills and having some fun at the same time. As a graduate right out of university, you will fit right in as you can just continue to be a student! There is always something to get involved in here at Trainline.

Perks of the job

Also, no article about working at Trainline would be complete without mentioning the numerous perks on offer. While some organisations are content with offering you a vanishing Aston Martin with rocket launchers and expensive watches that explode, we go one step ahead and offer … free breakfast! It is impossible to stress how easy this makes my day. Then there are salary sacrifice schemes for things like gym memberships and bicycles. The location of the London office, right next to Leather Lane, gives you access to some of the city’s most awesome street food right at your doorstep, thus making it possible to look forward to every weekday!

My First Week at Trainline was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post goes through our Oracle migration journey in more detail and also includes some general tips for moving large databases to the Cloud.

Our Oracle Exadata Migration

The Challenge

Databases running on Exadata are at the core of many big systems and are a common challenge when moving to commodity hardware in the Cloud. Typically, they are big, high performance, and latency sensitive.

Our primary database was 4TB in size and required 600MB of mixed IO per second. We were fortunate that it was largely read heavy but unlucky in how the applications were using it. The database was called several times during some key user journeys so any extra latency or slow-down would be amplified for our users.

Another complication, as ever with Oracle, was licensing. We had enough licenses to cover 16 VCPUs in AWS but knew that keeping to this target was going to be tough. One downside of AWS is that you can’t miss performance on 16 cores and just go for 18 or 20 instead. The next size up is 32 cores which would have been painfully expensive!

Step 1: AWS Baseline

Our first move was to simply throw the database into AWS and get a feel for how it worked.

We used a specialist tool from Oracle called Real Application Testing (or ‘RAT’) to record 1 hour of live production traffic so we could play it back against the AWS version and compare performance.

As a starting point, we created an R3.8xLarge instance (32 cores), gave it 4 1TB disks (largest size available at the time) and played back the RAT test.

Initial results showed the scale of the problem — 33% slower on double the cores.

Step 2: Infrastructure Tuning

From the baseline is was obvious that the key issue for our particular database was IO throughput rather than CPU or RAM. We were hitting the throughput limits of individual EBS volumes and noticed that a large number of reads were hitting the comparatively expensive EBS volumes when we might be able to cache these better.

After a fair bit of experimenting, we ended up with the following configuration:

• I2.4xLarge instance (16 cores, IO optimised, more ephemeral storage)
• 8 x 500GB EBS volumes (more disks to help Oracle ASM stripe and avoid hitting the throughput limits of any single volume)
• Option set within Oracle to move 400GB of level 2 buffer cache to the faster ephemeral storage

These changes meant we had an IO optimised AWS Server, avoided single volume throughput limits and were able to serve a large proportion of our read traffic from local instance storage rather than EBS.

The new results from our RAT testing showed we were now 20% slower than our production database but on a 16 core machine. Overall this was a big step forward.

A couple of notes:

• In general, we are big fans of AWS’s RDS service. Unfortunately, it wasn’t the right fit for this particular database due to the level of fine tuning we needed access to within Oracle
• We did experiment with PIOPS for the EBS volumes but ultimately found that for us, GP2 offered the best performance/price point. Your mileage may vary, especially if your database is more write heavy.

Step 3: Database Tuning

Our next step was to review the database itself for optimisations.

We found we were keeping a longer transaction history in the OLTP database than necessary and so ran clean-up scripts to get rid of this older operational data. The history was already safe in our data warehouse and this simple step helped shrink the database considerably.

We also took the opportunity to upgrade to the latest version of Oracle to benefit from a few useful performance improvements in the new edition.

Finally, we tuned some indexes. On Exadata, indexes tend to be removed specifically to benefit from Exadata’s storage cell offloading but on AWS we had to keep analysing the slowest queries from each RAT run and tuning the execution plans to make better use of index scans. In some areas, the direct access from Level 2 flash cache was actually faster than index scans, although this will depend on your queries and workload.

At this point our RAT test results were around 12% slower than production.

Step 4: Application Tuning

Knowing that IO was the limiting factor, we did some analysis on the heaviest IO queries coming from our applications. This showed some obvious areas where we could reduce the amount of data being requested or the frequency of calls. This work got added to our Dev team’s migration backlogs and we were soon within the ~5% performance window we agreed would unblock migration to AWS.

It seems like the sheer power of Exadata has a tendency to make everybody just a little bit lazy. There is no urgency to optimise queries because results get thrown back near instantly even when badly written. The move to AWS has definitely helped serve as a bit of a forcing function to help us identify and optimise a few dodgy queries.

Today

Since our initial migration we have continued to optimise the infrastructure, database and application usage. Thanks to some amazing and ongoing work by our DBAs and Dev Teams, the key user journeys hitting our database now run 10% faster in AWS than they did on-prem against Exadata!

Unfortunately, it’s not really possible to get a direct like-for-like comparison of just the database element anymore. There are a lot of different factors that influence overall performance and the database and our use of it have evolved over time. None the less, the database went from being a major problem for our migration to a more flexible and cost effective solution hosted in AWS and providing our customers with a better experience.

We’re really pleased with how things worked out and would definitely encourage you not be put off if you too have a monster database to move!

Large Database Migrations — General Strategies

The following are some approaches to consider if you’re planning your own Exadata or large database migration.

Divide and Conquer

First it’s worth validating the assumption that your database really is one database. Many monolithic schemas were created for historical or convenience reasons rather than necessity. It may be there are logical subsets of schema that can be teased apart to reduce the scope of the problem.

Shrink and Shift

If the database must be kept whole, there are still opportunities for optimisation before migration.

For example, can the retention period for transactional data be reduced? Is the same period needed for all tables?

Proper use of indexes can make a big difference to the IO and memory requirements of your queries. The raw power of Exadata can cover for under-optimised indexes and hide problem queries. Finding and fixing these issues can reduce the target requirements in AWS considerably.

Modify Apps

Database read load can be reduced by:

• Avoiding unnecessary calls and reducing the frequency of required calls
• Minimising the volume of data retrieved by queries
• Making greater use of application level caching
• Working from read-replicas rather than a single master

Write heavy databases are harder to deal with. One strategy, if some writes can afford to be asynchronous, is to create a separate writer process. Suitable updates can then be posted to the writer’s queue and persisted to the database at a different speed to time-sensitive writes.

Change the Database Engine

One pretty new option worth considering is PostgresSQL for Aurora RDS.

Provided you aren’t using too many Oracle specific stored procedures, triggers etc. then migration should be relatively painless. Once there, Aurora can support impressive scale and speed. Aurora is really shaping up to be an impressive offering so do check it out if you haven’t already!

Go Native or Go Home

Sometimes the right choice is to give up. If your database is too big, too Oracle specific, too complicated to move to AWS, then chances are it is also the cause of significant friction and risk in your development cycle.

In these cases, starting from scratch and running the 2 systems in parallel is a good approach. You can build a new Cloud-native solution in AWS whilst verifying the results against the original system. Once you have enough confidence in the new system you can quietly lead your Exadata behind the cow shed.

In fact, you may be able to do this earlier than expected if you bring the new system online in stages. Once some load has moved on to the new system, what’s left on Exadata may be small enough to migrate using one of the other approaches above.

Summary

There are a number of options available to help move large databases to the public Cloud. What at first may look like an intractable problem can in most cases be broken down and handled by some combination of the different techniques.

Having your databases in AWS also comes with a raft of benefits in terms of agility, cost, flexibility etc. We’ve certainly found it well worth the effort. Good luck and happy migrations!

Migrating from Oracle Exadata to AWS was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We recently started working on rebuilding the desktop version of the Trainline website. It is a big deal for the front-end engineering team because we have to make sure every choice is justified so that the user experience is never compromised. I am writing this blog post to explain how we went about selecting our front-end tech stack and why we made these choices.

How we approached it

First, it seemed obvious for us to use the following JavaScript dependencies as a base for our front-end stack:

• React
• React-router
• Redux
• Webpack

Things became more complicated when we had to discuss the following topics:

• Which library to manage side-effects: Redux-saga, Redux-observable or Redux-thunk ?
• Is static typing valuable for front-end development and, if so, should we use Flow or TypeScript?
• Which library should we use for styling in React: CSS-modules with PostCSS or Aphrodite?
• Is server-side rendering valuable for performance and SEO?
• Should we keep our control components (buttons, drop-downs …) in a separate git repository?

This is a lot to bring to the table and we spent a lot of time deliberating. Due to the number of users of our website, every choice has to be carefully considered. For example, we had to make sure that every library we selected is well maintained and fits well with the other ones.

For that, we did some spikes (short, focused investigations) on each of the above points. It would take too long to discuss each one in detail, but here, I will cover the two most controversial.

Static typing in JavaScript — a long debate

Today, there are two main technologies which bring static typing to Javascript:

• TypeScript (maintained by Microsoft)
• Flow (maintained by Facebook)

Both provide some common basics feature of static typings but are actually quite different in their implementation. To us Typescript seemed to be the most adapted and, to be honest, we didn’t focus too much on Flow, mainly because the team was already used to TypeScript. As opposed to Flow, Typescript is a compiler, and we are using it as a replacement for Babel to compile to ES5 which also simplifies our stack.

Now the main debate in the team was why we should be using static typings with TypeScript. We had a look at multiple articles to help us out here, such as:

• The Shocking Secret About Static Types
• Why Should I Use TypeScript ?
• FLOW VS TYPESCRIPT TYPE SYSTEMS FOR JAVASCRIPT

Each of these covers a lot of valuable opinions, but I will try to summarise the team opinion on this. I personally think that the most important point is that TypeScript helps us to catch some static type related bugs. This is even more so since TypeScript 2.0 came out with the strictNullChecks compiler option.

Next, having static types helps us to understand the shape of the data at any time. By just looking at a TypeScript interface, we already know what is at our disposal. We don’t need to look at the API documentation, everything is there in the same codebase. This way, we only focus on the IDE and we spend less time in the browser trying to debug using console.log or break points. To make sure that we benefitted from this, we decided to be strict and force everyone to define an accurate type by enabling noImplicitAny flag.

Another nice point that TypeScript provides, which is not always shown, is that it gives a proper “auto-completion” and “jump to definition” and this is very valuable as well. Now that I am used to the syntax, my productivity has increased a lot by just jumping between files, so I don’t spend time hunting around the files trying to search for any information.

That being said, one downside of TypeScript is that we rely on the community for the type definition files. If a library doesn’t have a type definition file you either have to write it yourself or you have to use it without typings. To me this is not a big deal and shouldn’t be a big worry, as the community around TypeScript is big enough that all the most-used libraries already have their type definition files. If the library you are using doesn’t have any, you should think twice about using it.

Styling in react, inline-style with Aphrodite vs CSS modules

And now the second most controversial topic our team had to face. We were quite literally divided in two around this one. In the end, we decided to go with Aphrodite and here is why:

• It is easier to apply dynamic styles with inline styles rather than applying a css class as a string depending on some logic
• Aphrodite provides real CSS pseudo-selectors (`:hover`, `:focus` etc.) that inline styles alone do not cover
• Because CSS involves cascading styles, the rules are not scoped to a component and this can lead to some unexpected styling issues.
• Aphrodite is compatible with server-side rendering
• When using Aphrodite with server side rendering you can extract the CSS styles into a separate file so that the browser can cache it.
• Aphrodite provides granular font importing. If the styles in your page don’t reference a font defined by Aphrodite, it does not get inserted (although Chrome already behaves this way).

These arguments were sufficient for us to choose Aphrodite as a styling library over css-module, but there are plenty of other elegant solutions worth trying if Aphrodite doesn’t fit your needs. At the moment I would suggest having a look at Glamor and the new shiny Styled components which is, I think, the most “React way” to tackle the subject.

PS: If you want to have a look at Styled components, at Trainline we have used it for the website of our Reactivate meet up.

The challenges coming up

Once we had tested everything we wrote a boilerplate containing the full software stack. We now have around 20 developers working full-time on the desktop site using Typescript and Aphrodite and haven’t found any limitations so far.

Although it may take a bit of time for new joiners to get up to speed on all these technologies, I think it is good for the business in the long term. Enforcing some guidelines with these tools helps to reduce the impact that technical debt could have on the project.

We now have to make sure we share the knowledge with each other in an effective and efficient way and this is the upcoming challenge for the team. Sharing knowledge well is particularly important around Typescript and RxJs as these two technologies are quite disruptive.

If you liked this blog post, or if you are interested about the tools we are using, please come along to our next React meetup and join our Reactivate meetup group!

About the author

Alexandre Rieux is a front-end developer mainly working with React, sometimes playing with Swift, or learning Haskell and Elm (FP enthusiast). He is co-organiser of reactivate.london

Trainline replatforming: our front-end journey was originally published in The Trainline Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.