Tuesday, August 12, 2014

Git Tower 2 Recommendation: Cautious Buy (Update: Buy)

I've been using Git Tower for a couple of years now, and I'm happy to recommend v1.x as a solid GUI Git client for OS X. There are a few things I'd like to see improved, but the basics are quite good, and it's been relatively bug-free for me (although after doing a Twitter search, I can see some people had some problems with v1.x that I didn't).

Since Git Tower v2.0 was released, I've installed a trial and I've been using it on and off in parallel with Git Tower v1.x. In general, I like it. I think it's a fine evolution of Git Tower, I think the UI changes are mostly improvements, and I'm looking forward to using it full-time.

Having said that, I don't think it's ready for prime-time use, at least not for me. I've reported a few bugs already while using the trial, and I'm not the only one. And if you read over the mentions that @gittower has on Twitter, I think that's the general sentiment: looks good, but needs a bit more attention.

There has been a few point releases already (v2.0.3 at the time of this writing) and I expect there will be more. Basically, I'd say it looks like a promising upgrade, but if you're in no rush, it wouldn't hurt to wait a little longer. If you're curious, then download the trial in the meantime. If you really want to use Tower 2, you probably can, but accept there might be a few issues along the way.

Update: I have been using Git Tower 2 for months now and almost all the issues have been worked out. It still, isn't perfect, but I don't think the remaining issues warrant much caution. I would say "buy".

Wednesday, June 11, 2014

TweetDeck XSS Vulnerability in Desktop Application

TweetDeck's recent XSS vulnerability highlights one of the downsides to using web technologies to build a desktop app.

Of course, no app is immune to vulnerabilities, and using desktop application platforms certainly doesn't prevent all vulnerabilities. But TweetDeck's vulnerability exists in part because the content it displays is delivered in the same form as its user interface.

A desktop application that failed to properly control web content that it was displaying would still expose the web container in which the content was running, but that wouldn't make it vulnerable to manipulating the application controls. A badly secured web view to display a tweet within in a native application with native controls for displaying tweets would still make it hard to, say, trigger the application to retweet the content automatically.

Friday, May 23, 2014

Moo v2.0 Released

I put the finishing touches on the second release of one of my open-source projects, Moo, last night. I'd been updating the documentation for a few weeks now to get that in sync with all the code changes that have been taking place. Now that it's finally done, I've released Moo v2.0 up to the Maven central repository.

Moo v2.0 is the first release that was driven more from requests made by users of Moo than for my own needs. If you're using Moo and you'd like to make a request, get in touch over email, twitter, or GitHub, and I'll see what I can do.

For those of you already using Moo, I'd love to hear some thoughts about how Moo v2.0 works for you and what enhancements you still need.

If you're not using Moo, it's a relatively unintrusive way of mapping one object graph to another in Java. Check out the website, the release notes or the wiki to learn more.

Tuesday, April 22, 2014

Dash Cheatsheet for git-svn

One of my clients uses Subversion for source-control, and since I spend a lot of time in git anyway, I have been using git-svn to interact with their subversion repository. I like being able to commit locally even when I don't have a connection to their server, and then push the commits up to subversion when I do have a connection.

However, while git-svn lets me use some of the same tools that I use elsewhere, like Git Tower, the syntax for git-svn isn't exactly the same as either the git or svn clients, and it's not a perfect abstraction, which means that I occasionally have trouble remembering the exact syntax or the way to do something like find out which git commit corresponds to a subversion revision number.

Since I've been using Dash as a documentation browser as well, and since Dash 2.0 introduced cheat sheets, it seemed like I could save myself some time by writing a git-svn cheatsheet for Dash, which I did, and since it might save someone else some time, I contributed it to the Dash cheatsheet repo (using a pull request).

It's available now, so if you ever use git-svn and you use Dash, you should be able to download it within the app. And since the repository is open, you can even submit a pull request for changes to my cheatsheet if there are things you'd like to add to it (or, if you prefer, you can let me know, and perhaps I'll make the change).

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 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.

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 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 makes even JIRA look good. I don't understand why people use it.

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.