App Entwicklung für iOS und/oder Android (Köln oder Berlin)

December 21st, 2011
Teilen

Wir sind auf der Suche nach einem erfahrenen App-Entwickler, der uns bei der Implementierung einer iOS sowie Android-Anwendung unterstützt.

Projektumfang ca. 2-3 Monate, Start kurzfristig möglich.

Entwickelt werden soll eine native iPhone- sowie Android-App. Das Backend wird von eigenen Entwicklern in Abstimmung mit dem App-Entwickler umgesetzt.

Ein Konzept der App, sowie Mockups beispielhafter Workflows und Dialoge liegen vor.

Kernelemente der Anwendung:

  1. Erfassung user-generierten Contents (Video, Foto, Text)
  2. Bewertungssystem, Favoriten und Listenverwaltung
  3. Messaging-System mit Kalenderzugriff
  4. User-Profile
  5. Foto-Stream
  6. Social Media-Integration (Authentifizierung / Sharing)
  7. InApp Purchase (virtuelle Währung)
  8. Smartphone-Funktionen: Lokale DB, GPS, Kamera, Push-Messages, Multi-Touch

Was die UX angeht, wünschen wir uns einen kritischen Dialog und die Einbringung eigener Ideen, um eine wirklich runde App für die jeweilige Plattform zu erstellen.

Entsprechende Erfahrung mit den unterschiedlichen Bedienkonzepten und Workflows auf Android und iOS Geräten sind von Vorteil.

Ort: Köln oder Berlin

Bei Interesse, wenden Sie sich bitte direkt an:

Ingo Friepörtner
ingo@friepoertner.com
+49 (0)151 22633195

Benchmarking SSD with MongoDB and CouchDB, Part 3

October 23rd, 2011
Teilen

I’m still waiting for the Firewire adapter to arrive. The first order got lost, the second order was canceled, and the third order has not yet arrived. Thanks to Amazon I got my money back without any problems. Therefore, I decided to ignore the Mac OS X for the moment. In addition to the OCZ and ADATA SSD, I’ve also got a Western Digital VelociRaptor hard disk:

Before moving on to benchmarking MongoDB and CouchDB, I did some tests using different filesystems. In Part 2 the BrtFS did not perform that well on SSD, so I re-ran the tests using the SSD and the hard disk.

Zooming into the diagram, restricting to 4096 bytes per block

While BtrFS performance comparable to ext4 on a hard disk, it seems to be a lot slower on SSD. xfs is even faster than ext4, so I’m looking forward to see, if there is any performance impact on MongoDB or CouchDB.

Benchmarking SSD with MongoDB and CouchDB, Part 2

September 28th, 2011
Teilen

In Part 1 I started to investigate the performance impact of SSD on MongoDB and CouchDB. However, I got sidetracked because of the strange behavior of Mac OS X. The Mac is lying about msync. You have to force a synchronization by explicitly calling fnctl with F_FULLSYNC for the underlying file descriptor. So, I decided to do some more experiments with block sizes, file systems, operation systems, connection types and SSD.

The two combatants for today are

Test Setup

Recall that the test programs creates a sparse file, fills this file block by block, and does an msync at every block. For the first tests I’m using a AMD Phenom II X6 1055T, OpenSuSE 11.4. Simply using dd gives for the ADATA

> dd if=/dev/zero of=/ssd/test1 bs=512 count=10000000
10000000+0 Datensätze ein
10000000+0 Datensätze aus
5120000000 Bytes (5,1 GB) kopiert, 39,5451 s, 129 MB/s

and for the OCZ

> dd if=/dev/zero of=/ssd/test1 bs=512 count=10000000
10000000+0 Datensätze ein
10000000+0 Datensätze aus
5120000000 Bytes (5,1 GB) kopiert, 21,7511 s, 235 MB/s

Blocksize

The first test uses different block sizes. Keep in mind that the page size is 4096.

(click on diagram to enlarge)

The ADATA is much faster than the OCZ when using a small block size. With larger block sizes it wins because of its higher bandwidth.

File Systems

I’ve used the OCZ directly connected to the SATA on the mortherboard to test various file systems: EXT4, EXT3, EXT2, Reiser, XFS, VFAT, BTRFS. The results are as follows

(click on diagram to enlarge)

The tests used the msync-bench test with block sizes of 1024, 4096, and 65536.

Next Steps

The same tests have to redone using a hard disk. First tests indicate, that a SSD is 10 to 100 times faster in this setup. I hope the FireWire connector for the Mac arrives soon, so that I can tests the different operating systems and connection types (SATA, eSATA, FW, USB). I still have to figure out, what are good tests for MongoDB and CouchDB.

Benchmarking SSD with MongoDB and CouchDB, Part 1

September 24th, 2011
Teilen

Doing benchmarks is always complicate because it is most of the time totally unclear what one wants to measure and what will be measured. There is article describing this dilemma, see Benchmarks-You-are-Doing-it-Wrong. The CouchDB – The Definite guide contains a longer version of this, see High Performance. I assume that this is also one of the reasons why MongoDB does not officially publish benchmarks, see Benchmarks. Kristina Chodorow, Software Engineer at 10gen, published a nice, unofficial benchmark at snailinaturtleneck.

As SSD are getting cheaper and cheaper I wanted to investigate what impact SSD have on the performance of MongoDB and CouchDB. Let me stress that this is not a real life example, it is not exhaustive test. It is not a complete test suit measuring the performance of a document store. I did that test out of interest for the implication of SSD on the NoSQL movement. There are also more complete benchmarks of SSD, but as zorinaq points out most of them are also flawed.

They very first question is “what do we actually measure?”. In order to answer that we need some baselines. CouchDB is using a REST/HTTP interface, so I am going to measure the throughput of this interface. Just requesting the version information should give a good indication. The next step would be to reproduce the claims in High Performance. Basically I’m interested in the “reliable” setup, where each and every change is written back to disk. This should show the biggest difference in performance between hard disks and SSD. Again you might ask “what is the point?”. It is clear that only very few application require that level of reliability, but I do not want to measure how good CouchDB or MongoDB are handling main memory. That would be a completely different test setup. Presumable, you would want to setup some sort of 2 server replication and feed realistic request with a certain create/read/update/delete ratio, because that is what most web applications look like. Or you want append only tests with few reads and no replication because you are using that database as store for log-files. Or you want an update-centric setup, because you are storing ticks for shares. Or, or, or … There are quite a lot of very different scenarios and presumably MongoDB and CouchDB will behave differently in all these situations.

The article High Performance suggest that there is a difference between Linux and Mac OS X in the way syncs are handled. Therefore the following hardware was used in the tests:

  • iMac 2010 running Mac OS X 11 (Core i3)
  • Dell Optiplex 980 running OpenSuSE 11.4 (Core i7)
  • OCZ Vertex 3 Max IOPS

I first wanted to establish a few cornerstones.

  1. What is the disk / ssd throughput?
  2. What is the throughput of msync?
  3. What is the throughput of fsync?
  4. What is the protocol overhead?

Disk Throughput of the Harddisk

Using DD to copy a 1 GByte file with random data gave

MAC / Hard Disk

> dd if=random of=test
2048000+0 records in
2048000+0 records out
1048576000 bytes transferred in 8.753879 secs (119784157 bytes/sec)

Linux / Hard Disk

> dd if=random of=test
2048000+0 Datensätze ein
2048000+0 Datensätze aus
1048576000 Bytes (1,0 GB) kopiert, 10,0028 s, 105 MB/s

The write performance between Linux and Mac OS X seems to be comparable.

Memory Mapped Files

Because of the hints given by CouchDB concerning MacOS and Linux, I’ve tried to understand what the difference between Linux and Mac OS X concerning memory mapped files is. I wrote a program to create (append-only) memory mapped files, which can be found on github. The program repeatedly appends blocks of 674 bytes. After each append msync was called.

Mac

The throughput under Mac OS is

> msync-bench "/tmp/test1" 674 10000
insert time: 2.277690 sec for 10000 documents (4390.413094 docs / sec, 0.000228 secs / doc)
2959138.425334 bytes / sec, 2.822054 mbyte / sec

Each memory page of size 4096 is written 6 times, because msync is called after 674 bytes.

To get a baseline for the overhead introduced by my programm I’ve switched off the msync – only one msync at the end.

> msync-bench "/tmp/test1" 674 10000
insert time: 0.081228 sec for 10000 documents (123110.257547 docs / sec, 0.000008 secs / doc)
82976313.586448 bytes / sec, 79.132379 mbyte / sec

So msync is indeed doing something.

Linux

Under Linux the behavior is very different

> msync-bench /tmp/test1 674 1000
insert time: 26.022067 sec for 1000 documents (38.428923 docs / sec, 0.026022 secs / doc)
25901.093868 bytes / sec, 0.024701 mbyte / sec

In order to investigated further I used a larger object of size 4096

> msync-bench /tmp/test1 4096 1000
insert time: 25.632864 sec for 1000 documents (39.012418 docs / sec, 0.025633 secs / doc)
159794.863344 bytes / sec, 0.152392 mbyte / sec

The throughput seems to be independent from the size. The number of msync is what counts.

The baseline without msync (resp. only one msync at the end) is

> msync-bench /tmp/test1 674 10000
insert time: 0.044011 sec for 1000 documents (22721.592329 docs / sec, 0.000044 secs / doc)
15314353.229874 bytes / sec, 14.604905 mbyte / sec

Using FDATASYNC

Instead of msync I also tried to fsync a file. Basically same setup as before. Open a file, append a block of 674 bytes and fdatasync the file descriptor.

Mac

Under Mac OS I get

> fsync-bench /tmp/test2 674 10000
insert time: 34.173727 sec for 10000 documents (292.622458 docs / sec, 0.003417 secs / doc)
197227.536815 bytes / sec, 0.188091 mbyte / sec

Using fdatasync is much slower (10 times) than msync. Again to get a base without fdatasync

> fsync-bench /tmp/test2 674 10000
insert time: 0.412287 sec for 10000 documents (24254.948616 docs / sec, 0.000041 secs / doc)
16347835.367111 bytes / sec, 15.590511 mbyte / sec

Linux

The same under Linux

> fsync-bench /tmp/test2 674 10000
insert time: 11.934775 sec for 1000 documents (83.788760 docs / sec, 0.011935 secs / doc)
56473.624346 bytes / sec, 0.053857 mbyte / sec

and the baseline

> fsync-bench /tmp/test2 674 10000
insert time: 0.046587 sec for 1000 documents (21465.215618 docs / sec, 0.000047 secs / doc)
14467555.326593 bytes / sec, 13.797336 mbyte / sec

The MSYNC Mac Mystery

MAC LINUX
msync 4 390 38
msync base 123 110 22 721
fdatasync 292 83
fdatasync base 24 255 21 465

So, either memory mapped files are much better under Mac OS X than under Linux, Mac OS X is somehow lying about msync, I am missing some magic madvice flags, or one needs a different filesystem. I’m using EXT4 under Linux. Strangely, fdatasync base (writing the file and then fdatasync at the end) is equally fast on both machines.

Any suggestions about what is going on are welcome. Why is msync under Linux 100 times slower? With only one final msync the Linux version is still six times as slower.

Next Steps

I’ve ordered a OCZ Vertex 3 MAX IOPS. It will be fun to see if and how this changes the figures. I still have to figure out how to connect the SSD to my Mac. Maybe I’ll try Firewire first before resorting to more drastic measures. After that we are ready to test MongoDB & CouchDB on this SSD.

To be continued …

Siegerehrung beim FrOSCon Gewinnspiel der triAGENS

August 21st, 2011
Teilen

Herzlichen Glückwunsch an die Sieger  des triAGENS Gewinnspiels bei der FrOSCon!

Wie geht man am besten vor, wenn man ein paar Eier und ein ziemlich hohes Hochhaus hat und herausfinden möchte, wie stabil diese Eier sind, indem man sie aus verschiedenen Höhen aus dem Hochhaus wirft? Diese Frage galt es beim triaAGENS-Preisausschreiben auf der FrOSCon zu lösen – und stellte sich als nicht trivial heraus.  Über 40 Einsendungen gab es, doch nur drei Teilnehmer kamen auf die richtige Lösung.

Von vierzig Teilnehmern haben nur diese drei die Aufgabe korrekt gelöst. Dabei hat sich mal wieder gezeigt, wie wichtig Zusammenarbeit für den Erfolg ist! Denn unsere drei Gewinner haben das Rätsel gemeinsam gelöst.

Die drei Gewinner dürfen sich über Amazon und ThinkGeek Gutscheine freuen. Wir wünschen viel Spaß damit.

Das komplette Rätsel findet ihr übrigens hier.

Siegerehrung des triAGENS Gewinnspiels bei der FrOSCon

Der Froscon 2011 Eiertanz

August 21st, 2011
Teilen

Während die Froscon Besucher bei dem Voc am Rhein neue Rundenrekorde aufstellen konnten, war auch für das geistige Wohl gesorgt. Wer das Eierrätsel richtig löste, hat attraktive Gutscheine von Amazon und ThinkGeek gewonnen.

Das Froscon 2011 Eier Rätsel

Gegeben seien Eier mit einer unbekannten, aber für alle Eier gleichen Stabilität N. In dem Sinne: sie überstehen einen Fall aus dem N-ten Stockwerk, aber nicht mehr aus dem N+1-ten Stockwerk. Dabei ist N minimal 0 und maximal 100.

Die Stabilität soll jetzt bestimmt werden, indem wir von einem Hochhaus mit hinreichend vielen Etagen Eier herunterfallen lassen. Uns interessieren optimale Verfahren, bei denen die Anzahl der Versuche, die man im worst case – für das ungünstigste N – machen muss, möglichst klein ist.

Wenn man nur ein Ei zur Verfügung hat, so ist das beste (gewissermaßen das einzige) Verfahren die lineare Suche, bei der man mit der ersten Etage anfängt und sich dann Etage für Etage hocharbeitet. Wenn das Ei beim Fall aus der m-ten Etage kaputt geht, so weiß man, dass N = m-1 ist. Im worst case muss man also 100 Versuche machen (wenn N = 100 ist).

Wenn man beliebig viele Eier zur Verfügung hat, so ist das beste Verfahren die binäre Suche. Im worst case
muss man also 7 Versuche machen.

Was ist aber die Anzahl der Versuche, die man bei einem optimalen Verfahren im worst case machen muss, wenn
man zwei Eier zur Verfügung hat? Und bei drei Eiern?

Ei des Kolumbus oder des Rätsels Lösung

Vorüberlegungen

Angenommen man hat zwei Eier zur Verfügung. Folgt man der Idee der binären Suche und lässt das erste Ei in der 50. Etage fallen und es geht kaputt, so weiß man, dass N minimal 0 und maximal 49 ist. Man hat einen Versuch durchgeführt, aber leider nur noch ein Ei zur Verfügung. Das heißt, um heraus zu finden was die Stabilität ist, kann man nur linear vorgehen und braucht im schlimmsten Fall (N = 50) jetzt nochmal 49 Versuche. Insgesamt
also 50 Versuche.

Geht es besser? Lässt man das erste Ei aus dem 10. Stock fallen und es geht kaputt, so muss man jetzt die Stockwerke 1 bis 9 linear durchprobieren. Insgesamt im schlimmsten Fall also 10 Versuche. Geht das Ei jedoch nicht kaputt, so hat man einen Versuch verbraucht, aber noch beide Eier. Startet man den nächsten Versuch im 20. Stock und das Ei geht kaputt, so hat man jetzt zwei Versuche verbraucht, nur noch ein Ei übrig und man weiß, dass N zwischen 10 und 19 liegt. Man braucht aber jetzt noch 9 weitere Versuche. Insgesamt also 11 Versuche.

Geht man bei zweiten Versucht statt in den 20. Stock nur in den 19. Stock und das Ei geht kaputt, so kann man in 10 Versuchen feststellen, was die Stabilität ist. Das heißt, geht man im ersten Schritt in den m. Stock, um nächsten Schritt in den (m-1). Stock, usw. kommt mit m Versuchen aus. Allerdings muss m so groß sein, dass die Summe

m + (m-1) + (m-2) + … + 1 = m * (m + 1) /2

größer als 99 ist. Für m = 10 ist die Summe allerdings nur 55. Für m = 14 ist die Summe gleich 105. Das heißt, mit diesem Verfahren braucht man im schlimmsten Fall 14 Versuche, kommt aber mit zwei Eiern aus. Die Frage ist jetzt, gibt es vielleicht einen ganzen anderen Algorithmus, welcher noch viel besser ist. Die binäre Suche kommt ja schließlich auch mit 7 Versuchen aus.

2 Eier Theorie

Dazu müssen wir etwas Theorie anwenden.

N(i,m)

bezeichne die maximale Stabilität, welche man erraten kann, wenn man i Eier und m Versuche aufwendet. Dann gilt für i = 1

N(1,m) = 1 + N(1,m – 1)

Lässt man das Ei aus dem 1 Stock fallen, und es geht kaputt, so ist die Stabilität 0. Also muss

N(1,1) = 1

sein. Die Rekursion kann man jetzt auflösen und erhält:

N(1,m) = m

Wie sieht es bei zwei Eiern aus?

Lässt man das erste Ei aus dem x.ten Stock fallen, dann gibt es zwei Möglichkeiten:

(a) Das Ei geht kaputt. In diesem Fall muss man die Ein-Eier-Strategie für 0 … x-1 anwenden.

(b) Das Ei geht nicht kaputt. In diesem Fall kann man die Zwei-Eier-Strategie für x+1 .. N anwenden.

Das heißt, es gilt

N(2,m) = (N(1,m-1) + 1) + N(2,m-1)

Wir wissen bereits, dass

N(1,m-1) = m-1

gelten muss. Also

N(2,m) = m + N(2,m-1)

trägt man dies als Tabelle auf, so gilt:

m    N(2,m)
1     1
2     3 = 2 + 1
3     6 = 3 + 3
4    10 = 4 + 6
5    15 = 5 + 10
6    21 = 6 + 15
7    28 = 7 + 21
8    36 = 8 + 28
9    45 = 9 + 36
10    55 = 10 + 45
11    66 = 11 + 55
12    78 = 12 + 66
13    91 = 13 + 78
14   105 = 14 + 91

Das heißt, das erste Mal, wenn N(2,m) größer oder gleich 100 ist, tritt bei m gleich 14 auf. Unsere oben beschriebene Algorithmus ist also ideal. Mit weniger als 14 Versuchen geht es nicht.

3 Eier Theorie

Bei 3 Eiern ist die Argumentation die gleiche

N(3,m) = (N(2,m-1) + 1) + N(3,m-1)

tragen wir dies wieder als Tabelle auf, so sieht man

m    N(2,m)             N(3,m)
1     1                  1
2     3 = 2 + 1          3 = (1 + 1) + 1
3     6 = 3 + 3          7 = (3 + 1) + 3
4    10 = 4 + 6         14 = (6 + 1) + 7
5    15 = 5 + 10        25 = (10 + 1) + 14
6    21 = 6 + 15        41 = (15 + 1) + 25
7    28 = 7 + 21        63 = (21 + 1) + 41
8    36 = 8 + 28        92 = (28 + 1) + 63
9    45 = 9 + 36       129 = (36 + 1) + 36

Also ist das kleinste m, so dass N(3,m) größer oder gleich 100 ist, gleich 9. Damit ergibt als
Algorithmus:

Gehe in den 36 Stock und das erste Ei fallen. Geht es kaputt, haben wir noch zwei Eier und müssen die Stockwerke 1 .. 36 ausprobieren. Aus dem Überlegung zu N(2,m) wissen wir, dass man 8 Versuch braucht. Das heißt, insgesamt brauchen wir 9 Versuche.

Geht das erste Ei nicht kaputt, so lassen wir das erste Ei aus dem 36 + 28 Stock fallen. Geht es kaputt, haben wir zwei Versuche gebraucht und noch zwei Eier. Um die Stockwerke 37 .. 64 auszuprobieren, brauchen wir jetzt 7 Versuche. Insgesamt also wieder 9.

Und so weiter.

Geschlossene Form

Man dann die Werte für N(2,m) und N(3,m) per Programm berechnen oder sich eine geschlossene Form überlegen. Wir wissen bereits

N(1,m) = m
N(2,m) = m + N(2,m-1)

Folgt man z. B. http://classes.soe.ucsc.edu/cmps201/Winter00/handouts/recur.pdf so kann man die Rekursion auflösen und erhält

N(2,m) = m * (m + 1) / 2

Für drei Eier folgt damit

N(3,m) = (N(2,m-1) + 1) + N(3,m-1)

bzw. mit obigen Wissen

N(3,m) = (m*m – m + 2) / 2 + N(3,m-1)

Löst man die Rekursion auf erhält man

N(3,m) = m * (m*m + 5) / 6

Wer wissen möchte, wie man solche geschlossene Formeln systematisch bestimmen kann, dem sei das Buch “Concrete Mathematics” von Ronald L. Graham, Donald E. Knuth (genau der von TAOCP) und Oren Patashnik empfohlen.

NoSQL und sportliche Herausforderungen auf der FrOSCon 2011

August 17th, 2011
Teilen

Auch in diesem Jahr ist triAGENS Gold-Sponsor der Free and Open Source Software Conference FrOSCon in Sankt Augustin. Unter dem Motto “NoSQL matters” präsentieren wir am 20./21. August 2011 interessante Neuentwicklungen rund um das Thema NoSQL.

Neben den fachlichen Dingen, haben wir uns in diesem Jahr einige Aktionen und spielerische Herausforderungen einfallen lassen. So werden wir an den beiden Tagen unter anderem eine knapp 13 Meter lange Carrerabahn aufbauen! Wir laden Euch ein, an unserem Stand zu verweilen, über das Thema NoSQL zu diskutieren und auf der Rennbahn einen neuen Rekord zu brechen.

Für diejenigen, die sich näher mit dem Thema NoSQL und Session Management beschäftigen, haben wir einen Tipp: Am Samstag um 10 Uhr halten Martin Schönert und Frank Celler einen interessanten Vortrag zu dem Thema “Session Management für skalierbare Web Projekte – Zentrales Session Management mit SessionVOC und node.js”. Weitere Infos befinden sich auf der FrOSCon-Website.

Nächstes Treffen der NoSQL-Gruppe Köln am 3. August

August 1st, 2011
Teilen

Das nächste Treffen der NoSQL-Gruppe ist in am 3. August um 19:30. Falls ihr Lust und Zeit vorbei zu kommen, dann meldet euch doch bitte unter http://www.doodle.com/ny87xwxravvnu2qv an, damit wir Getränke und Knabbereien einkaufen können. Folgende Vorträge sind angeboten:

  • Nils kann einen Anwenderbericht über den produktiven Einsatz von MongoDB geben
  • Arkadiusz kann eine Einführung in REST geben
  • Martin kann etwas zu Dynamo erzählen

Folgende Vortrage stehen nach der Urlaubszeit an:

  • David kann einen Anwenderbericht über REDIS geben
  • Sebastian kann über CouchDB / Riak / Redis berichten
  • Marc Boeker kann über MongoDB berichten

Außerdem steht noch die Diskussion über “The Case for Determinism in Database Systems” (siehe http://db.cs.yale.edu/determinism-vldb10.pdf) aus. Das wird aber sicherlich länger als 30 Minuten brauchen. Diese Diskussion können wir vielleicht im informellen Teil nach den Vorträgen führen?

Erstes Treffen der NoSQL-Gruppe Köln am 06.07.2011

June 30th, 2011
Teilen

Am 06.07.2011 um 19:30 Uhr trifft sich erstmalig die NoSQL-User-Group Cologne, um sich rund um die Themen NoSQL und verteilte DB-Systeme auszutauschen. Zur Zeit gibt es noch keine NoSQL-Guppe in Köln. Diesen Umstand möchten Frank Celler und weitere Entwickler aus Köln korrigieren. Insgesamt haben sich bereits rund 20 Interessierte per Doodle angemeldet. Wir, die triAGENS, stellen der Gruppe unsere Räumlichkeiten zur Verfügung und werden selbstverständlich auch anwesend sein. Wir freuen uns auf anregende Diskussionen, spannende Vorträge und neue Kontakte im Raum Köln!

NoSQL ist ein weites und vielschichtiges Themengebiet. Daher möchte Frank regelmäßige Treffen und Vortragsreihen organisieren. Wer beim ersten Meeting nicht anwesend sein wird, kann sich somit auf weitere spannende Events freuen.

Weitere Informationen sind auf der Website zu finden. Per Twitter werden über @nosqlcgn die Termine und Themen angekündigt. Wir bitten um Eure Anmeldung zur Snack- und Getränkeplanung per Doodle (gerne auch per Pseudonym).

Auf Wiedersehen “Developer Conference Hamburg”

May 23rd, 2011
Teilen

Ein Wochenende mit vielen interessanten Vorträgen und Gesprächen liegt hinter uns. Vom 20. bis 21. Mai 2011 fand im OTTO-Forum die erste Developer Conference in Hamburg statt. Als wir im April von der Konferenz hörten und das spannende Programm sahen, entschlossen wir uns sehr kurzfristig, die Veranstaltung als Gold Sponsor zu fördern.

Der gute Eindruck hat sich bestätigt und wir sind froh, dass wir dabei waren. In über 40 Vorträgen, Workshops und Diskussionsrunden konnten sich Web-Entwickler über aktuelle Technologien und Trends informieren. Die Bandbreite der Themen war sehr groß. So gab es technische Themen (z.B. Many-Cores & Functional Programming von Prof. Dr. Friedrich Esser), aber auch praktische Leitfäden zu Randthemen (z.B. Gut verhandeln von Judith Andresen).

Wir hielten einen Vortrag zum Thema “Session Management für skalierbare Web
Projekte”. Martin Schönert berichtete über die Probleme des Session Managements in großen Webprojekten und zeigte auf, welche Lösungen und Funktionen der SessionVOC bietet. Martin konnte wieder auf Zuruf hochinteressante Hintergrundinformationen zu den verschiedensten Themen liefern, z.B. über die Generierung von One-Time-Tokens.

Auf unserem “World of VOC”-Messestand präsentierten wir die Produkte SimpleVOC (schneller Key-Value-Store) sowie den SessionVOC. Hier möchten wir noch einmal ausdrücklich erwähnen: Der SimpleVOC und SessionVOC sind als Open-Source-Versionen verfügbar und können selbstverständlich für eigene Projekte verwendet werden! Die Funktionen sind dabei nicht extrem reduziert, wie einige Besucher unseres Stands vermutet hatten.

An unserem Stand verteilten wir verschiedene Buttons, mit denen sich die Besucher “taggen” konnten. Diese waren sehr beliebt und wir verteilten in den zwei Tagen ca. 500 Buttons! Besonders beliebt war übrigens der Button #node.js.

Für uns steht schon jetzt fest, dass wir auch im nächsten Jahr wieder dabei sind. Die tolle Organisation, das sehr gute Essen sowie die schönen Räumlichkeiten haben das Programm abgerundet. Vielen Dank an die vielen Sprecher, den Organisatoren und Helfern. Wir sehen uns bald wieder!

Weitere Informationen zum SessionVOC: www.sessionvoc.com
Weitere Informationen zum SimpleVOC: www.simplevoc.com