csdigi's comments

It depends on how they got their income in the first place. My family are dairy farmers and frequently trade cattle at local auctions. This is still a cash based society (rural Ireland), it does not take many heads of cattle to make up 10k, many other deals are done informally (e.g. my grandfather buying cows from a neighbor without auction) with a value that is of that order. The money may hit a bank account if something more formal needs to be bought (insurance, new machinery etc) but those are not all that common.

As a child I would always remember my grandfather carrying (at least in the house) large rolls of bills.

Importantly though the UK does not need to apply those rules and standards to domestic trade (which is over 90% of it).

I am not an author, but was around when we decided to create Please in 2015.

When we created Please we were currently using Buck from Facebook. As has been covered elsewhere at the time it had some limitations which meant that it was getting more and more expensive to workaround (no multiple outs from rules so doing things like sourcemaps was hard etc). We had previously migrated from a set of disparate build tools (Gradle, Gulp etc) to Buck after evaluating it against Pants (we actually trialled our repo with both).

We all had experience with Blaze (Bazel did not exist in 2014/2015) and wanted to get closer to the experience we had in Google, hence the final decision to build our own. At the time we rolled it out we had full Buck compatibility (and actually most of our engineers did not notice initially). Once we were happy it worked, we migrated in full to Please.

Overall it allowed us to provide much better tooling for our developers (queries on the build graph for smaller CI/CD footprints, coverage in all languages, and for rules that can output multiple languages (like protocol buffers) we only build variants in the requested languages rather than all languages).

If Bazel had been open-sourced and easy to extend at the time we would certainly have looked to adopt and improve it (as we did with Buck at the time). But by the time they open-sourced it the two system had diverged in their approach and use cases.

I (obviously somewhat biased) think having multiple principled build systems which prioritise the needs of different communities is good for the ecosystem overall (and allows the sharing of good ideas such as the Remote Execution Interface).

I agree, if anything I think the remark looks more like a joke targeted to her young age than her gender in the context of the video.

Try using this url instead: http://angularjs.blogspot.com/ncr

Mark Roth did an interesting TED talk 4 years ago on that very subject.

http://www.youtube.com/watch?v=uVAaZVz9pDs

I travel in Europe a lot, but Google Maps for Android has had the ability to save offline maps for ages now (which I use all the time). GPS also works offline obviously so you can navigate pretty well (still no search for offline though). In the latest version (7.5 I think) you just get the area you want to save in screen, click the search bar and scroll down to the bottom to see the option. I think it works on iOS too but you might need to use the "OK Maps" easter egg.

I use this exact same system, although it sort of hurts to see my old phones get slowly crippled by my girlfriend. She is currently just bringing my old Galaxy Nexus to the end of its life.

The sectioned titled "Inconsistent get interface" compares get() to getattr() which are two unrelated functions. getattr is the same as a property lookup on an object (person.name, person['name']), get() is a method defined by some types which returns a stored value.

In the provided example he calls get on an empty dictionary for the key 1, then calls getattr of 'a' on an int. Finally he calls it again with an optional default argument of None.

The difference is made apparent by the example:

In [13]: test = {'values': 1}

In [14]: getattr(test, 'values') Out[14]: <function values>

In [15]: test.get('values') Out[15]: 1

With Chrome you have to trade memory usage for the process sandboxing of each tab which adds a measurable overhead. But I think for the general population it is a trade worth making.

Backbone like spine has moved to support the "asynchronous UI" in its models by default. The general philosophy is that all storage should seem local, and the interface should wait as little as possible with data being synced in the background (given the appearance of success to the user). However this is not always possible, and needs to be worked around, as some people have covered (validation for uniqueness in a DB). But it was generally accepted as a sensible default stance. To read about it from the Spine author checkout his blog and presentation.

http://alexmaccaw.com/posts/async_ui http://www.infoq.com/presentations/Asynchronous-UI