pixie_

Is this for real? Seriously this is the definition sensationalism.

It begs the question why can't the operator watch a computer that does the operator's job for him. Is split second power allocation really done better by a human? Note I'm not suggesting computers are perfect operators, just less error prone.

Incredible companies are run by management teams, run by founders. Jobs, Gates, Musk, Bezos, etc..

True, I wish I could take Objective-C's handling on null and put it into C# or Java.

Is it better for you, or for your user? Are you building a game, a social app, or space shuttle software? These questions should guide your decision in language requirements.

I wish more languages treated null like objective-c. Where if a method is called on a null object, nothing happens and the method returns null. In user land a 'null bug' in objective-c often results in a feature not responding, as opposed to the entire app crashing. It's a much better user experience, and I can write code less paranoid about null values as well.

The car doesn't need to blow up if the air conditioning isn't working.

Cool thanks. Makes me think of my own video voice overs.. equally horrible..

Interesting, I thought it sounded computer generated. Do you know if it was?

Nice work. What did you use for the voice over in your demo video?

WPF does take time to wrap your head around because it's more complicated, and in a lot of cases writing business apps (which most straight windows apps are) there is no need for all the 'power' WPF provides. WinForms is easy to develop using just the GUI designer. WPF you often need to mix your development between the form designiner and the XAML code itself. It's a needless headache. Also WinForms GUI designer translated the design into straight C#. The WPF->XAML->C# conversion isn't readily accessible, or editable by the programmer and is the source of a lot of complexity and confusion. Often typos in XAML can bring a whole application crashing down with not much of a clue to the source of the bug. /rant

Is it really though?

I really don't like the excuse laden and sugar coated style of this postmortem.

If you're writing abstractions to avoid bad language features, maybe you shouldn't be using bad language features in the first place.

I understand 'this', that's why I avoid it. All languages have their quirks, and some programmers like to think they're 'smart' by taking advantage of those quirks. Then when you or your team members run into problems you blame the person and not the language, which you're right, but maybe you should of just kept your code simple in the first place.

You really don't see anything wrong with making money a top priority? Forgoing all other responsibilities. Do you believe a company should be responsible for more than just profits?

They need to figure out a way to persist these games. Either sell them off, or open source them or something. It makes me rage when companies lock in users to a game and shutdown the servers.

These people are really interesting. Going to read more about them, thanks!

object.bind doesn't look very clean compared to using self.

Of course there are exceptions to the rule, but the rule should still be - avoid 'this.'

Better a little dangerous 'self' than a lot of dangerous 'this.'

var self = this; why do people bother with 'this'?

Can you find anything that says fire was a necessity for survival for paleo-eskimo cultures because I remember reading it wasn't, but I'm having trouble googling a source for or against it.

What's amazing to me is Eskimos lived without fire.

This is pretty interesting, I'd like to hear more about it. I'd also like Amazon to hear more about it because maybe they could treat web buckets differently or something.

I use Knockout, but whatever MVVMs are awesome.

'Single page web app' makes me think of hash tag routing. I think Static+API or S+API (whatever) is like a typical web site with multiple pages. Whats unique is the layout and content are requested separately.

yea all API calls are POSTs, the API server allows the static server to request.

That's really awesome. Lately I've been a fan of a Static+API architecture where the site content is served static and dynamic content is loaded through an API call to api.mysite.com and bound using an MVVM. With caching set, static content is never re-requested and API calls are immediately made when a user loads a page. My server can be a simple event io platform like node, and can handle more requests because it's not building dynamic pages, just directly getting data from the db or memcache to serve back json. Unit testing is simplified because my tests are all integration tests against the same API my webpages use. I can write test scripts to create new users, login, run features and verify the JSON results. Basically use my site from the commandline if I want to, or provide 3rd party api support with no extra effort. I'm not a fan of rest urls mixing data with content requests so I use query params to specify the data to request in the api call. Like homework.com/assignment?id=324324 - when the page loads (immediately from cache) the javascript reads the id and makes the API call to get the content. Anyone else using this kind of design?

I think it's pedantic to confuse 'americans' with everyone from north/south america.

Don't be evil!