On 13.03.2016 we had three elections in Germany. In Sachsen-Anhalt, Baden-Württemberg and Rheinland-Pfalz the member of the local parlaments were elected. Our company (dimap – shareholder of infratest-dimap) were supporters for the Germany-wide TV-broadcaster “ARD” and the regional-wide TV-Broadcaster “SWR” (for Baden-Württemberg and Rheinland-Pfalz) and “MDR” (Sachsen-Anhalt).
We do the prediction and projection calculations, data analysis for these broadcasters and the production of the TV-ready animation of the results/analysis. On the “ARD” the results are presented live on a pretty large touch screen in an interactive way by a moderator, the other moderators (on the other broadcasters) prefer live full-screen presentation of the results.
We also do the exits polls (in around 600 polling stations in three countries) on the election sunday and analyse the evening results based on the interviews (around 85000 in three countries) given during the day.
While we have smaller, local tv-studio-teams in Mainz (Rheinland-Pfalz), Magdeburg (Sachsen-Anhalt) the main part of the personal is located where the ARD is broadcasting – this time in Stuttgart and organized by the “SWR” and “ARD”. They rent three large tents (one for “ARD”, one for “SWR” and one for the “ZDF”) on the area of “Neues Schloss” in Stuttgart. These tents contain the tv-studios, part of the broadcasting technology and behind these tents lots of containers for people working there (like us).
All the software we have build over the years are primarly target for live-broadcasting situations – the data itself is hold in an IN-RAM database C# based system to have maximum speed.
On earlier elections we also started to produce result-pages for “HbbTV”, but during this event we also produced for the first time election-results pages for the internet for the SWR in Baden-Württemberg and Rheinland-Pfalz. The results can be seen here:
The database technology behind our web-solution is Gemstone/S. The database is listening to our result-data-stream, is data-compatible to our older (main) C# in-ram-database and is a pure REST-API-based server system (not Seaside – just pure Zinc).
The system contains lots of logic to decide how new results are handled, which layout should be used for which customer and for which type of result. Then it produces/updates the broadcast-lists (automatically) for all the result pages on the customer-web-application and writes all the information into the file system.
Gemstone/S produces graphics-building description (for each result), which external applications query and transfer this information to a render server system – the rendered pictures are returned to the database and managed in the file system.
Several of these systems are running parallel to be able to minimize the risk of a hardware failure.
The system is located behind an Akamai-Caching system to reduce the load of our production servers, which is pretty low now.
The overall technical structure looks like:
During development we use our own modelling-tool PUM to maintain a model and create the data structures in several languages:
Just to add some comments here:
- We use REST in a RPC call way – nothing more
- As an additional communication library we use 0MQ
- We consider using 0MQ as a replacement for http in several situations
- C# code is also supported and was used in earlier versions, but the additional complexity of Mono/.NET was not worth the work
- Python is much more multi-platform friendly and performance is more than enough
- Python and/or C# code was needed due to these CPU-license limitations of Gemstone/S – otherwise too much work was put into the two-core license we had.
- Python usage lowers the acceptance problems of other non-Smalltalker programmers. Nobody will criticizes the usage of Python or C# in a project
- Python GUI stuff is done based on TkInter which gives us a pretty nice GUI under Windows, Linux and Mac OSX
- There is no suitable Smalltalk available on the market to offer a suitable GUI approach für Mac, Windows and Linux. VW is needless due to their license limitations
- As an alternative for the Python GUI stuff we use Sencha ExtJS for our internal GUI tools in a browser
- We used jQuery-Mobile for the customer-end-user GUI simply due to the fact, that we had to use the customer CSS files and those customers are simply jQuery oriented
- The support for multiple programming languages is a big step forward to accept Gemstone/S in the company and other programmers. Otherwise it would be *very* difficult to keep Gemstone/S
- Though the domain-model differs between our C# system and Gemstone/S system the programming model is more or less the same for the programmer, which is very comfortable
- We are heavily using the RcQueue classes to reduce conflicts and the optimistic locking approach and revision countings in the objects
- We are heavily using a communication model via RcQueues in different languages via REST-calls in different languages
Schrievkrom 
Leave a comment