I have been experimenting with the D programming language over the past couple of weeks. D is a native language and was conceived by Walter Bright. Although the language itself has been in development for many years already, it seems that it has been getting more traction over the last couple of years. The name D hints already at it’s reason d’etre: to be a better C++. Because of endless backwards compatibility and decades of evolution the C++ language has grown.
Development
We as programmers like to think otherwise, but we are by no means perfect. We do make mistakes all the time. One of the most important traits of a good programmer is to recognize this and, more importantly, to act upon it. If one takes on a development endeavor there is one obvious path that also happens to be the most error-prone. It is this path: you have an idea, you code, you startup your app, click through it once and you’re finished.
Just wanted to let you know that during the past year we have been working really hard at the successor of our human capital management solution. Our new product has been re-architectured in order to be fully multi-tenant, scalable and highly reliable. This is a huge step forwards compared to our previous product (Human Capital Manager) and allows us to really deliver our software as a service; no old technology wrapped in adapters here.
At the vari-arch workshop at the European Conference on Software Architecture (ECSA 2010), I presented my work on Active Components. Active Components are the building blocks in a software product line infrastructure that I have designed. In it’s design I have chosen flexibility over rigidity (i.e. a strong compositional way of specifying your software product, rather than driven by a central architecture). This gives better means to widen the scope of a software product line, something that was specifically the case at the ISV where I did my research.
A key distinction between SaaS and non-SaaS is the housing of multiple-tenants in a single instance. This required mass-customization techniques. Most of the customization, or variability, has to be defined at runtime; (re)deploying of the instance should be kept to a minimum! As an effect, the software system engineer has to design the application with support for runtime variability. For more advanced customization scenarios such as business logic and workflows, you will need a (turing-complete) programming language to support this.
