hcm

Love it!

For getting Apple Health data into duckdb, I’ve used this in the past: https://github.com/dogsheep/healthkit-to-sqlite. (You can load the SQLite database directly in duckdb.)

I can't recommend nand2tetris highly enough – it's a great crash course in computer architecture, operating systems, compilers, etc. but also it's just mega fun.

A big part of the joy came from making up my own extra credit side quests: implementing a compile-to-WASM emulator for the hack machine, adding optimisations to the compiler to produce smaller and/or faster programs, etc.

Thanks! It's just a few dozen lines of CSS. The body font is Inter and the monospaced font is JetBrains Mono.

Doh! Thanks for pointing out another silly mistake – I'll fix that.

(Author here) I don't see that in Chrome so had no idea that was happening – thanks for pointing it out! I'm not a fan of coding ligatures so I just pushed a change to turn it off.

I built https://grephub.com for that. It doesn’t maintain an index so it’s not super snappy, but it’s good enough / better than you’d expect in many cases!

Thanks!

Thanks! We have plans to make it even more awesome from within GitHub :-)

Great article. We've just moved a large portion of our async jobs over from Resque to Que because of the huge benefits you get from transactional enqueuing and processing. Performance seems good so far, and if it really becomes an issue, running two queuing systems side by side (one transactional, one high-throughput) seems viable.

We're super cautious about long-running transactions anyway, as they cause a load of other issues (e.g. http://www.databasesoup.com/2013/11/alter-table-and-downtime... - full blog post coming soon!)

Similar to http://codecube.io/

GoCardless (YC S11) is hiring senior software engineers and web operations engineers in London.

We're a fast-growing online payments startup that makes it really simple to collect money with Direct Debit. We've been around for 2 and half years, and are now a team of 25. We're backed by a bunch of top-tier investors (inc. Y Combinator, Accel, Balderton), pay very competitive salaries, and will shortly be moving in to a shiny new office.

We're looking to hire senior software developers to work on our core product, and web operations engineers to scale & manage our infrastructure. We've got lots of interesting challenges to solve this year: building the next generation of our product to handle the growth we're seeing, finding more intelligent ways to fraud-assess our merchants and customers, expanding what we do to work internationally (we're already beta-testing a European expansion).

There's plenty more information at https://gocardless.com/jobs. If you're interested in finding out more, email me at harry@gocardless.com.

I'm working on CodeCube (http://codecube.io) - a pastebin that allows you to run the code snippets and see the output live in your browser.

It's built on Docker. I posted an article about how I built it here: http://hmarr.com/2013/oct/16/codecube-runnable-gists/

The source is up on GitHub at https://github.com/hmarr/codecube

This is actually something I'd quite like to do with CodeCube - it wouldn't be hard at all. Replace SSE with websockets, attach to the container's stdin as well as stdout, add something like term.js, and it'd work a treat.

For one, it's much faster. CodeCube also streams the output to the browser. Also, CodeCube is open source (https://github.com/hmarr/codecube).

Check out Hutch (https://github.com/gocardless/hutch) - a similar system built on top of RabbitMQ

Thanks for posting this. Some of these ideas could work very nicely in hutch.

Very interesting. How exactly does the retry-later logic work? Does it just push the message on to a 'deferred' queue, that you manually process at your convenience?

Totally agree with your last paragraph, introducing a message queue has solved a lot of problems for us.

Another open-source alternative is Sentry (https://getsentry.com/), which supports multiple languages and frameworks. A hosted version is also available.

The Ruby support in Sentry currently isn't quite as good as the Python support, but it's not bad at all, and constantly improving.

Perhaps it wasn't clear enough, but the post pointed out that typing 'bundle exec' and explicitly using --path isn't necessary. Once you've added one item to your PATH, and two lines to your bundler config file, you don't need to think about it ever again, it just works. If you want all your gems in one place, simply remove the BUNDLE_PATH line and change the BUNDLE_BIN directory to whatever you want (presumably something within your home directory).

I don't want to get in to the rbenv vs RVM debate - they're both good tools and it's an issue that has been done to death. I linked to five articles in the post, and you can find many, many more with a simple Google. My personal motivation for switching was that bundler's overridden 'cd' function includes some commands that fail, which is fine under most circumstances but it breaks as soon as you use 'set -e' in bash. We spoke to the author and he said he said that RVM wouldn't be 'set -e' compatible in the foreseeable future.

That's also a good approach. The moving the bundler binstubs to a central location would work nicely as well, I imagine.

The issue with not using --path is that gems will leak between different projects, so you'll probably run in to trouble when projects depend on different versions of the same gem.

I've also used shell plugins to remedy the bundle exec issue, but they've often caused more problems than they solve. I'd much rather just stick something in my PATH than use shell plugins.

Interesting! Constraining tracking to regions of interest is definitely on our list of things to try.

The black proved slightly harder to track than the yellow and red balls, as it didn't have a particularly distinctive hue. The first step towards tracking the black was filtering out everything except the green surface, which is demonstrated in the video. Unfortunately we ran out of time before getting the black tracked.

Looks like it's back up http://www.meetup.com/Vim-London

GoCardless is a VC-backed London-based startup looking to hire for the following positions:

- Backend engineers

- Front-end developers

- Business development roles

We're building the next generation of online payment tools, and are partnered with one of the world's largest banks.

GoCardless is built using bleeding edge Ruby and Rails, Postgres 9, Coffeescript and Redis. Experience with any of those technologies is a plus, but certainly not required.

More detail here: https://gocardless.com/jobs

As Alex and Justin mentioned, users can pre-authorise a given amount, optionally over a time interval (e.g. up to £100 each month). The merchant can then bill the user within this limit directly via the API.

The result of an evening hack, so not very robust or feature-complete. Only has support for hijacking hacker news sessions so far.

Let Crockford himself explain why 'Yes' is the right answer: http://www.youtube.com/watch?v=hQVTIJBZook#t=30m39s

I'd say it really depends on what you're storing and how you're using it.

Redis is great for situations where you need a very large volume of reads and writes, and have a fairly simple data model. See http://simonwillison.net/static/2010/redis-tutorial/ for more information and some use cases.

MongoDB allows for data to be structured and queried in more complex ways, and touts itself as more of an alternative to an RDBMS than Redis does. If you're looking to use it with Django, check out MongoEngine at http://github.com/hmarr/mongoengine