Tweets by Donnie - Building a serverless sentiment analysis application with the twitter streaming API, Lambda and Kinesis

tweets-by-donnie dashboard

 

Thinking of Trumps tweets it’s pretty obvious that they are controversial. Trying to gain insights of how controversial his tweets really are, we created tweets-by-donnie.

“It’s freezing and snowing in New York — we need global warming!”
Donald J. Trump

You decide if it’s meant as a joke or not.

But wouldn’t it be nice to know whether the public is seeing this as a joke or whether it’s getting upset by it? That’s where our idea originated from. By measuring the emotions presented in the responses we can see what the public is thinking of Trumps posts throughout the day.

Continue reading

Testing a MongoDB with NodeJS, Mocha and Mongoose

Related articles: ►Take Me Home – Project Overview  ►CI/CD infrastructure: Choosing and setting up a server with Jenkins as Docker image Android SDK and emulator in Docker for testing  ►Automated Unit- and GUI-Testing for Android in Jenkins 


Setting up the testing environment and workflow

Setup:

  • Jenkins CI Docker Container
  • MongoDB Docker Container
  • Production-MongoDB on mlab.com
  • NodeJS Web-Application, hosted on heroku.com

Regarding our database tests we wanted to achieve two things: first of all, we wanted to test any functions of our web application using mongoose which change persistent data. Secondly, we needed database tests to test if eventual model-changes are compatible with our data in the production database.
In relational database management systems one defines constraints in the database, which are tested by the database tests. Since we are using MongoDB though, we don’t really have any constraint in the database. Instead we can define any needed constraints with mongoose right in the application. Therefore, cloning the production database for testing is only required when migrating data (or when having constraints defined) but non-essential for the consistency of the as-is backend.
So alternatively when testing a MongoDB we could also use a shell-script or a “before”-function, that gets called once before starting the tests, to define our database testing environment, like creating the same collections we have in the production database and put in test data for our test cases.
Continue reading

Building an HdM Alexa Skill – Part 3

Test-driven Development of an Alexa Skill with Node.js

This is the third part in a series of blog posts in which we will describe the process of developing an Amazon Alexa Skill while focusing on using new technologies like serverless computing and enforcing the use of clean code conventions. We decided for our project to use continuous integration and delivery. For that to work as it should and to prevent unnecessary bugs from being discovered by the user, we relied on test-driven development for our code.

Continue reading

Building an HdM Alexa Skill – Part 2

Decisions, Developed Modules and Implementation

If you missed the first part you can catch up by reading it here.

In the second part of our blog post series, we first describe what decisions were made in the course of the development process, then we show which code we actually had to develop on ourselves and finally we give an overview on how we implemented the skill.

So let’s get started with how we ended up from the inital idea of developing a chatbot to the development of an Alexa Skill.

Continue reading