For this reason I created a plugin for DokuWiki that allows me to cite sources from my online Zotero database by using the syntax known from LaTeX. The plugin reads my reference list from the Zotero website and caches it on a local wiki page. After that I can cite a source simply by adding \cite{ShortName}. Take a look at my wiki (e.g. Programming Hints) for some examples.

For this to work, every source needs to have a short name as I did not want the cite key to be the Zotero ID but rather a more meaningful name. Almost every Zotero entry type has the field “short name” assigned to it so I used that for this purpose.

Here is an example of the steps to perform to be able to cite a Zotero source:

1. I add a new entry to my Zotero database, e.g. Robert Martin: Clean Code (2008) and assign the short name Martin2008 to it.
   
   
2. I synchronize my Zotero database with the Zotero server (because the plugin reads the data from the Zotero website).
3. I write some text in my wiki and add \cite[p.123]{Martin2008}.
4. I preview or save the current wiki page and the plugin tries to find the cited reference in its local cache and displays it. If the entry is not already in the cache, it automatically loads my newest Zotero sources from the website, caches them, and displays the cited source afterwards.

For the initial import of all my Zotero entries I added a script that parses the complete reference list on the Zotero website.

Download

The plugin can be downloaded here: Download DokuWiki Zotero plugin or installed via the plugin manager.

Also see the DokuWiki Plugins page: zotero plugin.

Please see Install.txt for a short installation guide.

I tried editing the RTE parse function in TYPOScript but that did not solve my problem. So, after a while of searching the internet I found the answer: append rtekeep="1" to the link like in the following example. This tells the RTE to leave the link untouched.

<a href="file:///path-to-network-share" rtekeep="1">Link to file</a>

(via tuga.at)

However, I ran into some problems as the user id could be read by getUserId() but getUserItems() returned an empty item list. I found the solution after analyzing the request URLs: the user id is read using HTTP while all the other functions use HTTPS. So I simply added these two lines to httpRequest() to avoid checking the server certificate:

Furthermore, the name of the parameter for the API key is not apiKey but key. So the URL pointing to my bibliography items has to be https://api.zotero.org/users/{USERID}/items/?key={APIKEY} (you don’t need username). Although the API key is passed to phpZotero’s constructor, the class doesn’t use it in any of its HTTP calls, so I added this line to zoteroRequest():

After theses small changes my items could be read successfully.

1. Deinstall PowerShell 1.0: Control Panel → Show Windows Updates → Windows PowerShell 1.0 → Remove
2. Reboot the computer
3. Install Windows Remote Management
4. Install PowerShell 2.0
5. Test installation: Start → Run → powershell → $PSVersionTable:
   
6. Get rid of the “New updates available” message in the system tray: Start → Run → wuauclt /detectnow

I didn’t know the answer myself, although I presumed the function gets called only once. Interestingly, the PHP Manual doesn’t say a word about this question.

So, what’s the answer? The function gets called only once, as I suspected. Here’s the output of the code above:

1. call to getArray
ForEach: 1
ForEach: 2
ForEach: 3

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.

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

Downloads

• NUNIT’s source code (including intermediary versions as described in the thesis)
• The part of my Master’s thesis about the development of NUNIT (German)

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.

Example project in C#

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:

• MockASocket (Visual Studio 2008 project including executables and needed DLLs)

• Hochzeitsfotos auf Bali (”normales” Blog)
• Hochzeitsfotos auf Bali (Hochzeitsblog)

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

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: