Category: Events

Open Source Love Day November 2009

Our Open Source Love Day for November 2009 brought love for EGit, the Eclipse git plugin and some frustration over lacking documentation.

Today, we celebrated our third Open Source Love Day (OSLD). It was slightly degraded by a company-wide illness outbreak, but we tried to make the best out of the situation.

Open Source Love Days are our way to show our appreciation and care to the Open Source software ecosystem. Our work wouldn’t be as fun or just not possible without professional Open Source software. You can read more about our motivation and specifica in our first OSLD blog posting.

You can participate at our OSLD by using the features we’ve built today:

  • We think git is an enrichment to the SCM market, as is Eclipse to the IDE market. Improving the quality of Eclipse’s git plugin is the next logical step. The ability to diff the content of two revisions in EGit was committed today. As a bonus, the name of the committer shows up in the right manner, too. See the screenshots to get the idea:

When developing EGit, we were already using it to pull the sources. Unfortunately, the repository URL changed bigtimes since our checkout without us noticing. This got us into trouble trying to follow the contributor guide. The command line version of git isn’t that communicative yet. But after all, this is a great time to learn about the real world problems when using git. The EGit contributor guide itself is a fantastic way for a project to show initial appreciation to volunteer efforts. Thanks for caring, guys! If you are interested to review our changes yourself, fetch the patch.

  • Another part of today’s work was on the KDevelop project. We tried to fix some outstanding little features or bugs, whatever is on the list of KDevelop 4. But we spent our day fixing our development machines instead. The Ubuntu linux operating system (8.10) was way too old to get useful results and KDE needs to be up-to-date to develop KDevelop. Besides our sluggishness to keep our virtual machines on the bleeding edge, the checkout experience of KDevelop was rather sleek. What bothers us a bit is the ominous entanglement between KDevelop and KDE. It seems you can’t have one without the other and need to master both to make a stand.
  • As a third part, we wanted to contribute to the TANGO project (not the useful icon collection, but the useful control system). They migrated their main repository from CVS to SVN lately, but the migration seems unfinished still. At least, the migration effort lacks public documentation for the occasional contributor. That’s a real showstopper, because you never get beyond the very first step: setting up a working project. We won’t give up and email the project leads on this topic, but it didn’t fit into this OSLD.

What were our lessons learnt today?

  • Just having a possibility to view or download the source code doesn’t make an Open Source project. The key to success is the ability of complete strangers to hop in and perform useful work. Having terse, but accurate documentation helps a lot. The EGit contributor guide is a good example of a single document that makes the difference. If you own an open source project and want to attract occassional contributors (like us), write such a document and watch us (and others) drop you a patch. That said, we come to belief that the person that writes technical documentation for the developers is one of the most important roles on a project. Perhaps we join some projects in the future to fill that role.

To sum it up, this OSLD was limited from the beginning by developer availibility. With lacking documentation, we nearly grinded to a halt. We look forward to our next OSLD in December.

A Campfire plugin for Hudson

Our last OSLD resulted in a new hudson plugin: a build notifier for Campfire. Right now it is pretty simple and just posts the last build result in a chat room:
Campfire-Notification

You can configure your account data and the room to join in the job config page under Post Build actions:
Hudson-Campfire
But there is more to come:

  • global config
  • SSL support
  • a link back to hudson

or what is your favorite missing feature?

Follow-up to Schneide “Dev Brunch” October 2009

A follow-up to our October 2009 Dev Brunch, summarizing the talks and providing bonus material.

brunch64Last weekend, we held our October Dev Brunch in the rooms of our company. This posting is the follow-up, summarizing the topics and providing additional information.

The Dev Brunch

Let me start by introducing the concept of a “Dev Brunch” as we perform it. Once a month, we spend nearly half a day of the weekend by meeting and talking about topics related to software development. The meeting starts at perfect brunch time, everybody brings along some brunchable food and the party begins.

Everybody who attains the Dev Brunch has to prepare a topic to tell about. We set a limit of 15 minutes for the talk and unlimited time for questions and discussion. We elect a moderator, though, to bring us back on course when we disgress too much.

To prepare a topic isn’t hard work. No slides are required, no written handout or code examples. You just have to work up a topic to fit it into 15 minutes.

The October 2009 Dev Brunch

The topics of this session were:

  • Java’s upcoming Fork/Join framework – Java 5 brought the util.concurrent classes, Java 7 will bring the Fork/Join framework to further ease concurrency in Java.
  • The current status of JIT on mobile devices – the tagline was “why is my Android phone so slow?”. This talk even included slides!
  • Project estimation with planning poker – the talk gave away the secrets of planning poker and even more secrets of how to sell it to the management.
  • Pitfalls of unit testing Spring infected code – Developers often mix up the framework with its concepts. The example given was dependency injection (concept) vs. Spring (framework).
  • First impressions of Scala – Tales of a first contact with Scala from a Java developer.

Several talks included bonus material that will be provided in the comment section of this blog posting. Most material will be in german, as were the talks. But to ease our international readers: most links within the bonus material point to english articles.

Stage your own Dev Brunch

We cannot stress this enough – holding your own Dev Brunch isn’t complicated but very valuable. Just invite your mates and bring food. Once you started, you’ll attract other developers from your vicinity and get to know them in an informal manner.

Our second Open Source Love Day (OSLD)

A retrospective report of our second Open Source Love Day (OSLD). We present the results of our work on hudson and git and the lessons learnt.

opensourceloveday

Today we celebrated our second Open Source Love Day (OSLD). When we say “celebrated”, we actually mean that all of us worked hard and concentrated for hours, just to have a short meeting with candy at the end of the day.

The Open Source Love Day is our way to show our appreciation to the Open Source software development ecosystem. We heavily rely on Open Source products for our customer projects, so it’s just fair to donate back. You can read more about our motivation and specifica in our first OSLD blog posting.

For this day, we adjusted the rules a bit. While Object Calisthenics are very powerful in formulating rather academic software development values in some easy-to-remember rules, they just don’t fit well with existing projects. We still kept the rules in mind, but didn’t follow them strictly. We also learnt our share from last time’s experience of jumping right into the middle of arbitrary projects without a real need to do so. Today, we scratched more of our own itches.

You can participate at our OSLD by using the feature we’ve built today:

  • Hudson gets a brand new plugin. Currently, it’s in alpha status and needs some more nurturing, but is planned to be published within the next few weeks. The proof of concept was successful today. You will read more about it on this blog soon.
  • Another of our hudson plugins, namely the cmake builder plugin, got some feature love, incorporating suggestions from plugin users. We especially thank Ole B. for his feedback. The new features are checked in and will be available with the next plugin version 0.6, scheduled to be published in a few days. You’ll read the details about the new features here.
  • We’ve produced a feature implementation for hudson, adding the ability to use environment variables for the job’s workspace path. This feature touches core hudson functionality, so we just proposed a patch and leave it up to the core hudson team to decide on its inclusion. For more details, head over to the hudson issue tracker, entry #3997.
  • And we didn’t forget about git. As we are multi-IDE users (today’s development took place using NetBeans, IDEA and Eclipse), the EGit eclipse plugin for git will soon have the ability to diff the content of two revisions. An undocumented method argument took too much time to finish the feature today. After email communication with the project owner, the feature works on our machine, but needs some polishing before being committed in the near future.

As you can see, the hudson continuous integration server received a great share of our today’s love. It’s a great tool with a great community that really deserves our contributions.

What were our lessons learnt today?

  • While implementing the variable expansion feature, the author got distracted by a similar concept and followed this red herring. Namely, instead of a hudson.util.VariableResolver, we needed to use the hudson.EnvVars class. The EnvVars are pre-filled with all global variables like JAVA_HOME, while the VariableResolver is not. This could have been avoided by looking at the actual code instead of just type names. Once you think you’ve found your type, you read code the wrong way just to sustain your assumption.
  • To implement advanced plugin features, whether for hudson or eclipse, is a matter of skill with the “monkey see, monkey do” development style. Documentation is mostly non-existent or out-dated.
  • When handling HTML and HTTP in java, some survival tricks are crucial. Stay tuned for a whole blog post on that topic.
  • We still don’t feel comfortable within the JGit source code, as we still lack advanced git feature and terminology knowledge and the project lacks documentation. Our part of the problem will decline over time, as it’s a question of tool/mindset/slang exposure.

To sum it up, this OSLD worked out much better than our first one. We had more fun and yielded better results, mostly because we adjusted our goals to better suit our working style.

What are your experiences with open source development? Drop a comment!

Our first Open Source Love Day (OSLD)

opensourcelovedayLast week we had our first OSLD and started with the usual hopes and fears:

  • how much time will be consumed setting the project up?
  • will we find issues that are small enough to be finished in one day?
  • the hope to learn something new: a new technology, language or tool
  • the hope to improve our skills in reading a different code style and a new codebase

As an additional challenge we tried to do object calisthenics (which we will covered in a different blog post). In short they are a list of coding guide lines which try to bend your mind to get more flexible when coding/designing software.

Start

After an initial meeting we decided to work on EGit/JGit. This project was on a familiar ground (Java) and had enough new tools (Git) and technologies (plugin development under Eclipse). Setup was very easy and fast (thanx to the EGit/JGit team!) and we started to look at the low hanging fruits linked from the EGit wiki which are basically issues that are categorized as easy. This is a very good idea for project newbies to start (in theory…). But the reality was that most of them were already patched and other had not enough information to make any sense for us (which could be also our lack of knowledge of the GIT wording and its internal concepts and function). At the end of the day we had worked on issues which were definitely too big for us (requiring changes in the infrastructure of JGit) and reported some issues as non-reproduceable.

Finish

So we learned a few things from the first day:

  • project setup can be very fast and easy
  • low hanging fruits are a very good idea
  • avoid infrastructure changes
  • a basic familiarity with the concepts involved is key to get along
  • don’t do too much on one day, instead: focus!
  • scratching your own itch would benefit the understanding of the issue and your motivation

So in the next month we give OSLD another chance and hope to learn even more.

Merry christmas – and check your candles before you light them

LED tea lights are dangerously akin to their waxen antetypes.

xmas-treeThe Softwareschneiderei (Schneide) team wishes you all a merry christmas and a happy new year.

We might pause this blog for a few weeks as everybody is on holiday.

This year, we sent out christmas cards that needed to be assembled. The card with a tea light made up a little latern. To have all batteries included, we bought some tea lights but couldn’t resist to buy some LED tea lights, too. The we put the parts together in giant envelopes and sent them out.

We got really nice feedback, but several reports suggested we might additionally package a warning note next time we send out LED tea lights that look too similar to traditional ones. The LED tea lights refuse to catch fire when burned, that’s for certain now.

So a word of warning in advance: Double-check your christmas tree candles before you kindle them. They might operate with batteries instead of fire.

We’ve won a prize!

When we switched our continuous integration platform from CruiseControl to Hudson, it was still a younhudsonbutler-149_50pxg project with many white areas on the project roadmap. But it already was powerful enough to handle our settings and delivered real value, so we eagerly wanted to contribute back.

The development process with “release early, release often” policy and community focussed drive fit right into our mindset, so we (in fact, mostly me) spent a few nights figuring out what and how to contribute. The effort materialized in a few private tweaks and a new plugin: the Crap4J hudson plugin.

With the knowledge of Hudson’s internals, we were able to help out various customers to set up their own sophisticated installations (which nearly led to the development of a Perforce plugin when Mike Wille finished his one right on time). This led to various bug reports and feature requests that we filed to Hudson’s issue database.

Soon afterwards, Sun Microsystems announced the GlassFish Awards Program (GAP) as part of the Community Innovation Awards Program. Hudson was part of the participating projects, so I gave it a try and submitted some feature requests and the plugin.

lauriersAnd we won a prize! It’s not the big sort of prize (look at position 50 in the list), but a reward for our filed issues and a honorable mention of the plugin (which truly stands no chance compared to the awesome work of Dr. Hafner, who contributed a complete “get-them-all” collection of useful metrics reporting plugins). At least, we are the only winner from Karlsruhe.

Lately, we blogged about awarding your customers. Well, that’s just what Sun did here. Thanks for that!

JTable index madness

A coworker of mine recently stumbled upon a strange looking JTable:
A broken down JTable

This reminded me of an effect I have seen several times. Digging through the source code of the JTable we found an unusual handling of TableEvents:

    public void tableChanged(TableModelEvent e) {
        if (e == null || e.getFirstRow() == TableModelEvent.HEADER_ROW) {
            // The whole thing changed
            clearSelectionAndLeadAnchor();

            rowModel = null;

            if (getAutoCreateColumnsFromModel()) {
		// This will effect invalidation of the JTable and JTableHeader.
                createDefaultColumnsFromModel();
		return;
	    }

	    resizeAndRepaint();
            return;
        }
...

The hidden problem here is that the value of TableModelEvent.HEADER_ROW is -1. So sending a TableEvent to the table with a obviously wrong index causes the table to reset discarding all renderers, column sizes, etc. And this is regardless of the type of the event (INSERT, UPDATE and DELETE). Yes, it is a bug in our implementation of the table model but instead of throwing an exception like IndexOutOfBounds it causes another event which resets the table. Not an easy bug to hunt down…

Das Ende einer Ära

Seit kurzer Zeit hat die Schneide den ersten Vertreter einer neuen Ära in der Computertechnik in Besitz: einen mechanikfreien Rechner.

Bisherige Elektronik funktionierte nie ohne einen Restbestand an Mechanik, die dann in bester Tradition auch zu den beliebtesten Verschleißteilen gehörte. Herausragendstes Beispiel waren/sind Festplatten (hier sei besonders die IBM DTLA/IC35-Todesserie genannt, die in der Schneide damals in Massen starb). Aber auch Lüfter gehören unüberhörbar zur Mechanik.

Unser neuer Rechner ist ein Hilfsserver, d.h. ein “Immer-an”-Rechner mit einer Aufgabe, die nur geringe Anforderungen stellt. Mehr zu dieser Aufgabe in den folgenden Beiträgen. Dementsprechend ist er kompakt und stromsparend konzipiert.

Ozone von vorne Ozone von der Seite

Wir entschieden uns für den kochbuchgroßen Thin-Client “Linux Via C7” der deutschen Firma Thinking Wires. Der Via C7 Prozessor ist als Nachfolger des in der Schneide vielfach eingesetzten C3 ein gerne gesehener, endlich vollständig 686-kompatibler Rechenknecht. Er lässt sich lüfterlos betreiben, so dass die Kühlung lautlos geschieht. Das passende Netzteil ist ein ebenfalls lautloses externes 65 Watt Netzteil. Die Festplatte wird durch ein sogenanntes Flash-IDE-Modul ersetzt, das bei uns mit 2GB Kapazität genug Platz für eine Ubuntu Server Installation hat.

Dieses Flash-Laufwerk ist garantiert kein Geschwindigkeitswunder (die Installation des Betriebssystems dauerte fast zwei Stunden gegenüber 10 Minuten auf einem normalen Server), aber dafür wirklich komplett lautlos.

Der ganze Rechner liefert im Betrieb nur ein leises Summen (bzw. Bruzzeln, wenn man pessimistisch formuliert), das in einem Meter Abstand nur noch hörbar ist, wenn sonst keine Geräuschquelle in der Nähe ist. Da unser Rechner direkt neben dem Code Flow-O-Meter steht und dieses entsprechend unserer Produktivität meistens läuft, ist das kein Problem.

Wir haben den Rechner “Ozone” genannt. Dabei ist uns selbst nicht klar, was der Name wirklich aussagen will:

  • Ozon: Mehr als Ozon wird durch den Rechner nicht emittiert
  • 0Sone: Das Betriebsgeräusch liegt bei fast Null Sone
  • Onoez: Mal wieder alles falsch geschrieben…

Und wofür brauchen wir diesen Rechner? Das verraten wir erst in den nächsten Beiträgen. Nur ein Tipp: Die ONOZ-Lamp gehört zum Einsatzzweck dazu.

Lethal risks of bugfree software

Bei der routinemäßigen Kontrolle unserer Continous Integration Server Hardware fanden wir heute eine tote Spinne auf dem Mainboard. Das ist sehr bedauerlich für das arme Tier, wir glauben aber zu wissen, woran sie gestorben ist: Verhungert wegen zu wenigen Bugs.

Eventuell hätte sie in einen Entwicklerrechner ziehen sollen.