Generally, testing is perceived as boring, time consuming and 'expensive'. This is also the first question business people will ask when you propose it. 'Fine, but how much does it cost?'. This article should give you some sort of a hand-hold to determine what it might bring you and if the time is right.
A couple of blog posts ago we've set up a basic build-line, in particular for TypeScript. In this post we'll get our hands-on again and apply some automagic stuff for doing TDD and / or unit-testing on our builds.
A story about the risk of over-abstraction and false assumptions on technical debt.
There is tight coupling involved between a database structure and an application. There's no way around it. And that's okay. But what I think is not okay, is setting rules about the relations more than once.
During development you will work with lots of individual files, comments, testers and such, to ensure that the project is structurally sound, but also understandable for humans. But as soon as we deploy for our client, there will only be machines interpreting your code, and we’d like to get rid of all that isn’t strictly necessary and really get the highest performance we can get. In this article, I give an example of a routine for doing exactly that (with TypeScript as foundation)