Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts

  • Chris Kaempfe 5:12 pm on May 31, 2012 Permalink | Reply
    Tags:   

    Outlook 2010 – Tastenkürzel für springe zu Heute 

    In der Kalenderansicht von Outlook 2010 kann man mit einem einfach Klick auf Heute zum aktuellen Datum springen. Jedoch hab ich bisher keine direktes Tastenkürzel gefunden, welches mir die gleiche Funktion liefert. Die Tastenkombination Strg + G (Gehe zu Datum) kommt schon gut ran, jedoch wird hier das Datum ausgewählt in dem sich der Cursor gerade befindet. Mit einem kleinen Trick, kann man aber genau dieses Kürzel dazu verwenden, um zu ‘Heute’ zu springen.

    Man gibt einfach unter Gehe zu Datum folgendes Möglichkeit ein: h, heute oder today. Schon springt Outlook zum aktuellen Datum!

     
  • Chris Kaempfe 8:43 am on April 13, 2012 Permalink | Reply
    Tags: nas-server, telnet   

    Aldi NAS Server (P89626) und Telnet 

    Der NAS Server von Aldi (P89626) ist ein super Einstieg, um sich näher mit dem Thema NAS Server vertraut zu machen. Eine detaillierte Übersicht, was sich hinter dem Server versteckt findet man auf Mikrocontroller.net: http://www.mikrocontroller.net/articles/P89626

    Telnet

    Auf den P89626 kann man auch mittels Telnet zugreifen. Dazu muss man zunächst die Backdoor auf dem NAS Server ansprechen mit folgendem URL:

    http://nas-server/r32694,/adv,/cgi-bin/remote_help-cgi?type=backdoor

    oder

    http://192.168.xxx.yyy/r32694,/adv,/cgi-bin/remote_help-cgi?type=backdoor

    ACHTUNG! Ein Problem kann man beim Telnetzugriff über die Backdoor bekommen, wenn die Kombination nach dem Hostnamen nicht stimmt. Im Beispiel ist folgendes gemeint: r32694. Diese ID ist wohl bei jedem Server verschieden. Man kann sie aber herausfinden, indem man sich regulär anmeldet und anschließend in der URL überprüft, wie diese Nummer lautet. Danach die oben genannten Links anpassen, aufrufen und via Telnet verbinden (Username und Passwort sind die selben wie beim Webzugriff).

    Nach jedem Neustart des NAS Servers ist allerdings der Telnetzugriff wieder zurückgesetzt und man muss erneut die URL aufrufen. Wie dies unterbunden werden kann, wird in dem Artikel von Mikrocontroller.net beschrieben.

     
  • Chris Kaempfe 10:42 am on December 23, 2011 Permalink | Reply
    Tags:   

    Ein Zitat das ein Perfektionist stehts behalten sollte:

    “Done Is Better Than Perfect”

     
  • Chris Kaempfe 3:59 pm on December 21, 2011 Permalink | Reply
    Tags:   

    MongoDB Einträge löschen anhand eines Datums 

    Einträge aus einer MongoDB löschen mittels eines Datums lässt sich wie folgt lösen:

    db.collection.remove({ "importDate" :{"$gte": new Date(2011, 11, 24, 18)} });

    Mit dieser Query werden alle Einträge aus der Collection entfernt nach dem 24.12.2011 ab 18 Uhr.
    Wichtig ist dabei, dass die Monate mit 0 (Null) beginnen, also Januar entspricht der 0 und Dezember der 11. Mit Hilfe der Advanced Query $gte werden alle Einträge berücksichtigt die nach dem angegebenen Datum liegen.
    Dem Datum kann man auch noch Minuten und Sekunden übergeben:

    new Date(yyyy, mm, dd [, hh, mm, ss, milliseconds])
     
  • Chris Kaempfe 9:40 am on December 9, 2011 Permalink | Reply
    Tags: , ,   

    JUnit Tests und Reflection 

    Mit Hilfe von Java Reflection lassen sich grosse POJO Objekte unter JUnit einfach Vergleichen.

    Angenommen man hat ein einfaches POJO Objekt Metadata mit einigen Attributen:

    public class Metadata {
        private Integer id;
        private String filename;
        private Integer height;
        private Integer width;
        private long fileSize;
        private String fileFormat;
        private String comment;
        // and some more attributes
    
        /**
         * Getter and Setter-Methods
         */
    }
    

    Es werden nie alle Attribute gleichzeitig gefüllt, sondern je nach Prozessschritt immer nur ein paar. Zum Beispiel beim Einlesen der Datei können Breite, Höhe, Dateiname und Dateigröße gesetzt werden. Alle anderen Attribute sollen nicht gefüllt werden. Um sicherzustellen, dass beim Einlesen der Datei auch keine weiteren Attribute gesetzt werden, muss im Test abgefragt werden, ob alle anderen Attribute auch NULL sind.

    @Test
    public void testReadFileMetadata() {
        Metadata meta = new Metadata();
        File file = new File("someTestFile.jpg");
        // Metadata attributes will be read and set
        foo.readFileMetadata(meta, file);
        // now test if attributes were set correct
        assertEquals("someTestFile.jpg", meta.getFileName());
        // ... go on with height, width and size
        // all other attributes should still be NULL
        assertNull(meta.getFileFormat());
        assertNull(meta.getId);
        assertNull(meta.getComment);
    }
    

    Die Id wird dem Metaobjekt zum Beispiel über eine Datenbank hinzugefügt. Hierzu gibt es eine eigene Methode createMetaId():

    public void createMetaId(Metadata meta) {
        // set up database stuff
        Integer id = database.getNextId();
        meta.setId(id)
    }
    

    Für einen vollständigen Test, müssten auch hier wieder alle Attribute abgefragt werden:

    @Test
    public void testCreateMetaId() {
        Metadata meta = new Metadata();
        dbTier.createMetaId(meta);
        assertEquals(123456, meta.getId()):
        // test if all other attributes are NULL
        assertNull(meta.getFileFormat());
        // ...
        assertNull(meta.getComment);
    }
    

    Unter Verwendung von Reflection kann man bei den Tests sich eine Menge an Code sparen:

    public class ReflectionComparator {
    	public static void compareObjects(Object expected, Object actual) {
    		try {
    			for(Field field : expected.getClass().getDeclaredFields()) {
    				// setAccessible == true will allow to access private fields
    				field.setAccessible(true);
    				assertEquals(field.get(expected), field.get(actual));
    			}
    		} catch(Exception e) {
    			fail(e.getMessage());
    		}
    	}
    }
    

    Die Tests angepasst mit der Klasse ReflectionComparator sehen wie folgend aus:

    @Test
    public void testReadFileMetadata() {
        Metadata metaActual = new Metadata();
        File file = new File("someTestFile.jpg");
        // Metadata attributes will be read and set
        foo.readFileMetadata(metaActual, file);
        // create new object Metadata and set the expected attributes
        Metadata metaExpected = new Metadata();
        metaExpected.setFileName("someTestFile.jpg");
        // ... go on with setters for height, width and size
        // compare metaExpected with metaActual
        ReflectionComparator.compareObjects(metaExpected, metaAcutal);
    }
    
    @Test
    public void testCreateMetaId() {
        Metadata metaActual = new Metadata();
        dbTier.createMetaId(metaActual);
        Metadata metaExpected = new Metadata();
        metaExpected.setId(123456);
        // compare metaExpected with metaActual
        ReflectionComparator.compareObjects(metaExpected, metaAcutal);
    }
    

    Damit hat man sich jede Menge an Testcode gespart und überprüft zusätzlich alle Attribute eines Objektes, ob diese gleich sind.

     
  • Chris Kaempfe 9:38 am on December 6, 2011 Permalink | Reply
    Tags: eclipse   

    Eclipse Console Buffer erweitern 

    Hin und wieder passiert es in Eclipse, dass plötzlich der Buffer der Konsole nicht mehr reicht aufgrund zu vieler Log ausgaben. Dies lässt sich jedoch leicht beheben in Eclipse:

    Window -> Preferences -> Run / Debug -> Console

    Nun kann man unter: ‘Limit conole output‘ einstellen, ob man ein Limit möchte oder wie groß der Buffer sein soll. Dabei kann die Buffergröße zwischen 1.000 und 1.000.000 eingestellt werden.

     
  • Chris Kaempfe 10:09 am on November 30, 2011 Permalink | Reply
    Tags: misc   

    Erfolglos vs Erfolgreich bloggen 

    Jeder der schon einmal einen Blogpost geschrieben hat und nicht unbedingt eine kreative Gehirnhälfte für das Schreiben von Texten hat, weiss wie schwer so ein Post zu formulieren sein kann. Nicht nur das Schreiben an sich ist eine Schwierigkeit, sondern auch das “Worüber” soll man denn schreiben? Um sich dieser Frust Luft zu machen, gibt / gab es einen netten Blog: erfolglosbloggen.

    Leider wird dieser Blog anscheinend nicht mehr weiter gepflegt, da die Idee dahinter doch sehr vielversprechend scheint.

    Dem erfolglosen Bloggen gegenüber steht natürlich das erfolgreiche Bloggen. Einen sehr unterhaltsamen, witzigen und doch ernst gemeinten Artikel gibt es auf dem Blog von: Spreeblick.
    Hier eine kurze Übersicht der 10 Regeln für erfolgreiches bloggen:

    1. “I had a blog before you had a blog”
    2. Die Blugroll zuerst!
    3. Kommentieren ist wichtiger als eigene Artikel
    4. Sei mysteriös und gemein
    5. Stelle technische Fragen
    6. Fotos
    7. Services
    8. Verlinke!
    9. Stöckchen
    10. Misch dich ein

    In wie fern man sich an die Regeln hält und für Polarisierung sorgt, darf zum Glück jeder selbst entscheiden :-)

     
  • Chris Kaempfe 10:27 am on November 29, 2011 Permalink | Reply
    Tags:   

    Programming Jargon 

    Man merkt das manche Entwickler einfach zu viel Zeit haben um sich Dinge auszudenken … aber irgendwie sind sie auch sehr passend: new programming jargon.

    Meine Favoriten: Bugfoot, Pokemon Exception Handling und Yoda Conditions.

     
  • Chris Kaempfe 10:10 am on November 29, 2011 Permalink | Reply
    Tags: ,   

    Yoda Condition 

    Gestern bin ich über den Begriff Yoda Coding gestoßen und nach ein wenig recherchieren hab ich einen sehr interessanten Blog Eintrag gefunden: debuggen du musst

    Bei einer Yoda Condition geht es sinngemäß darum, wie man Konstanen vergleicht: if(var == const) oder if(const == var). Bei dem letzteren Beispiel erinnert der Aufbau an einen falschen Satzbau, wie es Yoda so gern verdreht: “… der letzte der Jedi Du sein wirst.”
    Der Vorteil von Yoda Conditions ist, dass man einen Fehler bekommt, wenn man in Sprachen wie C oder PHP programmiert. Ein Beispiel hierfür findet man bei dem Link von Oben.

    Yodas Sprüche sind nicht immer leicht zu verstehen. Wendet man dies aufs Coding an, wird deutlich dass auch das Lesen des Codes schwieriger wird. Da es beim Programmieren nun einmal kein Schwarz und Weis gibt, muss jeder für sich entscheiden was einem besser gefällt bzw. an einer Stelle besser passt.

    Einen netten Blogeintrag wie schlecht Yoda Conditions sind, findet man unter: why yoda conditions are bad.

    Aber es gibt natürlich auch immer Ausnahmen:

    public void foo(String someString) {
        // without yoda condition
        if(someString != null && someString.equals('myString')) {
            // do something
        }
    }
    

    Ohne Yoda Condition muss bei Java immer noch überprüft werden, ob der String NULL ist. Der Code mit Yoda Condition hingegen ist um einiges kürzer und lässt sich immer noch ganz gut lesen.

    public void foo(String someString) {
        // with yoda condition - don't care, if someString is NULL
        if('myString'.equals(someString)) {
            // do something
        }
    }
    
     
  • Chris Kaempfe 2:32 pm on November 14, 2011 Permalink | Reply
    Tags: , ,   

    Mockito und Byte Arrays 

    Der Aufruf von Methoden mit Byte-Arrays ist mit Mockito kein grosses Problem. Um ein Byte-Array zu matchen wird nicht, wie für die ‘Standard’-Argumente, die Matcher-Klasse verwendet, sondern die AddiationalMatchers. Die AdditionalMatchers können für alle primitiven Arrays von Java verwendet werden.

    Ein kleines Beispiel um dies zu verdeutlichen:

    // handles several types for some purpose
    public class TypeHandler() {
        public void byteMethod(byte[] array) {
            // do something here with byte array
        }
    }
    

    Die von Mockito zu verifizierende Methode byteMethod hat die oben gezeigte Signatur und es soll getestet werden, ob die Methode auch einmal mit dem entsprechenden Byte-Array aufgerufen wird:

    public void testByteMethod() {
        byte[] data = new byte[7];
        // create Mock
        TyepHandler typeHandlerMock = mock(TypeHandler.class);
        Foo foo = new Foo();
        foo.setTypeHandler(tyepHandlerMock);
        // within this method the 'byteMethod' should be called once
        foo.runByteMethod();
        verify(typeHandlerMock).byteMethod(AdditionalMatchers.aryEq(data));
    }
    

    Mit Hilfe des AdditionalMatchers und der Methode aryEq wird überprüft, ob auch das erwarte Byte-Array an die Methode übergeben wird. Das ganze kann man aber auch allgemeiner halten:

        verify(typeHandlerMock).byteMethod(any(byte[].class));
    

    Nun überprüft Mockito, ob die Methode byteMethod mit irgend einem Byte-Array aufgerufen wird.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel