A lot of companies nowadays depend on services provided by Amazon. Babbel is no exception. Calling these services through Http usually requires the requests to be signed. Although Amazon provides a vast amount of libraries that handle this for you, sometimes you need to use your own. Maybe the level of customization you’re seeking is not possible with the provided libraries. Maybe you want to add a feature that uses other 3rd party libraries that are incompatible with the ones provided by Amazon. Or maybe you simply want to avoid adding an entire library just to use a very small part of it. In this blog post, I’ll introduce an open source library we’ve built here at Babbel that signs OkHttp requests.
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.
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.
At Babbel Bytes, our engineers – ranging from Junior developers to seasoned programmers – write about findings, tips and tricks they encounter in their daily work at Babbel.
Join us at Babbel!
Find out what working at Babbel feels like and have a look at our current opportunities.