Today I needed to find out the IP address of the currently logged on user (e.g. via SSH) on a Linux system to use it in a bash script. After searching the web for a simple tool for this task for quite some time, I finally came up with the following bash script to get me the needed information. Is there any way to obtain the IP address in a simpler way by using built in Linux tools?
HOST=`who am i | sed -r "s/.*\((.*)\).*/\\1/"`
IP=`host $HOST | sed -r "s/.* has address (.*)/\\1/"`
Update (10.04.2012): NUNIT (now NatUnit) is now available via SourceForge: NUNIT/NatUnit at SourceForge.
As part of my Master’s thesis about Test Driven Development (TDD) I developed a Unit-Test-Framework for the programming language Natural. This 4GL language from Software AG is in use for over 30 years now but the notion of automated tests has not been spread throughout the developer community. Perhaps now, with a framework for tests available, this will change 😉
The Unit-Tests that can be run by NUNIT are subprograms and need to have the following structure. As you can see, the fixture’s and tests’ names are simply plain text to allow strings that are longer than 32 characters (the longest possible name for a Natural module) to provide meaningful names as in Behaviour Driven Development. The TestCases are parsed by NUNIT for this structure to make sure that all the needed parameters, subroutines etc. are available. To create a new TestCase all you have to do is copy the example source code and change the names and the implementation of the tests in the IF-branches.
DEFINE DATA
PARAMETER USING NUTESTP /* parameters for a single test
LOCAL USING NUCONST /* NUNIT constants (error code etc.)
LOCAL USING NUASSP /* parameters for the assertions
END-DEFINE
*
NUTESTP.FIXTURE := 'Example TestCase 1' /* this TestCase's fixture
*
INCLUDE NUTCTEMP /* the template method (SETUP -> TEST -> TEARDOWN)
INCLUDE NUTCSTUB /* stub implementations of SETUP and TEARDOWN
*
DEFINE SUBROUTINE TEST /* the main test routine
*
**************************************************************
IF NUTESTP.TEST EQ 'comparing two equal numbers should pass' /* name of first test
**************************************************************
ASSERT-LINE := *LINE; PERFORM ASSERT-NUM-EQUALS NUASSP 2 2
END-IF
*
**************************************************************
IF NUTESTP.TEST EQ 'comparing two different numbers should fail' /* name of second test
**************************************************************
ASSERT-LINE := *LINE; PERFORM ASSERT-NUM-EQUALS NUASSP 1 2
END-IF
*
END-SUBROUTINE
*
END
The following diagram shows NUNIT’s architecture. I tried to make the adaption of NUNIT to a different platform than ours (Solaris with Natural modules saved in the file system) as easy as possible and encapsulated the OS-specific implementation into two modules that need to be changed accordingly. I have also included some basic assertions like ASSERT-NUM-EQUALS, ASSERT-STRING-EQUALS and ASSERT-ARRAY-EQUALS and some example TestCases in the source code you can download below.
The TestCases’ names are defined in a user-specific workfile in the home directory (in the current configuration, but this may be changed e.g. to a DB READ). A run of all defined TestCases is as simple as calling the main program NUNIT and produces an output like the following (even with a “red bar” 🙂 ).
Notice the nice failure/error messages including the module names, line numbers etc. 😀
I developed NUNIT by applying TDD which means the framework tests itself. After you “installed” it (which means importing the NUNIT modules into a library of your choice, preferably a steplib if you plan on using it throughout your application) you can run a simple TESTNU to make sure NUNIT behaves as expected.
All NUNIT modules include a detailed header comment so they should be pretty self-explanatory. But in fact, all you need to start are the programs TESTNU, NUNIT and NUSINGLE (with which you can run a single TestCase) and a TestCase like TCEXMPL1. Just try it out and let me know if you like it 🙂
In one of my C# projects I wanted to add tests for a class that uses System.Net.Sockets.Socket. The problem was that the class (FTPConnection) depended directly on Socket as shown in the following class diagram. So I had to find a way to get rid of this direct dependency and mock the Socket class to be able to test FTPConnection without connecting to a live FTP server for each test.
The problem with mocking System.Net.Sockets.Socket is that it implements no abstract interface and is also sealed (which means you cannot derive from the class). Therefore, you cannot mock the class directly with RhinoMocks (which otherwise would be able to mock the class directly without the need for an interface). So we have a (framework) class to whose source code we have no access (which we would need to add something like Socket : ISocket) and from wich we cannot derive a new class. How do we mock such a seemingly isolated class?
First of all, we need a common interface that we can use for mocking. The problem is that we have to make sure Socket implements this interface (let’s call it ISocket). How do we do that? We find a possible answer to that question in the GoF design patterns catalog:
The adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. (Wikipedia)
So we have to create an adapter class that implements ISocket and simply delegates all calls to its methods to an instance of Socket. Then we make sure FTPConnection uses the adapter class (or rather ISocket) instead of Socket directly and provide a constructor through which we can inject our own implementation of ISocket (e.g. the mocked one) as shown in the following class diagram.
It is quite a bit of effort to mock the Socket class (you have to define every needed method in ISocket and implement the delegation in SocketAdapter) but it definitely pays off! The resulting design is less coupled due to FTPConnection depending on ISocket instead of Socket directly and can be tested easily by providing a mocked socket that simulates valid or invalid FTP server responses. Examples of how to simulate FTP calls and responses using RhinoMocks are included in my example project below.
I have created a small console application in C# according to the second class diagram above which demonstrates the mocking of System.Net.Sockets.Socket and produces the output shown in the following screenshot.
You can download the project here:
Wir haben einen Tag unserer Hochzeitsreise nach Bali mit unserem Hochzeitsfotografen Michael Stange (und seiner Frau, sowie dem einheimischen Fahrer Nyoman) verbracht und wunderschöne Bilder am Strand, in den Reisfeldern und im Monkey Forest machen lassen. Hier sind die entsprechenden Blog-Einträge von Michael dazu:
Einige Fotos kann man (in hoher Auflösung) bei Flickr bewundern: Fotostream von michaelstange (26.10.2009).
Und ein paar davon gibt es auch hier zu sehen. Kommentare sind erwünscht 😀
Es war wirklich sehr heiß bei 35° Grad im Anzug und Kleid, obwohl man das auf den Bildern dank Puder nicht sieht 😉
Das grüne Tuch, das z.B. auf dem vorletzten Bild zu sehen ist, ist ein Sarong. Den muss man auf Bali tragen, wenn man den mittleren Hof eines Tempels (in diesem Fall der Tempel im Monkey Forest) betreten möchte. Da der untere Teil des Körpers dort als unrein gilt (bzw. den Dämonen nahesteht), muss er durch den Sarong bedeckt und durch einen Gürtel vom oberen Körper abgegrenzt werden.
Die Affen im Monkey Forest heißen Makaken (wie passend zu meinem Namen ;-)) und einer von ihnen hat hartnäckig versucht, die Perlen vom Kleid abzuknabbern, was ihm bei einer auch tatsächlich gelungen ist. Ansonsten waren die Affen aber friedlich und faul.
Sehr witzig war, dass Julia Roberts an dem Tag, an dem wir die Fotos gemacht haben, auch im Monkey Forest war (allerdings erst nachmittags als wir schon weg waren) und die einheimischen Besucher sie mit Jaqueline verwechselt haben, weshalb sie fast mehr Fotos von ihr gemacht haben als Michael. Wir Europäer/Amerikaner sehen für die Balineser wohl alle so “gleich” aus wie sie für uns 😉
Um die Namen von Autoren, die in LaTeX mittels \citep oder \citet zitiert werden, im Fließtext (und nicht etwa im Literaturverzeichnis!) in Kapitälchen zu setzen, war bei mir eine winzige Anpassung in der Datei natdin.bst nötig (via mrunix.de).
Diese sorgt dafür, dass in die *.bbl-Datei die entsprechende Auszeichnung in die \bibitems eingetragen wird: In der Funktion output.bibitem musste der Output "\bibitem[" lediglich durch "\bibitem[\scshape{}" ersetzt werden.
Und schon sehen die Zitate aus wie hier:
Heute nehme ich mal an meiner ersten Blog-Parade teil, weil das Thema gerade sehr gut passt: Die 3 beliebtesten Fachbücher aus dem .NET-Umfeld (gestartet von Wolfgang Kluge). Bei der Literaturrecherche zu meiner Masterarbeit zum Thema Test Driven Development habe ich nämlich durchaus auch das ein oder andere .NET-Buch gelesen.
Meine drei aktuellen Favoriten im .NET-Umfeld sind die folgenden Bücher:
So. Das waren meine Top 3. Vielleicht ist ja was Interessantes dabei oder es hagelt Kritiken, warum ich ausgerechnet diese Bücher ausgewählt habe… Wie auch immer, Kommentare sind ausdrücklich erwünscht 🙂
Die ALTE OLDENBURGER Krankenversicherung in Vechta sucht zu sofort eine/n Anwendungsentwickler/in im Adabas/Natural– und/oder Java-Umfeld. Voraussetzung ist eine abgeschlossene Ausbildung zum Fachinformatiker Anwendungsentwicklung oder ein Studium der (Wirtschafts-)Informatik.
Außerdem soll im kommenden Jahr ab dem 01. August 2010 wieder ein/e Student/in der Wirtschaftsinformatik in Kooperation mit der BA Emsland ausgebildet werden. Bei der ALTE OLDENBURGER wird bei diesem dualen Studium die Ausbildung zum Fachinformatiker Anwendungsentwicklung absolviert, während das Studium in zehnwöchigen Praxisphasen an der BA Emsland in Lingen stattfindet.
Die Kontaktdaten für die schriftlichen oder elektronischen Bewerbungsunterlagen gibt es hier: Stellenangebote bei der ALTE OLDENBURGER.
Dann also mal nichts wie ran an die Bewerbung und vielleicht sind wir bald Kollegen 😉
Bei meinen Recherchen im Rahmen meiner Masterarbeit zum Thema “Test Driven Development als Maßnahme zur Qualitätssicherung bei der Softwareentwicklung” habe ich versucht, herauszufinden, welche Eigenschaften “gute” Unit-Tests aufweisen sollten. Herausgekommen ist die folgende Liste aus acht Eigenschaften, für die ich leider auch nach mehreren Versuchen mit unterschiedlichen Wörtern kein leicht zu merkendes Akronym finden konnte:
Wer hat noch mehr zu bieten?
Am kommenden Donnerstag, den 13.08. um 19 Uhr halte ich einen zweistündigen Vortrag zum Thema “Tod durch PowerPoint” bei der Kolpingsfamilie Rulle. Im Rahmen ihres Projektes 3KR (Kompetent Kommunizieren) werde ich auf die Gestaltung von PowerPoint-Vorträgen eingehen, die das Publikum nicht nach 5 Minuten in den Schlaf wiegen, sondern es vielmehr ansprechen und mitreißen.
Die übliche Literatur dazu sollte inzwischen allgemein bekannt sein. Wenn nicht, erfolgt hiermit der absolute Lesebefehl 😉
Wer sich nicht gleich alle Bücher zulegen will, kann auch erstmal mit dem Vortrag von Garr Reynolds bei Google anfangen: Authors@Google: Garr Reynolds. Da wird schon so ziemlich alles beschrieben, worauf es bei Präsentationen ankommt.
Mein Handout zum Vortrag gibt es hier: Tod durch PowerPoint (ShortURL zum Verlinken).
Es fasst die Oberpunkte meines Vortrags zusammen:
Heute hatte ich die Aufgabe, mit einem Script aus einem Ordner alle Dateien außer die 10 neuesten zu löschen. Kein Problem für die PowerShell:
$allFiles = dir *.* | ? { -not $_.PSIsContainer } | sort LastWriteTime -descending
$keepFiles = $allFiles | select -first 10
$allFiles | ? { $keepFiles -notcontains $_ } | % { del $_ -whatIf }
Aber irgendwie kommt mir das zu lang vor, für eine solche Aufgabe… kennt noch jemand eine einfachere (bzw. kürzere) Lösung?