At Avisi we use a custom built EJB 3 based application for scheduling and running (automated) regression tests. This involves a queue from which objects are taken. These objects contain metadata describing the tests to execute. I won’t go into detail as to why we aren’t using Apache ActiveMQ (or a similar library) for this purpose, but I can say that we didn’t need distributed test-executing minions at that time.
Continuous integration and code quality management tools are pretty much used by every project. And it’s a must if you are in for high quality code. But these tools also need to be managed… or they will manage you.
Last week we held our monthly techday, this time the topic was an introduction to NoSQL databases.
When you are the driver in a pair programming session and you find your navigator grabbing the keyboard all the time it’s time for a good talk. The rule is simple: You hand off the keyboard when pair programming, you don’t grab it.
In my previous post (Part I – Introduction) I gave an introduction to Walle, Avisi’s information radiator. After making some high-level design decisions we started focussing on developing the front-end. When we got the final version of the visual design, it appeared that HTML5, CSS3, jQuery and websockets could make it work. This post shows some highlights of the HTML5 and CSS3 features we used.
Our company culture is based on transparency. As a consequence, visibility and measurement tools are essential to us. In the past, we built several dashboards for Confluence, JIRA, Sonar, Jenkins, Nagios, etc., because dashboards are excellent at making things visible for everyone. The problem with them however has been that they would usually display information for only one target audience at a time.
We then built Walle, an information radiator, to give insight into all the work disciplines combined (development, test, support and systems management). The main objectives behind the build were: to gather all the relevant project information in one central place; to enable anyone to react instantly when needed, to make everyone involved feel responsible for the entire project.
When working with file uploads from a browser it is good to realize that you don’t know what is coming. Character set wise that is. You simply do not get a hint from your browser that says: here is a UTF-8 encoded Unicode text file. Or, beware, this document I am sending you now is created on a Windows machine, using the windows-1252 character set.
Why don’t browsers do this? The answer is rather simple: they don’t have a clue either. The file is read from disk and most file systems don’t store meta information on character set or encoding.
How do we correctly deal with that? There is only 1 valid option. The person uploading the file must tell us what it is. If you have a form with a file upload, put a drop down next to it with a list of character sets and let the user indicate what he is sending. If it’s a system sending in files via REST make sure you know what it sending, or give it a parameter to indicate the character set used.
That is the only solution that is 100% guaranteed. If you want to try something more advanced, look at IBM’s icu project (Java / C/ C++). It has functionality that detects the charset or encoding of character data in an unknown format, but the results can not be guaranteed to always be correct.
Just a reminder:
inspired by http://www.goodfuckingdesignadvice.com/ (the family friendly version of course). Not only funny, but very valuable advice. Not just for designers.
I’m currently working on a project that involves the use of the Apache Shindig OpenSocial container. As you may know Shindig relies heavily on caching, which is no surprise considering where Shindig originally came from (i.e. iGoogle, with millions of users).
This is the first in a series of summaries of our monthly “Techday” events. We organize them because we like to stay sharp and have fun. Check out our previous blog post about why we do techdays.
The first techday of 2012 was about Mendix. Mendix is both a company and a Rapid Application Development (RAD) tool. FraternIT demonstrated how simple it is to create a new application in Mendix. After a short introduction, we got to try it out for ourselves.