A few days back at work I was trying to open a fairly large unformatted (a single line) JSON file generated through one of the junit tests. At first I tried to open it in Eclipse since my Eclipse JEE IDE contains an inbuilt JSON formatter but it ended in a disaster! So much so that I had to kill the Java process running Eclipse. Then I tried to open it using Mousepad, the default text editor that comes pre-installed with Xubuntu. It also failed and got hung. I even tried with Gedit but still no luck. I copied the file to a Windows machine and opened it using Notepad++. The online JSON formatters were able to prettify it, so I went on with it then. But the fact that I was not able to open it natively on my system was bugging me.

This week and last week I spent a lot of time writing code to implement the persistence feature for our module with EJB 3 at work. This is the first time I was working with EJB so there was quite a bit of learnings involved. During this time, I noticed that even some of the most seasoned developers don't have a very clear idea about how the whole Persistence thing in JPA works under the hood. They would take some of the things for granted like if they use an EntityManager in their managed objects, something will auto-magically manage everything for them and in the process, did some rookie mistakes.

try-with-resource is the new feature introduced in Java 1.7 to automatically close a resource after using. It basically helps you to avoid a finally block at the end of the try-catch block to close any resource that needs closing like the BufferedReader. But there's a catch. You can not use any type of resource with a try-with-resource block, only those classes that extend java.lang.AutoCloseable can be used, an interface that has a single method:

Before the final release, I like to test my Python scripts the way these are supposed to be invoked in actual environment, usually with command line arguments. And this is apart from the unit testing and integration testing that I have for the individual modules. I also use Python venv for development because I don't like to directly install all the required libs in my operating system, thus keeping the system PATH clean from the development libs. Invoking a Python script within the test cases is easy, you just need to use the os.system() function. But running a Python script from os.system() using the 'python script-name.py' syntax invokes the python executable from the OS even if I am running the outer Python test case from withing a venv.

This is my second post on LXD containers. Sometimes, using a container is a cleaner way to install and use applications for a number of reasons:

• You can install packages from any version of any distribution. That means, even if you are using an LTS release of Ubuntu like me, you don't necessarily have to stick to an older version of a package. Or if some package is only supported on rpm based distributions, you don't need to worry about it.
• You can go ahead and completely uninstall/reinstall it at any time without worrying about residual files or configurations.
• You can roll back to a previous state in no time if something goes wrong unexpectedly (lxd snapshots!)
• And then there is the security perspective also (lxd containers are secure by nature).

Last weekend I tried running mysql database from a local container and connect to it from my local system. Here's how: