I remember back then I used think of this as a “wrapper” of my JQuery code and go on with my life without trying to find out what it’s actually doing. So let’s deconstruct this code together.
One way to evaluate the code is to profile it. Luckily, Node.js already provides us with a profiler, behind the
--prof flag. So let’s just run our app with the profiler.
node --prof build/server.js
You can see that a
isolate-0x....-v8.log file is created in your working directory. Now let’s stress test our app with ApacheBench.
ab -k -c 1000 -n 10000 -T "application/json" -p post.data "http://localhost:3000/slack/events"
After waiting for about a minute, the stress test is complete. We can terminate our process and start analyzing the logs. We can do that by executing something like this:
node --prof-process isolate-0x102801e00-v8.log …
As we strived to serve Scrum.ai as a Software-as-a-service, we need to be ready for everything, that includes scaling and security aspects.
One way to test if our app can handle a big volume of request is though stress testing. For this purpose, I came across a novel tool called ab, or ApacheBench. It’s easy to use and give a fairly good metrics to evaluate.
Let’s start with testing our landing page.
ab -n 1000 -c 50 -s 3 https://scrum-ai-test.herokuapp.com/
Here we define the number of request we want to stress test, that is 1000 request (the landing page is…
Here’s the thing. I’ve always thought of Test Driven Development as a burden, slowing the development time of critical features that needed to be shipped as soon as possible. Well, it seems I’m not the only one thinking this way, just look at the interesting numbers in this article:
Nearly half of the respondents have not implemented a BDD/ATDD/TDD approach.
It seems there is a strong resentment among certain programmers to the idea of doing something that seems to be “useless” rather than doing what they like, writing code that works toward implementing features.
Well, after being forced to practice…
Check out the earlier story:
Let’s start from the Agile Manifesto. As we know, there are 4 points in the manifesto:
Checkout the previous story:
As you can see, we follow microservices architecture to emphasise on scalability and prevent system wide failure.
Let’s walk through the architecture bit by bit.
This is the main service that will contain most of the logic on an abstraction level. We host it in the We also plugs our database to this instance, with some redundancies/replicas as needed as we scale. The Main Service will communicate mainly with the Queue Service, although we also tightly use KataPlatform API to enable Natural Language Understanding to our bot.
As we grow to a Software-as-a-Service product, we expect…
A bit of background of our stack before we dive into the architecture.
Who doesn’t know about agility? It has become such a common stats in games such as RPGs as the main stats for ranger, thief, and so on. Well, outside the context of games, the term agile is also used in the context of software development. Here at Scrum.ai, we are building tools to help you with agile software development, of course in the development, we utilize this so-called agile software development too.
In the early days of software development, software projects is often developed using a model called the Waterfall Model. It can be described as a series of phases…
If you’re reading this article, you most likely have already known a few popular example of DBMS or Database Management System like MySQL, MS-SQL, PostgreSQL, or even the NoSQL one like MongoDB or Redis.
A database-management system (DBMS) is a computer-software application that interacts with end-users, other applications, and the database itself to capture and analyze data. A general-purpose DBMS allows the definition, creation, querying, update, and administration of databases. — Wikipedia
Choosing a DBMS is a topic of its own, but we have chosen to use PostgreSQL considering a few things:
Express has long been the de facto standard and mainstream pick when you start a project in Node.js. But recently (well, not that recent), the team behind Express has started a new, shiny library called Koa.js with a different phillosophy in mind.
Why isn’t Koa just Express 4.0? Koa is a pretty large departure from what people know about Express, the design is fundamentally much different, so the migration from Express 3.0 to this Express 4.0 would effectively mean rewriting the entire application, so we thought it would be more appropriate to create a new library. — Koa vs. Express