Git whilst disconnected

I've been using Git (and helping out on the EGit project) for a while, and once you've gone Git, it's really difficult to go back.

I often find that when I'm working on the train, using Git to work in a semi-disconnected mode helps – although the train has WiFi on board, it's not particularly consistent, and I can periodically get connectivity drops. Using Git (or any other DVCS) means that all my work can be done on a local image, and that I don't need to worry about whether I'm connected or not.

This week, I downloaded the WWDC 2010 videos as well as putting together and uploading (and downloading) the vimeo EGit screencast. Unfortunately, this meant that I had blown through my monthly bandwidth quota without realising, and as a result, my net connectivity had been suspended until the end of the month.

Fortunately, none of that changed my ability to work with my Git repositories; I'm still able to commit into them, knowing that when I am back and connected again, I'll be able to upload the changes to the review system and keep going as if nothing had happened.

I wonder how long it will be until every project at Eclipse is on Git...

Ruminations of an iPad user

It has been a couple of weeks since I bought an iPad (and about half that time being able to use it), so what are my experiences?

Since I pre-ordered my iPad, I took delivery a day before it was released and hooked it up to the net via an O2 SIM card (my Three micro SIM didn't turn up until the next day). As far as connectivity goes, it's about the same as an iPhone, in that it's always connected. In fact, the 3G signal will often outperform my iPhone 3G connection – but then, the signal on the iPhone is so bad when it's on 3G that i turn it off most of the time.

Incidentally, with all of the furore about the 3G signal dropping on the new iPhone, I wonder if the real issue is that the iPhone 4 just sends all of the audio calls over 2G instead of 3G – either that, or they have fixed the handover between 2G and 3G.

But I digress. And, as my last comparison with an iPhone goes, saying that an iPad is just like a big iPhone is like saying a bicycle is just like a big unicycle. Yes, it's true that they share similarities in the OS (now called iOS) and in the way that applications are built and delivered (the term "universal binary" has gone from meaning Intel+PPC to meaning works on both iPhone and iPad).

The apps built specifically for iPad (or with iPad support) stand high above other iPhone apps. If you are a developer, and thinking of getting away with just building an iPhone version, think again. Yes, it meant that on launch day, there were a lot of applications available for the iPad – in much the same way that the original OSX had support for running "classic" apps, or the first Intels had Rosetta in order to allow existing PPC apps. Being able to run iPhone apps on an iPad is purely a transitional support phase. Of course, the best apps are those which can be installed on either an iPhone or an iPad and automatically present themselves in the appropriate way.

So what of the device itself? Well, there are stories abound that iOS is going to put Mac developers out of business. Certainly there's a lure to the AppStore if only because it gives access to a much wider market than independent developers are able to command – and with a built in mechanism for collecting money.

However, OSX isn't going away any time soon. The iPad is an excellent consumption device, but not a creation device. Even the iMovie available on the iPhone now is just an indication of the GPU horsepower (combined with the fact that stitching together movie segments isn't the most difficult thing to do from a UI perspective). Whilst the on-screen keyboard is good, it really doesn't work well as an elongated input mechanism - and although the keyboard dock is acceptable, you can only really use it on a steady surface like a desk. Other than the lack of haptic feedback, there are really three problems with the keyboard:

• The input text line is often at the bottom of the screen, closest to where they keyboard is. If your fingers are in touch typing mode, then they almost always obscure what it is that you are typing. As a result, any errors that creep in are often not noticed until you have gone over a few words, and it takes a while to reposition the cursor to go back and manipulate the errors.
• The shift key is too near the A key; and since there's no feedback (and rough approximations of where the fingers are) it means the shift key is hit about 1% of the time you want to hit the A key. You end up with words like thT which aren't picked up by the auto correction engine; and although iOS 3.2+ highlights words that aren't in the dictionary, it still interrupts the flow of typing.
• The speed of being able to arbitrarily jump to a point to fix an error is insanely slow. Whereas on as keyboard, the key repeat is sufficiently tuned to be able to speed up after the first few keys, the iPad doesn't have that incremental speed up. So you end up deleting one char at a time to fix problems. If you have made an error in the past few words, it's often quicker just to delete all of the interim odds than it is to move your hands to get it back again. What's worse is that after about three seconds, it jumps to deleting whole words at a time which often means that you go too far back and delete more than what you want.

In order to measure the effective speed differences, I went to http://www.typeonline.co.uk/typingspeed.php on my devices. Both the iPhone and Blackberry suffered from having to scroll up to see the copy text; I expect they'd be more like 25wpm for on-the-fly composed text.

• Blackberry: 20wpm (4 errors)
• iPhone: 20wpm (4 errors)
• iPad: 35wpm (4 errors, half A problems)
• iPad with keyboard dock: 90wpm (1 error)

Although the keyboard dock is a great advantage over speed, the accuracy problems still persist. You'd think with having a touch screen it would be easy to correct. However, deleting a char is much more difficult than it needs to be - in fact, in a number of occasions it's just easier to select and delete the whole word rather than trying to move the magnifying glass to the precise space. When you're only doing 20wpm then taking 2 seconds to delete an extraneous character is in the flow - but at 35wpm you are doing 3 chars/second: if the word is shorter than 6 chars then it's just faster to retype. The problems are magnified if you are doing two to three times faster.

The conclusion of this piece is that an iPad is a good addition to the set of device, but not really a replacement for a laptop. The bigger screen size helps to create more immersive applications and the on-screen keyboard means that you cam type faster than with an iPhone - nut if you are a hunt-and-peck typist then there probably won't be a significant difference between them. If you are a touch typist the problems are more magnified.

Where it really wins is in being portable. It's much easier to take an iPad with you to write a brief missive than to lug a laptop round with you. With a decent cover, it feels like you are carrying a large book or a small magazine; and you can carry it one-handed. As a result, it's good for getting some notes jotted down – but pencil and paper would be much faster (especially with shorthand).

Unlike the iPhone though, the iPad is really a two handed device. The keyboard is too big to use one handed effectively (as compared with an phone or blackberry) – and if you need two hands to type, then you need a third hand or a desk/lap with your legs stretched out in front of you in order to work.

The ability to store movies (especially with 64Gb storage) is a real win though. Having downloaded (and crapped out my broadband connection with) the WWDC 2010 presentations, it was easy to just prop up the iPad over the weekend whilst preparing food in the kitchen, sitting on the sofa and be able to pause and resume where I left off whenever the need took me. Having a laptop feels much more defensive, and even though it's possible to go full-screen there as well, you occasionally switch over to twitter or try and shut off the rest of the room. With an iPad, particularly because it can be standalone in a much smaller space, you don't mind just hitting pause and leaving it where it is.

So is an iPad worth it? Well, it's not going to replace a laptop any time soon; but if you've got a lot of media (photos/video; audio is handled well enough by an iPhone) then there's a lot to be said for getting an iPad. If you're a developer, it's not going to replace a laptop – if you want a more portable developer device, the MacBookAir is really for you. If you don't really need a laptop (or use a laptop mainly for viewing videos/photos) then an iPad is a (slightly) cheaper replacement. One thing's for sure; when the iPad comes out with FaceTime as well next year, I'm pretty sure it will be the best way of keeping the grandparents in touch with their grandkids.

EGit DemoCamp screencast available

As I noted last week, I was fortunate enough to give a state of play presentation on EGit and Git at Eclipse. For those who weren't able to make it, I've made the presentation available as a PDF, although it has animations (which don't show up in a static copy). I've also audio-dubbed the presentation, along with a screencast recording approximating the demo I gave as well, which is available as a QuickTime presentation (on request) or viewable at Vimeo in HD:

EGit 0.8 at Eclipse DemoCamp 2010 London from Alex Blewitt on Vimeo.

Sadly, no-one commented on the Eclipse Tie I was wearing at the time.

Eclipse DemoCamp London - EGit

I'm giving a presentation on EGit on Thursday night at SkillsMatter in London. The Eclipse Helios release is just round the corner, and one of the new features is built-in Git support. I've written about Git in Eclipse before, but this will be an interactive presentation with live demo elements to go wrong.

If you want to come along, you'll have to sign up first but it's free. Note that SkillsMatter have moved so check the new location before going.

There's also other talks as part of the DemoCamp, including Ian Skerrett on the Eclipse Marketplace Client, Neil Bartlett on BndTools and Zoe Slattery on Graphical OSGi Analysis Tool. I look forward to seeing you there!

XCode 4 and new features

It looks like the decision to close up ObjectivEClipse was probably the right one, since Apple have just released XCode 4, with a lot of new goodness inside. Even if we'd not closed up shop before the announcement, we would have done shortly afterwards.

Top on the list is built-in support for Git, the popular DVCS tool. In fact, they seem to have done what they always do, which is to let others experiment with a feature, find out its capabilities, and then once all is done, write a great UI on the top. The new XCode has a time-machine like time-slider for showing you how your code changed over time.

There's also support for Clang, a new Apple-sponsored and LLVM-backed compiler for C, C++ and Objective-C. This has been in beta support for a while; it wouldn't surprise me that the eventual switch for compiling for iOS uses Clang by default. One of the things that Clang does much better than gcc is its error messages; for example, see amazing feats of clang error recovery. In addition, the static analyser produces a lot of useful feedback to the compilation process, which uses the LLVM internals.

New is the lldb debugger (see the announcement), a replacement for gdb. Slowly but surely, gcc is being shown the door — and whilst it may be around for a while to come (especially for compilation of platform-portable code), it looks like Clang is the future of compilation on the Mac.

Given that Clang is platform-portable, open-source, and demonstrably better in certain aspects (e.g. the license is BSD and so can be compiled-in to projects, instead of externally invoked), how long will it be before other tools, like Eclipse CDT, take it up?

Effective UX with the Clipboard

One of the things that becomes apparent if you use OSX for a while is that small things matter. It's not necessarily that writing in any particular target language is more or less capable than the other, but rather attention to detail – I've written about this before.

However, attention to UX can be the icing that turns a good product into a great product. The phrase “It just works” is often used with Mac products (both Apple and non-Apple) – when in fact, most software works in any case. So how is it done?

One tip I want to share here is the benefits of using the clipboard automatically where appropriate. I've used this before in examples, and proposed it for EGit (bug, review) as well. My feeling of why it's not more widely used is simply that people haven't thought about doing it before.

If a user navigates into a dialog where they're expected to put in a line of structured text (say, a git URL for cloning), then the user really has two choices. The first is to re-type the text, character for character, by reading it off a page or e-mail. The second is to copy the text from that page and paste it in (with Command/Ctrl+C/V or mouse, for preference). The majority of times, especially if you're using a URL, you'll be using the clipboard to copy and paste the data in.

The second thing to observe is that you almost certainly have a good idea of what the text needs to look like. If that text begins with git://, then there's a pretty good chance that it's the URL in the right format. On the other hand, if it's Did you enjoy the curry last night? then it's probably some other irrelevant stuff from an e-mail or chat window. The point is the program can automatically detect if it's valid or not.

So, when activating the dialog, either at construction time or (better) at focus time, you can detect if the user's input is already in the right form, and use that. (A common case is when the dialog gains focus-switch, especially if the user already has the dialog open, Alt/Command tabs over to Firefox/Safari to copy the URL, then Alt/Command tabs back again.) There's really three cases here:

• The clipboard text is a random chat transcript, so we ignore it – net result, same as if we didn't introspect the clipboard in the first place
• The clipboard text is in the right format, and the user has to paste it in manually upon dialog activation
• The clipboard text is in the right format, and the program pastes it in automatically

The number of cases where the data is almost in the right format (but not quite) is vanishingly small, and often can be resolved with a tighter regular expression. In fact, some programs that need a licence code to activate will send the code by mail, and then allow the entire message to be copied. Given that the licence code is a known format, it's possible to detect even if it appears anywhere in a block of text, not just if the entire text matches.

This technique has been pushed to the EGit project for cloning git repositories. If you copy a git URL and go to the clone dialog (providing that you're using the development or nightly builds) then it will pre-fill the dialog out with that value.

Here's an example of detecting a URL inside a block of text on the clipboard:

package com.example.clippy;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

import org.eclipse.swt.dnd.Clipboard;
import org.eclipse.swt.dnd.TextTransfer;
import org.eclipse.swt.widgets.Display;

public class ClipboardDemo {
  /**
   * Must be run in the main SWT thread
   */
  public static String getClipboardText() {
    Clipboard clippy = null;
    String text = null;
    try {
      clippy = new Clipboard(Display.getDefault());
      text = (String) clippy
          .getContents(TextTransfer.getInstance());
    } finally {
      if (clippy != null)
        clippy.dispose();
    }
    return text;
  }
  public static String getURL(String text) {
    Pattern p = Pattern.compile(".*(https?://\\S+).*"
      ,Pattern.DOTALL);
    if (text != null) {
      Matcher m = p.matcher(text);
      if (m.matches())
        return m.group(1);
    }
    return null;
  }
  public static void main(String[] args) {
    System.out.println("URL detected was: " + 
      getURL(getClipboardText()));
  }
}

Overview of the Lambda project

I've written up an overview of the lambda project over on InfoQ. It covers some oddities about Java's type system, why invocation of lambda expressions uses .() syntax instead of just (), and some general background on the project.

You can read about it at http://www.infoq.com/articles/lambdas-java-analysis

ObjectivEClipse project closing doors

My first object-oriented language was Objective-C in the early nineties, and I've been a devotee of the language for some time. When Java was released in 1995, I remember being able to transition into the UI and object orientation fairly painlessly; and although I never left my NeXT box, time moved on and I went into Java development – and ultimately, onto Eclipse.

I picked up Objective-C again when I bought my first TiBook in 2001, but it wasn't until the release of the iPhone in 2007 (and the jailbreaking scene) that developing Objective-C apps became 'cool' again. Since then, interest in Objective-C has once again risen; and even though it feels clunky (in comparison with newer languages like Java or C#), the language has certainly evolved – with exceptions, blocks, threading and not to mention improvements in technologies like OpenGL, OpenCL and Quartz along the years.

I've often wondered what people see in C++ when Objective-C is available, and has been so, on the gcc platform for ages. There's been a long-running GNUstep clone of AppKit and friends, and other conversion kits like The Cocotron enable Objective-C based applications to be compiled for other platforms (for more details, see Cocoa with Love). Unlike C++, Objective-C classes generally avoid the fragile base class problem, and can dynamically link in newer versions of frameworks and perform framework-dependent versions – arguably, why it's possible to write iPhone apps that run on the latest-and-greatest hardware versions, but still enable the same binary to run unmodified on older versions with weak linking.

Everyone's opinions of IDEs differs, but those who have grown up with Eclipse can see where the advantages over Xcode shine. Unfortunately, the CDT project only natively supports C and C++ – althouhg there has been an enhancement request to support Objective-C in CDT for some time. (It was first raised in Eclipse 2.0 in 2004.) It's currently got 67 votes, but it's really up to the community to make it happen.

Last year, I proposed the ObjectivEClipse project on Google Code as a way of trying to advance the support of Objective-C in CDT. The hope was with enough interest, it would be possible to fold that back into the main CDT and make it a default part of the CDT installation.

Sadly, that project has failed.

There's a number of reasons why it didn't take off. Predominantly, the main one was a lack of interest in making it happen. (That's not the same thing as a lack of interest in it happening.) There were a few contributions; Ryan Rusaw did an excellent job in extending the parser to support Objective-C's blocks, which has been made available (but not implemented outside of Apple's gcc and the clang project.

From a technical perspective, although it's possible to configure a new language in CDT, there's a lot of internal packages that are shared between the C and C++ plugins which aren't conducive to an externally developed language plugin. Secondly, in looking at the possibilities of upgrading the Objective-C support for CDT 6 (in Eclipse 3.5) to CDT 7 (in Eclipse 3.6), it's become clear that the CDT parsers for C have been significantly refactored, breaking the existing ObjectivEClipse parsers. Even before this refactoring, in order to hook in the parser to the existing code required more than desirable duplication of code in the parser directory and others.

Wouldn't moving to Eclipse Labs help?

Putting aside the fact that the Eclipse Labs is a relatively recent creation (and ObjectivEClipse was asked whether it wanted to be part of the beta test), having availability has never really been a problem. The key is whether there's an interested set of developers, who develop in Objective-C and use Eclipse as their preferred IDE. Where the project is located wouldn't really change that dynamic; even after promoting it via my blog, on the CDT mailing lists, and on Twitter (including at NSConference), it's clear that there's a small number of people wanting it to happen, and an even smaller number of people interested in making it happen.

Even if there were, the arm's length approach to Objective-C support (if you build it, it can come) really doesn't work for the development of a new language, particularly when refactorings occur. That's not to say that the CDT team weren't helpful; they were responsive to requests for information, and even some of the CDT team now run Mac OS X. But there's a long-running impression that Objective-C is just for Macs, even when it works on Windows and Linux. Conversely, the existence of C and C++ on many platforms is treated as the de-facto standard, and so the CDT project supports these out of the box.

But projects like Wascana live on ...

Doug has been a long term supporter of CDT on the Windows platform. Although it's not possible to host or distribute GPL code from Eclipse.org, it is from Eclipse Labs, and the Wascana project lives there. However, this is really a packaging of the standard CDT with required binaries for the Windows platform – it's not a set of code extensions. It's really just a P2 Generator and some gcc packages, compiled with MinGW to make for an easy Windows install.

Would a DVCS help?

Being able to pull changes as they happen from the Eclipse codebase is one way of picking up on changes to the code as they happen. In quite a few cases, this is enough to keep up-to-date with the changes – but it's not enough. If the parser changes significantly, or changes are created by duplication, then refactoring isn't going to be included even with a DVCS.

In any case, Eclipse Labs doesn't support Git so that would be another problem – and even though Git is the de-facto DVCS of the future for Eclipse, the CDT project isn't part of the git.eclipse.org cloned respositories. That's not to say that some haven't created git clones of cdt-core – but it's a manual process, and is still falliable. Whether this would have been in place at the start would have avoided some of the bulk copying is an open question; but ultimately, a fork is only good if it can be folded back in at some point – and that was never likely to happen.

Is this really news?

Well, the activity on the project page (combined with the activity on my github clone) really shows that not much has happened for a while. Part of that can be attributed to the same time that Apple killing off ZFS since much of my development focus has been getting that back on track (and merging in the OpenSolaris codebase).

There's also the thorny question of Apple's policies and Section 3.3.1. There's been a long-term clause which states that Xcode must be the only tool used to build iPhone applications for submission into the AppStore; though it doesn't prevent other tools being used in addition to that. However, it's become increasingly clear that although development of Objective-C tools for other non-Mac systems is possible, it's the iPhone (and iPad/iPod Touch) platforms that are driving the Objective-C resurgence. In fact, just this month Objective-C made it into the top 10 languages on the Tiobe report (note: site is Slashdotted at this time), presumably through the Apple device strategy.

The future

There are those who want CDT to achieve world domination, and there's hope that this might include Objective-C at some point down the line. Certainly, I think that the usefulness of Objective-C as a language exceeds just a single manufacturer; the fact that clang and gcc both support Objective-C means that you don't need to be on closed platforms to write Objective-C code. However, it's my opinion that an Objective-C extension to the language has to happen within the CDT upstream source in order to survive refactorings instigated by other CDT languages. As it currently stands, ObjectivEClipse is firmly wedded to CDT 6.0, and there's no plans to change this at any time in the future; so, once CDT 7.0 comes out this month, the purpose of ObjectivEClipse effectively grinds to a halt.

I'd like to thank those that supported the idea of Objective-C in CDT, and in particular those that offered their time and advice at prior EclipseCons and on the CDT mailing list to give it the best chance so far.

Smart Git HTTP checkout from Eclipse.org

Thanks to Shawn's implementation of the smart http protocol in both the C git and in JGit, cloning repositories from git.eclispe.org is now much faster.

In essence, the standard git: protocol works by having a bidirectional conversation deciding what changesets are available. This is remarkably efficient; in fact, one of git's strengths is its fast checkout. Sadly, the dumb HTTP protocol worked by setting up multiple HTTP connections, one per pack required, with the obvious overhead that that entails.

In addition, the dumb HTTP protocol required an index file, updated by update-server-info hook, in order to be able to access the data. If this hook wasn't configured then the repository couldn't be checked out over HTTP.

The smart git http backend works by providing the standard git: protocol, provided by one (or a few) HTTP connections to a smart backend, which knows how to provide information from a git repository (with or without the update-server-info information). In addition, the connection provides progress information over the HTTP channel, in much the same way that the git: protocol works, so the difference between cloning over git and over HTTP is now practically indistinguishable.

Thanks to the hard-working Eclipse webmasters (especially Denis), bug 302353 is now marked as fixed, and all of the Git repositories available via http://git.eclipse.org are now available via http as well as git and ssh. This is great news for those of us who are stuck behind corporate firewalls and can't access either CVS or SVN/git protocols.

At the moment, committer (write) access is available by CVS or SVN only; however, having cloned a read-only repository, it's possible to upload into a different repository by cloning via http, and then configuring the url.location.pushInsteadOf to push to a different repository name.

Finally, a couple of Git related notes: firstly, if you haven't bought the excellent Pro Git book you almost certainly should – but it's now also available in ePub format for your iPad. Secondly, the EGit and JGit teams will very shortly be announcing the availability of 0.8.0 coming to an update site near you soon ...

PS since Eclipse Labs doesn't support Git yet, you might want to vote for it, since one of the reasons for Google choosing Hg over Git in the first place was due to lack of speed in their initial analysis at the time.

Update

No sooner than I had written this, than Chris had blogged about EGit and JGit availability, with a link to the new-and-noteworthy for both EGit and JGit. Whilst it is usable, there are some rough edges and missing functionality, which it is hoped to deliver this autumn as part of the 0.9.x release.