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 <3 functional programming, this video will be preaching to the choir and you're better off looking at a video from StrangeLoop.

Friday, February 24, 2012

"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

Monday, February 20, 2012

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.

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.

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

Inside the included script, do nothing except define a giant function.

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?

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.

Tuesday, February 7, 2012

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:

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.