sstephenson

When will GitHub terminate its contract with ICE?

jwalk parses JSON into a stream of TSV records: https://github.com/shellbound/jwalk/

Performance depends on what toolset you’re using and how large your data set is.

For small JSON documents, like a package.json file, jwalk is around ten times slower on my machine: 0.03 seconds, vs 0.004 seconds for jq.

For larger documents, like the 1.5 MB GitHub API response tree.json [1] in the jwalk corpus, jwalk on mawk takes 0.37 seconds vs jq’s 0.11 seconds, but jwalk uses just 1.18 MB of memory, vs jq’s 5.81 MB.

Other interpreted parsers don’t fare as well: JSON.awk [2], which only runs on gawk, takes 0.8 seconds and 27 MB to parse tree.json; JSON.sh [3] takes 201 (!) seconds and 43 (!) MB, and JSONPath.sh [4] takes 7.4 seconds and uses 1.7 MB.

[1] https://raw.githubusercontent.com/shellbound/jwalk/master/te...

[2] https://github.com/step-/JSON.awk

[3] https://github.com/dominictarr/JSON.sh

[4] https://github.com/mclarkson/JSONPath.sh

Try to imagine yourself in the shoes of someone who doesn't know HTML and just wants to write a message or comment with a little emphasis and maybe a bulleted list. That's the majority of our customer base at Basecamp.

Creating an editor for that does sound like a simple task, doesn't it? Except the tools the browser gives you just don't work, as we've experienced first-hand over the years in the form of customer bug reports.

That's why we built Trix.

I was involved with the Wysihat project too. What we found is that its approach, like most other editors', is fundamentally broken. We created Trix to solve the problem. https://github.com/basecamp/trix#different-by-design

I think you'll find Trix's toolbar easy to style however you'd like, but if not, it ought to be straightforward to implement your own using the API.

Sadly, while the Scribe developers correctly identified all the various problems with contenteditable (https://github.com/guardian/scribe/blob/master/BROWSERINCONS...), they chose to solve it like most other editors: by using execCommand, waiting for the browser to make a change, and then attempting to clean it up afterwards.

Trix's thesis is that this approach is fundamentally broken. Instead, Trix updates an internal document model on each input event, then re-renders the editor contents in response.

Yes, of course we've seen ProseMirror. It looks quite nice.

By the time we first heard of it several months ago, the bulk of Trix had already been written.

It is not impossible. It just takes a lot of time and effort. It took two developers around 18 months to build Trix.

The readme explains how our approach is different from other WYSIWYG editors. (Most others are just toolbars that call execCommand.)

Trix fully supports file attachments and image attachments, as documented in the readme. It includes an inline caption editor for images.

Trix also supports "content attachments" (currently undocumented) which allow embedding arbitrary HTML as attachments in the document. Basecamp 3 uses this feature to embed @mentions with avatars, and various oEmbed types, in messages and comments.

No, it's not distributed as a Ruby gem.

"Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now."

Incorrect. It is support for an enhancement that rbenv provides.

You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub.

rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.

Here's another perspective: http://sstephenson.us/posts/on-configuration

Patches welcome.

Or you can use xip.io and save yourself a lot of trouble.

How are you going to add an entry to the hosts file on an iPhone?

For those who missed the other announcement, Pow 0.4.0 has xip.io support built-in: http://37signals.com/svn/posts/3191-announcing-pow-040-with-...

You're right. I'm probably just running xip.io to steal all your sensitive development-mode form data!

I've got just the tool for you!

https://github.com/sstephenson/gosh

Because I didn't know about it :) Great tip!

Sure thing.

For high-level measurements I use good old "new Date().getTime()". One call before, one call after, subtract the former from the latter and log it to the console.

When I want to dig deeper, I go to the WebKit Inspector's Profile tab. You can turn it on or off through the UI, or use console.profile()/console.profileEnd() in your code to control it programmatically.

Thanks, I really appreciate it!

At that point it's much more about feel than a hard time measurement.

After implementing deferred initialization I asked myself "does reordering feel laggy?" and the answer was no. If it had felt laggy then I'd have started profiling again.

Of course we support browsers other than Internet Explorer.

Here's the full list of supported browsers: https://basecamp.com/browsers

And way to miss the forest for the trees, guys—this article isn't about IE at all. I've come to expect no less from the Hacker News crowd these days.

For those who are curious, the new Basecamp calendar is a Backbone.js/CoffeeScript/Eco affair.

It's not a single-page app—at least not in the traditional sense. Only in the sense that we don't need to reload assets with each page change.

We are using a dash of Backbone here and there for cases where interaction speed is of utmost importance, but most of what you download over the wire is HTML.

Like most sane people we have abandoned the idea of XHTML in favor of HTML 5.

We started out with pjax (which is awesome) but ended up rolling our own framework called Stacker which lets us have complete control over the UI.

All of the above.

On the app level, each fragment of markup is free of user-specific data so all users can share the same cache. (User-specific concerns are pushed down into JavaScript and CSS.) Those cache fragments are then nested, so we can cache at all levels of display: an individual to-do item, the to-do list with all its items, all to-do lists in a project, and the entire project itself.

At the HTTP level, we send an ETag in the response for every GET request. Since our app caching means we don't incur the cost of a full render, we can serve the requests very quickly and avoid sending back the contents of the page if your browser already has it.

At the JavaScript level, we cache DOM elements for every sheet you've visited in the current page load, and display them immediately (while fetching the latest version in the background) when you re-visit a URL.

Eric, our plans have changed and we're no longer working on Cinco.

Rest assured, you can cmd-click everything!