Roo – Page 72 – Roo's View

iPod Touch 3.0 Upgrade

Apple provides the 3.0 upgrade “free” for iPhone owners, but those folk have either paid a premium for their devices or are locked into multi-year service agreements. If you have an iTouch, the upgrade is basically $10. While I would prefer that it was a free upgrade, I feel obligated as a software professional to pay for the software I use (I like it when people who use my software pay for it).

The 3.0 upgrade adds a bunch of features. In the brief time I’ve had the update, I haven’t used many of the new features but cut & paste is a welcome addition. Push notifications look like they will possibly fix the ‘no background apps’ issue, I’m looking forward to trying out some apps that make use of the feature. I didn’t notice that the web browser was slow, but I’m all about faster browsing.

I wish they had gone further with the bluetooth enhancement – ideally if they had managed to allow me to use my existing bluetooth enabled phone via an iTouch based interface I would have had a budget iPhone. Imagine being able to dial your current non-Apple phone via the touch and then have it route the headset audio through the touch. I suspect you’d soon get sick of carrying two devices and would drop the money on a real iPhone. Oh well, today all that is offered is stereo headset support.

Read on for details on my upgrade difficulties, and how I resolved them.

Continue reading “iPod Touch 3.0 Upgrade”

Writing better JNI code

Well, it seems Ron beat me to the punch to blog about this – but allow me to promote the recently published developerWorks article that I had a hand in bringing to life: Best practices for using the Java Native Interface

Here is the summary:

The Java™ Native Interface (JNI) is a standard Java API that enables Java code to integrate with code written in other programming languages. JNI can be a key element in your toolkit if you want to leverage existing code assets — for example, in a service-oriented architecture (SOA) or a cloud-based system. But when used without due care, JNI can quickly lead to poorly performing and unstable applications. This article identifies the top 10 JNI programming pitfalls, provides best practices for avoiding them, and introduces the tools available for implementing these practices.

Many kudos to Michael Dawson for his wordsmithing and persistence to make this article happen, he really deserves the lion’s share of the credit.

Ron calls out his favorite pitfall as using the wrong JNIEnv. I’ll pick the one that makes me laugh because it is sad but true: Choosing the wrong boundary between native and Java code – believe it or not there was a real world example that motivated the sample code. The customer had decided to go for a “pure java” solution for their embedded application, so the minimal amount of native code was written – two functions that could read or write individual bits (not bytes). While the example is outlandish, many times the integration of legacy code via JNI is done without thinking of the cost of the boundary.

Let’s discuss the picking the right side of the JNI boundary for a minute. The NIO implementation is a good example of trying to fix file performance by keeping the data on the “right” side of the JNI boundary. While NIO provides other functions allowing for tighter OS integration, one key performance win is due to the file data is kept in native buffers. If you’re trying to get the data into java objects to be manipulated, you are likely defeating the performance win of NIO by forcing all that file data across the JNI boundary. Where NIO will excel is needing to pull a bunch of data from a file and put it in another file – if you don’t need to hoist that data up into the java object space, you’ll get close to pure native performance.

Please check out the article, or at least bookmark it and send it to people who write JNI code. Maybe we’ll see fewer false JVM bugs that turn out to be JNI related problems.

Managing Cable Clutter

This is something I actually did back in February when we moved our computer room to make room for our new arrival. This is one of those DIY tasks that doesn’t take very long to do (a couple of hours tops), but you can put it off for ages (sort of like writing this post). Anyone dealing with a rats nest of cables behind / below their desk, maybe this will serve as a kick in the pants to do something about it.

The LifeHacker article inspired me, but clearly not enough to quickly leap on the idea and deal with my mess of cables. They actually have a whole category dedicated to cable management which is worth a browse if you are looking for ideas. The original concept came from a site which seems to be gone now, but can still be seen via the Way Back Machine.

So pictured above is my version of the peg board cable organizer. I’ve got a 2′ x 4′ peg board mounted on the back of the desk (between the desk and the wall). There are only 2 screws holding the board to the desk (upper left and right corners). I’ve used a couple of washers between the peg board and the desk to give it a bit of room for the cable ties. Everything is zip-tied to the board, power bar included. Since I’ve only got 2 screws at the top, I can bend the board (gently) away from the desk to get easy access to the back side to help route the zip ties.

The view from the front of the desk is what makes this worth doing. No clutter on the floor (ok, an errant ethernet cable and the USB to the printer). Even for my desk (pictured is Jenn’s) – where I need to plug and unplug things like my laptop regularly, this setup works well. I simply mounted the powerbar near the top of the peg board and that places the outlets near enough to the top of the back edge of the desk that its not a problem.

This project only took a couple of hours, it is very functional – and tidy too. What are you waiting for?