1,671 karma · joined January 27, 2009
But I think there is one question left unanswered: Why are we assuming this story itself is in fact true? Because it's written on a blog? :)
Copyright on characters, art, text, code, and logos is great. We obviously don't want direct clones. But, Copyright applied to a genre and style of gameplay is ridiculous. We wouldn't have any of the great games we have today if those things were enforceable.
There might also be an opportunity to modify what is served from the customer's sites, depending on how all that is architected.
When I'm writing code I'm boxed into production mode. Get. Shit. Done. But, particularly when the work I am doing is self-directed and self-prioritized (aka my own startup or side project), I need hours away to really think about the big picture.
Activities that are away from the bombardment of input of my computer/phone work best for me. Let my mind wander. Think about different ways to approach problems. I often find there are higher priority things to do than whatever I thought I was going to code up next.
EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.
Publishers/networks are broken. The industry needs something to happen to it like Steam, then Facebook, and finally Apple did to video game publishers. Take the (old) middle men out of the loop. Let content producers "sell" directly to consumers.
Scalability and performance is complicated. Unless you KNOW your product will have a big splash, premature optimization will kill your productivity. And you will get it wrong. You will get the implementation wrong. You will optimize the wrong things and not really understand your bottlenecks. Especially if you've never scaled anything before and haven't been bitten twice by all the compromises you have to make.
Distributed systems are hard. Multi-threading is hard. Sharding is hard. CAP is a bitch. If you can scale vertically, do it. Avoid the demons of distributed work until you require them.
Most of the services/apps we build today would do just fine with setups like Mailinator or gasp ACID-compliant data stores.
Understanding performance and result trade-offs of various sorting algorithms is sometimes useful. But usually not.
Understanding how the nagle algorithm works in TCP is sometimes useful. But usually not.
Understanding how the A* algorithm works is sometimes useful. But usually not.
Understanding how zlib works is sometimes useful. But usually not.
That is the beauty of our field. We can build larger and more complex systems because others have laid the foundation. Actively seek out and learn relevant existing algorithms and libraries when you need them.
All of this stuff may or may not be useful to know. However, it is largely irrelevant when it comes to getting shit done in most bits of software. Sometimes, ignorance is blissfully productive.
What makes you happy? Screw the rest.
There is a "to the metal" mode in ASP.NET/IIS now, mentioned in that article, that lets you use the IOCP thread directly in your applications and avoid that context switch. But, of course, if you do blocking things there it will completely block your web server.
http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thr...
Out of the box the callback model can be difficult to wrap your head around. But if you are serious about writing a vertically scalable IO-bound service, it is currently the only option. There are some add-ons to make the code less ugly, but you still have to have the mental model down.
It's a lot like multi-threaded programming, or functional programming. It's a matter being able to visualize the flow and pass context around. This takes time to change the way you think.
If you approach problems in Node like you'd approach a problem in a functional language the spaghetti of callbacks becomes much less of a burden.
For the async haters out there operating at scale. How many of you have farms of machines with idle CPU's, maxed out memory, and practically idle network interfaces? Yeah, I thought so.
However, the bottom line impact of a false positive on some indie software has to be negligible.
An aptly timed popup from the antivirus vendor will appear shortly thereafter asking the user to pre-purchase 2 more years of complete computer protection! Oh, the business of fear mongering. . .
EDIT: This is one of those very hard problems startups should be solving.
I'd like to try an experiment with a less open online geek news community. Social trust-based. Very hard to get an account that can write comments. Must be invited or voted to have that privilege. Very easy to get perma-banned. Though, to avoid appearing as Skull and Bones or some other private club, all comments would still be public. Even as a lurker, the insightful comments are often the most valuable thing on a site like this.
There are successful examples of these communities as simply forums in other fields like video game programming, cars, medicine. I'm a member of one for video game developers and one for car computer tuning. There ought to be a good way to apply it to peer-voted news.