Wow, this was the month of conferences. First we visited Barcelona for the Euruko: a great conference taking place every year in a different city. We attended it the 3rd time. The talks ranged from practical like “Cooking with Chef“, over entertaining like “Fun with Ruby (and without R***s), program your own games with Gosu” to just geeky like the lightning talk about “Vimmish and how much fun gramma parsers can be”. I really liked the 2 days 1 track format and the people I met there. And you can be sure that we will be in Krakow next year too.

5 days later I visited Amsterdam for Ruby on OS X, which I already blogged about.

And a little more than a week later, until yesterday, four of us attended the RailsWayCon here in Berlin, which tries to fill the gab that the RailsConf Europe left. The first day was reserved for whole day tutorial sessions.

The second day offered a lot of advanced topics to choose from in 3 tracks. I chose to hear more about Asynchronous Processing from Mathias Meyer and the nitty gritty details about Events from Lourens Naudé. The keynote about the Present and Future of Programming Languages by Ola Bini was also very interesting.

Upstream also took an active part at the conference: Alex gave his talk about CouchDB Frameworks for Ruby and CouchApp (using his new presentation tool boom_amazing) and I introduced MacRuby, the Ruby that plays nice with Objective-C.

On the third day Yehuda Katz revealed some more details about Rails 3. The talk by Michael Koziarski about Rails Performance was good for a reality check. In the afternoon everybody was tired after 3 days of conference and the talks lost quality. Still a very good conference with potential.

On Thursday I gave a talk about Bug fighting with TDD and how it will help you to write better software at the Ruby User Group in Berlin. Sorry, I won’t put the slides online, although people asked about it. I think they are a pretty useless collection of keywords and pictures without the talking. Instead I like to provide a collection of links to dive into the whole testing matters.

First a collection of tools you can choose from for various testing scenarios. They all have their pros and cons, it just comes down to which will do the job best for you.

Tools for Unit Testing

• Rspec
• Test/Unit (part of Rails)
• shoulda

Tools for Mocking

• Flexmock
• Mocha
• RR

Tools for Acceptance Testing

• Webrat
• Cucumber
• HtmlUnit (with JRuby)
• Selenium

Tools to generate test objects

• Machinist
• FactoryGirl
• ObjectDaddy

Misc tools

• Autotest
• Tarantula
• Culerity

To save you the initial searching where to start, I collected some links where you find basic information about testing in general or with certain tools.

Getting started

• A Guide to Testing Rails Applications
• An introduction to RSpec
• Functional Testing awesomeness with Webrat
• How I Test Controllers, 2009 Remix
• Shoulda tutorial
• Mock objects explained and intro to Mocha (de)

For everyone who wants to get more into the subject, I drilled down my feed reader to collect some interesting blog posts on testing matters.

Opinions and In-sign

• The Great Test Framework Dance-off
• Thoughts on Developer Testing
• Spikes, test-after, and learning how to test
• A case against a case against mocking and stubbing
• A critical look at the current state of Ruby testing
• One Line Tests Without the Smells
• Mocks Aren’t Stubs
• Testing as Communication: Real-World Techniques Notes
• When duplication in tests informs design
• Writing Code That Doesn’t Suck (vid)

So much for my two cents to make the software world better.

—

Does your company need help with software testing? We can help: check out our new product Scene Investigation.

Gestern Abend habe ich als letztes den Vortrag zum anonymen Zugangskontrollsystem AnonAccess gehört. AnonAccess ist eine Eigenentwicklung die aus dem Bedürfnis entstand ein günstiges und vor allem bei Bedarf anonymes Zugangskontrollsystem für den eigenen Hackerspace zu haben.

Das Ziel eines günstigen Zugangskontrollsystem konnte recht einfach durch entsprechende Hardware realisiert werden. Die Hardware besteht grob aus Chipkarten – ca. 73cent pro Stück -, Mikrocontroller – 10 Euro – und kleinere Komponenten deren Kosten auch bei 10 Euro lagen.

Dem Ziel eines anonymen Systems wurde sich langsam angenähert. Als erste Idee wurden Pseudonyme auf den Karten hinterlegt und Zugangstoken von einer Datenbank vergeben. Pseudonyme sind allerdings nicht wirklich anonym. Um richtige Anonymität zu erreichen wurde die Idee so abgeändert das satt eines Pseudonym, eine zufällige ID dem der Token zugeordnet wird und diese ID auch immer mit auf der Karte geschrieben wird. Damit ist kein Rückschluss mehr möglich welche Karte welche ID hat und somit auch keine Information mehr über dessen Besitzer. Das Modell ist zwar anonym aber absolut nicht wartbar, etwa wenn jemand seine Karte verloren hat, die entsprechenden Token zurückzuziehen.

Erst die Kombination der beiden Konzepte ermöglicht einen anonymen Zugang der sich auch verwalten lässt. Dazu wird eine Zweite Datenbank verwendet die Informationen über die ID der Karten und den hinterlegten Nutzerinformationen enthält. Dies ermöglicht eine dreistufiges Identitätsmanagement. Namentlich bekannt Nutzer, ein Pseudonym und geteilte Pseudonyme. Damit die Daten nicht einfach durch den Angriff auf eines der Teilsysteme kompromittiert werden können, etwa durch auslesen der Karte, Mithören der Kommunikation oder auslesen der Datenbanken kommen entsprechende Hashing- und Verschlüsselungstechniken zum Einsatz. Als Authentifizierungmöglichkeit für den Nutzer wurde vor kurzem die Verwendung einer PINs implementiert. Das System befindet sich immer noch im Entwicklungsstadium. Wie die Verschlüsselung im einzelnen Abläuft und wie die Datenbank aussieht kann in den Slides nachgelesen werden.

In der anschliessenden Diskussion wurden einige Kritik hinsichtlich der Architektur geäussert. Unteranderem wurde die Betreibssicherheit hinterfragt, da die Karte bei jeder Verwendung mit neuen Daten beschreiben wird und ein vorzeitiges herausziehen der Karte, diese unbrauchbar macht. Ein Problem dem durch den Einsatz von Einzugslesegeräten aus dem Weg gegangen werden kann. Grundlegender waren die Bedenken, dass das System nicht inhernt anonym ist, sondern auf das System vertraut werden muss.

Wir sind wieder am Start. Jetzt gleich starten wir mit einen Talk zum Thema, Metaversen (Kurzerklärung: Immersive 3D Welten wie z.B. Second Life).

Der Vortrag startet mit einem Screenshott des ersten grafischen Metaversum: Habitat(Lucas Filmgames). Dies soll zeigen das Metaversen ihren Ursprung in Computerspielen hat. Denn werden die in metaversen verwendeten Begriffe erklärt, wie, woher der Begriff Avatar kommt. Die Geschichte der Metaversen geht wie gesagt bei den Spielen los, M.U.D. war der erste Schritt in diese Richtung, dann folgte ein weiterer Meilenstein mit TinyMUD. Dann schön anschaulich, ein noch laufendes MUD (Aardwolf). (more…)