05 November 2012

Google Groups: The Orphan Child

It's been quite a while, now, since Google rearranged the menus providing links to their various sites and tools. And right from the start Google Groups has been Missing In Action. At first I thought it might just be a small oversight, but evidently it's a deliberate design decision.
Google Groups: Nowhere to be found.

I wonder why... I find Google Groups to be one of the most useful tools they offer, especially when I am working with people who are not very net-savvy -- those who are not as comfortable with web-based tools as I am. The only rationale I can come up with is that Google would like us all to migrate over to g+ and abandon the somewhat old-school "forum" style that is Groups. Ain't gonna happen!

Unless they force the issue by killing-off Groups, in which case I will hazard a guess that existing fora using Google Groups as their carrier will simply hike on over to elsewhere that does provide a forum-style interface.

I'm not a huge fan of forum-style UX, and I avoid it as far as possible, but it is something simple and familiar to many people, and so sweetly occupies a place where it is the best thing to use because it is the simplest thing for the largest number of users. I do hope it's not going to vanish completely in a stupid attempt to force everyone over to g+... (Like what Microsoft seem to be trying to do to their user-base.) That would be,... well, not quite Evil, I guess,... but certainly quite an unfriendly move.

29 October 2012

Unit-testing Android Apps: Netbeans and Robolectric

Testing for Android Apps is a bit of a mess. The Android Test Framework dismally fails to make a clear distinction between unit tests, functional/integration tests and UI tests, and assumes that all tests will be run as an Android application on a device or emulator (AVD) as Dalvik code. For unit testing this is extremely clunky. It means that unit tests must be written as a standalone Android project, built as an APK and deployed to the device running a build of the application under test, where it takes over the running of the application to instrument it for testing. This is quite a slow process, and slowness is the very opposite of what we want for unit tests.

All I wanted, though, was to run (quickly!) some simple unit tests against domain classes. There might be some Android mocks needed where my application classes rub up against the SDK, but that's just accidental.

Then, too, there is (currently) a bug in the Ant build script for the Android Test Framework that means that, out of the box, tests cannot be built or run using Ant. I neither know, nor do I care, whether the test might be runnable if I were using Eclipse; I'm a diehard Netbeans user, and Netbeans uses Ant (or Maven, and possibly soon, Gradle) rather than relying on a parallel build system of its own. I think this is one of Netbeans's key strengths. Along with the still-evolving NBAndroid Module and Netbeans's superb out-of-the-box handling of XML files, I've been finding it an absolute pleasure to use for Android development. But unit-testing remained an itch that I had to scratch.

The upshot of all this is that I could not find a satisfactory -- or, indeed, a working -- way to write and run unit tests for the Android project I'm working on.

Down into a Rabbit Hole I went!

Emerging a couple of days later, here's the solution I came up with... It's probably not the best solution ever. It's certainly not definitive. But it Works For Me.

I'm using Robolectric -- a framework that modifies Android platform methods on the fly and provides shadow classes for Android platform classes so that unit test can be run in a standard JVM on my development machine.

Predictably, it was not all Plain Sailing!

The Robolectric documentation is pretty sparse, and very strongly oriented towards IntelliJ and/or Maven-and-Eclipse usage (didn't investigate too closely, don't care!) If I'm going to be shafted into using Maven, then my unit testing is so slow that I might just as well stick with using the standard Android Way of Testing, so I wanted to avoid that. Additionally, this brings the advantage that I can use JUnit-4 style tests (with a caveat - see below.)

The first step is to create a standard Java Project in Netbeans. We already have a directory structure like

...project-root
       |
       +---android-main-project
       |
       +---other-project-related-dirs

so I created my unit-test project on the same level as the main project:


...project-root
       |
       +---android-main-project
       |
       +---other-project-related-dirs
       |
       +---unit-test-project


In Netbeans add at least the following libraries as dependencies for your test project:

  • Your main project's bin/classes directory - otherwise the test-project cannot find the classes you want to test.
  • JUnit
  • Any mocking library you might choose to use - PowerMock looks pretty good, though I haven't used it beyond tyre-kicking yet.
  • android.jar for the SDK version you have as your targetSdkVersion in the AndroidManifest of your main project. This is important, since the Robolectric framework uses a custom test-runner (which we'll slightly modify as described below) that examines your AndroidManifest to figure out where to find resources.


The order you specify the libraries is critical: android.jar must come after junit in the classpath for your unit-tests.

Now only one more things remains: telling Robolectric where to find your main project's manifest file and resources...

In your test-project, create a custom test-runner like

net.mikro2nd.android.junit;

import java.io.File;

import org.junit.runners.model.*;
import com.xtremelabs.robolectric.RobolectricConfig;
import com.xtremelabs.robolectric.RobolectricTestRunner;

public class MyTestRunner extends RobolectricTestRunner {
    public MyTestRunner( final Class<?> testClass )
        throws InitializationError
    {
        super( testClass, new RobolectricConfig(
            new File( "../android-main-project" )
        ));
    }
}


Of course you should now annotate your test classes using

    @RunWith( MyTestRunner.class )
    public class DeviceIdTest{
        ...
    }


Now you can "Test" your test project to run all unit tests, select just a single unit-test class to run, or even debug unit-tests without leaving Netbeans at all. And you can run them in a CI server.

Slightly less convenient than unit-testing a non-Android project, but still way better than the alternatives (no testing, Eclipse or Maven, or the bloody slow Android Test Framework.)

My thanks to Justin Schultz who's Eclipse Robolectric Example put me on the right track. All I've done is adapt his hard work for Netbeans use.

11 August 2012

Moving Furniture: The Scrum Way

As a housewife, my wife
Wants the bed in one room swapped with the couch/futon/bed in another
So that  she can more comfortably sit and watch the Olympics on TV in the sunnier, warmer room.

With 3 programmers in the room, it was inevitable that we would choose an Agile approach to this requirement. The User Story above was our first step, and was duly agreed to by said wife as Accurately Describing What She Wanted and its Business Value.

Given the constraint that both rooms involved are too small to contain both pieces of furniture simultaneously, we realised that we would need a temporary variable as a swap space. I'm pretty sure that, barring some major advance in our understanding of Quantum Mechanics, pieces of furniture can't be swapped by being XOR'd through each other.

We broke the Story down into some Tasks:

  1. Remove the bed from Room 1 into the Swap Space.
  2. Remove the Futon from Room 2 into the Swap Space.
  3. Move the Futon Base (a finger-eating piece of folding woodworkery) from Room 2 into Room 1 and position it in its final position.
  4. Move the Futon from the Swap Space into Room 1 and position it on its Wooden Base.
  5. Move the bed base from the Swap Space into Room 2 and position it in its final position.
  6. Move the mattress from the Swap Space into Room 2 and place it on its base.

Seemed like a reasonable breakdown at the time. We did some estimations and figured we could fit it all into a single Sprint.

Here's how it played...

Task-1 went quite smoothly. Mattress and bed base moved to the Swap Space.
Task-2 also went well. Please bear in mind that the futon and mattress are large, floppy and heavy items, so not all that easy to move about.
Martin and I -- Pair Moving -- make an attempt at Task-3. Space is very constrained, so moving the Futon-base into Room 1 involves a brief detour into Room 3. Halfway there we suddenly realise that -- because the base is asymmetric -- we have to turn it around in the Swap Space before it can be Deployed into Production.
We complete Task-4, only to realise that we were entirely wrong about which way round the base has to go. We've moved it into the room the wrong way round. And the room is too small for us to turn it around short of Interesting Topological Manoeuvres.

So we back out again, via Room 3, back into the Swap Space where there is sufficient room to turn the base around.
Some discussion ensues. We realise that we should have had better Unit Tests in place for this Task. Finally we manage to complete the Task.
It's a tight fit, but the Futon/couch will serve our User perfectly as she wished.
Sadly there's an unforeseen bug. A small drawer unit now blocks the doorway, making for extremely poor UX. Not our problem, though. We've met our spec and implemented the Story. People will simply have to leap over the drawer-unit for the time being. Changes will have to be the subject of a subsequent Sprint.

Happily I can report that the rest of the Sprint went quite as anticipated. We were even able to implement a small Improvement Task by orienting the bed in Room 2 in a much more User Friendly fashion.

I do wish Furniture Topology was amenable to Version Control, though. It would have made our Task-4 issues a bit simpler to resolve. But then, perhaps we should have abandoned the Sprint at that point.

Still not quite sure how all the Scrum ceremony helped, though.

03 April 2012

JSP/JSTL: Versions and Standards

It baffles me. So many developers who use  infrastructure standards like servlets and JSP, but don't have any idea what versions of these they're coding to. They are blissfully unaware of whether they're targetting HTML4.01, XHTML-1 or HTML-5, CSS 2.1 or CSS 3, Servlet 3, 2.5 or 2.4...

Maybe I'm just funny that way - I think that managing dependencies in a tight, controlled way really matters! Otherwise things quickly spiral out of control, and you end up with that classic Design Pattern, "Big Ball of Mud".

On the other hand, I freely confess that I keep forgetting which pieces belong together. It's such a confusopoly.

So, mainly as a Note To Self, here's a quick lookup:

JSP/Servlet/JDK Versions

Servlets JSP JSTL Java EE Tomcat Min. JDK
3.02.21.2 57.x1.6
2.52.11.2 56.x1.5
2.42.01.1 1.45.5.x1.4

The list goes on, but if you still have systems in production running those archaic versions, you're probably in deeper trouble that mere version-confusion anyway!

06 February 2012

Work Wanted

This is a small call for help. I am looking for work, and need your help.

Contract or permanent. Preferably (but not exclusively or even at all) telecommute. I can code, design, architect software, consult in any of these (and dev process/team issues) and teach a variety of Java, OO Design and web development topics, and would be happy to do any/all of these. I additionally have some experience doing system administration work. I work in Linux/Unix environments and know next-to-nothing about Windows.

I've done web stuff, and loads of backend "heavy lifting" coding where reliability, scalability, etc. are important. I am not good at quick'n'dirty. Skeptical of the value of buzzwords and big-arse frameworks.

Check out my "business" website for more details about me and what I've done in the past.

R (as they say) "highly neg".

If you have anything suitable, or know of anything that fits, please drop me a line.

I will be in Cape Town and environs next week, so an ideal time to get together and chat about possibilities and opportunities.

11 November 2011

Android Nails Sandboxing

So I'm learning to programme the Android platform. Despite constantly typing it as "Androind" finding programming fun again after many years of regarding it as somewhere between tiresome drudgery and only mildly interesting in sporadic parts.

It's early days, yet, but I do think that Android's architects had one flash of brilliant insight: Using Unix user and group permissions to sandbox applications. Brilliant! We've had this mechanism since forever, and let's be honest, it's never been all that useful except in the very early years of Unix when we actually did have to put multiple users on a single computer. And even then, most users didn't understand it. Questions about umask and file permissions are among the commonest of Unix confusions I've run across for the past 25-odd years.

Warping the idea to mean that every application is a unique user is a flash of inspiration.

09 November 2011

QOTD


'the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."'

Donald Knuth 25 April 2008

(Okay, so I'm late to the party. As always.)
Related Posts Plugin for WordPress, Blogger...