Assigning HTML “rel” attribute to all page images

Very briefly, in a CakePHP app, I want to apply the lightbox script on all the images that link from a thumbnail to a larger image. If there are more than two, I want them to appear as a lightbox group. I don’t want the user to mess with TinyMCE and HTML, therefore I automatically apply the rel attributed for every single image in a page that is a hyperlink. The following PHP bit is added in app/Plugin/Nodes/View/Nodes/view.ctp. With some small changes it can be used for any PHP compatible web site.

$body = $this->Nodes->body();
if (strpos($body, "img")) {
   $pattern ="/<a(.*?)href=('|\")(.*?).(jpeg|jpg|png)('|\")(.*?)>/i";
   $newLink = '<a$1href=$2$3.$4$5 rel="lightbox[group]".$6>';
   echo preg_replace($pattern, $newLink, $body);
} else {
   echo $body;
}

Java encrypt class

A simple implementation of an encryption class to be used in Java applications for either encrypting strings and calculating files’ fingerprint.

import java.io.FileInputStream;
import java.math.BigInteger;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

public class Encrypt {

   private FileInputStream fis;

   public Encrypt() { }

   public String encryptString(String input, String salt, String algorithm) {
      String output = null;
      String fullInput = null;

      if (!salt.equals(null)) {
         fullInput = salt + input;
      } else {
         fullInput = input;
      }

      try {
         MessageDigest digest = MessageDigest.getInstance(algorithm);
         digest.update(fullInput.getBytes(), 0, fullInput.length());
         output = new BigInteger(1, digest.digest()).toString(16);
      } catch (NoSuchAlgorithmException ex) {
         ex.printStackTrace();
      }
      return output;
   }

   // Based on: http://www.mkyong.com/java/how-to-generate-a-file-checksum-value-in-java/
   public String calculateFingerprint(String fileName, String algorithm) {
      StringBuffer sb = new StringBuffer();
      try {
         MessageDigest md = MessageDigest.getInstance(algorithm);
         fis = new FileInputStream(fileName);
         byte[] dataBytes = new byte[1024];
         int nread = 0;
         while ((nread = fis.read(dataBytes)) != -1) { md.update(dataBytes, 0, nread); }
         byte[] mdbytes = md.digest();
         for (int i = 0; i < mdbytes.length; i++) {
            sb.append(Integer.toString((mdbytes[i] & 0xff) + 0x100, 16).substring(1));
         }
      } catch (Exception ex) {
         ex.printStackTrace();
      }
      return sb.toString();
   }
}

Link to GiHub repository. The class is intended to be used as a library within Java applications.

Example for encrypting a string:

Encrypt en = new Encrypt();
String encryptedString = en.encryptString(textField.getText().toString(), \
"salt goes here if you want", "md5")));

Example for calculating the fingerprint of a file:

Encrypt en = new Encrypt();
String fingerPrint = en.calculateFingerprint("/path/to/file", sha1);

Android SQLite Adapter class

Working with an SQLite database on Android can require some times more effort than what you should really give. For instance, if you ship a pre-configured and populated database with an application, you would need first to copy over the database to the specific database directory and then open it for reading and/or writing data to it. The SQLiteOpenHelper class provides a few methods that make life a bit easier but it does not provide a copy method for handling this issue. In addition to this, a check method would be required before copying the database and so on. Following on this, I implemented a SQLite adapter class to cover my needs as bellow:

- Copy database to the correct directory.
- Open and close the database.
- Execute raw SQL query.
- Execute SQL query for string, int, long, double.
- Drop table.
- Return count of a table.
- Download a db copy from Internet and replace local one.

Source code at GitHub.

Android SDK x86_64 – adb, libraries, emulator issues

I have installed the latest Android SDK on Fedora 17 x86_64 version. I’ve chosen the bundle for my platform, expecting it would work straight away, but that was not the case. The adb (Android Debug Brdige) needs to make use of the of libraries for the i686 version, such as glibc, ncurses and tdc++. Errors look as usual:

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

In addition to these I required to install libz for the SDK to perform correctly without any errors. Simply linking from /lib64 to /lib wouldn’t work, as adb would exit with segmentation fault, something expectable since it deals with different architecture’s libraries.  The following command will install all the required packages (with a couple of dependencies) to get that bit working:

yum install glibc.i686 ncurses0libs.i686 libstdc++.i686 libzeitgeist.i686

In addition to the libraries issues for the adb, the emulator binary that lunches the Android emulation images is also targeted for i686. The bundle comes with emulator-x86_64 but when you lunch an AVD (Android Virtual Device) through the ADT Manager, it wouldn’t start the emulator as the binary was failing to execute and wouldn’t pick automatically the x86_64 version. In this case a simple link would work. I renamed the initial i686 binary to emulator-32, and linked emulator-x86_64 to emulator. The actual AVD would then start as it should and operated normally, being able to install applications via the Android SDK.

Converting OS X .plist to XML

The failure of my MacBook Pro seems that it didn’t cost much in terms on data loss, actually all the really crucial data were there. There are though some bits here and there that need to be moved over to my Linux box. One of the most important for everyday use the was the feed list for my RSS Aggregator. I was using the elegant, nice and simple NewsFire which uses binary plists (XML-like) for storing the feed list and I was never bothered exporting the feed list to OPML. The plist command in OS X can convert the .plist file into a .xml file, however I had no other Mac to do this operation or copy over the plist and export in OPML from there. Therefore I had to find a workaround for getting the plist working on RSSOwl or Liferea. Found the Perl plutil for Linux which converted the binary plist to standard XML. RSSOwl managed then to import the XML with all the blogs’ feeds as on NewsFire.

Regarding liferea, it wouldn’t import the XML file as it wasn’t proper OPML. But since RSSOwl imported the XMl file, I exported the feed list as OPML, which would be imported into Liferea or any other application.

An ARM comparison: Raspberry Pi vs OpenRD Client

Bellow there’s a comparison between Raspberry Pi (Model B) and OpenRD Client, two low-power ARM SoC (System on a Chip), running Linux (Rasbian and Fedora respectively). I used the EEMBC CoreMark benchmark with default settings for 100000, 1000000 and 2000000 iterations. For each set, each device keep its performance with the same rate of iterations per second. The difference between the devices is at, an average level of, 520 iterations per second. That translates to 1.4x faster in favour of the OpenRD Client.

While OpenRD Client performs better, in terms of efficiency, Raspberry Pi seems to doing much better. In terms of CPU, Raspbeery Pi uses a 700MHz (with the possibility of setting it up to 1GHz) ARMv11 processor while OpenRD Client an older 1.2GHz Marvell Sheeva (ARMv5TE). ARMv11 supports an FPU unlike ARMv5 and that is one of the reasons that Raspberry Pi performs quite well despite its lower specifications. In terms of memory, Raspberry Pi uses 256MB DDR2 800MHz (newer models have 512MB RAM), in share with its relatively powerful GPU, while OpenRD Client uses 512MB DDR2 800MHz. OpenRD Client also provides Gigabit Ethernet as well as many more I/O interfaces. Also, OpenRD has preloaded OS, unlike Raspberry Pi that boots from an SD card. During this benchmark, Raspberry Pi was running Rasbian “Wheezy” (unofficial Debian port to armhf) while OpenRD Client Fedora 8.

(Raspberry Pi diagram - http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspi_Iso_Blue.png)

(OpenRD Client Hardware Block diagram - http://www.globalscaletechnologies.com/skins/skin_1/images/OpenRD-Client_back.PNG)

HFS+ on Linux

My MacBook Pro seems to have died. Its hard disk holds lots of data that have not been backed up anywhere else. The important data have been mostly backed up but latest changes haven’t been backed up. Other than that, I had to check the hard disk for bad sectors etc and since I don’t have another Mac to test it on I had to do it on my Fedora box. My system (Fedora 15) would automatically detect and mount the HFS+ hard disk on read only mode. It was also missing the fsck tool for HFS+ partitions. Getting the fsck tool for HFS+ required downloading and installing hfsplus-tools via yum.However, fsck.hfs will not allow you, except if you use the –force option, to scan the partition if it has journalling on, which is the case with HFS+ partitions by default.

But how would I turn off journalling when I don’t have a Mac system to attach my disk on? After a couple of minutes I came across a post on the Ubuntu forum which linked to this blog. The author has a C code that turns journalling off. A fixed version of this code can be found here. The compiled code results in an executable which gets as its only argument the partition that you want to get journalling off.

# gcc journalling_off.c -o journalling_off
# ./journalling_off /dev/sdg2

Next step was to perform the fsck check on the target disk

# fsck.hfs /dev/sdg2
** /dev/sdg2
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking Extended Attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume OS X appears to be OK.

Disk looks OK. Next step is to mount it with read-write permissions:

# mount -t hfplus -o rw,user /dev/sdg2 /mnt/osx

Next issue encountered was the different UIDs between my account on the OS X system and that on the Linux system. Therefore, next step was to change the UIDs under the whole user directory on the OS X disk so I could access without problem with write permissions from my Linux box:

# find panoskrt/ -uid 501 -exec chown panoskrt {} \;