CoffeeScript

Vert.x supports JavaScript through the Rhino JavaScript engine. Although JavaScript is a decent language once you get to know it, I prefer CoffeeScript, a language that compiles to JavaScript. Luckily, vert.x has built-in support for CoffeeScript, so I can use it nearly transparently. You will only notice the JavaScript under the hood when reading stack traces, which will refer to the compiled JavaScript file.

For the examples in this blog post, the only thing you need to know a little CoffeeScript:

foo = (a, b) -> a + b

Translates to the JavaScript code

Aloha, liebe Freunde des Visitenkarten-Bullshit-Bingos. Ich brauche eure Hülfe! Mich treibt folgende Frage um: „Welche Titel soll synyx in Zukunft auf den Visitenkarten und in E-Mail-Signaturen verwenden?“

Wir werden in absehbarer Zeit in ein anderes Büro umziehen. Sprich, eine neue Anschrift haben. Das wiederum bedeutet, dass wir unsere alten Visitenkarten entsorgen können und neue benötigen. Also, ein guter Zeitpunkt sich Gedanken über die jeweiligen Titel auf den Visitenkarten zu machen.

The last few blogs about acceptance-testing focused on setting up a nice and scalable infrastructure to do testing through the (web)-GUI using a Selenium grid. Since we've got this running now we can go on to topics that focus how we write these tests. At synyx we try to write our web-tests as "acceptance-tests" so we first take a small dive into what that is.

Event-Driven Concurrency

At synyx, we are looking at vert.x for an upcoming project where we are building a system that will need to scale under load. The tag-line of vert.x is effortless asynchronous application development for the modern web and enterprise, which fits the bill, so I decided to play around with it a little bit.

The advantage of event-driven concurrency compared to traditional technologies is the reduced risk of deadlocks, livelocks and race conditions. Using mutexes and semaphores correctly is extremely difficult and can lead to very subtle bugs that are difficult to reproduce. The downside is that information can only be shared by passing messages.

In this post, we want to show you our Liquibase setup in a larger scale project that we've been developing for some time now.

Gather Requirements

First off, a bit more information about the project and the whole project environment:

• The software developed in this project consists of different applications
• Some applications use the same database, some use different ones
• The software runs in multiple branch offices of a company
• Not every application runs in every branch office
• Some of the data in the databases of the branch offices is the same as in the others, some isn't

A few words about Continuous Deployment

Continuous Deployment is the deployment or release of code to Production as soon as it is ready. (...) The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button).
Once you have moved to a Continuous Deployment process, you will have to have several pieces of automation in place. You must automate your Continuous Integration Build Server and Continuous Delivery to Staging, as well as have the ability to automatically deploy to Production.
Read full blog post

Mit diesem Blog-Beitrag möchte ich etwas Einblick in die Unternehmensstrategie, die „Denke“ und Werte von synyx geben - und, natürlich aufzeigen, was das Ganze mit Google's „80/20 Formel" zu tun hat. Seit Mitte Oktober bin ich hier für Sales verantwortlich. Vor mir gab es in der Firma noch keinen Vertriebsmitarbeiter. Von daher war und ist es immer noch eine Herausforderung, die eigenen aber natürlich unterschiedlichen Erfahrungen, wie Unternehmen funktionieren und sich entwickeln können, auf einen gemeinsamen Nenner zu bringen. Eine spannende Aufgabe, vor allem auch, weil es bei synyx keine Entscheidungen von „Oben“ herab gibt, sondern wirklich alles im Team/in der Firma diskutiert und beschlossen wird. Das macht das Ganze natürlich sehr spannend, weil man die Kollegen für seine Ideen begeistern muss.

A few years ago, a good friend of mine installed a small photovoltaic system on his roof. I'm very exited about installing some solar panels on a roof and start producing electricity. It turned out that the installed inverters have massive quality problems. So the idea was born to monitor the whole setup like i know it from computer systems. Each inverter in this system has a serial port interface to transmit data.
But at this time, the market of low cost and low power consuming computers wasn't distinct as it is nowadays. In February 2012, the Raspberry Pi Foundation started to sell Raspberry Pis. I saw this as a chance to get a cheap computer with a minimal power consumption.

In the last posts we set up our infrastructure to be able to aquire Browsers that run on a remote host and we created a selenium Grid infrastructure that is scalable and reboot safe.

Within this post I want to describe how to extend the grid with windows nodes to be able to test on our beloved Internet Explorer.

Adding windows nodes to the grid

To be able to run tests on Windows browsers I wanted to go a similar way as on the linux-machines: As soon as the machine boots the selenium-server should get started and registers itself to the selenium-hub (set up like mentioned before).

This expands on the idea in the first part of this blog series.  We will still be working NIH style here - this time to improve the visuals, user-interface and information density.

The idea still is:  collect arbitrary information, stay small, display distilled information.  The goal is to learn more how to visualize things, and of course do it within the constraints mentioned in the previous blog entry.

Prototype #2

General idea:

• Web interface (Cubism)
• real database
• real programming language