jb55

Another Vancouver sw eng here. Only got here 3 years ago. Have to rent, impossible to buy unless I move outside the core. Then why bother living here if I have to live in Surrey? Unhappy with the fact I have to raise my first kid in a 500sqft apartment. Not sure what I'm going to do if I have another. Hoping the market crashes so I can keep living here...

So basically xmonad + with a tagged file indexer. Although fzf + https://github.com/rupa/z works for me most of the time.

With respect to eye tracking, I had a similar idea the other day. Imagine holding a key, then moving your gaze to see an on-screen target following where you're looking at. You could use this as a really quick way to scroll or highlight/copy text without leaving your home row.

I really don't like leaving my home row.

I may be crazy.

It would be a stretch to call express a framework. It's just a collection of connect middleware and a few helpers.

Recently on the voices of vr podcast, Dr. Thomas Furness mentioned that he also tried it, and it was based off his (Human Interface Technology Lab)'s virtual retinal display technology/patent. I'm guessing this is what you're referring to?

I had a decent experience with it. We got $24k for using Haskell for a project. All I had to do was a couple writeups here and there explaining why Haskell was a technical uncertainty for the given task. SR&ED funds Haskell dev!

Take a look at http://www.thoriumenergyalliance.com/downloads/plutonium-238... for how it could be done

If anyone wants to jump into this, Josh Tenenbaum and Noah Goodman put together this amazing interactive book for learning probabilistic programming with Church: https://probmods.org/

I don't think we need another build system, what we really want is a package manager that knows how to fetch and build dependencies and gets out of your way. This is why people like npm. This is why nix is awesome.

Yup, it works in conjunction with other build tools. nix knows how to build make projects, cmake projects, cabal, etc. This is what allows you to depend on pretty much anything. Then I just use nix-build and it will build all the dependencies in a virtual environment and symlink the result when its finished.

nix is starting to replace all my build tools, building c code is as easy as putting together a small nix file like this: https://github.com/jb55/polyadvent/blob/master/default.nix

The nixpkgs community is then responsible for making sure that the build compiles on all platforms. It's not just for C code either, nix files can be used to declare any kind of dependency. It's a full blown declarative, functional, domain specific programming language for packages. So your project can depend on haskell or python code and everything just works.

There's a heavy linux focus right now but there's a whole group of people making the packages work nicely on osx and cygwin. Check it out: http://nixos.org/nix/

Recent versions of Amethyst https://github.com/ianyh/Amethyst have made a pretty much xmonad-like experience on osx. There are a few quirks but I don't see me going back at this point.

I think if someone can hack my wallet from a public key we have bigger problems

I have a single, permanent Bitcoin address (1jb55g498MEa274Z1YWUXQFxZE5NzvhV7). I don't pretend Bitcoin is anonymous and I always set my change address to go back to the inputs.

I understand the risks of how the address inputs and outputs as probabilistically tied to my identity. If I cared about those things I probably use stealth addresses and dark wallet or something.

We have been using redo for the longest time until parallel builds broke on Mavericks. The project basically has 0 maintainers so we had to switch off of it. It's a shame because redo was pretty great while it worked.

Note that this is just a generator yielding callback functions/promises. You need an interpreter such as co to actually run them.

They are the two most common node abstractions. You can get by without them but it's pretty important to know about them.

Streams are the more important one. Once you embrace streams in your applications a lot of things become easier. For example here's a small script I wrote at work to process some csvs and do stuff with them

https://gist.github.com/jb55/0ea6aba86e269f1e526b

Needless to say before I knew about streams that program was twice as large and twice as buggy. Also check out substack's stream handbook to learn more, they are really handy.

Use dig:

$ dig txt jamiehankins.co.uk

https://gist.github.com/440ef567e4bcc8f7ce34

He did a tech talk awhile back that goes into a bit more detail:

https://www.youtube.com/watch?v=HQmFEt6l6Tw

In fighting games people are very sensitive to latency when you get to a high enough level. There is an interesting networking library called GGPO http://en.wikipedia.org/wiki/GGPO that cancels lag out using a clever algorithm. I imagine you could apply a similar technique to other problems.

Weird I also made a small dot-lens javascript library to do the same thing just the other day...

https://github.com/jb55/dot-lens

It even works for zooming into arrays

We've come to the same conclusion with coffeescript but for a different reason. We're starting to move away from it to simplify our build process.

We have tons of little modules that are all in coffeescript that need to be compiled to js before we run component-build. Just not having to deal with that step would simplify everything. We're starting to value simplicity over fancy things at scale.

Kind of made me appreciate the thesis of Go a bit more now. I was initially unimpressed with the lack of language features in Go. Once you get to a larger sized codebase you start caring less about fancy features and more about agility and build times funny enough.

It's genetic. It has a very unpleasent soap-like taste. Even if there's a little bit it tastes like someone put a bar of soap in your meal.

I am one of those people. The worst part of eating out at restaurants is finding out at the last moment that they put cilantro on everything, making it inedible. It might as well be called tryratpoison.com.

The site is not as unpleasant as cilantro so I will overlook it for now.

I'm still using backbone.js within our app but a lot of people seem to be using things like:

* https://github.com/component/view for views built on top of reactive for declarative bindings

* https://github.com/component/model for models

* https://github.com/component/router for routing

So what we have so far from these 3 libraries is basically a decomposed backbone with declarative bindings. That will cover 99% of your typical app. I don't find there is too much boilerplate.

It's unfortunate that people still think they need monolithic libraries to get anything done on the client side. The node ecosystem showed this doesn't have to be the case. It becomes even more important on the client side to keep dependencies small.

My favourite ecosystem for client side development these days is component (https://github.com/component/component). It's similar in style to npm but faster and made for building apps from small modular pieces. It has a growing community and lots of modules already (https://github.com/component/component/wiki/Components).

As long as your nested types have implemented or derived the ToJSON typeclass, nested structures will serialize just fine

I've always viewed OO as a nice optional UI for most programmers. Given an object to mutate and call methods on seems to click for most people. I tend to go for a more functional style internally for the composibility and maintainability properties you gain.

For a high level overview of your branches I still think http://stackoverflow.com/questions/1057564/pretty-git-branch... is the best git log

My only problem with subtree merging is I have to look up how to do it everytime

I instantly uninstalled it after I saw that as well. Shame, I liked feedly the most out of the alternatives.