Tired of your commits taking >10 seconds? Give this a bash. Linting is great, but no one likes slow commits! At Tes, we use husky to run code when the git precommit hook triggers. Most often, we run npm run lint so that we can catch linting errors before they’re even committed. (We use ESLint for linting.) The problem is that, even when you’re developing microservices, it could take quite a while to lint all the files in your repository.
David Morgantini is a Canada native living in London, a lover of rock climbing, and an engineer who is truly passionate about helping his team find growth and motivation. He is a graduate of the University of Alberta, and found his love for rock climbing during his second year at university. Since then, the longest he’s gone without rock climbing has been a month. As well as rock climbing, he likes to spend time with his wife, and his two-year-old son Lucas.
Working remotely has multiple benefits for the Tes Technology team. These include improved engagement and happiness of our team members, a flexible and dynamic workplace, and the best possible situation for team members to find and decide where/when they can work most effectively. One key challenge for working remotely at Tes is the blend of remote & office workers. This leads to a set of challenges that, were this a 100% remote team, would not exist.
A few days before International Women’s Day, Tes hosted the Ladies of Code Meetup group for an evening of talks, networking and community. Three speakers gave advice on how to become a ‘next-level developer’: how to advance your career, become a ‘superhero’ and negotiate your salary effectively in the context of the gender pay gap. While the event was aimed at women, there was sound advice for engineers of any gender.
If you want to be confident that your users are able to achieve their goals using your service there’s more to do than monitoring the health of individual microservices. You need assurance that your set of microservices are working well together, and when they aren’t, you need the information necessary to fix any problems as soon as you can. This blog follows one Tes team’s mission to better identify and diagnose problems, enabling them to move fast and ship with confidence.
A friend of mine tells a great story of a team avoiding a great deal of grief. All of their system health checks were green, but the live graph of purchases dropped to zero and stayed there. Despite the many positive system indicators, the team were able to see they had a problem and were able able to react quickly to find and to fix it. It turned out that user purchases was a key indicator of success.
Hack days are an interesting idea based on the 15% time from 3M in 1948. The fundamental goal for hack days is to empower engineers to solve problems that they see however they want to. Without the day-to-day delivery pressure they can solve problems that other people don’t even realize they have or in ways that are incredibly creative.
Rachel is a full stack engineer at Tes and works from her home office in Scotland. When she is not working, you will find Rachel either training for a race (she loves to run!), or exploring the outdoors. Want to get her attention? Just say the word “challenge”.
On Tuesday evening, post the launch of the new home page, we had a second set of performance problems that impacted the entire tes.com site around 6pm for 40 minutes, and then subsequently during two periods at 9pm and 12am. The root cause turned out to be a misconfigured Redis caching server that was moved to in response to the issues on the 24th of April. During the post-mortem of the issues the day before we had agreed that a key action was to upgrade and improve the monitoring of the part of our platform that does the composition of the shared fragments (e.g.