The MySQL database can store large chunks of binary data (up to 1 GB) using the BLOB data types.

However, this does not work well if you access the MySQL database from Java (or any other JVM based language) using the MySQL JDBC driver.

The JDBC API supports an efficient stream based way to handle BLOBs, but the MySQL JDBC driver does not implement this properly. It works, but it will buffer all data in memory in a way which is very inefficient and can make your JVM run out of memory if the BLOBs are large.

A good rule of thumb is to not store any objects larger than 64 KB in MySQL. Store such objects as files outside of the database instead. So never use the MEDIUMBLOB, LONGBLOB, MEDIUMTEXT or LONGTEXT data types.

(I am not sure whether this advise is only valid for JVM, or for usage of MySQL from other environments as well.)

I was using java.io.PipedOutputStream in an Android app. The app performed horribly bad. After doing some profiling, it turned out that the call to PipedOutputStream.write(byte[]) that was really slow. After digging into the Android source code, I discovered that PipedOutputStream.write(byte[]) was not implemented, it just delegated to the default implementation in OutputStream which iterate through the array and call PipedOutputStream.write(byte) for each byte.

Since PipedOutputStream.write(byte) does some synchronization and Object.notifyAll() each time, it is really slow to do this 1000 times when you write a block of 1 KB data.

Just out of curiosity, I had a look on how PipedOutputStream is implemented in Oracle’s standard Java implementation. I haven’t actually done any benchmarks on it, but I can see from the source code that it is a completely different implementation which does implement writing a block properly and probably efficiently.

The bottom line is: Don’t use PipedOutputStream on Android. If you need similar functionality, implement it yourself or find a 3rd party library which does it.

I use Adobe Lightroom 4.4 for photo editing. There is one very annoying aspect of this program, it is not available for Linux (only for Windows and Max OS X).

In order to run Lightroom on my computer, I had to use VirtualBox and install Windows 7 in it. This works, but is quite clumsy and annoying. And since Lightroom is the only reason for me to run Windows, I would like to get rid of it.

So I decided to try out Wine. The current version of Wine does not support Lightroom out of the box, but I found some patches which seems make it work. This is how I did it, for Ubuntu 12.04 32-bit.

Uninstall any Wine installation you might already have

Prepare to build Wine from source (for some odd reason, it should be wine1.4 and not wine1.6):

This is no longer relevant, since the PPA have updated to GIMP 2.8.10, which has fixed the bug.

If you use Ubuntu 12.04 LTS, you only have access to the old GIMP 2.6 in the standard repositories. This is unfortunate since GIMP 2.8 have a lot of new useful features.

The standard way to get GIMP 2.8 is to use the a PPA, as described here. This used to work fine. However, then the PPA upgraded to GIMP 2.8.6, which contains a horrible UI bug (seems like neither the GIMP team, nor the PPA maintainer has any particularly strong QA process).

I find this bug unacceptable, and the PPA has not yet released any new update. So I chose to use GIMP 2.8.4 instead. This is not available from the PPA, so I decided to build it from source.

I found some instructions for building here. However, I was unable to build GEGL since the latest version uses a newer version of a standard library than what is available in Ubuntu 12.04.

Fortunately, you can still use BABL and GEGL from the PPA, and only build GIMP itself from source.

If you have an file with .aac extension, it is AAC encoded audio in an ADTS container. If you want to play such file on an Android device, you have problems. Android 2.x does not support this file format at all, and not even the latest version of Android supports reading metadata tags from it.

The solution is to repackage the audio in an MPEG-4 container to a file with .m4a extension. Android can both play and read metadata tags from such files.

This can be done with the MP4Box tool. You can also add metadata tags while repackaging:
MP4Box -itags "artist=${ARTIST}:name=${TITLE}:genre=${GENRE}" -add ${FILENAME}.aac#audio ${FILENAME}.m4a

If I understand it correctly, this will not recode the actual audio data, and thus not affect the quality in any way. The file size will also be almost the same.

What is REST?

In most cases, it is sufficient say that REST is a way to design a network protocol based on HTTP. I perfer to call it a RESTful protocol, but it can also be called RESTful API or RESTful Web Service. It is important to keep in mind that it technically is a network protocol, and not an API like an interface with some methods in a regular programming language.

REST is not RPC or RMI. You should not try to map an existing API in a regular programming language to a RESTful protocol directly method by method. Rather, you should map the domain model of your application to the protocol.

REST is not a religion. Be pragmatic and use what works for you. But be sure to understand the rules before you possibly break them, otherwise you may get unpleasant surprises.

How to do REST

The most important rule is to use HTTP properly and leverage it extensively. Read and understand the HTTP 1.1 specification in RFC2616.

Understand the concept of safe and idempotent methods:

safe – no observable side-effects

idempotent – doing same request several times have the same effect as doing it once

And use the appropriate HTTP methods:

GET and HEAD are safe and idempotent

PUT and DELETE are not safe but idempotent

POST does not have to be either safe or idempotent

Utilize the rich set of response codes defined in HTTP:

200 OK

201 Created

202 Accepted

303 See Other

304 Not Modified

400 Bad Request

401 Unauthorized

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

409 Conflict

412 Precondition Failed

415 Unsupported Media Type

500 Internal Server Error

503 Service Unavailable

Make use of HTTP headers:

Location

Allow

Authorization, WWW-Authenticate

Content-Type, Accept

ETag, If-Match, If-None-Match

Last-Modified, If-Modified-Since, If-Unmodified-Since

Cache-Control

etc

The request and response messages should simply contain your domain objects, probably encoded as JSON or XML (do not forget to set proper Content-Type). Do not wrap it in any envelope as SOAP does.

Do this: {"prop1":"foo","prop2":["one","two","three"]}

Do not do this: {"result":{"prop1":"foo","prop2":["one","two","three"]}}

Use HTTP response codes for errors/exceptions.

State and security

Try to avoid storing client session state on the server. You can push small session state to the client in URLs. Use HTTP Authentication, possibly with OAuth, to avoid having to keep track of “logged in users” on the server. Always use HTTPS with proper server certificates if you have any authentication, and consider using client certificates if it makes sense.

HATEOAS

This will give you a high degree of decoupling between client and server. It will be easy to evolve the protocol in a backwards compatible way, to allow newer clients make use of new features and still allow old clients to operate. And you can do this without any explicit versioning of the protocol.

The client should only need one entry-point URL, and will get all other URLs in responses from the server.

In HTML, you have semi-standardized link relations:<link href="http://foo.com/bar/edit" rel="edit" />

Use something similar to allow the server to send back URLs to the client:{"links":{"edit":"http://foo.com/1/edit","next":"http://foo.com/2"}}

URLs should be opaque to the client. The client should accept both absolute and relative URLs, and resolve relative URLs according to RFC3986 (use a platform or 3rd party library for this). The client may sometimes append query parameters. The client should never inspect or manipulate URLs in any other way. (This is exactly how an ordinary web browser handles links in an HTML web page.)

These instructions are tested with Ubuntu desktop 12.04, but will probably be useful in other Linux distros with GRUB2 as well.

The goal is to block everything except booting the default system. In paricular, it should not be possible for anyone to boot into recovery mode, since that will bypass normal login and give root access directly.

Run grub-mkpasswd-pbkdf2 from a terminal and enter the desired password, copy the output.

Please note that this by itself does not give you a secure system. It should be combined password protection for BIOS setup and for booting from removable media (CD-ROM) and USB devices. And you should not allow login without password in the main Linux system.

None of these measures protect from serious tampering with the hardware, such as removing the internal HDD and connecting it as non-boot device to another computer.

There is also a different approach which I will describe here. Have an image file of the root file system on the CD which you mount in RAM. This will bypass the restrictions of ISO 9660 since you can use any file system in the image, and it can be read/write after being read into RAM. The obvious disadvantage is that this will consume RAM proportional to the size of the root file system, which can be a problem since you will not have any swap space available. But in several use cases, the size of the root file system can be kept small enough for this to work.

The easiest, and probably best, way to do this is to simply use the initramfs mechanism built into the Linux kernel.

In the initramfs, the Linux kernel will start executing /init as the first process, and this process is not expected to exit. This /init can be (and usually is) a shell script. In a regular root file system, /sbin/init will be executed first. So you can convert a regular root file system into an initramfs by adding an /init like this (don’t forget to make it executable):

#!/bin/sh
exec /sbin/init $@

Then you need to package it as a gzipped cpio archive with these slightly awkward commands (${ROOT_FS} is where you have prepared the root file system, ${ISO_FS} is where you are preparing the file system for the CD-ROM, don’t forget to create the directory ${ISO_FS}/isolinux first):

Then put this initramfs image along with the kernel image and pass it to the bootloader. Given that you use isolinux as bootloader, put the kernel image in ${ISO_FS}/isolinux/vmlinuz, copy isolinux.bin to ${ISO_FS}/isolinux/ and create a config file ${ISO_FS}/isolinux/isolinux.cfg:

Then you can burn the ISO image on a CD-ROM, or use the image directly to test it in a virtual machine.

You can reduce the size of the root file system by placing some large auxiliary files (such as the files to install if you are building an installer) outside, directly on the CD-ROM. Then you need to mount the CD-ROM after boot, which can be a bit tricky. Given that you know that a file install.cgz should be on the CD-ROM, you can do like this to mount the CD-ROM on /media:

This is inspired from this article. However, that article uses the older and less efficient initrd instead of initramfs. It also mounts the root file system in a two-step bootstrap process which seems redundant to me. So I have made it simpler and more efficient. The procedure with boot menus and different run levels described in the section Customizing and Adding Scripts can be useful though, I recommend reading that section if you need some kind of menu.