One of the most important features of the Synology DS110j NAS is the ability to let it backup itself. This is actually a new feature in V2.3 of the DiskStation firmware. Here are my first impressions.

There is one thing that bothers me; I could not re-use the old bucket which I created when using Jungle Disk, at least what I could tell. When selecting the existing bucket, the DiskStation does not accept it because of its long name. The Jungle disk also create strange directory layout with something that looks like a tree map. This is in normal cases hidden for the user; Jungle fixes to mount a network drive. The network drive looks like a normal directory. If I remember correctly this is something that I choose when creating the original bucket. Anyway I tested and created a new bucket. I then started a backup of a small amount of files to test how it worked. The DiskStation solution is much simpler than Jungle Disk. One must consider that the Amazon backup is a new feature of the DiskStation software, while Jungle Disk has been around for some time. For example, you could not encrypt the content. You only use an encrypted transfer, that is you are using HTTPS for transfer. Another thing that I miss is a progress bar or similar. As it is today, you only see the status like this:

You only see that the backup is going on. I think I need to file a feature request for this. Notice that the backup type is a little bit misleading. As I wrote earlier, it is only the transfer that is encrypted.

The Jungle Disk desktop software discovered the new bucket I created for the DiskStation server. It informed that the bucket was compatible with Jungle Disk. I was then a little bit surprised when I could not discover any contents there. I decided to get another Amazon S3 browser. I found the CyberDuck browser. It has the capability to browse an Amazon S3 account, as well as a multitude of other servers like FTP, Samba etc. The FTP browser could come in handy when connecting to the FTP server in the DiskStation. (I have actually tested it and it worked without any problems.)

The CyberDuck browser works like a charm with all my buckets, see the picture below.


This shows the directory layout for the DiskStation and the Jungle Disk buckets. Notice that I have decided to do no incremental backup for the DiskStation. This is because I want to be able to restore my data, even if my DiskStation crashes. I could for example use CyberDuck to download all the contents. I think that I have configured the Jungle Disk to do incremental backup, which is like comparing apples and oranges. Anyway I am a little bit wiser than I was when I configured Jungle Disk from the beginning. The drawback is of course that is uses a lot of more space on the server. My opinion is that it is worth the extra money to be on the safe side. It is going to take some days to backup the pictures once more, but the DiskStation could work 24/7 without affecting my daily work. Meantime I could test other DiskStation features. There seems not to be any performance problems using other services while doing the backup. But this is only a problem during the first backup. When the initial backup has been performed, I have scheduled the backup to run at night every.

All in all I think that this solution is much better than the old one. All of our media files are now stored on the DiskStation and the backup is done as described. On my Mac I run TimeMachine to backup my laptop automatically. I will be able to go to sleep each night being sure that the things that I have added are safely transferred to my Amazon S3 account.

It is now time to configure and install my brand new Synology DS110j NAS. It comes with a CD containing V2.2 of the firmware and the desktop application. However I want to use V2.3, since it has support for backing up to a remote Amazon S3 account. I had downloaded and installed V2.3 of the desktop application. The desktop applications are the Synology Assistant and DownloadRedirector. The Assistant is used to find all the Synology servers on your network. When it does, you could use it to configure it and do basic setup. It also contains a resource monitor and a photo uploader. The DownloadRedirector is used for setting up downloads that downloads files directly to the DiskStation. Thus it is time to start the Synology Assistant.

When starting the Assistant you see a list of servers. In my case there was only one. The status of it was "not configured". By double clicking on it, I started a configuration wizard. I used the standard settings on every page. However at the last page I was given the choice to select which firmware version. Good! I selected the downloaded zip file. It complained that it was not the correct file extension. It should a .pat file, that is a firmware patch file. OK, I double clicked on the zip file to extract it. No .pat file inside it. I downloaded another version to figure out if it contained a .pat file. But no success. I decided to go with the supplied version while I was to figure out what the problem was. Some people have complained about the long configuration time, especially the formatting have been causing problems for a lot of people. When I started the configuration I was told it could take about 10 minutes. It looked like this:

Meanwhile I was trying to figure out what the problem with my downloaded firmware was. Could not figure it out. Time to test the support. I filled in a rather basic issue report on-line. After that I continued to find the problem. Unzipped the original zip file once more. What? I saw the status information flashing by "Unzipping .pat file" or something. Does it really contain a .pat file? Strange! Is it a hidden file. No, it would not be possible to select the file by default then. Maybe it was the archive utility that is causing me all the trouble? I decided to use the command line zip. An there it was. The zip contained a .pat file. However the .pat file seems to be a zipped file as well. When it is discovered by the archive utility, it unzips this as well. In normal cases this is a good thing. If you extract a .tar.gz file, this is what you want.

For those of you that encounter the same problem, let me explain in more detail. You start the Terminal. You find it in the Utilities folder in the Application folder. The type the following (assuming that you downloaded it to the Downloads folder)

cd Downloads

unzip synology_88f6281_110j_1141.zip


As a result you have a file called synology_88f6281_110j_1141.pat in your Downloads folder. Very easy if you know how to do it.

Now let me continue with the story. The next thing I decided to do was to setup the printer. The printer has always been connected to my wife's computer. The reason for this is that she simply print more documents than me and my laptop is not always at home. However I find it annoying to start her computer to print a single document. This day I for once really needed to print a document.

When the device was configured, I connected to it. This was done by double clicking it or select it and select connect. A web page was prompting me to login.


After login I found the "USB Printer" in the folder "External Devices".  I plugged in the printer and it was automatically discovered. This is how it looked like:



I Googled the Internet and found the same description on the Synology wiki. However it contained more information for newer Mac OS versions. I started the configuration, but halted when I was prompted to enter an IP address. Not good! I should enter a name and the IP should be resolved automatically. After a little bit of research I found something called Bonjour. It is a service discovery protocol. Actually it is Apple's implementation of Zeroconf. I found the configuration for this in Home->File Sharing->Win/Mac OS. I enabled the Bonjour broadcast as seen here below.


From now on it was simple. Just opened the "System Preferences", clicked the "Print & Fax" button.  Pressed the + button below the printer list. The printer was automatically discovered. Very easy setup.

This is all for now. Look out for my adventures with my DiskStation.

Yesterday I came home from Istanbul, Turkey. My NAS that I ordered a couple of weeks arrived at the DHL pickup place the day I left for Turkey. As you might have guessed I have been eagerly awaiting to pick it up. Today I got some spare time to pick it up. I have always loved to unbox new technical stuff. This time I thought it was a good idea to do an unboxing article. Please enjoy!

The first look at the stuff I received:

To the right you see the Synology DS110j NAS. There is no harddrive included, so you must install one yourself. To the left you see the harddrive that I ordered. It is a Western Digital Green 640 MB. All Synology products are energy conscious. Thus I hope that I get a solution the is environmental friendly and does not give me big electrical bills.


Here you see the label on the side listing the main features of the DS110j. The specifications are there as well. For more information please download this document.

The box contains two smaller boxes and the power cord. The box to the left contains the NAS device and the box to the right some additional cables and the power supply. Let us take a look a closer look at the box to the left.

Now we are getting somewhere.  The NAS is about the be unveiled. But there seems that I need to read something first. Synology have saved some trees by printing a very small booklet. It references to the documentation stored on the enclosed CD. So you need a computer to set things up, but that should be no surprise since it is intended to be used with your computer.

This is how the front looks like

A fairly regular set of LEDs and buttons. From top to bottom, the LEDs are; STATUS, LAN, DISK. Below the DISK LED there is an unnamed LED. Maybe a LED showing the USB status. Me do not know. Then comes a USB connector. Here you could connect a harddrive or a printer. If you connect a harddrive or a memory stick here it is possible use the USBCopy functionality. By pressing the button below it, the content is copied to the diskstation. At the very bottom you find the On/Off button and the corresponding LED. This turns into blue when the device is on. It blinks when the device is starting up.

The back looks like this

Last week I decided to buy a NAS. Every time I buy some new geek stuff, I spend many hours on research to select the optimal model. I usually start out with a price comparison site like pricerunner or prisjakt (in Swedish only). Of course I set up some requirements as well. My initial requirements was:

1. Support for Windows & Mac OS (Samba or an equivalent solution)
   
2. Secure FTP server
3. Reasonable amount of harddisk space

Nothing special, but at least I need to know what I am looking for. After a couple of hours of hard research I had these alternatives left:

1. Netgear Stora Home Network Storage MS2110
2. D-Link DNS-313 or D-Link DNS-323
3. Synology Diskstation DS110J or DS210J NAS server

Of course there are a lot of other brands, but these are the ones that I feelt was right for me. Both Netgear and D-Link are brands that I knew before, but I have never heard of Synology. The Netgear model is the most affordable. It comes with a pre-installed harddisk which is 1 TB big. It also has the option of adding an additional harddisk. The D-Link and Synology NAS servers requires you to install one or two harddisks yourself. I prefer to select the harddisk myself. The Netgear looks a little bit bulky.  The D-Link and both have support for Samba and FTP.  The feature that sticks out on the Synology NAS is the Amazon S3 support. Today I make backup using an S3 account. It would be even more convenient if the NAS could do that for me. Then I could schedule backups when I am not at home and have my computer with me. Last but not least, Synology have forums with many active users.

When I receive the NAS I want to change the network a little bit as well. This is how it looks today:

Our family photos are saved on either of the external harddisks. I sync these harddisks with the excellent Beyond Compare tool. When in sync, I use Jungle Disk to do the backup. Even though Beyond Compare is my favorite tool, I find it a little bit boring to synchronize these harddisks.  This is where the new solution should be a little bit smoother.

This is how it should look like after the upgrade.


Now we could store all of our photos on the Synology NAS server. The NAS server do backup at scheduled times. No need to synchronize the harddisk anymore. Each the computers should backup other valuable content as well, to the NAS. There is still room for improvement. For example, I plan to have wired connections to all computers in the household. The "old" switch that is used for the home entertainment should be replaced by a faster one.

But what model did I choose? You might have guessed it; I ordered the Synology DS110J together with a Western Digital Green 640 GB harddisk. This way I have an environmental friendly solution. All Synology products are designed to be environmental friendly. Notice that I use a D-Link Green DGS-1005D switch in the new network solution. 

That is all for now. I am really eager to get started with my new NAS. The original ETA was tomorrow, but the time seems to have slipped. I hope that it will arrive before the weekend.

What should it take to upgrade Microlog to 3.0? A while ago I release V2.3.4 of Microlog. There was only one "small" change, the Microlog instrument and instrument example modules were activated once more. They had not been part of any previous 2.X release. But was it a good decision to make only a patch release for such change? I must admit that I think this was an incorrect decision. The change was big enough to make a minor release or even a major release. What should I do to solve the situation right now?

I think the best solution would be to make a major release, that is that I should make a Microlog V3.0. This makes it possible to make some other changes that I wants to do. The changes that first comes to mind are these:

• Add the logging level NONE.
• Remove the Android module
• Remove the Amozon S3 module
• Cleanup the PropertyConfigurator
• ?

Some explanation might be in place. Adding the Level NONE gives the possibility to stop the logging without removing the logging from the code. This is sometimes used for production builds, with the possibility to enable logging after distribution. The feature has been asked for many times. To be honest I do not remember why this has not been implemented before.

Removing the Android module is for obvious reasons, since we have forked the Android parts this is no longer necessary to keep in the Microlog project. But is might not be obvious why to remove the Amazon S3 module. For me this was an experiment, but not something that turned out well. It is big and clumsy. A 3rd party library is used for the SOAP communication which also adds to the size. Fortunately it is kept in a separate jar. Thus only developers using the Amazon S3 modules are affected by this. Another drawback is that we need to maintain this module. I feel that I rather spend time on maintaining the core and other modules that are more important. But this is something that certainly is worth discussing. What do you think?

Cleaning up the PropertyConfigurator is something that I have wanted for a while now. When adding the hierarchical logging support in V2, I kept the original configuration possibilities. This is not wrong. However there are parts in the code that could be shared between the Microlog classic configuration and the new configuration. The parsing of attributes could be replaced by a separate StringTokenizer. All in all I think that the size of the configuration classes could be slimlined.

I guess that there are some more parts that could be improved and/or added to the list for Microlog V3. This was all that I could think of right now. Do you have any suggestions?

Today I have investigated the possibilities to read properties files on Android. In microlog4android there is no configuration possibilities via file as it is today. The microlog4android development team feels that we need to re-write the configuration from scratch. There are many reasons for this decision, for example there is the Properties class available on Android while in Java ME we use microproperties. These are my findings about properties files on Android.

My first thought was to use the SharedPreferences class. My brain picked up this idea while using the SharedPreferences in another project. The SharedPreferences is used to read/write preferences for an Android application. The preferences are stored in an xml file that is put in the private directory structure of an application. You could edit the file by pulling it from the device or emulator using adb pull. After editing it you push it back using the adb push command. If you are using the Android Eclipse plugin you could use the file browser to do the same trick. But this is cumbersome to pull/edit/push the file and I do not really like to use XML for storing properties.

But how do we do it in microlog? The properties are stored in a properties file that is put in the JAR or by setting properties in the JAD file. Both are easily edited in Eclipse without no need to pull/push the file. The same goes for NetBeans. The properties file is bundled with the jar. Why not do the same on Android? Time to Google again! I found out that there was primarily two ways of doing this:

1. Using the AssetManager
2. Reading a raw resource

To test this I created a simple Android project in Eclipse and copied two microlog properties files. One was put in the /assets directory while the other was put in the /res/raw directory. The first thing that happened was that Eclipse complained about the naming of micrologV2.properties that was put in the /res/raw directory. It was kind enough to inform me that only [0..9][a..z] was allowed. Changing the capital V to a lower case v was simple. Now time to do some coding. The code for reading using the AssetManager looked like this:

Resources resources = this.getResources();
AssetManager assetManager = resources.getAssets();

// Read from the /assets directory
try {
    InputStream inputStream = assetManager.open("microlog.properties");
    Properties properties = new Properties();
    properties.load(inputStream);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
} catch (IOException e) {
    System.err.println("Failed to open microlog property file");
    e.printStackTrace();
}

The code is dead simple and thank God for the Properties class, although microproperties would do the trick. The second way to do it is as simple as the first approach. The code looks like this:

// Read from the /res/raw directory
try {
    InputStream rawResource = resources.openRawResource(R.raw.micrologv2);
    Properties properties = new Properties();
    properties.load(rawResource);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
} catch (NotFoundException e) {
    System.err.println("Did not find raw resource: "+e);
} catch (IOException e) {
    System.err.println("Failed to open microlog property file");
}

Notice that I omitted the code for getting the resources, since this was part of the first example. Both ways seems to be good. But what to choose? Using approach 1) has the following advantages from a microlog4android perspective:

1. You are not limited to name your file with lower case letters only.
2. It is possible to use a default file name if the user does not specify one.

But I probably will implement both solutions, since this gives the user a freedom to choose where to put the file. What do you think? Is there any other solutions that I have missed out?