Mike Reedell

I’ve spent entirely too long being an “enterprise” developer. Too much time putting a UI on a database with a dash of proprietary ‘secret-sauce’ to justify 6- and 7- figure per annum license agreements. Too much time stringing together an ever-growing collection of frameworks, containers and libraries to build these applications in the name of ‘enterprise Java’.

These are precisely the reasons why I’m going back to basics and learning low-level programming. What do I intend to do with such knowledge? Who knows. Maybe a job building development tools, data-stores, web-servers, platforms, etc. or maybe not. Either way I’ll be learning something new and thinking about concepts that I don’t get to think about in my professional setting.

I don’t know about you, but when I hear ‘low-level programming’, I think of good, ‘ol-fashioned C. So that’s where I’m starting, getting back into the land of structs, pointers, header files and other things that give most Java developers nightmares. From C, I intend to re-kindle my brief affair with Go and possibly Rust, learning lower-level programming in a language built for modern multi-core machines.

With JUnit 4.x, the developers introduced the concept of annotating tests with @Ignore so developers could mark tests that the test runner should ignore. What wasn’t added was the ability to specify conditions for which the test should be ignored, for instance:

A bit of google’ing will yield a lotof pagesthatpurport to have the solution to this problem or discuss ways to work around it.

While there’s nothing wrong with any of these solutions technically, I didn’t want to write a custom JUnit test runner nor have code that executed after the class- and method-level setup’s were run. In other words, I wanted a conditional short-circuit that would exit the test as soon as possible without running any code the test-to-be-ignored depends on.

That leads us to using JUnit’s @Rule feature. By using Rules, we can introduce just the type of short-circuit mechanism mentioned above by creating a rule that applies to all test cases that will determine whether the test case should execute or not.

The case we had to solve was specifying the test data sets that certain tests could run against. If one test had test data available in data set QA01 but not in QA02, we didn’t want that test to run, and fail, when the suite was run against QA02.

This rule checks the value of the annotation, and if the ‘dataset’ JVM argument is contained in the list of allowed data sets (or the annotation isn’t present at all), passes the test (Statement object) unaltered to the next step in the execution sequence. If the ‘dataset’ JVM argument is not in the list of allowed data sets, the rule creates a new, empty Statement object which then gets executed in place of the actual test case.

To put the DataSetRule into effect, we need to decorate our test classes with one more annotation:

@Rule
public TestRule dataSetRule = new DataSetRule();

This snippet lets JUnit know that there’s a rule that needs to be executed before each test case gets run. There’s also a ClassRule interface that can be implemented to create JUnit rules that are executed before any @BeforeClass methods are run.

While this solution isn’t perfect: it still shows the tests as being run and passing, albeit with an execution time approaching zero, it does allow JUnit tests to be decorated with custom annotations that control the execution of the test

I recently updated one of my Java projects from and old iBatis version to the latest and greatest MyBatis 3.0.4. The conversion part was fairly straightforward so I decided to see what the new library could do to help with performance.

Since the application I’m writing is an ant task that process XML documents into list data that needs to be saved to MySQL, I wanted to see if MyBatis could help out with inserting Collections.

If you google around for ‘mybatis insert list’ you’ll end up on this page which shows the following (incorrect) XML snippet:

After downloading the source, finding the unit test that covered this scenario and adding an additional test for the case I was seeing I discovered that this is the snippet that generates correct MySQL SQL for inserting a list into a table:

While writing MacGist, I had to engineer my way around GitHub’s lack of API support for gists. The gist API doesn’t allow for much, just simple GET’s around the gists metadata and content, for public gists only. The only way around these limitations that I saw was to programmatically access the web interface of gist.github.com and POST the data in the HTTP headers.

Sounds easy enough.

And it was, but my lovingly crafted HTTP POST’s didn’t actually do anything. Some quick Firebug’ing uncovered that Github uses CSRF form fields to protect themselves from, well, CSRF attacks. Without this uniquely generated key present in the POST data, the requests weren’t going to do anything.

Here’s the solution I came up with:
1. Login to github using standard username/password authentication (BASIC auth over https).
1. Construct the URL of the form you want to POST to, in my case the URL has the form https://gist.github.com/gists/$GIST_ID/edit.
1. GET the form URL.
1. Get the “authenticity_token” hidden form field from the HTML content.
1. Use the value of the “authenticity_token” in the POST data.
1. POST the form.

Getting the authenticity_token from the HTML form data is pretty straight-forward:

In this solution, we’re essentially grep’ing the HTML for the string “authenticity_token” then returning the next 40 characters. There’s more than one hammer for this nail: NSScanner, regular expressions, parsing the XHTML and walking the DOM, but for something quick and easy, this one works just as well.

Just did a push to github of sunrise-ws, a super simple Sinatra wrapper for the RubySunrise gem. The concept is simple: call a web-service to get the sunrise/sunset data for a given location in a given timezone. Since the requirements were so simple and there is no database or security, it made sense to use Sinatra instead of rails. First off, Sinatra is easy. I know I’m not breaking new ground here, but as a 10-year professional java developer, getting ANYTHING done in that little code is next to impossible. I certainly appreciated the ease of setup of the Sinatra app and how easy it was to test it using RSpec.

Like the title says, this app is SIMPLE. It only exposes three web-services: get the sunrise/sunset data for today, a specified date, or for the entire year. That’s it. And instead of using XML as the response, everything is in JSON.

For more information on how to use it, go to the project’s README on github.

As a follow-up to the Java sunrise/sunset calculator I released early last year, I’m releasing a ruby gem that does essentially the same thing. Just in A LOT less code, but with the same attention to test goodness.

Want to add something to your projects Maven builds (like code coverage…) but don’t want to CTL-C/CTL-V your way to boredom? Use the below script to lend a hand. Substitute the XML in the SNIPPET variable to the artifact/plugin/dependency to be injected (leave the ‘inject’ tag in place) and use the command:

In the beginning of the ‘for’ loop in the inject method I remove the read-only bit from the file. This is for those of us afflicted with ClearCase and can be removed for those fortunate enough to use a sane SCM.

Maven projects can become a wasteland of neglected, old dependencies: huge, unmanageable .pom files and a local repository that’s catalog of every Apache project in the past 10 years. Who knows if your project still requires that old version of Xerces?

This script takes the name of a dependency and removes it from every pom.xml in any sub-directory from where it’s called, removing the dependency element for the given jar file from each one. The script also saves the dependency tree in the file $artifactname.xml in case you need to put it back.

Do you have an existing project you want to open-source? Does the thought of manually adding the license comment block to EVERY. SINGLE. SOURCE. FILE. sound not-so-exciting? Here’s some help, ruby style:

class Licenser
def licenseFiles(dir)
filenames = Dir[dir.chop + "**/*.java"]
for filename in filenames do
contents = ''
File.open(filename, 'r') { |file| contents = file.read }
contents = HEADER + contents
File.open(filename, 'w') { |file| file.write(contents) }
end
end
end
HEADER = <<HEAD
/*
* Copyright 2008-2009 Mike Reedell / LuckyCatLabs.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
HEAD
Licenser.new.licenseFiles(ARGV[0])

This script was inspired by the the check_license_headers.rb script in the Apache SVN repo. Couldn’t get it to work on my setup, so I rewrote the parts I needed.

This can be found in the GitHub scripts project. Look for updates to handle more source types and to check for existing license headers.