On November 28-29, a fellow engineer from the Payment team, Karen, and I attended the European Women in Tech Conference in Amsterdam. It was my first tech conference and it was definitely the first event I have ever attended where the only males to be seen were cameramen and members of staff 🤭 On a more serious note, we spent the two days chatting with professionals in the field (both tech women and women-in-tech) and listening to inspiring talks from leading women of tech companies, such as Amazon, Facebook, Xing, Arm, just to name a few.
This is the second in a series of blog posts entitled “How We Work” in which we share with you how we work in Engineering @ Babbel.
Without history, there is no future.
To effectively make technical decisions we need to share a common understanding on the context in which we work. Thus, we need to know “how did we get here?” and then “where do we want to go?”.
AWS Lambda is a powerful tool to build serverless applications, especially when backed by APIGateway and Swagger. Lambda executes your code without the need for you to manage a dedicated server. APIGateway provides a front-end for your Lambda to be easily accessed from the Internet via endpoints that can be configured with the Swagger framework. In this article we’ll take a look at one specific example of an AJAX endpoint that uses custom path parameters, something typically problematic to implement because of Swagger limitations.
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:
- Prioritizing tasks related to the engineering strategy proved difficult because we had no way to judge their importance
- Tasks were often started but not finished because there was a lack of time and urgency
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.
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.