Insights from the Babbel engineering team
Today, we will be talking about staging environment at Babbel and how we recently improved it. As a reader of our tech blog, there’s a good chance that you are already familiar with the concept of a staging environment. I will nevertheless start with a brief definition, so that we establish a common understanding before going into the details of how to secure a staging environment. Bear with me.
This is the first in a series of blog posts entitled “How We Work” in which we share with you how we work in Engineering @ Babbel.
When I started at Babbel earlier this year, I was struck by how many great ideas the engineering department here had and how they saw their technology evolving. In fact, in my first week, a compelling document was shared with me outlining the engineering strategy. When we attempted to put the strategy into action, we encountered many problems:
When we retrospected on what was done – and not done – we realized something that should have been obvious to us: the strategy wasn’t really a strategy at all. A strategy enables you to make decisions. This was rather a list of tasks.
There was no overarching vision of the future guiding us. We had no sense of mission.
At Babbel, we employ continuous integration to detect issues early in the development process. Our CI does not only automate the build and run different test suits but also handles some tasks for documentation purposes. With so many moving parts, the setup is not trivial. We (one of the Web teams) share our TravisCI setup here on Babbel Bytes in the hope that some of you find it helpful for your own applications.
Our application and its unit tests are written in JavaScript. Additionally, we have Selenium based UI tests written in Ruby. We use TravisCI to run all our tests and build the application for deployment. After a deployment, we also need to build a so-called Storybook and upload it to AWS S3. Storybook is a UI Development Environment. Finally, we check for vulnerabilities using a service called Snyk.
How similar are the words ‘hear’ and ‘here’?
There are many answers to that question. First and foremost, ‘hear’ and ‘here’ are indistinguishable in sound. Meaning, a fluent English speaker will pronounce ‘here’ just as they pronounce ‘hear’. However, ‘here’ and ‘hear’ are different semantically or, rather, their definitions are distinct. ‘Here’ and ‘hear’ are also different in spelling.
Spelling is a particularly important issue for our users, here, at Babbel. It’s common for language learners to make spelling mistakes in a new language. It’s also common for users to make typo mistakes while using a mobile or web application. As we’re constantly looking for ways to improve our language learners’ experience, these issues were addressed in a recent project by using a popular algorithm called Levenshtein distance.
A perfect blue sky. Warm sunshine. People wearing T-shirts and sunglasses. And yet, the orange and red leaves covering Berlin’s streets announce the cold season arriving soon. As we watch the leaves fall down, we start reflecting back on the warm summer day we all retreated out of the office to hack our hearts away working on brand new, exciting ideas at Hackday 2018. On June 7th, 110 Babbelonians (from Engineering, Product, Didactics, Marketing, and HR) took a break from their daily work and came up with a total of 18 projects entered into the final competition.
For many agile software engineering teams, it is common practice to estimate the complexity of the user stories that they will be working on. Estimation is not an exact science and so they choose t-shirt sizes, story points, or other non-time based scales to account for the uncertainty that is inherent to software development. Over time, a team of individual software developers gradually comes to an implicitly shared understanding of what degree of complexity each value on their chosen scale represents.
This implicitly shared understanding can easily be challenged, though, when a new joiner to the engineering team or colleagues from different disciplines (e.g. product management, product design, …) pose the supposedly simple question: “What do 5 story points mean in your team?” For the remainder of this blog post, we will use story points when describing complexity. However, what’s being said can be transferred to other complexity scales, too. Translating the implicit agreement into words is, in fact, quite challenging. Most likely, every developer on the team will phrase her or his answer differently, especially in a cross-functional team.
AWS provides a lot of low-level monitoring for Lambda functions out-of-the-box: invocations, duration, errors, throttles — you name it. But if you want to monitor aspects of your business domain in CloudWatch, you have to do this yourself.
Let’s explore how you can send metrics from Lambda to CloudWatch Logs.