Out with the old, in with the new
When we incorprated Swat.engineering early 2017, we quickly registered the domain swat.engineering and put there some temporary information. Little did we know that “temporary” would mean 3 years.
We needed all our time to run a start up.
A few month ago a colleague in an EU project said: “Hey, Swat.engineering must be doing pretty well, since your website is never updated”. Indeed, we are doing very well as a company working on exciting projects with a range of clients.
So time for a new website. With an increasing team and increasing ambitions we want to clearly communicate our technical expertise and what kind of services we can deliver to our clients.
We asked Kitty Molenaar to create a good looking web site that conveys the professional values we stand for. We think she did a great job. The technical realization of Kitty’s design was done by Bas Vredeling from Code Culture. All content was produced by the Swat.engineering team.
We hope that this website will help you to identify how we can help you to control your software. Or just ask us how we can help you.
We love to hear from you at [email protected].
Recent posts
In this post, we discuss some of the problems and solutions of introducing domain-specific languages (DSLs) to store data in an existing application. But first, a brief recap. In the first post of this series, we explained why you might want to store some of your data in the form of text files written in a domain-specific language (DSL). Next, in the second post, we showed how some legacy applications can benefit from an intermediate solution where the data is already stored in text documents using JSON.
Writing typecheckers is hard because a myriad of constraints must be checked. That leads to entangled and difficult-to-maintain typechecker code. TypePal is a new approach to improve upon this situation. We use it in many projects at Swat.engineering, including the typechecker of the open-source Bird DSL.
Typechecking is necessary and cost-effective Typechecking is omnipresent but not always very visible. It ranges from a friendly notice from your IDE that a certain import in your program is unused to a harsh error that a function is called in the wrong way.