jephir

There is no indication that ACB contributed to this collapse, rather, this was a faulty design that would have also posed a risk using traditional construction techniques.

[1] https://youtu.be/u3Gj1Nu_kjo?t=5m8s

There is a public ledger for every public move. If you move money within your own organization there is no publicly visible effect.

Why would this be the case? FreeBSD and SVN were developed without copyleft. GPL is not necessary to get people to contribute to open source.

It's important to keep in mind that this is all optimization. Don't lose sight of the big picture.

On one RTS we ended up just serializing world state over a TCP socket. If you can get away with the brute force approach then just do it. Don't optimize until you have a measurable performance problem.

While Firebase is proprietary, you can export your database as JSON and import into RethinkDB.

> Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

https://url.spec.whatwg.org/#goals

Leaving out semicolons actually makes the intent more clear. People run into problems with semicolon insertion when they try to create an unnamed expression, i.e:

    ["joe", "bob", "ann"].forEach(call);

    var employees = ["joe", "bob", "ann"]
    employees.forEach(call)

I think he means doing it on the server, i.e. checking the password as-is, if that doesn't work, then check it with case inverted.

Whenever you have null in a language, for every function you call that returns a reference, you have to check the documentation to see whether or not it will return null. You cannot know from only the function interface whether or not you have to deal with an optional value.

Option types move this checking to the compiler. The function declaration explicitly shows the presence of an optional value. You don't have to read the documentation or investigate the function implementation - the information exists in the function interface itself.

Given, Go tries to deal with this by using the multiple return idiom. By convention, you should only have to deal with null if you have a function with multiple returns. However, I think that compilers, not conventions, should enforce language rules. Leaving it up to conventions opens the window for human error.

> I've never heard of `if ok` being an idiom _as opposed_ to `if !ok`.

This comes from Effective Go: https://golang.org/doc/effective_go.html#maps

They explicitly call it the “comma ok” idiom.

1. It uses null (the billion-dollar mistake) to indicate optional values. A better designed language uses an option type.

2. It has conflicting idioms for conditions. Error types use the `if err != nil` idiom while map access uses the `if ok` idiom. This means that you read the main execution path downwards and the error path to the right, unless you access a map, then the execution path goes to the right and the error path goes downwards.

3. The `:=` operator declares new variables, unless you use it to declare multiple variables where one already exists in the same scope. As a result, you don't know if you have actually declared a new variable using `:=` unless you read upwards to see if a declaration for the same variable name already exists.

It does too many things. I want to use WebRTC data channels for a multiplayer game, but the current implementation libraries tie-in all the media components. It would be nice if there was a WebRTC implementation that provided data channels without having the media functionality.

I agree, predicting remote objects causes more problems than it solves. Any remote player input that affects the object causes noticeable position popping when the local client receives the update.

The Source engine has a better solution - instead of trying to predict remote objects, delay rendering by 100ms and interpolate the received updates. This makes the position updates appear smooth without any stuttering. However, now the client lags 100ms behind the server.

The server has to "undo" this lag when the player wants to execute a request (like shooting). It does this by rewinding the world state by 100ms + client ping when executing the request. This makes it so that a client's actions appear to execute without any lag on their view (i.e. they don't have to shoot ahead of their target).

This causes some temporal anomalies, for example, players can shoot you around corners because they see your position 100ms in the past. However, most players seem to prefer this over having to constantly shoot ahead of their targets to compensate for prediction errors.

Ericsson's implementation, on the other hand, has a much simpler build process. Just run the shell script and it works.

http://gafferongames.com/networking-for-game-programmers/flo...

[1] http://asmjs.org/faq.html