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.
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.
Davide Ramaglietta and Alexander Gudulin from the R2D2 team of the Learning Engineering Area attended the biggest React conference in the world with 1200+ attendees. Here are their impressions on the event and opinions on what they heard:
We had the feeling that nowadays the hottest topics in the React community are state management, the switch of REST architecture in favour of GraphQL and the potentiality of React 16 and further.
So you’ve just switched to Kotlin and thought it would be great to have all your API entities written using data classes with proper nullability rules. You’ve set up your Gson objects and prepare to deserialize your API response and surprise! Your non-nullable fields are actually null…
This post explains what’s happening and why is this still an issue if you specify default values for your fields.
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.