Last summer, I put up a quick entry about a new way to blog, which I’ve enjoyed using. After suffering through yet another Wordpress security breach (which I’ll admit might be partly my fault through how I have my site set up and "maintained"), I’ve decided to take the next logical step and just move the whole thing to Awestruct. Overall, it’s been an enjoyable process, but it has certainly had it’s bumps and bruises. Luckily, Dan Allen, Aslak Knutsen, Jason Porter, and Bob McWhirter have been kind and patient with me. :P

I’ll have more to say in the coming days about with it took, what I’ve learned, etc., but I wanted to post a quick note letting both of my readers know about the change. You should find the site faster, as it’s all static now, and much smaller (e.g., 16KB vs 47KB for the front page). Should you notice any issues, please let me know, as I still have a bit of cleaning up to do (e.g., images in older posts, implementing comments, etc). For now, though, enjoy the site. :)

As every Android developer knows, application crashes are reported back to Google and can be view in the Play Developer’s Console. This is helpful, but, in my experience, sometimes you don’t get enough context. You also don’t get notifications when crashes are reported. Fortunately, there is a tool, called ACRA, that improves the situation quite a bit. In this post, I’ll give you a brief introduction to the tool, and how I use it in Cub Tracker.

Earlier today, I wrote about a quick and dirty hack I put together to create a very simple editor for AsciiDoc files. While I have no immediate plans to make this a full-featured editor, there’s a part of me that can’t help but hack on it. This evening, I added support for loading and saving files. In fact, I’m using the editor to write this post. :)

For those interested in helping (or just need a good laugh :), you can find the code for this oh-so-cleverly-named project here.

This morning, I was reading through the Proposed Final Draft for JAX-RS 2.0 specification, when I found a little nugget that could have saved me some work, specificially in initializing subresources.

In the course of my work, I often find myself writing a script to automate a routine task. Almost invariably, there are cases where I need the script to behave in slightly different fashion, but only occassionally. My early scripts rather crudely used one if after, which is not very elegant. Finally, after tiring of this clumsy approach, I searched for a better way and found one: getopts. In this shortish entry, I’ll give a very brief introduction to getopts, and show how I write my scripts now.

As some of you may or may not know, I have small Android project, Cub Tracker, that I’ve been working on for quite some time now in my spare time. I’ve been trying to be better about quicker releases, but all the testing for the app is currently manual (and, therefore, hit-and-miss), so updates tend to be a bit slower and very cautious. (For the record, it used to have pretty decent tests, but I rewrote the app for version 2 and just never got around to porting/rewriting the tests.) My next change, though, will be pretty invasive, so I’ve decided it’s time to fix that. In doing so, though, I hit a snag pretty quickly. Cub Tracker now uses a ViewPager as the main form of navigation, and I quickly realized I didn’t know how to swipe from one page to another. It turns out there are several different ways to do it. Here are some…​

For both work and fun, I run Linux. I’m also a Java guy, which poses some interesting challenges, as most Linux distributions have a long, sad tale regarding shipping Java. Things are a bit better, I guess, with OpenJDK, but I’ve always liked running the "real thing", which historically meant the Sun JDK, and now Oracle’s JDK (Note: current employment has no bearing on that choice ; ). If I were running an RPM-based distribution, I would be set. At the moment, though, I’m running Linux Mint, so I get to use the tarball.

Most of the time that works fine, but for reasons I don’t remember, OpenJDK was installed on my system, and now everything is using that (which is at Update 7, and not the recently released and more secure Update 11 that I want). I’d rather not monkey with changing PATH and all that, so I turned to the Linux alternatives system to handle things. Sadly, it wasn’t quite that easy, as alternatives needs to know about your alternatives, so before I could change things, I had to educate it, which turned out be easier than I feared. With Java 7 Update 11 installed in /opt/java/jdk1.7.0_11 and symlinked from /opt/java/latest, I had to do two things.

Merry Christmas!

“Do not be afraid; for behold, I bring you good news of great joy which will be for all the people; for today in the city of David there has been born for you a Savior, who is Christ the Lord.” — Luke 2:1-20

Recently, I had to add support for asynchronous REST calls to the GlassFish REST interface to satisfy some customer requirements. In process of doing so, I learned something pretty interesting: while asynchronous REST may mean different things to different people (e.g., I’m pretty sure Atmosphere provides some sort of REST asynchrony, but I’m not sure what UPDATE #1: As noted in the comments, I know next to nothing about Atmosphere. I mention it here only as some weak attempt at completeness that is, in hind sight, a really bad choice), implementing an async REST resource with JAX-RS is really quite simple. In this post, we’ll take a look at two different approaches to "asynchronous" REST.

Wikipedia defines Server-Sent Events as "a technology for providing push notifications from a server to a browser client in the form of DOM events. The Server-Sent Events EventSource API is now being standardized as part of HTML5 by the W3C." It’s a great alternative to polling the server for updates. Long story short, thanks to the work of the Jersey team, we have "easy" access to this in GlassFish, and we’ve added support for it to our RESTful administration interface. Let’s take a look at a quick sample.