Video review:

If you’re a Java programmer who’s itching to switch to a newer, more exciting language, then remember we can still improve the paradigms we’re using in the language we get paid to use.

Erik Onnen’s video on InfoQ,, talks about why Java is still the language best-suited to the JVM, and how we can write Java code that doesn’t suck.

The first half of the video, about why Java is the best JVM language, boils down to “Java is easy to read because we’re all so familiar with it” and “Java has the best tools available to it.” It’s true that pure Java (with no AOP, no ORM frameworks, and no containers at all) is the most predictable and debuggable way to write for the JVM. But these aren’t good reasons to limit ourselves. Skip this half of the video.

It gets interesting at about 32:50: how we can write better Java. He has fantastic points here, about how we should throw away anything Enterprise-y, including containers; separate behavior from data; write small discrete services that pass immutable objects; never throw checked exceptions. So true! Use dependency injection – without a container. Write wep apps – without WARs. (Somebody should give a talk: Java Web Applications for Pacifists.”)

The 20 minutes of talk starting at 32:50 are useful to any Java developer looking to improve their code and think outside of the large corporate box we were trained in. (Caveat: he specifies early in the talk that most of these recommendations are only usable in greenfield development.) On the other hand, if you already ❤ functional programming, this video will be preaching to the choir and you're better off looking at a video from StrangeLoop.

Why programming is awesome

“Programmers don’t need an office. They don’t need infrastructure. They don’t need staff. They don’t need anyone to tell them what to do. They hardly even need money. They can just make things. A programmer is a human self-contained factory that can manufacture stuff that’s worth money. That is some insanely powerful stuff!” — Tess Snider

F# Snippet: sequence partitioning

This F# Snippet illustrates a way to divide a sequence into a sequence of shorter sequences of a fixed length. The snippet uses list comprehensions.

I don’t like it, because it involves flipping through the original sequence over and over and over.

With recursion, we can do all the construction in one pass through the original list. (Yes, I have narrowed the scope from Seq to List. The snippet requires a finite-length sequence so this is not a loss.)

here’s a simple implementation using a tail-recursive method to divide the list into groups of a fixed size.

// tail recursion
let rec build groupSize items outputSoFar currentGroup currentCount =
match items with
| [] -> outputSoFar @ [currentGroup]
| head :: tail when currentCount = groupSize -> build groupSize tail (outputSoFar@[currentGroup]) [head] 1
| head :: tail -> build groupSize tail outputSoFar (currentGroup@[head]) (currentCount + 1)

let buildGroups size items = build size items [] [] 0

buildGroups 2 [1..11] ;;

val it : int list list = [[1; 2]; [3; 4]; [5; 6]; [7; 8]; [9; 10]; [11]]

Of course, this is really a fold operation. Using List.fold ensures we really are tail-recursive.

// same thing, using List.fold
let buildWithFoldFunction groupsize (outputSoFar, currentGroup,currentCount) item =
if (currentCount = groupsize) then
(outputSoFar@[currentGroup]), [item], 1
outputSoFar, (currentGroup@[item]), (currentCount + 1)

let buildWithFold groupSize items =
let (output,lastGroup,_) = List.fold (buildWithFoldFunction groupSize) ([],[],0) items

buildWithFold 2 [1..11]

… but this isn’t really any better than the list-comprehension Snippet, because all those append operators (the @ signs) are causing copies of the original list to be made over and over.

Really, we need to start from the back of the input list. That way we can build the output list-of-lists from the back, using the cons operator, which is efficient. We can use foldBack:

// Now, using cons and foldBack
let buildWithFoldBack groupSize items =
let buildWithFoldBackFunction groupsize item (outputSoFar, currentGroup,currentCount) =
if (currentCount = groupsize) then
(currentGroup :: outputSoFar), [item], 1
outputSoFar, (item :: currentGroup), (currentCount + 1)
let lengthOfLastGroup = List.length items % groupSize
let imaginaryElementsInLastGroup = if lengthOfLastGroup = 0 then 0 else groupSize - lengthOfLastGroup
let (output,_,_) = List.foldBack (buildWithFoldBackFunction groupSize) items ([],[],imaginaryElementsInLastGroup) ;

let thingWithFoldBack = buildWithFoldBack 3 [1..11];;

val thingWithFoldBack : int list list = [[4; 5; 6]; [7; 8; 9]; [10; 11]]

The interesting bit there is how long that last list should be (the one with the leftovers). If the input list does not divide evenly by the group size, then we change the initial value of that accumulator piece — we pretend that there are already a few items in the last list, so the function that builds output will make that one short.

The fact that I feel clever for doing it that way is a warning sign: clever code is hard-to-read code. However, to someone used to working in a functional style, this would probably make perfect sense.

*For math people: I would prefer to do a second mod operation to determine the imaginaryElementsInLastGroup, but it seemed even more obfuscated: let imaginaryElementsInLastGroup = (groupSize – (items.Length % groupSize)) % groupSize

That’s kinda fun. It’s a little illustration of how functional programming can be efficient and short if we think differently.

Daily Javascript: input arguments to scripts

LinkedIn integration instructions provide the following syntax:

we say, WTF? what kind of script tag has a src attribute and content as well?

It turns out that the JS in the src attribute is pulling those lines out of the DOM and parsing them. It is not really JS inside there, but a language specific to in.js. Wow, that’s cryptic and unexpected.

What is a better way to pass arguments into scripts like this one?

Our method at work, so far, is

  1. Inside the included script, do nothing except define a giant function.
  2. Inside another script tag (this one with no src attribute), call that giant function, passing in whatever arguments it needs.

This allows us to pass in values that may be filled in by, say, our velocity template.
Anybody have a cleaner pattern?

Daily JavaScript: empty objects

How do you test whether a JavaScript object is empty?
The short answer (if you’re using JQuery) is:


The longer answer is, you loop through its properties. This is the method JQuery is using.

for(var prop in obj) {
// it is not empty if this hits

The even longer answer is, you loop through its properties and check that they really belong to it. Properties added to the prototype will come up in this loop, and you might not want to count those.

for(var prop in obj) {
if (obj.hasOwnProperty(prop) {
// it is not empty if this hits

The loop variable there (prop) is a string which is the property name. Here’s a handy fiddle to insert the results of this into an unordered list:

your_object = {"armadillos":"are brown","carrots":"are fun too"};

function addObjectToList(my_object){
for(var property in my_object) {
  • '+property+': '+my_object[property]+'
  • '));


    Cross-platform problem solving: how an Android Pro Tip helps our web app design

    Separation of concerns is a challenge in a web application. The quick, straightforward way to control a page winds up being messy, with business logic and application logic and view logic all mushed together.

    Here at my Stealth-Mode Startup, we’re using the Sitebricks web framework on top of Guice. One pain point in our webapps’ code is that the Sitebricks Page objects wind up serving too many purposes. They control what’s displayed to the user, what actions are taken on an HTTP request, and what data is available to the view. We grimace when we think too hard about them.

    Last month at CodeMash, I saw a presentation by Michael Pardo on Android Pro Tips. Android’s Activity objects have something in common with our Sitebricks Page objects: they control and populate the view as well as performing application tasks. One pattern Michael presented in the Android talk was the ViewHolder: an inner class inside the Activity takes responsibility for interacting with the view. The ViewHolder knows about the IDs of the particular components in the layout, isolating this from the rest of the activity.

    We’re going to try implementing this ViewHolder pattern in our web application. I love that a solution designed for one platform solves the same problem on another platform. Also, this shows how attending development conferences and learning about various technologies is relevant to my job in unexpected ways.

    Stupid git tricks: transferring part of one git repo to another

    Reference post. Don’t expect this to be interesting.

    We had a particular subdirectory of a repository (repoA) that really belonged in repoB. The goal is to transfer all files and history from repoA to repoB, permanently.

    Thanks to Nikolai in this blog post, the move isn’t too bad. I’m not going to repeat his instructions. Instead, here are three tricks we learned today:

    git filter-branch --subdirectory-filter dirName -- --all 

    This throws away everything in a repository except what’s in dirName, making dirName the new root. The “– –all” part tells it to keep the history, but it only keeps the portion of the history relative to this directory name.

    However, the experts report that I could have skipped some later steps if I had instead removed the other directories:

    git filter-branch --tree-filter 'rm -rf unwanted_folder/' --prune-empty -- --all

    Merging two repositories together means creating a new remote in the destination repo that points to the source repo. Fetch from it and then merge its branch into the current branch in your destination repo. The fetch and merge are very standard git.

    git merge --no-commit sourceRepo/master

    The new (to me) trick here is –no-commit; it lets you see and alter the results of the merge before committing.

    Finally, all this merging was fine, but it required moving the newly-imported files into a directory. Once they were moved, a “git log fileName” only showed the move in the commit history. Argh! The whole point of this operation was to retain the history.

    git log --follow fileName

    Here’s a trick useful all over the place. Telling git log to follow the rename gives the full commit history of the file, before and including the move.

    Thanks to Erik Jacobsen, Mike Bishop, and Jay Harris for this info.