This week we're installing HTTPS certificates for the tracking domains of all our customers. We use the Let's Encrypt API to get a certificate for every registered sender domain. This allows us to secure all hyperlinks from all the mailings that are sent from our servers.
Users who've used the Copernica SOAP API to construct URL's to share emailing statistics should take notice. We've made a change to the SOAP API that could require that you make changes to your SOAP scripts.
A couple of years ago I encountered a PHP framework that claimed to be based on the “Model View Controller” (MVC) pattern for the first time. When I heard about this, I was seriously surprised because PHP is not at all an appropriate programming language for making MVC applications. But nowadays there are many different PHP frameworks that also claim to be MVC – but as far as I have seen, this claim is still as ridiculous as it was for the first would-be MVC framework that I saw. PHP and MVC are not compatible with each other, and it is about time that we stop calling each PHP framework MVC.
Logging on and managing users, accounts and company information in Copernica can sometimes be confusing. Copernica is not a simple single-user system, but a multi-user, multi-account and multi-company environment. In this blog I will explain how these concepts relate to each other, and what consequences this has for licensing and invoicing.
We recently introduced a number of changes to our incident system. We have almost completely rewritten the system "under the hood" so that it is now fully integrated in the Copernica architecture. As a result of the changes, end users can now use their Copernica user name to access the full support history. We also changed the notification mails that are sent when the status of an incident changes, and made changes to the Copernica.com pages on which you can review our answer.
At Copernica we have split up the development process in a number of steps to ensure that all things we do are well tested before they reach the production phase. The work has essentially been split up in the following steps:
To provide the performance and high availability that Copernica.com customers expect, we run a cluster of (many) physical servers. With a few exceptions, all these servers are multi-CPU blades with a large amount of memory, that are the host of even more virtual servers. Those virtual servers are controlled through PHP scripts that make use of a customized libvirt PHP extension.
At Copernica we use a cluster of Dell EqualLogic SAN devices as storage backend for our database servers. To get the best possible performance from MySQL running on a SAN we have spent quite some time on configuring the database servers for low latency and high throughput - and we discovered that the official Dell advice to use the noop disk scheduler does not always give the best performance
We will soon replace the email library of Copernica Marketing Software. This library is responsible for both generating MIME messages (it turns an email object into a string) and for doing the opposite: to parse MIME strings into useful objects.
Among the many things that we do at the Copernica R&D department is the transition to a new object model. Our software has (of course) a layered architecture in which the user interface, the data storage layer and the object model are all seperated. The current data layer in this setup is called POM which stands for Publisher Object Model. But this is about to change.
An overview of improvements you can make while using the SOAP API to connect to Copernica Marketing Software.
