When will GitHub terminate its contract with ICE?
1,066 karma · joined February 20, 2009
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
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 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.
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.
By the time we first heard of it several months ago, the bulk of Trix had already been written.
The readme explains how our approach is different from other WYSIWYG editors. (Most others are just toolbars that call execCommand.)
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.
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.
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.
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.
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.
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.
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.