Mitarbeiter Blog

Galettes & Crêpes

Fri, 03 Feb 2012 12:12:13 +0100

Am Donnerstag, 2 Februar 2012 führten wir zum 4. Mal unser Apéro für Kunden, Partner und Freunde durch. Wie in jedem Jahr haben wir uns eine kleine kulinarische Überraschung überlegt. Nach Raclette, einem winterlichen Grill und Chili con carne haben wir uns in diesem Jahr für Galettes und Grêpes entschieden.

Wikipedia sagt zu den beiden Varianten folgenes:

Eine Galette (Bretonisch Krampouezhenn) ist ein 
aus der Bretagne stammender Pfannkuchen. 
Sie ist die herzhafte Variante der im deutschen 
Sprachraum bekannteren Crêpe.

Quelle

In der Bretagne werden Crêpes grundsätzlich süß 
belegt, beispielsweise mit Zucker, Konfitüre, 
frischen Früchten oder Nuss-Nougat-Creme.

Quelle

Wir hoffen natürlich, dass die von uns angebotenen Varianten der beiden geschmeckt haben. Die meisten haben sicher zu Hause schon Crêpes gemacht. Wir möchten hier noch das Rezept für den dunklen Teig für die Galettes mit euch teilen. Vielleicht hat die eine oder der andere ja Lust bei Gelegenheit dieses zu Hause zuzubereiten.

200 g Buchweizenmehl (erhältlich im Reformhaus)
100 g Weissmehl
3 Eier
450 ml Milch
40 g geschmolzene Butter
Salz

Die Zutaten sollten in der oben stehenden Reihenfolge beigefühgt und der so entstehende Teig am Besten von Hand mit einem Schwingbesen zu einer gleichmässigen, rel. flüssigen Masse verarbeitet werden. Vor der Zubereitung sollte er ca. 2h im Kühlschrank ruhen.

Danach die Galettes portionenweise in der Bratpfanne je Seite 1-2 Minuten ausbacken. Die Galettes können mit allerlei Zutaten gefüllt werden. An unserem Apéro hatten wir folgende angeboten:

Karotten-Rahm - Sauce
Schinken Käse
Käse
Bolognaise - Sauce
Tomaten-Pesto - Feta - Salat
Poulet-Curry - Sauce

Hier sind der Kreativität keine Grenzen gesetzt.

E Guete!

Compile Save UI Binding based on Mockito Part 2

Wed, 23 Nov 2011 13:09:48 +0100

Remember my previous blog entry about creating compile/refactoring save ui binding based on Mockito and BeansBinding?

Today we'd like to make some improvements to the previous prototype. Mainly we'd like to add support for binding nested properties like

obj.getAdress().getStreet();

On the other hand we'd like to encapsulate the usage of Mockito into simple a helper class which may be needed in different projects. Therefore we investigated the Mockito implementation to trace the problem of binding nested properties and encapsulated the required parts into an own class called 'ObjectBinder'. The ObjectBinder is defined using generics to create a wrapper of any object. The ObjectBinder may be used with the following method calls to create a BeanProperty based on a real method call to the object classes stub.

ObjectBinder<DummyPojo> binder = new ObjectBinder<BeanBindingPrototype2.DummyPojo>(

            DummyPojo.class);

binder.getModelTemplate().getName();

String path = binder.getBeanPropertyPath();

BeanProperty<DummyPojo, String> name = BeanProperty.create(path);

Using the so called ModelTemplate of the ObjectBinder creates a new Mock-Object of the provided class and starts the tracking. It is following the method calls to that object.

/**

 * @return type template used to declare gui bindings

 */

public O getModelTemplate() {

    MockSettingsImpl settings = (MockSettingsImpl)new MockSettingsImpl()

        .defaultAnswer(new EXReturnsDeepStubs(m_mockingCache));

    O mock = mockUtil.createMock(m_clazz, settings);

    mockingProgress.mockingStarted(mock, m_clazz, settings);

    return mock;

}

We use an own answer to keep track of all nested method called based on that mock.

    private static class EXReturnsDeepStubs extends ReturnsDeepStubs {

        private static final long serialVersionUID = 1880837724076720541L;

        private final MockingCache m_cache;

        private Map<Object, Object> m_follower = new HashMap<Object, Object>();

        public EXReturnsDeepStubs(MockingCache cache) {

            m_cache = cache;

        }

        @Override

        public Object answer(InvocationOnMock invocation) throws Throwable {

            // Class<?> clz = invocation.getMethod().getReturnType();

            Object answer = super.answer(invocation);

            // if (new MockCreationValidator().isTypeMockable(clz)) {

            // return will be another mock

            Object mock = invocation.getMock();

            Object parent = m_follower.get(mock);

            if (parent != null) {

                m_cache.registerInvocation(parent, mock, invocation);

            }

            else {

                m_cache.registerInvocation(mock, invocation);

            }

            // register the following mock

            m_follower.put(answer, mock);

            // }

            return answer;

        }

    }

That is where we register every method invocation in a shared cache object instance:

    public static class MockingCache {

        public HashMap<Object, Stack<InvocationOnMock>> m_invocationCache = new HashMap<Object, Stack<InvocationOnMock>>();

        public void registerInvocation(Object mock, InvocationOnMock invocation) {

            Stack<InvocationOnMock> stack = m_invocationCache.get(mock);

            if (stack == null) {

                stack = new Stack<InvocationOnMock>();

                m_invocationCache.put(mock, stack);

            }

            stack.push(invocation);

        }

        public void registerInvocation(Object parent, Object mock, InvocationOnMock invocation) {

            Stack<InvocationOnMock> stack = m_invocationCache.get(parent);

            if (stack == null) {

                stack = new Stack<InvocationOnMock>();

            }

            stack.push(invocation);

            m_invocationCache.put(mock, stack);

            m_invocationCache.remove(parent);

        }

        public void clear() {

            m_invocationCache.clear();

        }

        public Stack<InvocationOnMock> retrieveMockInvocationStack(Object mock) {

            // m_invocationCache.get(mock);

            return m_invocationCache.remove(mock);

        }

    }

Now the whole trick of getting deep method invocation stack after calling a nested property is fetching the actual stack of the shared cache.

public Stack<InvocationOnMock> getLatestInvocationStack() {

    mockingProgress.stubbingStarted();

    @SuppressWarnings("rawtypes")

    OngoingStubbing stubbing = (OngoingStubbing)mockingProgress.pullOngoingStubbing();

    Object mock = stubbing.getMock();

    stubbing.thenCallRealMethod();

    return m_mockingCache.retrieveMockInvocationStack(mock);

}

The stack of the method invocation will also get converted into an appropriate BeanProperty using a simple conversion mechanism:

    public String getBeanPropertyPath() {

        // convert stacktrace into bean property

        Stack<InvocationOnMock> latestInvocationStack = getLatestInvocationStack();

        StringBuffer buf = new StringBuffer();

        for (InvocationOnMock invocation : latestInvocationStack) {

            String methodName = invocation.getMethod().getName();

            for (String prefix : PREFIXES) {

                if (methodName.startsWith(prefix)) {

                    int len = prefix.length();

                    methodName = String.valueOf(methodName.charAt(len)).toLowerCase()

                            + methodName.substring(len + 1);

                    break;

                }

            }

            if (buf.length() > 0) {

                buf.append('.');

            }

            buf.append(methodName);

        }

        return buf.toString();

    }

    public <S> BeanProperty<O, S> getBeanProperty() {

        return BeanProperty.create(getBeanPropertyPath());

    }

So now we've got a real BeanProperty of a nested method call using compile save method invocation. This BeanProperty can get used as in the first example binding this property to a property of a swing ui element like:

ObjectBinder<DummyPojo> binder = new ObjectBinder<BeanBindingPrototype2.DummyPojo>(

            DummyPojo.class);

binder.getModelTemplate().getParent().getStreet();

String path = binder.getBeanPropertyPath();

BeanProperty<DummyPojo, String> street = BeanProperty.create(path);

//bean property refering to swing element

BeanProperty<JTextField, String> textProperty = BeanProperty.create("text");

JTextField field = new JTextField(20);

DummyPojo realObject = new DummyPojo();

ParentPojo parent = new ParentPojo();

realObject.setParent(parent);

//binding nested beanproperty of real object to textfield property

AutoBinding<DummyPojo, String, JTextField, String> binding = Bindings.createAutoBinding(

    UpdateStrategy.READ_WRITE, realObject, name, field, textProperty);

binding.bind();

That's all. The drawbacks of this solution is still that we have to do a method call of the mocked template before fetching a bean property of the ObjectBinder. That means two sequential method call which are required in this order otherwise the mockito framework (clearly) will raise an exception.

In the next prototype I'd like to create a simple example of a base ui class that may be used to encapsulate the binding logic and provide a simple an easy interface to extending GUI classes.

The whole maven project can get downloaded from here.

Compile Save UI Binding based on Mockito

Fri, 18 Nov 2011 13:24:56 +0100

A very technical project on which we are working at the moment consist of refactoring a rich client (direct jdbc-DB access) into a thin-/rich-client connected to a JavaEE service layer. We've got the challenge to introduce a couple of new architectural patterns. One of the challenges is to bind the service model data to the swing based gui elements. Sure, there exists a well known bean-binding [1] project hosted on jgoodies [2] to automatically bind two properties of different objects against each other. This would look like this:

Property propertyVolume = BeanProperty.create("volume");

Property propertySliderValue = BeanProperty.create("value");

Binding bindingVolumeSlider = Bindings.createAutoBinding(

    AutoBinding.UpdateStrategy.READ_WRITE, 

        volume, propertyVolume,

    sliderVolume, propertySliderValue);

bindingVolumeSlider.bind();

The Problem of binding those properties against each other is the fact, that the binding is based on property names defined by strings. Refactoring of model classes won't affect those property definitions. The risk in refactoring is therefore very high because errors will occur only at runtime by accessing such a property or by automated tests calling those properties as well. On the other hand there don't exist any code references to those properties used anywhere in the code.

Therefore we pursued an architectural goal of integrating a compile save bean binding into our new client application. After some coffee and some brain power the idea came up to use parts of the testing framework Mockito [3] which itself provides the functionality of creating mock based unit tests using compile save statements like

 LinkedList mockedList = mock(LinkedList.class);

 

 //stubbing

 when(mockedList.get(0)).thenReturn("first");

Where the methodcall 'get' reflects the real method call of a provided class object.

Starting with this idea we developed the following prototype showing a simple way to integrate compile/refactoring save UI binding using the two frameworks JGoodies Binding and Mockito.

We start by creating two dummy objects only used to bind UI elements to some properties of them:

    public class DummyPojo {

        private String m_name;

        private int m_number;

        public String getName() {

            return m_name;

        }

        public void setName(String name) {

            m_name = name;

        }

        public int getNumber() {

            return m_number;

        }

        public void setNumber(int number) {

            m_number = number;

        }

    }

    public static class DummyPojo2 {

        private String m_street;

        public String getStreet() {

            return m_street;

        }

        public void setStreet(String street) {

            m_street = street;

        }

    }

Now we created a simple example which binds properties of those two objects to two different swing elements. Any modifications done to the swing components will be propagated to the objects thanks to the JGoodies Binding framework.

public BeanBindingPrototype() {

        DummyPojo spy = Mockito.mock(DummyPojo.class);

        DummyPojo2 mock2 = Mockito.mock(DummyPojo2.class);

        BeanProperty<DummyPojo, String> prop = registerPojoProperty(spy.getName());

        BeanProperty<DummyPojo2, String> prop2 = registerPojoProperty(mock2.getStreet());

        JFrame frame = new JFrame();

        JPanel panel = new JPanel();

        panel.setLayout(new GridLayout(2, 2));

        JTextField field = new JTextField(20);

        BeanProperty<JTextField, String> textProperty = BeanProperty.create("text");

        panel.add(new JLabel("Name:"));

        panel.add(field);

        JTextField field2 = new JTextField(20);

        panel.add(new JLabel("Street:"));

        panel.add(field2);

        frame.getContentPane().add(panel);

        final DummyPojo realObject = new DummyPojo();

        final DummyPojo2 realObject2 = new DummyPojo2();

        AutoBinding<DummyPojo, String, JTextField, String> binding = Bindings.createAutoBinding(

            UpdateStrategy.READ_WRITE, null, prop, field, textProperty);

        binding.bind();

        binding.unbind();

        binding.setSourceObject(realObject);

        binding.bind();

        AutoBinding<DummyPojo2, String, JTextField, String> binding2 = Bindings.createAutoBinding(

            UpdateStrategy.READ_WRITE, realObject2, prop2, field2, textProperty);

        binding2.bind();

        frame.pack();

        frame.setPreferredSize(new Dimension(200, 200));

        frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

        frame.addWindowListener(new WindowAdapter() {

            @Override

            public void windowClosing(WindowEvent e) {

                System.out.println("Name:" + realObject.getName());

                System.out.println("Street:" + realObject2.getStreet());

            }

        });

        frame.setVisible(true);

    }

The interesting part of this idea is the following:

DummyPojo spy = Mockito.mock(DummyPojo.class);

DummyPojo2 mock2 = Mockito.mock(DummyPojo2.class);

BeanProperty<DummyPojo, String> prop = registerPojoProperty(spy.getName());

BeanProperty<DummyPojo2, String> prop2 = registerPojoProperty(mock2.getStreet());

We create BeanProperties of the two object class properties 'name' and 'street' while referencing a real getter access method.

Those properties are created using Mockito:

public <T, S, V> BeanProperty<S, V> registerPojoProperty(T methodCall) {

        OngoingStubbingImpl<T> stub = (OngoingStubbingImpl<T>)Mockito.when(methodCall);

        List<Invocation> registeredInvocations = stub.getRegisteredInvocations();

        Invocation invocation = registeredInvocations.get(0);

        String methodName = invocation.getMethodName();

        for (String prefix : prefixes) {

            if (methodName.startsWith(prefix)) {

                int len = prefix.length();

                methodName = String.valueOf(methodName.charAt(len)).toLowerCase()

                        + methodName.substring(len + 1);

                break;

            }

        }

        BeanProperty<S, V> property = BeanProperty.create(methodName);

        stub.thenCallRealMethod();

        return property;

    }

Performing a Mockito 'when' operation we can extract an OngoingStubbing of the effective method called on that mock before. Within this OngoingStubbing we get all informations needed to extract the real methodname called and derived from that we can create dynamically a string based BeanProperty describing this methodcall.

Drawbacks of this implementations are the missing support for nested object property access like this one:

 obj.getAdress().getStreet()

The solution to this we'd like to solve in the next chapter.

So far best regards from the tegonal development team.

Download maven Project source code of prototype [tar.gz-File]

Wiederauferstehung einer GPU - oder der Beweis für die Holzhammer-Methode

Thu, 01 Jul 2010 11:37:31 +0200

Mein nettes kleines Dell XPS 1330 hat vor ein paar Wochen den gefürchteten Nvidia-GPU Hitzetod erlitten: Angeblich sind in dieser Serie technisch nicht ganz einwandfreie (hah) Nvidia Chips verbaut worden. Nvidia hatte Rückstellungen in dreistelliger Millionenhöhe gemacht, Dell hat sich aber nicht sonderlich angestrengt, seine Kunden an diesen Millionen teilhaben zu lassen. De Facto ist mein Dell Laptop nach der Garantiezeit ausgestiegen und hat sich grafikmässig verabschiedet.

Nach etwas Recherche bin ich auf dieses interessante Video (Youtube) gestossen. Nach einer Behandlung mit dem Heissluftföhn (1800 Watt, ca 300 Grad Celcius) zeigt sich beim Starten wieder ein Bild ... tja, manchmal hilft die Holzhammermethode tatsächlich.

Die Tücken einer Webcam (2/2)

Wed, 24 Mar 2010 10:00:00 +0100

(Wie wir die Idee einer Webcam mit unsere Büro-Aussicht angegangen sind, im ersten Teil des Artikels.)

Lange mussten wir nicht warten. Der Tag war wohl ereignislos und die Online-Presse hat die Bärencam gleich wohlwollend in kurzen Artikeln erwähnt.

Warteschlangen

Die Besucher blieben auch nicht lange aus und schon nach kurzer Zeit musste man eine Stunde, manchmal zwei Stunden warten um die Kamera bedienen zu dürfen.

Das war natürlich nicht praktikabel. Wir entschieden uns in der Folge eine andere Art der Steuerung umzusetzen: Die Community sollte die Kamera gemeinschaftlich steuern. Alle 6 Sekunden wird ein Kommando abgesetzt. Es wird jeweils jenes gewählt, welches am meisten Stimmen erhält. Dies hat sich schnell als optimal heraus gestellt.

Datenschutz

Die Bärencam lief nun einige Tage und mussten wir wieder eingreifen. Die Bärencam, ein Nebenbei-Projekt, hatte nun schon mehr Aufwand generiert als erwartet. Nun wurden wir auf die Datenschutz-Problematik hingewiesen. Zugegeben, wir hatten uns nicht vertieft mit dem Thema auseinandergesetzt. Im Leitfaden "Datenschutzkonformer Betrieb von Webcams" des Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten steht u.a. folgendes:

Falls es jedoch möglich ist, Personen zu bestimmen, liegt ein Bearbeiten von Personendaten im Sinne von Art. 3 lit. e DSG vor. Bestimmbar ist eine Person auch dann, wenn sie zwar durch ihre Daten nicht eindeutig identifiziert wird, aus den Umständen, das heisst aus dem Kontext einer Information (z.B. Gegenstände, Kleidung, Fahrzeuge etc.) aber auf sie geschlossen werden kann.

Auf der Bärencam kann man Personen sehen. Die Auflösung der Kamera ist zwar schlecht und Gesichter sind kaum zu erkennen, Kleidung aber schon. Daher ist die Kamera nicht Datenschutz konform. Ein kurzer Blick auf die Webcams in der Schweiz ergibt, dass viele die oben genannten Bedingungen nicht erfüllen.

Wir lösen das Problem mit einer Folie, welche wir vor das Fenster kleben, so dass das Blickfeld der Kamera nur noch auf das Innere des Bärenparks fällt.

Zusätzliche Erweiterungen

Haben wir Zeit, werden wir auch in Zukunft kleine Erweiterungen für die Bärencam umsetzen. Dies könnten sein:

Eine Möglichkeit Schnappschüsse zu vermailen
Schnappschüsse in einer Galerie aufnehmen
Die Bären mittels Bildanalyse automatisch finden und tracken

Übrigens:

Wir geben den Code für den Camproxy übrigens gerne unter der GPL weiter. Falls Interesse besteht, dann nehmt bitte mit uns Kontakt auf.

Die Tücken einer Webcam (1/2)

Wed, 24 Mar 2010 09:49:00 +0100

Die Idee eine Webcam zu installieren und den Ausblick aus unserem Büro mit den Internetbenutzern zu teilen hatten wir schon länger. Mit der Eröffnung des Bärenparks auf der gegenüberliegenden Aareseite hat sich die Idee konkretisiert und wir haben uns daran gemacht die Idee umzusetzen. Von Anfang an war klar, dass das Vorgehen "kaufen, anschrauben, laufen lassen" nicht wird möglich sein. Die Problemstellung war die folgende:

Die Webcam würde an unser Netz hier in der Bürogemeinschaft angeschlossen. Dies darf nicht zu stark belastet werden. Die Last darf daher nicht proportional mit den Nutzern der Webcam steigen.
Webcams verfügen im Allgemeinen über ein hässliches UI zur Bedienung. Wir möchten aber eine hübsche Webseite anbieten.
Die Kamera soll gesteuert werden können. Sind viele Leute gleichzeitig online, muss hier eine Lösung gefunden werden.

Als Kamera haben wir uns für die WCS-2040 von level1 entschieden welche ein gutes Preis/Leistung Verhältnis hat für ein Tilt/Shift/Zoom (T/S/Z) Modell. Der Bärenpark sollte ja von nah sichtbar sein, also musste ein Zoom möglich sein..

Diese oben stehenden Punkte haben wir gelöst in dem wir einen Kamera-Proxy entwickelt haben. Diese Applikation läuft als www.bärepark.ch auf einem unserer Server im Puzzle-Rack im Sunrise Rechenzentrum. Der Proxy lädt alle ca. 2 Sekunden das aktuelle Bild von der Kamera, verteilt dieses an alle Webseiten und setzt allfällige Steuerkommandos zuhanden der Kamera ab. Zudem führt die App einige Batch-Jobs durch. Die Übersichtsbilder werden alle 10 Minuten neu geladen sowie kalibriert und die Kamera wird alle 2 Stunden neu gestartet (sie hat sich im Dauerbetrieb leider als störanfällig heraus gestellt).

Das Web-UI haben wir mit Apache Wicket umgesetzt. Dieses Web-Framework bietet einige Ajax-Funktionalität, was für die geplante Umsetzungsvariante unabdingbar war. Wicket ermöglicht es eine kleinere bis mittlere Web-Applikation in sehr kurzer Zeit umzusetzen. Die sehr moderne Architektur der Library erleichtert zudem die Integration von Spring und anderen State-of-the-Art Technologien.

Daneben setzen wir ImageMagick zur Bearbeitung der Bilder ein. Dies beinhaltet das Drehen der Bilder sowie das Einfügen des Tegonal-Logos als Watermark.

Um allen BesucherInnen die Steuerung der Kamera zu ermöglichen, haben wir eine Warteschlange vorgesehen. BesucherInnen können der Reihe nach 60 Sekunden steuern.

Gut. Funktioniert. Kurz eine Mitteilung an die Presse verfasst und gewartet.

(Was dann geschah liest du im zweiten Teil des Artikels.)

Neue Tegonal Webseite mit Silverstripe CMS

Thu, 14 Jan 2010 15:00:00 +0100

Unsere alte, sehr alte Website haben wir damals schnell und unkompliziert mit PHP und eigenen, sehr rudimentären Templates erstellt. Den Zwecks hat sie über die Jahre stets erfüllt. Das Erfassen und Ändern von Inhalten war zwar immer etwas mühsam, aber regelmässig haben wir den Inhalt der Seite eh nicht verändert. Oder haben wir dies nicht oft gemacht, gerade weil das Abfüllen umständlich war? Nun gut, auch der optische Eindruck der Website liess seit längerem zu wünschen übrig, höchste Zeit also für eine neue, hübsche Website.

Und natürlich wollten wir bei der Gelegenheit auch gleich ein zeitgemässes Content Management System (CMS) einführen. Manfred von monkee solutions hat uns auf SilverStripe aufmerksam gemacht. Vielen Dank für den Tipp!

SilverStripe ist ein PHP/MySQL basiertes CMS und deckt unsere Bedürfnisse optimal ab ohne riesig und überladen daher zu kommen. Wir freuen uns nun über ein neues, angenehmes Tool und wir hoffen nun auch etwas öfter die Inhalte zu verändern und zu ergänzen.

Unsere Mitarbeiter-Blogs sind ein erster Schritt in diese Richtung. Diese Blogs sollen ein Gefäss sein um die vielfältigen Erfahrungen die wir täglich bei unserer Arbeit machen von Zeit zu Zeit in einen Blog-Eintrag einfliessen zu lassen um auch so der OpenSource-Community einen kleinen Beitrag zurück zu geben. Mehr dazu aber später...