Friday, January 17, 2014

HTTP 2.0 should simplify Web Development

It's nice to see that HTTP 2.0 should simplify aspects of web development by making it possible for browsers to optimize on our behalf rather than forcing web developers to know and care about things like how many requests a browser can make at once, and how to make your website load faster by pushing files together.

That sort of thing should be dealt with in the plumbing between the browser and server and shouldn't have to be the domain of web developers.

Maven XML Verbosity is Amusing

Let's say you need to do something very slightly off the beaten path with Maven, like extract a single file from one of your dependencies so that it will be available to an XHR request in an offline web app as a static resource. No problem, just enter a quick 18 lines of XML.

But wait -- what if you're using Eclipse and M2E, and M2E decides that it doesn't know what to do about that dependency unpack you've just added? No problem, another 27 lines of XML oughta fix that.

Even though I know this to be true about Maven, every time I actually have to do it, it amuses me yet again.

Ah, Maven.

Thursday, January 16, 2014

Pivotal Tracker and Parallel Releases

I've used a fair number of issue trackers, but lately I've been leaving most heavily on Pivotal Tracker. It sits in the sweet spot between simplicity and complexity for me, does the key elements well and emphasizes some things that I mostly don't need.

In particular, I feel like Pivotal does a really good job of allowing you to keep a prioritized list of features / stories, work on the most important one, know what people are working on and how it's going, manage them with iterations and velocity. It's ability to predict release schedules is also reasonably solid, as is its implementation of subtasks.

Pivotal is very definitely opinionated software. It works well if you approach software from a particular perspective, but there are lots of situations in which Pivotal's approach might either not help or actively interfere with how you might want to run your own project. That's fine, that just means that Pivotal isn't the right tell to help you in that situation.

Its emphasis on user stories means that you can only put so much detail into a story before it starts to feel unwieldy. Some trackers are a more rich environment for describing requirements in detail, but Pivotal's agile mindset doesn't encourage that, and that works fine for me.

You can't really customize the workflow or the issue fields, but the standard workflow and issue fields that Pivotal supports are roughly the ones I would want anyway.

However, a few times I've noticed an area where Pivotal's approach isn't to my liking, around managing parallel releases.

Parallel Releases
It's not uncommon when working on software to have a couple of releases running in parallel. Unless you're doing something like continuous delivery, it's likely that after a significant release, you will sometimes want to deliver bug fixes for the recent release while at the same time working on features for the next release. This is easy to do in most source control systems, and not that hard to do in most issue trackers, but in this case, Pivotal's opinionated simplicity tends to get in the way.

Some examples:

  • If the patch release boundary is already in the 'current' section of pivotal, you can't move tasks above that marker without starting them. This can make it confusing to manage tasks that you want to include in a patch release that will be done during the current iteration. You either have to mark them as started when you may not be ready to do so, or to remember that when you do start them, they need to be moved into the patch release.
  • If you accept a feature for the next significant release while the patch release is still unfinished, the accepted story moves up above all incomplete stories, making it look like it's part of the patch release, when it might not be.
There are workarounds. You might:
  • Not accept features for the next release until the patch release is finished.
  • Always mark patch release stories as started as soon as they're created if you need them to move into the 'current' section.
  • Use labels or epics judiciously to help out.

These do work, and ultimately, it's nothing I'm going to quit pivotal over, but it is an annoyance.

Other Issue Trackers
What other issue trackers might you consider?

GitHub Issues
GitHub is great, and having issues built in works reasonably well for fairly small projects. I use it happily for some open-source projects, but I'm not at all certain that I'd like it for even a relatively small team. I haven't used it much in a team setting, but I suspect I wouldn't be that pleased with its ability to keep me informed about the progress of a team and a project if I were managing scope, timelines, deadlines and priorities for a team.

Basically, what's there works fine, but it's pretty limited and in particular I think it's limitations would be strongest on the planning and prediction side which tends to be pretty important in a corporate setting.

JIRA
Jira has a ton of features, and it's very customizable. If you need a lot of features and you want to customize heavily, Jira might be the tracker for you. That said, in my experience, Jira was always a little clumsy in places, and it seems to have gotten worse in that respect rather than better. It's very easy to end up feeling like you have a lot of good information in Jira but that you can't find all of it when you want to. It's not very good at giving you an idea of how a project is going, it's easy to misconfigure Jira in a way that will end up biting you in the butt. I've seen more than a few Jira configurations that I thought were absolutely terrible.

Still, if you really feel like you need these features and these customization capabilities, I don't know what else to recommend, so it still fills a niche.

Trello
While not strictly an issue tracker, I definitely know people who've used and enjoyed Trello as an issue tracker. It's closest to a kanban setup, so if you're choosing an approach closer to lean software development or kanban, this might be more your style.

I've played with it enough to know that I'd be willing to give it a try on a project, but I'm not certain yet how I'd feel about it.

Sprintly
Sprintly looks like it's a close competitor to Pivotal, but I don't know anyone who uses it and I haven't used it myself. Looks good from the outside.

Bugzilla
Bugzilla makes even JIRA look good. I don't understand why people use it.

Trac
Redmine
Neither of these are terrible choices but neither would be in strong consideration for me.

Lots and Lots More
There are lots of others. Some of them might even be good.

Saturday, January 11, 2014

Moo v2.0: Release Candidate 1

I've released the first release candidate build of Moo v2.0, which can be found in Sonatype's OSS staging repository if you use Maven, or you could just download one of these JARs directly from the repo:

If you've been using Moo v1.0 and you're using MVEL expressions, then you'll want both of these. If you don't need MVEL expressions, then you can simply use "moo-core" and not bother with the "moo-mvel" extension JAR.

I'll be conducting some tests with these against some of my own projects, and in the meantime, I'll be documenting more accessibly some of the changes to Moo v2.0, which include:
  • Translation expressions for collection items
  • Factory creation of destination objects
  • Translatable maps (key, value, key & value)
  • Collection type factors in destination type
  • Support for source properties without getters
  • Translation ordering (superclass properties before subclass properties)
  • Separating MVEL from the core of Moo so that it's an optional add-on.
  • MVEL expression pre-compilation.
  • Support for translating objects to Strings via toString().
  • Translator and annotation caching.
  • Dependency upgrades
If you do use the release candidate, let me know how it goes so I can address any issues before putting out the full release.

Wednesday, October 23, 2013

Git-Svn via Homebrew on Mavericks

One of my clients uses Subversion 1.7.x, and I've been connecting to it using Subversion 1.7 and git-svn installed via Homebrew. Last night, I upgraded to Mavericks, and this morning when I went to commit some changes, I discovered that all was not well.

This led me down a merry path involving:

  • Discovering that subversion was broken because sqlite is now keg-only.
  • Updating and upgrading homebrew.
  • Reinstalling xcode command-line tools for Xcode 5.0.1.
  • Checking out an older 1.7.10 recipe since my 1.7.9 installation was broken
  • Modifying the subversion 1.7.10 recipe to work with 1.7.13 since 1.7.10 is no longer available on the Apache mirrors (change hash, sha)
  • Telling Homebrew about Xcode 5.0.1 (modifying macos.rb)
  • Reinstalling neon (--universal), serf (--universal), subversion (--java --universal)
  • Fixing the Perl bindings for git-svn (using Victor Quinn's instructions, but replacing 5.12 for 5.16)
Every once in a while, enough things collude to fail that you have to dig in deeper in your tool stack, and that's not a terrible thing. I'm just happy that most of the time I can do things like update installed tools easily without having to manage the process myself all the time.

Monday, October 21, 2013

Google, Android and Open Source

Ars Technica's "Google's Iron Grip on Android: Controlling open source by any means necessary" is an interesting look at some of the problems that Google faces with Android and some of the strategies they've had to employ along the way.

Google has had to take a very interesting position with Android because they didn't really want to be in the mobile phone business, they just want to protect themselves from the Mobile business changing the business they are in too drastically. Google's business depends on the health of the web, and Google's place in that.

In order to protect their position, Google doesn't want to rely too heavily on the goodwill of others, any more than Apple does, although I don't think that's as ingrained in Google's DNA as Apple's. Android, for Google, is about ensuring that they have a say in the evolution of the mobile phone and mobile device market and how that has an impact on Google. They were willing to give away a fair amount of value in this new market as long as it helped to support Google's existing business.

Exerting enough control over an open-source project to meet your own objectives is a tricky thing, and Android has always had to walk that line carefully by being a hybrid of open and closed source models. Much of the development of new versions of Android is done completely in the dark, with code only being open-sourced near the release date. Portions of the overall Android experience are wholly dependent on proprietary closed-source Google applications and services which are only available to you if you meet certain conditions. You can build an Android device without these, but not without a significant investment in filling these holes.

The emergence of out-and-out-forks that do exactly that has encouraged Google to continue to seek more leverage over the Android ecosystem by moving features into closed-source applications and tying them to Google services, which they can control more completely.

Ars Technica has done a typically solid job of covering those problems and some of the solutions Google has employed, and it's a worthwhile read.

Wednesday, September 11, 2013

Adobe Generator using Layer Names

Adobe Generator seems like a nice addition to photoshop, the ability to generate image assets on the fly within Photoshop in a reasonably painless way. I'd have to use it for a real project to get a good sense for it, but my first instinct is that trying to pack all that information into the layer name is going to make the layer names much harder to read.

My first instinct was that they should have put the Generator information in layer metadata, but by the time you go that far, it might not be all that different from the slicing capabilities that were already present in Photoshop.

I'm curious to see what it feels like to actually use, but I have spent so little time in Photoshop lately that I'll probably just read what other people feel about it instead of taking the time to experience it myself.