…so lässt sich am besten meine bisherige Erfahrung mit der ICANS beschreiben. Um mich kurz vorzustellen: Ich heiße Ansgar Mertens und fange erst im September als Dualer Student bei der ICANS an. Kaum hatte ich im Dezember den Vertrag unterzeichnet, wurde ich auch schon zu Firmenevents wie der Weihnachtsfeier oder dem Kneipenabend eingeladen. Doch wirklich überrascht war ich, als in den Osterferien das Telefon klingelte und ich gefragt wurde, ob ich denn nicht zur droidcon nach Berlin fahren möchte. Und ob ich da Lust zu hatte! Android hat mich schließlich zum Programmieren gebracht. Also fuhr ich gemeinsam mit Sven, der bei der ICANS für iOS verantwortlich ist, am Dienstag mit der Bahn nach Berlin.

Der erste Vortrag, den wir uns anhörten, war von Simon Stewart, der in London für Facebook arbeitet. Er erörterte wie Facebook seine Androidapps, welche auf Unmengen von Geräten installiert sind, entwickelt. Zur Verwaltung des Quellcodes wird hier git mit nur einem tree für alle Apps (Facebook, Instagram, etc.) zusammen verwendet und mit einem eigens entwickelten Buildsystem kompiliert. Um sauberen Code und einen 4 Wochen-Update-Zyklus einhalten zu können, wird bei Facebook lieber mal auf neue Features verzichtet.

Der darauf folgende Vortrag von Markus Junginger zeigte gelernte Lektionen bei der Entwicklung und Veröffentlichung der TV-Programm-App „Prime Guide“. So empfiehlt Junginger beispielsweise eine Beta-Version zu Veröffentlichen, da Nutzer aufgrund des Beta-Status toleranter seien und man so konstruktiveres Feedback bekäme. Bei Prime Guide findet aufgrund einfacherer Skalierbarkeit die Google App Engine als Backend Anwendung.

Für die Mittagspause hat sich der Veranstalter echt ins Zeug gelegt. Es gab unter anderem Zitronenhühnchen in Weißweinsud und Spinat-Ricotta-Lasagne. Lecker!

Und weiter geht’s mit den Vorträgen: „Improving Android Experience For Both Users And Developers“ von Pavel Lahoda. Das klingt doch interessant. Und mal wieder richtiges Englisch. Lahoda stellt fest was allen Android-Developern bereits klar war: Die XML-Layouts sind nicht flexibel genug. So gibt es keine zufriedenstellende Möglichkeit mit Prozentwerten zu arbeiten. Dafür liefert er aber auch gleich einen Lösungsansatz, der in der Praxis bei der App „BBC NEWS“ angewendet wurde. Man verwendet eine sogenannte Custom View, die per Java definiert wird, und deren Größe in onMeasure() berechnet und festgelegt werden kann. Im weiteren Verlauf seines Vortrages schlägt er einen neuen TimePicker-Dialog mit dem Aussehen einer Analoguhr vor und stößt am Ende seines Vortrages an, sich doch mal mit Bewegungsgesten des Gerätes in der Hand auseinanderzusetzen und zu prüfen, ob es dort nicht weitere Interaktionsmöglichkeiten gibt, die praktikabel sein könnten.

An diesem Tag hörten wir uns noch zwei weitere Vorträge an. Der eine von Leif Janzig über das Bauen von Android-Apps mit Jenkins und automatisierten Device-Tests und im anderen schlug Matt Brenner ein „EventConsumer“ Design Pattern vor.

Neben den Vorträgen gab es viele Stände von Unternehmen der Branche, welche am laufenden Meter versuchten entweder Entwickler für ihr Produkt oder als neue Mitarbeiter zu begeistern.

Insgesamt hat mir der Besuch auf der droidcon sehr viel Spaß gemacht und ich durfte einiges dazu lernen. Vielen Dank an die ICANS!

Thomas Steiner hielt einen Vortrag über seine aktuelle Arbeit, in der er Echtzeit-Änderungen von Wikipedia-Artikeln automatisch analysiert, um damit aktuelle große Ereignisse auf der Welt zu erkennen – und das natürlich schneller als traditionelle Zeitungen. Seine Slides hat er – in guter Googler-Manier – als Google Docs Presentation abgelegt.

Für mich persönlich spannend fand ich bei diesem Vortrag zum Einen die Einfachheit des Codes (Node.js) und zweitens die Tatsache, dass es IRC-Chats gibt, über die alle aktuellen Änderungen an Wikipedia zugänglich gemacht werden – wirklich ALLE!

Nach einer kurzen Pause startete der zweite Vortrag von Robert Kowalski. Robert präsentierte aktuellste Entwicklungen heutiger Browser in der Unterstützung von ECMAScript 6. Einige interessante Features sind bereits schon in heutigen Versionen enthalten, wobei der Standard sich noch in der Entwicklung befindet. Klar sollte man nicht einfach alles blind anwenden in seinem Produktionscode, dennoch kann man einen Blick riskieren :-). Roberts Slides findet ihr hier.

Video-Mitschnitte der Talks könnt ihr bei Lecture2Go finden.

Fazit: Es war ein sehr aufschlussreicher Abend! Nicht nur die Vorträge waren spannend, auch die Diskussionen während des “Socializing” danach waren interessant.

Nun noch ein paar Impressionen des gestrigen Abends.

Einführende Worte @ HH.js Meetup

Thomas Steiner @ HH.js Meetup

Thomas Steiner @ HH.js Meetup

Robert Kowalski @ HH.js Meetup

Robert Kowalski @ HH.js Meetup

Menschenmenge @ HH.js Meetup

Biervorrat @ HH.js Meetup

ich bin Marco Eichberg und studiere zurzeit im 6. Semester Kommunikationsdesign in Hamburg. Seit November arbeite ich als Werkstudent in der Design-Abteilung und unterstütze die Kreativen bei der Umsetzung ihrer Design-Aufträge.
Unser Design-Team arbeitet in sehr vielen Bereichen: Von Web-Design über Illustration bis hin zu Printanzeigen und Merchandise Artikeln. So auch für den Kneipenabend in unserer Cafeteria, zu dem auch unsere Alumni eingeladen wurden.
Es gab lecker Spanferkel, frischen Salat, Tofu-Würste, Cola, Bier, Wasser und a kneipentypische Aktivitäten wie Kickertische und einen Spielautomat.
Für mich persönlich war es das erste Event bei der ICANS und es wird mit Sicherheit nicht das letzte gewesen sein!

Obwohl ich ein Werkstudent bin fühle ich mich vollständig in das Design-Team integriert und unterstütze jeden Einzelnen mit meinen Skills. Eine meiner Aufgaben war es, zusammen mit Annekathrin ein Plakat und einen Bierdeckel für das interne Kneipenevent zu gestalten. Für das Plakat, das hauptsächlich Annekathrin gestaltet hat, habe ich ihr bei der Bildrecherche geholfen. Beim Auswerten der Bilder und beim Vergleich zum finalen
Plakatdesign konnte ich vieles dazulernen:

• die Stimmung des Bildes musste zu der Art Veranstaltung passen, die wir ankündigen wollen (Farbgebung warm, gemütlich, kneipenartig)
• das Motiv sollte eine Spielmöglichkeit abbilden, die am Abend auch ein aktives Beisammensein im Spiel ermöglichen sollte
• da Kickern unsere Haupt-Spielaktivität ist – bot sich ein Kickerstisch an
• das Bild sollte ruhige Bereiche aufweisen, in denen wir Text gut platzieren können
• weil Text und Motiv sich gegenseitig beeinflussen- bot sich die Lampe an, um die Aktivitäten in eine Art Spotlight zu rücken
• da das Motiv optisch horizontale/vertikalen Aufbau aufweist, lockerte schräg angeordneter Text die Strenge wieder auf

Auf dem Plakat aufbauend war es dann meine Aufgabe die Bierdeckel zu gestalten.
Schritt für Schritt sind Annekathrin und ich gemeinsam durch die einzelnen Steps gegangen:

Als erstes wurde ich von Annekathrin gebrieft. Mir wurde erklärt worauf ich bei der Gestaltung achten soll, welche Schrift und Gestaltungselemente ich für den Bierdeckel übernehmen kann und wie die Daten für den Druck aufzubereiten sind.
Danach habe ich die ersten Drafts erstellt und das Feedback von Annekathrin eingeholt.
Nachdem wir uns auf die 3 besten Entwürfe geeinigt hatten, habe ich die Drafts an unser Event-Team geschickt, die uns den Auftrag für die Erstellung der Printmedien gegeben hatte. Die Entscheidung fiel schnell,  so dass ich noch am selben Tag die Entwürfe reinzeichnen und für die Druckerei vorbereiten konnte. Nach mehrfacher Kontrolle (und 4-Augen Prinzip ;) ) habe ich das PDF erstellt und per E-Mail an die Druckerei versendet… Fertig!

Nach einer Woche waren meine ersten selbst gestalteten Bierdeckel da :)

Mir hat das ganze Projekt sehr viel Spaß gemacht und ich habe viel in Sachen Zusammenarbeit und Absprachen gelernt.
Ich hoffe, dass ich euch einen kleinen und interessanten Einblick in die „Designwelt“ bei der ICANS Gmbh gegeben habe.

Mit besten Grüßen,
Euer Werkstudent Marco Eichberg

Ich habe für euch noch eine kleine Infografik von den einzelnen Steps gemacht :)

Der angereiste Coach Markus Junger (Leiter des Instituts für Professionelle Gesprächsführung) führte uns an die Thematik mit den folgenden Worten heran: „Was ist für euch ein Team und was bedeutet für euch Teamorientierung?“. In kleinen Gruppenarbeiten kamen wir der Sache immer näher und führten rege Diskussionen zu den Themen Teamarbeit und Teamgefühl bei der ICANS. Dabei wurde auch festgestellt, was bei der ICANS hinsichtlich Teamarbeit schon richtig gut funktioniert (z.B. Reviews und Retrospektiven zum gemeinsamen Reflektieren, aktiver Wissensaustausch, transparentes Arbeiten, Diskussionskultur, etc.) und wo eventuell noch optimiert werden kann (z.B. Wissensinseln vermeiden, mehr teamübergreifende Interaktion, Teamerfolge präsenter machen, offene Feedbackkultur noch besser leben, etc.). Markus gab uns zwischendurch immer wieder wertvolle Tipps, wie bestimmte Ausdrücke und Verhaltensweisen beim „Empfänger“ ankommen, z.B. lieber UND statt ABER, wenn man die Arbeit eines Teammitglieds bewertet UND noch etwas verbesserungswürdig erscheint. Und statt jemanden mit einem scharfen WARUM an die Wand zu stellen, fragt man lieber WIE es zu einer Situation gekommen ist. Und siehe da, der Empfänger fühlt sich völlig anders abgeholt und verstanden. Sehr spannend waren auch die kleinen Gruppenübungen, wo wir abgeglichen haben, in welcher Teamrolle wir uns selbst wahrnehmen und wie unser Team uns tatsächlich wahrnimmt. Das hat die Teilnehmer einerseits näher zusammengeführt und andererseits einige interessante Erkenntnisse für jeden Einzelnen hervorgebracht.

Wir haben vieles mitgenommen und jeder Teilnehmer wird sein Wissen so gut wie möglich erfolgreich in die Praxis umsetzen – denn wenn Teamarbeit im kleinen Rahmen durch diese Tipps und Erleuchtungen noch besser, harmonischer und/oder erfolgreicher funktioniert, wird dieser Erfolg schnell teamübergreifende Früchte tragen.

Es war ein spannender und lehrreicher Tag … mehr davon!! :)

Pizza Days

Ende letzten Jahres hatten wir bei der ICANS unsere Firmenweiten Pizza Days – 2 Tage an denen sich Entwickler(-Teams) aus dem daily business zurückziehen können und an einem frei wählbarem “Pet-Project” arbeiten dürfen. Neben der Verpflegung mit Pizza, diversen Energy-Drinks und Feierarbendbierchen, befassten sich meine Kollegen mit der Entwicklung eines Web-basierten automatischen Essensbestellservice, legten die Grundsteine bald-kommender Features für Tradimo  oder nahmen die Neugestaltung ihres Büros in Angriff. Ich ergriff die Gelegenheit und befasste mich mit einem in mir schon seit geraumer Zeit rumorendem Thema: “Automatische Qualitätssicherung von Webseiten”.

Die Aufgabe

Jeder Entwickler von größeren Webseiten, jeder Teamleiter und Manager von Teams kennt die folgende Situation: Ein Kunde – oder man selbst – würde das System gerne mit einem neuen Feature bereichern. Gesagt getan, das Feature wird (evtl. im Pair mit einem Kollegen) entwickelt, der Peer des Features hatte noch kleine Änderungswünsche, diese wurden in einer weiteren Iteration umgesetzt, im Code Review wurde die Entwicklung als tadellos eingestuft, Unittests wurden geschrieben und ausgeführt, die manuelle Qualitätssicherung hat nach erfolgreicher Abnahme das Feature integriert und der Code ging live. Alles gut! Schlecht nur, dass die Umsetzung ungewünschte Veränderungen der visuellen Darstellung in einem nicht-frequentiertem Teil der Seite hervorbrachte.

Zurück zu den Pizza Days, dem anschließendem Voting des besten Projektes und meines daraus resultierendem “First Friday” Vortrags . Die Projektbeschreibung war recht kurz: “Entwicklung eines automatischen Systems zur Erkennung von unerwünschten Seiteneffekten bei der Feature-Entwicklung”. Klar war, dass in der kürze der Zeit ein vollautomatisierter Ansatz nicht zu realisieren war – schon allein die Frage wie das System entscheiden sollte, was denn nun ‘unerwünscht’ ist, bedarf einiges an Aufwand.

Die Umsetzung

Ich entschied mich, ein System zu entwickeln, dass einem Entwickler oder Tester möglichst leicht darstellt, wie das System sich nach der Änderung von dem vorherigen Stand unterscheidet. Ein Visueller Vergleich von Screenshots welche vor und nach den Änderungen erstellt wurden klang vielversprechend. Hier ein Ablaufdiagramm des Workflows:

1. Erstelle Screenshots des aktuellen Systems
2. Fixe Bug / Entwickle Feature
3. Erstelle Screenshots des neuen Standes
4. Vergleiche (falls Fehler entdeckt werden, gehe zu Punkt 2)

Das System entwickelte ich auf Basis von NodeJS. Dank der Unterstützung von CasperJS , war ich sehr schnell und einfach in der Lage, ein automatisiertes Einloggen, Ansurfen von verschiedenen Seiten und Erstellen eines Screenshots zu schreiben. Ein Screenshot des User Interfaces des dazu geschriebenen Tools ist hier (see: screenshot_avrt.png) zu sehen. Vorab muss eine Test-Konfiguration geschrieben werden. Diese listet die einzelnen Seiten auf, welche automatisch angesteuert werden sollen. Diese Konfiguration wird an den Server geschickt und die Screenshots werden erstellt. Die Links zu den Screenshots werden als Antwort anschließend an den Client zurückgeschickt:

Client -------------c------------> Server
if (c.id === null) {
    c.screenUrlsOld = server.genScreenshots(c.urls);
    c.id = server.genereateUuid();
 } else {
    c.screenUrlsNew = server.genScreenshots(c.urls);
    c.screenUrlsDiff =
    server.generateDiff(c.screenUrlsOld,
    c.screenUrlsNew);
 }
Server ---------up_c-----------> Client

Wird die gleiche Konfiguration nochmals an den Server geschickt, versteht dieser nun den Aufruf als Aufforderung, die alten Screenshots mit dem aktuellen Stand des Systems zu vergleichen. Hierbei werden Pixel für Pixel untersucht und Abweichungen rot eingefärbt. Zudem bietet die API an, die Anzahl der roten Pixel in der Antwort mit auszuliefern. Das Ergebnis eines solchen Bildvergleichs ist hier zu sehen (see: screenshot_result.png).

 Diskussion

Anhand des erstellten Bildes ist es nun für den manuellen Tester sehr einfach zu sehen, welche Teile einer Seite sich mit dem neuen Code verändert haben. Aufgabe gelöst! Nun, nicht ganz… Ein grundlegendes Problem der Vorgehensweise ist, dass das System entscheiden muss, wann ein Bildschirmfoto erstellt werden kann. Hier kann es zu Timing-Problemen kommen (z.B. rotierende Elemente, Gallerien, …). Zudem ist weiterhin ein manueller Test-Aufwand nötig, welcher zwar reduziert wird, jedoch nicht vollständig ersetzt werden kann.

Andere Produkte / Lösungen

Natürlich hatte ich mich auch auf die Suche nach anderen Produkten im Netz gemacht. Interessant fand ich PhantomCSS , welche praktisch mit gleicher Technologie einen ähnlichen Ansatz implementieren. Schließlich bin ich über einen Vortrag des GTAC 2011 gestolpert  in dem der Gründer von Mogotest.com  seine Plattform vorstellte. Der Ansatz von Mogotest basiert darauf, dass zwei Snapshots des DOM-Baumes miteinander verglichen werden und somit “semantisch wertvollere” Informationen über die Änderungen erfasst werden können. Dies funktioniert so, dass jedes DOM-Element des ersten Snapshots mit dem jeweiligen Pendant im zweiten anhand der x/y Koordinaten, sowie Höhe und Breite verglichen werden. Weichen diese um einen einstellbaren Wert ab, wird das Element markiert. Zudem kann man weiterhin noch Elemente wie in dem oben beschriebenen Vergleich immernoch Pixel-basiert vergleichen um mögliche Änderungen festzustellen (z.B. Farbverläufe). Cool hierbei ist auch, dass der Service anbietet, verschiedene System-Browser-Kombinationen miteinander zu vergleichen und somit Cross-Browser-Tests einfacher durchzuführen.

Summa summarum

Ein System zu entwickeln, welches visuelle Bugs vollautomatisch entdeckt und den Testaufwand von Webentwicklern automatisiert ist schwierig. Nichtsdestotrotz waren unsere Pizza-Days was das Thema ”visuelle Regressiontests” angeht erfolgreich. Wir haben prototypisch ein System auf die Beine gestellt, welches den Anforderungen entsprechend es einem Tester erleichtern würde, visuelle Änderungen im System zu entdecken. Zudem haben wir uns anschließend noch Erweiterungsmöglichkeiten angeschaut und Ansätze wie http://mogotest.com diskutiert. Umsetzen konnten wir diese bisher leider noch nicht, aber es kommen ja noch ein paar Pizza-Days… ;-)…

Dr. Stefan Schadwinkel hat seitens der ICANS die fachliche Betreuung übernommen und durfte bei der offiziellen Zeugnisübergabe eine Laudatio zu Dennis halten. Hier hat er auch verkündet, dass Dennis sein neuer Kollege wird, denn er wird das Web Analytics Team ab sofort als „Analytics Engineer“ unterstützen. Herzlich Willkommen, lieber Dennis!

Prof. Dr. Ulrich Hoffmann (Wedeler Hochschulbund), Dr. Stefan Schadwinkel, Dennis Muth (v.l.n.r.)

Viele Kollegen dachten, dass wir sie zu einer Kneipen-Tour durch Hamburg entführen.
Aber nein -  wir, das Organisations-Team, haben uns überlegt, wenn wir schon so eine schöne große Cafeteria haben, dann sollten wir diese auch nutzen.Die Ideen sprudelten nur so und schnell hatten wir ganz bestimmte Vorstellungen von dem Abend, die wir erfüllen wollten:

• Ein weiterer Kicker musste her um Schlange-Stehen zu vermeiden
• Für ein wenig „sportliche“ Abwechslung wäre außerdem eine Dartscheibe cool
• bürgerliche Küche, wie es in der Kneipe halt üblich ist
• Bier vom Fass :)

Unsere Highlights wurden mit Hilfe unseres Design-Teams in einem Flyer für die Einladung umgesetzt und die Kollegen wurden immer neugieriger….

Am Tag des Events konnten wir bei den Vorbereitungen die ersten überraschten Gesichter unserer  Kollegen sehen.
Wir haben unsere Cafeteria, wo mittags eher Kantinenstimmung herrscht, komplett umgeräumt und versucht mit einfachen Mitteln und kleinen Details ein Kneipen-Flair zu gestalten.
Manche Kollegen kamen rein und meinten: „Ich dachte, hier werden die Tische etwas zur Seite geräumt und es gibt Bier“. Umso überraschter waren sie von dem Endergebnis.

Um 18:30 Uhr ging das erste Bier aus der Zapfanlage über die Theke. Das Buffet wurde nach der Eröffnungs- und Willkommensrede von David gegen 19:00 Uhr mit dem Anschneiden des Spanferkels eröffnet. Zusätzlich zum Spanferkel gab es auch Tofu-Würstchen, verschiedene Salate und als Dessert Rote Grütze.
Es herrschte eine ausgelassene Stimmung. Die Kickertische waren heiß begehrt und auch der Dartautomat war ein weiteres Highlight an diesem Abend.
Die Kollegen, die nicht am kickern, darten oder Karten spielen waren, haben sich in netter Atmosphäre über Gott und die Welt und darüber, was in den letzten Monaten so passiert ist, ausgetauscht. Denn zu diesem Event haben wir auch unsere ehemaligen Mitarbeiter eingeladen.

Für das Organisations-Team war das ein richtig cooles Event und wir hatten an diesem Abend mehr Spaß als Stress :) . Hier auch noch einmal vielen Dank für die tatkräftige Unterstützung an die helfenden Hände.

Über folgendes Feedback durften wir uns im Nachhinein freuen:

• „Hi,wollte mich mal ganz anständig für den Kneipenabend bedanken. War ein Superabend mit beeindruckender Ausstattung! Super Design, Super Deko, Super Verpflegung und echt gute Gespräche :). Vielen Dank für die Einladung und ein ganz großes Lob an die Orga-Crew!“
• „War wirklich toll, 1.000 Dank auch von mir!“
• „Super Event – danke!“
• „Danke auch von mir – es war großartig! :)“

Somit sollten wir ein Event in diesem Rahmen auf alle Fälle wiederholen.
Weitere Eindrücke – in Bildern und Kommentaren von den Kollegen – könnt ihr auf unserer ICANS facebook-Seite sehen.

Euer Organisations-Team
Kristin, Janina, Katharina und Katrin

When developing a website it happens quite often that you see room for improvement or have ideas for new useful features but don’t have the time to implement those. Many of our colleagues used the Pizza Days to work on such subjects because everyone could choose their topic on their own to be free and flexible for creative and useful outcomes. The only condition: the project should be related to ICANS in the broadest sense. Teams of one to four persons had two days to work on their ideas before presenting them to the plenum. The following chart shows you the chosen subjects and the teams working on them:

• Application to test CSS changes and visualise the results [Sebastian]
• Application for smartphones and browsers to order lunch [Moritz, Axel]
• Build process optimisation [Sebastian, Nikolaus], Automatised paperless business processes [Bettina, Irina, Christian]
• PokerStrategy application for Windows 8 Modern-UI [Markus, Torsten]
  Colorise the  DevOps office [Jochen, Martin, Stefan]
• RaPS (RabbitMQ + RPS) to visualise RPS specific information (e.g. JSON decoding) [Carsten]
• AMQP message consumer for dispatching PHP commands [Stefan, Stefan, Mike, Björn]
• Coaching Player on AWS for live video streaming [Oliver]
• AETSPL (Abstract Eventual Type-Safe Persistence Layer) [Simon, Wolf]
• Calendar plugin for education communities [Sean, Timo]
• Evaluation methods for user testing in ECF [Tina, Stefan]
• SASS API documentation [Sascha]
• Notifications for education communities [Lutz, Urs, Kai]

Teams and Topics

As long as critical business operations weren’t affected, everyone was allowed to reschedule or cancel meetings that were supposed to be on these dates.  Before the actual Pizza Days took place, everyone with an idea described the topic in two sentences in Confluence and tried to infect others – that is how our teams were formed. Even some colleagues from Gibraltar came over to join so the Pizza Days were also an international team building workshop ;)

Day 1

On the first day the teams met in the offices, meeting rooms or the Cafeteria. You could feel that everybody was really high-flying and keen on their project. In the evening all teams had a lot (I mean really a lot!) of pizza in the Cafeteria and some beers. We sat together sharing our impressions of the first day. The atmosphere was really nice and everybody was curious about the topics and results of the other teams.

Day 2 and Results

The second day started like the first one but ended differently. After finishing their work on the project in the afternoon, each team had five minutes (more or less…) to present the results to the other teams. After the presentations, the first Pizza Days were over and everyone was satisfied about their achievements.  A few days later, the most interesting topic was crowned in our internal forum. Moritz and Axel  presented their food-ordering application at the next First Friday Breakfast in January. Now we are all waiting for the first stable beta!

Today

Today some projects have already been finished, some will finish soon and some are still on hold. Day by day new ideas come up for the next Pizza Days and we can’t wait for them to come. All participants really enjoyed working on alternative topics and would welcome to work on them more frequently.

A special thank you goes to Katharina for organizing the Pizza Days in such a superb way!

It was very inspiring to see everyone working on their ideas in (sometimes) cross-functional teams and to be part of this.

In short summary: our infrastructure produces a stream of highly diverse messages, stores them in chunks in Amazon S3, and then processes the mixed data to create a neatly sorted structure that provides the basis for all further analysis.

Considering these initial chunks: we have many of them. We push the data parallely to S3 every 30 seconds, using 12 “threads”. This leads to approximately 12 (threads) x 24 (hours) x 60 (minutes) x 2 (messages per minute) = 34560 files. While this poses no direct issue for S3, running a map-reduce job with 34560 mappers is quite inefficient, because of the time required to schedule and manage each map task. Also for archiving data, having so many small files is rather undesirable.

Our initial approach was to use S3DistCp. S3DistCp can do a distributed copy of files from S3 or HDFS to (again) S3 or HDFS. While doing so, it can concatenate small files into large, grouped chunks of defined sizes, and change compression types.

So what we were trying to do was to copy data from S3 back to S3, but as fewer and bigger lzo-compressed files. And here comes the crux of the issue: mysteriously, S3DistCp sometimes hangs in the last reduce step just forever. The job doesn’t fail, the EC2 instances keep running and producing costs, and just noone seems to know why.

Here are a few of our observations and ponderings:

• when the chunk target size is reduced, the problem happens less often, but still in at least 1 out of 10 trials.

• the problem can be reproduced again and again on the same input directory, but when the input files are copied or moved to a different input directory using s3cmd, the issue seems to magically disappear. It will work most of the times, but the issue still persists, it just happens much less often. Therefore it seems, it has something to do with the initial upload. We did this using s3cmd as well, however, the initial upload is from us, while the second copy happens completely within Amazon’s infrastructure. So it might be some issues happening while transfering the data to S3, yet, why can the S3 backend read the files correctly, but the EMR S3 file input can’t ?

• Interestingly, not many people seem to complain about this. What we have observed is that many people seem to use S3DistCp to copy from S3 to HDFS or from HDFS to S3. The other documented case of this issue (stuck EMR cluster) also tried S3 to S3 copies. It also claims hundreds of successful runs before the issue began to emerge.

• For the last case, the Amazon engineering team seems to have investigated, but on my case (s3distcp hangs in last reduce step), noone replied in over 2 weeks. Not so nice for a very critical piece in our processing pipeline. It thus seems that while it happens to our case very, very often, it seems to be very hard to reproduce on Amazon’s side and does not impact other customers. That’s the most mysterious point to me.

While we hope that Amazon will fix this in the future and we would still love to actually use S3DistCp, it is just not possible to use something so unreliable in a production environment.

Luckily, we can now come to the second and more fun part of this post: Hive to the Rescue!

With the current Hadoop at Amazon’s Elastic MapReduce, it is actually possible to use a special input format that allows to use multiple small, even non-splittable files like .gz or .lzo files without index, as input to a single mapper.

We do this by simply telling Hive that Hadoop supports the feature:

SET hive.hadoop.supports.splittable.combineinputformat=true;


For the output, we can also specify (for instance) to give us compressed lzo files:

SET hive.exec.compress.output=true;
SET mapred.output.compression.codec = com.hadoop.compression.lzo.LzopCodec;


Further, we control how many files are given to each mapper (and hence how many mappers will be run) by setting max.split.size:

SET mapred.max.split.size=$INPUT_CHUNK_SIZE;


To control the number of output files (and thus indirectly the size of these chunks), we can specify how many reducers to use:

SET mapred.reduce.tasks=$NUM_REDUCERS;


We now just create two external Hive tables, one at the location of our source data. In this case, our source data contains JSON-encoded strings:


CREATE EXTERNAL TABLE input_table (json STRING)
LOCATION 's3://Name of your Bucket/Your Input Path/';


As we do not change the data itself, we create an external target table to hold one string per record at our desired output location:

CREATE EXTERNAL TABLE output_table (json STRING)
row format delimited fields terminated by ',' lines terminated by '\n'
LOCATION 's3://Name of your Bucket/Your Output Path/';


Now, we just need to write the data from our input table to our target table. We cannot just run “SELECT * FROM …”, because that would not execute a MapReduce job, and therefore not result in compacted files. However, our subsequent processing has a de-duplication step, so we can just move the de-duplication to be the first step in the pipeline:


INSERT OVERWRITE TABLE output_table
SELECT DISTINCT json FROM input_table;


And that’s it. We basically get the same result as with S3DistCp and already have de-duplicated data.

The main bottleneck for both, S3DistCp and Hive, is to execute the S3 requests for fetching all the files. In total, for our setup, both solutions run for about the same amount of time. The hive alternative has been very stable so far, no stuck clusters anymore.