All Posts

At work, I and the other software developers work primarily with the Java programming language. Part of our organization's goal involves algorithms and scientific data analysis of data sets, which is researched by another team. Traditionally there has been a lot of data analysis and scientific work with Matlab, but since the team has switched to Python. Python appears to have a strong scientific community and tools (such as pythonxy) for rapid development for scientific computing, data analysis, and data visualization. Since then, I have looked at ways where we can collaborate by running their algorithms in the JVM, without the need for costly and error-prone porting to Java. Ideally I'd like a way for the Python code to leverage a codebase developed over 8 years for our problem domain, and for Java code to leverage new work being done in Python.

Read on for my current progress...

Short answer for the web searchers: if /usr/bin/emacs points to jove, install emacs.

I've had the privilege of starting to play around with Angstrom (fork of OpenEmbedded) on the BeagleBone. I needed to build some bleeding-edge software with bitbake on an Ubuntu 10.10 but I ran into an interesting problem. When building the distribution, it builds all of the tools from the ground up, including automake. However, automake would crash when building some sort of support for emacs with a jove crash. I couldn't understand how they were related.

In the end, I found that since jove was installed but Emacs was not, /usr/bin/emacs actually pointed to starting jove. Automake was trying to use some kind of compiler for emacs (I guess it was making some emacs macros or syntax thing?). It must have thought emacs was properly installed and called Jove with a set of parameters that caused it to crash. In the end, the solution was to install Emacs. The build system itself wasn't in error, it was my machine, so it can't be reasonably "fixed" in the code so I put this post in hopes of people finding it if they search for the same problem.

At work I've been making a foray into web development. I've always been one to be very interested in "how to do it right" rather than just "get it done" and stop when it looks like it works. Security is one of the things where it works perfectly for the user -- but also for the attacker if you don't do it right. I've had a lot of experience with securing things with encryption, but the web is an entirely new (and scary) world.

The two attack vectors I looked into is XSS (Cross-site scripting) and CSRF (cross-site request forgery, aka XSRF).

I have a dual monitor setup that consists of an old 19" CRT (Philips 109P) and a 20.1" 1600x1200 LCD (Samsung 204B). I've always just managed with having different resolutions on the monitors, but one thing that always bugged me is that the pixels were different sizes if I picked standard resolutions. When you drag a window from one monitor to the other you get an odd "zoom" effect. But I always knew that CRTs don't have fixed resolutions and you can pick whatever you want. I figured out the setup to create a custom resolution in Windows so the two differently sized monitors would match up exactly.

Continue reading for the details.

Even coders have to eat sometime. Check out my guest post on my wife's blog, Kitchen Trial and Error.

Summer is great for food because you can always find fresh ingredients at the local farmers' market or your own garden. Sometimes you bought (or harvested) a lot of great vegtables and don't know what to do with them. With no meal planned on a lazy Saturday afternoon, we were getting very hungry and needed something fast. I made a fresh pasta sauce from the tons of fresh vegtables in the house.

The last challenge in the Gillius.org conversion was assets. At first, I tried to find an external solution like the "Asset Handler" plugin, but it only works for MT4. In the end I wrote my own Java code to scan my assets and upload each of them via the XML-RPC interface.

Using the XMLRPC interfaces I mentioned in part 1, I needed to parse my HTML content, strip it of the original "template", and upload it to my development Movable Type instance. I used Java and XMLRPC for this, Java because I was most familiar and XMLRPC since that is what MT provides.

The original Gillius.org site was entirely static content. In order to move to Movable Type, I needed to first convert the original site's content in a way that would be compatible with the old one, both in looks, content, and even the URLs themselves. I did choose MT partly because it appeared to be easier to import. I also looked at Drupal and Wordpress as well.

In this first part, I will cover conversion of the blog posts, conversion of the style, and parsing the original static HTML pages into a format that can be uploaded into MT. Read on for the details.

While developing the updated Gillius.org site, I noticed that sometimes the pages would not update when I went to them, until I hit refresh, even after I exited the browser and restarted it. I was using Firefox, which I learned made the problem more apparent versus IE, but I learned that it was my site's cache settings that was having a problem. I've fixed the problem, so if you see content that doesn't look right, missing comments, or is out of date you might have to refresh manually once, but hopefully not again after this. Read on for the details.

Previously, I used to maintain this site as static content (with the exception of the news page). Now I am using the popular blogging software Movable Type to help manage the site. My intention is to start doing a lot more blogging posts, rather than articles/static content that have been seen (and hardly touched) over the last 10 years.

Moving to a proper system now means that you can search the site, leave comments and trackbacks, and navigate by categories/tags/dates. It also means you will see more content as it is easier for me to post now.

In the short-term, my next posts will detail some of my experiences converting my existing site to Movable Type.