Showing posts with label osx. Show all posts
Showing posts with label osx. Show all posts

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, 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, June 13, 2011

Apple's iCloud and Synchronization

Apple’s iCloud promises to keep your devices in sync so that you can use your Mac, iPhone, iPad, PC and iPod Touch without worrying about synchronization issues. No matter how that’s implemented, it’s going to be a big step up from synchronizing everything through iTunes over USB. But I’d like to know more.

What’s Been Said and Written

During the WWDC Keynote, Jobs said “the truth is in the cloud.” This could mean a lot of things, but people have been attempting to interpret it.

John Gruber paraphrases:
The gist is that Apple considers syncing to mean peer-to-peer — something where every device is on equal footing. With iCloud, there is one official data store: iCloud’s. As Jobs put it on stage, iCloud’s data is “the truth”. This means no conflicts or merging.
I don’t yet know how iCloud will work, and I can’t read John Gruber’s mind, so I don’t really know what he meant by what he said. The only way I can see iCloud avoiding conflicts and merges is if you can only modify shared data when you’re directly connected to iCloud. As soon as you allow for the possibility that you can make a change on a device that isn’t performed in lockstep with iCloud, you step back into the world of conflicts and merging.

There may be iCloud API documentation that covers this in detail, or WWDC sessions that expounded on the subject. I don’t know. I wasn’t at WWDC and I’m not a paid member of either of Apple’s developer programs[1].

iCloud-Only Changes

One possibility is that Apple will not allow you to change data that is stored in iCloud unless you’re directly connected to iCloud. For instance, if I wanted to change a Calendar event on my iPad, and I were connected to iCloud, I could make the changes. The changes would be stored in iCloud, and be broadcast to all iCloud-connected devices.

For instance, if I had an iPhone, iPad and Mac, all connected to the cloud, they might all start with the same piece of data (e.g. a calendar event), which I’ve marked with a '1’. The phone could request a change (’2’), which would be stored in iCloud and broadcast to the devices:



If I were to try and make a simultaneous change on another device, the broadcast from iCloud could simply overwrite it, or it could ask the user to make a decision.

This approach is technically possible, but not terribly likely. This would imply that if you have a laptop or an iPad without 3G service and you’re not currently on a network, you cannot make changes to your calendar or anything else stored in iCloud. That’s too limiting to make sense.

Offline Changes

If Apple is going to allow users to make offline changes — changes that can’t be immediately verified and stored in iCloud — then it seems like they also need to deal with conflicts and merges.

If you can make offline changes, and “iCloud’s data is 'the truth’”, then as soon as you reconnect to iCloud, your device will see that iCloud’s data is different than the data stored in your device and immediately overwrite it with the older version from iCloud. That’s actively worse than iCloud-only changes, because you can make all the changes you want when you’re not connected to iCloud, but they’ll all be lost:



If you make a change on a single device while offline, when you come back online, the changes could be pushed to iCloud and broadcast to all other devices connected to iCloud without having any conflicts or merges.

Similarly, if a change is saved to iCloud from one device while another device is offline, when that second device reconnects, the changes from iCloud can be broadcast to it without any conflicts or merges.

However, if two devices make a change to the same piece of data while one or both of them is offline with respect to iCloud, then things get more complicated. Either you have two unrelated changes to a single piece of data (for instance, you change the location of an event on one device and the date of the event on another device), which we’ll call a 'merge’ or you have you have two changes that disagree with each other, a 'conflict’.



Merging without conflicts is usually not too troublesome, but as soon as you have two conflicting changes, you must either make some hard decisions about which version of these changes from two devices is the 'best’ (for instance, the most recently-recorded change) or you must break the seamless user experience and ask the user which change is the best. The former will likely lead to you making the wrong decision now and again, whereas the latter is very hard to do in a way that’s not confusing to all but the most technical of users.

Saying that 'the Cloud is the truth’ doesn’t measurably change any of that complexity.

It Just Works

What you could argue is that while merges and conflict are unavoidable[2] and have the potential to be both complicated and confusing[3], Apple could conceal most if not all of that from the end user and even the developer who’s using the iCloud APIs.

Apple likes to build complex systems that offer a simple and clean user experience, so this makes some sense to me. Not only does this sound like an approach Apple might take, it sounds a lot like the approach they already take with Sync Services, as Weldon Dodd wrote for GigaOM.

Sticking with our Calendar Event example, if you make changes to your calendar event in one or more devices, some of which may have been offline at the time, either simultaneously or at different times in the day, iCloud will decide for itself which version represents the truth and present that information to any iCloud connected device. It’s possible that neither the user nor the developer will have any say in the matter. If what you end up seeing matches what you think is the right final value — and most of the time you probably will — then you’ll believe that it “just works.” As MG Siegler put it for TechCruch:
With iCloud, Apple is transforming the cloud from an almost tangible place that you visit to find your stuff, to a place that only exists in the background. It’s never seen. You never interact with it, your apps do — and you never realize it. It’s magic.
If this is the case, then the means by which conflicts are reconciled and merges are performed may remain a black box, even to well-informed iOS and OS X developers. And if Apple’s done a sufficiently good job, no-one will ever mind.


  1. And if I were a member of the developer programs or a WWDC attendee, I’d be bound by NDA, and unable to share what I know.  ↩
  2. They are.  ↩
  3. They do.  ↩

Friday, May 20, 2011

Scripting Twitter for Mac in OSX Spaces

Twitter for Mac was released alongside the Mac App Store, and quickly replaced its predecessor, Tweetie, as my client of choice. I preferred it in most respects save for a single, nearly-fatal, flaw: Twitter for Mac didn’t work well with OS X Spaces.

If you use Spaces under OSX, and you launch an App, you’ll usually see that that app appears in the space in which you launched it, and isn’t visible in any other space. The spaces preferences pane allows you some control over that, but for the most part the default works just fine. When you launch Twitter for Mac, it also appears in the space in which you launched it. If you open the spaces view, you’ll see that it isn’t visible in the other spaces, but if you switch to the other spaces, Twitter for Mac follows you wherever you go. After trying a few things and reading suggestions from others, I discovered that if I bound Twitter to a particular space in the preferences dialogue, it would stay there until I closed Twitter. If I were to open Twitter again, I’d have to repeat the binding after removing the old one in order to get the same effect. Irritating, but with a workaround, I could live with it.



Giving Up

As days turned to weeks and weeks turned into months, I came to accept that Twitter wasn’t going to fix this, at least not in a timely fashion, and poking around in the Spaces preferences every time I launched Twitter was starting to grate on me. This seemed like something I should be able to automate.

I’d never played with AppleScript, and every time I’ve considered it, I’ve always been a little thrown by the verbose natural-language-like style. I briefly tried a recording in Automator, but the result didn’t quite work. I came to accept that I was going to have to delve into AppleScript if I were going to solve this problem.

AppleScript and rb-appscript

I started to learn a little bit of AppleScript, figured out how to open the Spaces preference pane, and started reading more advanced AppleScript code that manipulated spaces bindings. As I was researching and learning, I thought about how much nicer this would be with Ruby or MacRuby. After doing a quick search, I came across an article about rb-appscript, which allows you to do automation using Apple Events from Ruby.

I started reading the documentation on the rb-appscript site, and Matt Neuberg’s unpublished book Scripting Mac Applications With Ruby: An AppleScript Alternative, and between some experiments in irb and the reading, I was able to find a way to unbind and bind Twitter to a particular space in the Spaces preferences. It wasn’t hard to go from there to a first, second and third draft of some Ruby code to get the job done. As I was refining the solution, I started to share it, first on Forrst, then on GitHub’s Gist.

The final version looks like this:


With this script, you can launch twitter, then quickly run the script to fix Twitter’s spaces binding. Alternately, you could enhance it very slightly to both launch and rebind Twitter, so that you can accomplish both with a single step:



But none of that is necessary, because…

Foiled Again

Shortly after I started sharing it, @JCB_K pointed out that just before I gave up on Twitter ever fixing this bug, they had finally fixed it. That means that everything I’ve done since then was educational but unnecessary.

So, while this is finally done, and you’re welcome to use it, it seems that your best bet is simply to fire up the App Store and take the latest update.