Dropbox vs. Box vs. HubiC

Edit: Brain Fart — I seem to have omitted about a paragraph of pertinent information.

I’ll assume you all know what Dropbox is. If you don’t, go get Dropbox now. It’s free and it’s awesome.

The only downside of Dropbox is that if you want more than the 2GB of storage you get for free, it gets more expensive, and the upper limit on how much you can store is (for practical purposes) quite low. Personally, I haven’t found either of these an issue — but thanks to my link on opensourcemac.com, I have a pretty huge “free” account. But it would be awesome to have something like Dropbox that was so big I could just stop managing what I keep on it altogether (of course, this is the problem with stuff that’s free — you waste it).

Box.com has been around about as long as Dropbox (heck, it has an even better domain name, right?) but has been targeted at the enterprise.

hubiC.com (their capitalization) I just found out about via Hacker News. It offers more free storage than Dropbox, but not quite as much as Box, and vastly cheaper paid plans, including about $140/year for 10TB. (I’m not sure how you can actually get 10TB into it, short of using a ZFS or Drobo style multi-disk volume.)

2GB vs 50GB vs 25GB

This is how much storage you get for free.

$100/year for 100GB vs. $10/month for 100GB vs. $13.60/year for 100GB (or $136/month for 10TB)

Edit: I’ve corrected the costs for HubiC.

This is how much it costs for more storage. Box gives you — by far — the most free storage but gets more expensive than Dropbox (while offering various enterprisey features). HubiC is insanely cheaper than both of them. By way of comparison, iCloud costs $20/year for 20GB, so in terms of dollars per unit storage, only HubiC is a better deal. In terms of useful features out of the box, Dropbox support is built into far more programs while iCloud offers useful functionality (notably over-the-air backups of devices and integration with Apple products) to Mac and iOS users that no other platform can (currently) match.

For Android users, the iCloud equivalent is Google Drive, which gives you 15GB free, and costs $60/year for 100GB, making it a bit cheaper (and less useful) than Dropbox.

Mac OS X Integration

All three programs appear as folders in your home directory by default, and stick shortcuts to themselves in Finder’s sidebar. Having installed HubiC and then Box after installing Dropbox, Box was very flaky when first installed. Its installer provided no feedback, and the first few times I tried to launch the application nothing seemed to happen, followed by weird broken delayed launches. Once I’d patiently killed a bunch of Box.app instances and started over it worked well.

Box and Dropbox have similar levels of Finder integration — they indicate the state of files and provide context menu items for sharing links. HubiC appears not to do anything like this, unfortunately.

All three applications provide status menus — those icons that appear in the menubar to the left of the Spotlight magnifying glass. I should note that HubiC’s icon looks like a shapeless blue blob — a blue cloud? — which is an anti-feature. The status menus of all three seem to be perfectly fine and offer decent functionality. Oddly enough, Box and Dropbox no longer keep you apprised of your usage level whereas HubiC does.

Box has one glaring defect — it won’t sync Mac OS X “bundles” (i.e. directories masquerading as files). I have no idea why — they’re just directories. It tells you to zip them up first (gee, how about doing it yourself?)

All three services offer support for all the usual platforms — although I can’t comment on how good any of them are (except the Dropbox client for iOS is decent, and all three work decently in a web browser, although HubiC’s in-browser account management is awful). I cannot yet comment on the security of Box or HubiC. Dropbox offers, and I use, two-factor authentication, and I’m pretty sure HubiC does not (but its website is pretty hard to navigate so maybe it’s there somewhere).

Conclusion

If you just want some free storage and don’t mind not being able to sync bundles then Box is a better deal than Dropbox and it’s probably quite robust given the money behind it. If you’re already using Dropbox and don’t need more storage, Box does not work as well so unless you want its enterprisey features (and you know who you are) you might as well stick with Dropbox. I can’t really comment on HubiC until I’ve exercised it by, saying syncing a buttload of RAW files to it (if I’m going to get more cloud storage, I want enough of it to not need more than one service). If you’re interested, HubiC is a damn good deal for free and it works side-by-side with the others. If it turns out to deliver the goods, I may well end up buying a 10TB plan and switching to it from Crashplan.

node-webkit

C3D Buddy 2.0 in action — built in an evening using node-webkit
C3D Buddy 2.0 in action — built in an evening using node-webkit

I don’t do very much desktop software development these days, and I’ve become increasingly frustrated with Realbasic (now Xojo), so the prospect of forking out $500 for an upgrade that may or may not be usable did not fill me with glee. Furthermore, as the years roll on, there’s more and more functionality tied to the web that desktop-centric development tools struggle to work with.

I was dimly interested in a thread on Hacker News this morning concerning a workflow for developing desktop applications with node. Turns out that the workflow was mostly to do with things like angular and jade, which I’m not especially keen on, and not so much with the actual desktop stuff — the heavy lifting for which is all done by node-webkit. So I started looking into node-webkit.

I like a tool which has you up-and-running in about three paragraphs.

It goes something like this:

Download an appropriate node-webkit binary. (Disappointingly, the Mac version is restricted to 32-bit.)

  • Write an index.html file. (The sample “hello world” app calls node inline.)
  • Write a package.json file. (The documentation suggests it’s like a “manifest” file, but really it’s more like a configuration file.)
  • Zip this stuff into a file into an archive whose name ends in .nw.
  • Double-click the archive.
  • Voila, your app works.

After working on this for about fifteen minutes, I knocked up a bash script (which I turned into a .command file, allowing me to double-click it in Finder) which does the archiving and then launches the file in one step. (It does leave dead terminal windows lying around, and it doesn’t quit the app if it’s still running. I think I may build an app for building apps if I do much more of this.)

And to build a distributable application you can simply put the archive in the application bundle (on the Mac) renaming it “app.nw” or name the file package.nw and put it in the same directory as the application (for those benighted platforms that don’t have bundles). One minor annoyance is that it’s not clear exactly what needs to be changed in the Info.plist file to fully customize your application.

So what is node-webkit? It’s essentially a version of Chromium that puts node.js alongside the DOM in your web pages, along with a few custom HTML and DOM extensions that let you do things like handle platform-native file requesters).

I should note that it’s a potential security nightmare as it stands. There’s no sandboxing (that’s kind of the point), so deploying an app that loads your banking website and then watches you press keys is totally doable. That said, it’s a desktop app so it can also delete all your files or encrypt them and hold them hostage.

Anyway, I had a lot of fun this evening rewriting a utility application I originally wrote in Realbasic a few years ago. It probably took me about twice as long to write it as it took me to do it in Realbasic. Part of that is I know (or knew) Realbasic very well, and I don’t know node very well. Another part of it is that Realbasic is almost always synchronous while node is almost always asynchronous. Writing code that spelunks a directory tree asynchronously is a lot more complex both conceptually and in practice than doing so in linear fashion, but the payoff is quite impressive — despite running an “interpreted” language, a task that took significant time in Realbasic (loading and displaying hundreds of thumbnails) happens in the blink of an eye.

One of the things that’s especially intriguing about node-webkit is that it gives you control over the browser you normally don’t have (e.g. window placement, file system access) — these are a constant usability sore-point in the project I am currently working on (which is a web app that is replacing a suite of desktop apps). It would be so much easier to get a lot of the things we want to do working smoothly using a hybrid desktop application built on top of something like node-webkit — it’s kind of a lemma of Alan Kay’s observation that anyone who wants to write really good software needs to build hardware — anyone who wants to write really good web apps really needs to build the browser.

The github repo for my project is here. It’s not a very general-purpose application; if you don’t use Cheetah 3D it’s completely useless.

Chocolat

Screen Shot 2014-01-07 at 4.46.16 PM
Chocolat is an ambitious programmer’s text editor, but it falls short (at least right now) in lots of little ways. E.g. integrating web-based documentation is a nice touch, but what about jQuery?

I discovered Chocolat by accident a month or so back. I can’t exactly remember how I learned about it — I saw a reference to it when reading the documentation of another product I use (I think it might have been Ulysses III) and so I gave it a spin. There was — and remains — a terrible problem with the way Chocolat identifies symbols in Javascript files, and I got into a bit of an argument with one of the developers on github over it, and set it aside. The thing is, Chocolat is an opinionated piece of software, and the downside of that is that one might not like all the opinions. E.g. in their FAQ is the question “will you add a minimap?” the answer to which is “Never!” That said, I like most of Chocolat’s opinions.

Well, there’s a new MacHeist “nano” bundle out and it’s particularly interesting for developers since it includes Hype (the would-be HTML5-based Flash replacement), Chocolat (a new programmer’s text editor which has a lot of potential), and — if some unknown number of people buy the bundle — PaintCode. I should mention that I bought the bundle for PaintCode and then realized it wasn’t actually included. Grrr. Oh well, Chocolat for $20 is actually a pretty good deal.

Here’s what differentiates Chocolat from my two favorite text editors (BBEdit and Sublime) right now:

Chocolat's symbol map is great when it works.
Chocolat’s symbol map is great when it works.
Chocolat tries to show a "symbol map" of your source file, but can't cope with code modules wrapped in anonymous functions (which unfortunately means most well-written Javascript library code). Note the empty rectangle where symbols should be.
Sadly, Chocolat can’t cope with code modules wrapped in anonymous functions (which unfortunately means most well-written Javascript library code). Apparently there are no functions in this source file.
  • Chocolat displays a symbol map (i.e. a list of object and function definitions you can use for quickly navigating source files) — the map is nice, but functionally it’s inferior to BBEdit (which can find symbols declared inside anonymous functions). Espresso remains the best in this respect, since it not only finds all the symbols you could ask for, it displays a nice symbol map too.

Screen Shot 2014-01-07 at 5.03.38 PM

  • Rather than giving you the choice of viewing two files side-by-side or one file, Chocolat lets you look at as many files as you care to side-by-side simply by selecting them.
  • Chocolat attempts to autocomplete Javascript (and does a pretty good job of it, including inferring the expected types for function parameters, and allowing you to tab around auto-inserted method calls TextMate-style). The only downside is that only works on currently open files. I imagine it’s even better with Obj-C (but haven’t tried).

Screen Shot 2014-01-07 at 5.07.14 PM

  • Chocolat attempts to integrate Safari (complete with debugging tools) by displaying it side-by-side with your code. This works pretty well.
  • Chocolat attempts to provide integrated documentation (e.g. select queryGetSelectorAll in a Javascript file and hit Command-Shift-J and it will look it up on MDN and show the documentation side-by-side with your code.
  • Chocolat does not attempt to integrate source control (git, hg, svn, p4, etc.) — I actually like this because I don’t want my text editor to do source control.

 

8 errors. Thanks.
8 errors. Um, ok. Thanks, I guess.

 

  • Chocolat is scriptable via Node.js. (Sublime is scriptable via Python, which is awesome too, but doesn’t happen to be the language I code in every day.) So far the available “mixins” seem pretty primitive (e.g. the jshint mixin tells me that there are “12 errors” in a file, but gives me no clue where or what they are).

For a while I thought Chocolat was a bit sluggish, so I started checking for signs of bloat. I did a quick comparison and BBEdit is actually the leanest of the three editors at 26MB on disk; Sublime 2 is 27MB, Sublime 3 is 28MB, and Chocolat is 34MB. Espresso, incidentally, is 18MB. But it turns out that the problem is I was using a “slow monitor” (i.e. my third monitor which is hooked up using one of those USB dongles). After comparing Chocolat, BBEdit, and Sublime on this display I concluded that BBEdit is even more awesome than I realized (because it appears to do minimal screen updates when scrolling), Chocolat is not bad at all, and Sublime is actually the worst. Again — avoid using USB-powered displays for editing text and you won’t care.

So here’s how it looks right now: Chocolat has the potential to become my favorite text editor since it’s heavily based on Javascript which means anything it doesn’t do well right now I can probably fix if I care to. BBEdit is the most polished, but the hardest to customize. Sublime remains — of course — the coolest, although given that Chocolat has support for both side-by-side editing, supports TextMate themes and snippets, and has “vim mode” it might take that crown, at least on Mac OS X.

But, Chocolat’s multi-file search is far inferior to BBEdit’s (it’s about on par with Sublime’s), its Regex support is also signficantly inferior to BBEdit’s, and it has no diff support (whereas BBEdit is my preferred tool for resolving differences between source files) — although I’m perfectly happy to use BBEdit as a dedicated diff front end, and do my text editing elsewhere.

Chocolat ★★★★ is $49 normally, currently available as part of Macheist Nanobundle 4 ($20).

I may review some of the other apps in the bundle later. In particular I have strong — mostly negative — opinions of Hype and Intensity Pro.

GraphicConverter 8

GraphicConverter 8 has layers and fast image browsing
GraphicConverter 8 has layers and fast image browsing

You may recall that I was a longtime user and fan of GraphicConverter, but gave up on it when v7 was a paid upgrade. I haven’t even launched GC in years. Well, v8 just came out (it’s still a paid upgrade for me, but not for folks who upgraded to 7) and it addresses one of my major gripes with v7 — it supports layers. It doesn’t address other concerns (it’s torpid and bloated — over 300MB!) but it does a fantastic job of displaying directories full of RAW images and allowing them to be rated quickly (even if, strangely, ratings made in the document window can’t be saved to NEFs, but those made in the browser window can). Despite importing RAW images and providing layer support, it doesn’t allow you to directly adjust RAW import settings (the way Acorn and all serious photo editors do), provide a non-destructive RAW workflow (the way, or attempt to remove lens distortions (iPhoto, Aperture, Lightroom, and many other photography-oriented image editors do all of these things).

So, it’s awesome that it supports layers, but image adjustments are incredibly slow (and don’t appear to work at all, but I assume that’s a bug), and the lack of (non-destructive) image adjustments mean that GC remains a pretty useless program for the time being.

So, for now, my photo-management software of choice remains Pathfinder.

Default Folder

Default Folder in Action

Default Folder X has been misbehaving quite a bit since I started using Mavericks. I clicked the “check for updates” button in its control panel and was disappointed to discover that I had the latest version. So, I went to the website and found out that there’s a beta that addresses the problems I’ve been having. Problem solved.

I felt an overwhelming urge to give a shout out to Default Folder, so here it is. This is the single most awesome utility on the Mac and has been for twenty years, give or take. It wasn’t the first program to do what it does, but it entered a market crowded with competitors (Now Utilities, Norton’s, and others) and simply outlived them.

And in all this time, I think I’ve paid for three, maybe four, upgrades.

Why?

Default Folder is a program that somehow extends standard open and save dialogs. It used to be a “Control Panel” in Mac Classic, now it’s some kind of background app. How it works isn’t important (it works!).

It does three incredibly useful things.

It lets you change the folder an open/save dialog is pointed at to any folder open on your desktop by picking it from a menu or (even better) just feeling around for where the folder’s window is (it gives you feedback) and clicking. How often do you have a folder open and want to get something out of it or save something into it from an open/save dialog? All. The. Fucking. Time. Well, Default Folder makes it really fast and really easy.

It remembers where you were in any given folder in any given application — so the file you had selected last time is what’s selected the next time.

It gives you access to pretty much all of Finder’s functionality from inside open/save dialogs, including the ability to rename, move, and delete files, and a quick look pane that’s always open, and — in Mavericks — which provides view/edit access to tags.

That’s basically it. I use it every day, dozens of times without thinking, and every time it saves me time, mistakes, and frustration. Almost anyone I’ve shown it to can’t believe they’ve lived without it. As far as I know there’s nothing equivalent for Windows or Linux (doubly depressing since they both need it ever worse).

That’s it. $35 is quite a bit for such a “simple” thing, but it’s seriously worth it. And the developer will not nickel and dime you for compatibility updates and other B.S. No, I am not being paid in any way, shape, or form to say this.