jesstaa

I wouldn't. It's like teaching someone to cook by starting with teaching them chemistry.

Racism is by definition a belief. Someone is racist if they believe in such a belief. Actions are actually irrelevant to this definition.

Similarly a fascist is someone that believes in the fascism ideology. That's just how these words work.

Expecting anyone to do 15hrs of useful work for a startup in a day is just foolish. There is lots of data to show that most of that 15hrs is just going to be a damaging waste of time. I would never invest in someone that naive.

The talk addresses this. The whole point of Reactjs is that updating the whole UI isn't very expensive so you don't have to worry about doing fine grained data change tracking (which is harder to optimise due it not scaling well as data sizes increase)

Performance characteristics are that this increases expsense with the size of your data where as just re-rendering increases expense with the size of your UI. It's actually much more common to have lots of data but only render a small amount of it, so re-rendering is generally cheaper.

The size and complexity of UIs have a natural limit because of screen size and usability, but the amount of data you use to generate a UI has essentially no natural upper limit.

Pete Hunt gave a talk on exactly this almost two years ago. https://www.youtube.com/watch?v=-DX3vJiqxm4

This is often very had to track. The solution is income tax breaks for the poor. Australia did this with our carbon pricing. The tax free threshold(income below which you're not taxed on) was raised a significantly to compensate the poor without having to track their actual usage.

9. Monkey patching instead of good design 10. Don't worry about data integrity

If it's actually a REST API then it's going to take multiple queries. Certainly you can put an non REST API in front of it to reduce the queries. Every site does it and every site does it in a different way. GraphQL is built to solve this exact problem in a standard way.

Interactively querying REST APIS is a massive pain, doing anything useful requires multiple dependent queries, postman doesn't really help with that. Being able to query a graph interactively is actually useful, I've used graphiql to explore the data graph to figure out the query I need for the data requirements of a component before I start writing the actual component itself.

Urban highways solve a political problem. When you have voters that spend a hour or so a day stuck in traffic it's really easy to sell them the idea that a highway will reduce traffic congestion without them having to change anything about their daily routine (ie. take public transport, bicycle, walk)

Since the highway will only reduce traffic congestion for a short time it's something you can sell to the voters again at the next election.

React and Redux are a great stack for making solitaire

You still need an index of your mail for searches and extra metadata for tags, threading, unread status etc. So you need a protocol for requesting this search and a format what how the client can use the result of that search to access the matching emails.

You need to be able to push email status changes out to connected devices, I don't want an alert for an email on phone if I've already read it on my laptop.

You need decisions around how attachments are stored. Most of the time you'll want to store the attachments separately from the text content of the email so clients don't have to download the attachments to access the text, so you'll need to decide on how this location would be communicated to a client.

Plain files are rather bad for multi-user access, if you have multiple users/devices all accessing the same email they're going to need some protocol for synchronization so you don't get data corruption or lost changes.

Reporting an increase of a percentage of risk is horribly misleading.

That's an optimisation. It's not core to the React model. If DOM mutation was ever to be faster than the cost of the diffing then they'd just remove the diffing and your applications would still work the same with the same API.

If financial institutions can commit complex theft on a massive scale without prosecution then the economy will fail. What value does money have if theft occurs on that scale regularly? Why invest in industry when it's more profitable to invest in theft?

Also, Ruby on Rails is Flux.

It's important to note that a lot of C programmers don't really understand the C declaration syntax anyway. Most are familiar with the simple cases, very few are familiar with how to declare complex types.

I can barely read this: void (signal(int, void (fp)(int)))(int);

I can read this easily: func signal(int, func(int)) func(int)

Containers, like virtual machines before them, aren't the future of computing. They're how we manage legacy apps.

The future of computing is not this horrible kludge.

The most interesting thing I've seen in this space recently is http://peaker.github.io/lamdu/.

Most people don't know their natural language as well as they'd need to know it to accurately and unambiguously describe things. The only reason natural languages are even useable is because the human interpreting them has a huge amount of context to infer the meaning from and do error correction with.

The reason programming languages exist is to simplify the language used to describe things so they can be interpreted without too much additional context and unambiguously.

The pipelining talk gives some good examples of where most the the instruction level parallelism comes from. http://millcomputing.com/docs/pipelining/

Most of the rest of the CPU design is really just to enable this.

It's 1,2,3,4,5,6 in the default format of the posix 'date' command.

so you're just manually doing with a linker is supposed to do for you? I guess it goes along with manually doing what a scheduler does for you.

It's not an alias, it's a new type. eg. http://play.golang.org/p/bXgryxNT0H

"A possible exception can be made for things like int, but even then I prefer defining type aliases for things as much as possible, so the type system is as helpful as possible."

It's important to note that Go doesn't allow you to define type aliases. Embedding is the closest you get.

This is faster because it's doing a linear search. Linear search is really fast when 'n' is small. But it's horribly slow when 'n' is large. But since the http route matching is never going to come up at all in your profiling unless 'n' is large it's better to have a router that handles large values of 'n'.

The format that git stores it's data in is great, the tool most commonly used to access that data is a bit of a mess. So there's no reason not to use git with a different UI and there are a lot of UIs for git.

You can make an io.Reader interface in any language. Interfaces don't really shine until you start composing them.

Say you have a type that implements the io.Reader, io.Writer, io.Closer and io.Seeker interfaces, eg. an os.File. This type would also automatically implement io.ReadCloser, io.WriteCloser, io.ReadWriter and io.ReadWriteCloser, io.ReadSeeker, io.ReadWriteSeeker, io.ReadWriteSeekerCloser, io.WriteSeeker, io.SeekCloser etc.

http://golang.org/pkg/runtime/pprof/#Profile Provides a "blocking profile" that tells you what things blocked and for how long they blocked for. You can use it to find places where you've deadlocked as well as places where adding buffered channels might help performance.

Most concurrent C programs of a reasonable size eventually have some kind of big global lock. The linux kernel had one for a long time and it took a lot of effort to add more fine grained locking. Similarly most large C programs have a garbage collector of some kind.