Whether you have a small frontend service, a big monolith, are building an MVP or a production grade application — having a Continuous Integration service running for commits will help your development speed and quality greatly.
Continuous Integration services nowadays are very easy to set up, support Dockerfiles, and are very cheap. They support picking up every code change or specific branches, and running your scripts so that you can implement checks for every code you commit and will never forget about running your unit tests. …
Here are the most important parts of every production-ready Express stack — regardless of whether you already have an app in production, or are starting up, follow these pointers to make sure your app will be able to scale team-wise and user-wise.
If you are developing a small application, want to have full control, understand how everything is put together, or have requirements that do not fit well with traditional APIs, Express is well-suited for the job.
Your startup finally managed to win a big client, but they ask you to go through a security audit first?
For most big corporates, making sure their suppliers fulfill basic security best-practices is mandatory. After all, if their suppliers work with personally identifiable information of potentially thousands of employees, or might get to know their trade secrets, not accidentally leaking this data to anyone is very important.
This is why most corporates have a standardized audit they do before new suppliers are allowed to deliver their services. Normally, these audits start right after winning a new deal — you would…
Nowadays, most software development teams have adopted agile methodologies for their development process. Scrum, in particular, can be found everywhere — in small agencies doing outsourced work for clients, in big corporations with many teams and many products, and of course in small startups where cross-functional agile development work is key to survival.
Scrum has just a few basic rules, and this low-entry barrier certainly helped to make it the go-to methodology for software-developing companies. The initial cost of setting it up is low, as it does not require lengthy training or many prerequisites. It doesn’t require expensive certificates, consultants…
One fundamental truth of software development is that there will be bugs, and this includes all sorts of quirks like coding errors, issues that arise because a dependency is offline, visual inconsistencies that occur because a mockup was misunderstood, and much more.
Whilst there are many techniques that help in increasing the quality of code, such as test-driven development and the SOLID principles; and whilst there are many other techniques that help in catching bugs early, such as regression tests, load tests, and much more, bugs will still occur and annoy your users.
Luckily, there are also a few techniques…
If you disagree, I suggest you just try it out on at least some of your often-called code and compare uncaught exceptions before and after via an error reporting tool.
When you add types to your codebase, chances are that you will notice dead code due to logical errors, unchecked access to potentially nullable variables, functions with too many concerns (input/output parameters), and more, which will immediately help to reduce the number of…
Once you start using AWS and notice setting up everything via the UI is tedious and error-prone, you’ll love using Terraform to describe your infrastructure in a versioned and transparent way — it’s the AWS-agnostic alternative to CloudFormation, but it does come with drawbacks.
One of the drawbacks is that you are not just running into AWS’s pitfalls, but also Terraform’s own little quirks, which is why even simple things like setting up an SSL certificate for the first time may become time-consuming.
There’s a very simple trick applicable to most companies with IT development that helps making the development process much easier and more transparent, whilst enabling everyone in it to become more agile.
What is the trick, you ask? Stop developing in separate repositories and follow a mono-repository approach.
Or, let me rephrase: Whatever your company builds and needs to continuously integrate with each other has to be in the same repository. If your company develops a suite of different tools, not related whatsoever, then off you go, continue using separate repositories for that.
However, if your company develops anything else…
Imagine this: It’s the year 2019. We have self-driving cars (or at least great marketing). Coding is becoming a regular part of curriculums around the globe. Even business managers know that agile is king. You can spin up your start-up in the cloud, with nothing but code; and writing good code has become easier ever since thanks to great frameworks, communities like StackOverflow, thousands of books, and an ever-growing number of open source libraries doing grunt work for us.
But still, we are all human, or in other words, sometimes sloppy, unfocused, inexperienced, unaware, and at times simply do not…
Whether you are a new developer, a senior systems administrator, or a product developer, there are many software development principles you have already heard or read about a lot; either, they are a part of every book on development, something thousands of tutorials have been written for, or something your company wiki lists as a good practice.
We all have heard of them — be it the SOLID principles for writing good code; the agile principles for making more progress with cross-functional teams in sprints; the extreme programming principles like Continuous Integration; or others.
Once you hear of them, it’s…
writes about web development, starting up, and managing projects and people.