_jmar777

This is what has me excited, too (although unfortunately we're still looking at a likely 6-8 years before relevant targets will support it too...).

This is truly incredible. I've spent the last 4 years neck deep in live video broadcasting solutions for consumer, commercial, and government use cases, and this just blew my mind.

Yeah, I think the latest and greatest in web standards for solving this problem would probably be using a Service Worker to transparently handle the failure and serve up a fallback... but like you said, that's a JavaScript-based solution.

Surprised by all the vitriol in this thread. Defold looks awesome. Maybe I just haven't tracked King closely enough in the past to have developed the community knee jerk reaction here, but this seems like a cool move.

I don't know if I would consider that a "default assumption", so much as being willing, in the absence of hard empirical data, to put some credibility into the glut of anecdotal evidence.

> they’re getting equal pay for equal equal positions, education, and experience

While those are certainly relevant control factors, I would presume that any conclusions are premature without demonstrating a lack of bias in the actual positions men vs. women are promoted to, relative to their experience and education.

I.e., large disparities in salary by gender for "Software Engineer III" within the same organization are a bit hard to overlook, whereas there are often much fuzzier criteria involved in who has that title in the first place.

Not looking to necessarily refute the article, but the control factors themselves are still rather variable.

A prime example of handjamming inconsequential happenings into a good/bad/ugly blogpost format. If this is what counts as "the ugly", they're doing pretty dang good.

That's an interesting assessment. I've actually been generally impressed with it. Loads fast, seems to be pretty intelligent about caching profile images and the like, and is generally pretty responsive (on a Galaxy S5). It is pretty handsy with the permissions, though.

There was a load error when I first clicked the link, resulting in a blank page. Was thinking "well played, punk".

So far I gather that the expressjs.com domain, the GitHub repo, and the npm module were transferred to StrongLoop's control. I don't believe that Express is actually trademarked (and likely isn't trademarkable at all, being such a common dictionary word).

Some additional info:

Note: I previously posted this to the wrong category and was advised to post here instead.

Stre.am is a free app for broadcasting live video from your phone, with an emphasis on simplicity. We previously launched the iOS version, but as an Android user myself, I'm particularly excited about getting Android out the door now as well.

The app itself is designed to be as self-explanatory as possible, but the general idea is to sign up, hit the green record button, and your video shows up on stre.am with as minimal of a delay as possible.

From a technology perspective, the mobile clients are 100% native, and the backend services use a combination of Node.js+Express (web), Java+Play (api), and Scala+Akka (video transcoding/streaming infrastructure). I'd be happy to answer any questions on that front.

Thanks for reading!

Android: https://play.google.com/store/apps/details?id=com.sparc.stre...

iOS: https://itunes.apple.com/us/app/stre.am/id852662600

Web: stre.am

Thanks, didn't realize when I posted it that urls aren't linkified in submission text.

Thanks - do you think it's best to repost as such?

There are a lot of comments about EC2's pricing competitiveness with dedicated hardware. These are fair discussions and should be had, but I figure it's worth commenting that EC2 (and AWS in general) is about much more than cheap metal.

The company that I am a developer at has aggressively adopted AWS with applications using it at both the PaaS and IaaS levels. At the end of the day what we've received the greatest value from isn't an impressive "cost per compute unit", but rather a flexibility that would be incredibly painful to let go of. For example, our QA team can spin up or tear down entire environments by chatting with our Campfire bot. Our developers can do likewise using a simple CLI we built.

Granted, this isn't exactly bleeding edge stuff here... it's simply "the cloud" (apologies) delivering on the promise of dynamic, elastic environments. But it's a really, really nice promise, and at risk of sounding like an advertisement, I'll still say that AWS/EC2 has delivered quite nicely on it.

This feels somewhat disingenuous. Naturally a site making it's money off of ads is going to give them an above-the-fold and prominent position. Just scroll down... the value add is in the qualify of the organic results (which is still there), not in the absence of scrolling.

If you think the ratio is off, then write an article about it... but this is hardly "killing organic search".

Just a few points:

1) If traffic is low enough, you can fit 100+ different apps on 8GB of RAM, regardless of tech.

2) Hourly backups are better than nothing, but not good enough if you want to make claims of durability and/or high availability.

3) BizSpark is more or less a loophole (they don't always accept), and when they do, you have to hope you go out of business w/in 5 years or never make more than $1M in revenue, or you're out.

4) Snarky comments about what the "cool kids" are doing hardly (in)validates anything.

5) If you enjoy the Microsoft stack and it works for you, then awesome. We're developers and should enjoy what we work on day in and day out.

6) My current projects have me bouncing back and forth between Node.js and .NET on a daily basis. Aside from getting an order of magnitude more enjoyment from developing w/ node, I'll also add that our node servers (plural) have been running for ~2 years for a total cost that isn't even approaching the cost of my Visual Studio license. If that makes me a "cool kid", then I'll rock that sag all the way to the bank (if cool kids are still sagging, that is).

The specification has already reached "draft", so it's usually pretty stable at that point. Firefox has actually included generators for awhile now (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...), but their implementation is based on JavaScript 1.7, rather than ES6. The end implementation was pretty close, but didn't include the function* syntax (I don't believe they implemented yield* either). Regarding timeline, that's obviously hard to guess at from an external perspective, but most browser vendors seem to be comfortable enough with developing against draft-level specs, so hopefully soon.

Sounds like it was a real cluster * * * *.

Woah... digg.

I think his point and yours are both fair enough. At the end of the day though, whether it's $2, £2, or £2k, it's really just a matter of ROI. The latte comparison is somewhat easy: most people like it, and it's (relatively) cheap. The argument at a more fundamental level doesn't extrapolate very well, though - I think it only survives on latte for the aforementioned reasons.

Sounds like a pain, especially if you have locking lug buttons.

From where I stand, the comment two levels up is more relevant to the article than the comment one level up...

So ya, I pretty much have to agree with everything you said. Salts have negligible impact on brute-forcing an individual password, but at least slow down the cracking of an entire database of passwords (as in the arstechnica article). I was definitely too general in my mid-vent statements there...

Regarding bcrypt/scrypt/pbkdf2... amen. Currently every system I maintain uses bcrypt. Prior to the *crypt slow hashes, I used a salt that was a combination of something stored in the db and some in-code transformations, and then pumped through a ludicrous number of sha-512 rounds. The salt generation technique I used was probably cryptographically naive, but the intent was to require both the data AND the code to be compromised for the hacker to have a fighting chance. Anyway, I still have no idea what I'm doing, which is why I [use bcrypt, use bcrypt, use bcrypt](http://codahale.com/how-to-safely-store-a-password/). :)

> Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123"

Agreed.

> All it does it prevent against rainbow table attacks

Salts do prevent rainbow attacks, but they also assist in brute force attacks. The article you reference was over passwords that had simply been MD5 hashed, which is about as computationally significant as doing nothing at all these days . Even in the ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially.

My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt. (Well, my real point was just to vent, but anyway...)

Moderately miffed that the email they sent out notifying how THEY allowed my password to be compromised included a lecture telling ME how to construct a strong password. Not the time, or place.

Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".

Looks really nice. Would be nice to see browser support formally stated somewhere, though.

Sounds like someone really wants us to all sign up for BitStamp.

Completely unsubstantiated theory: someone figured out how to compromise BitStamp user accounts, but not enough users yet...

I don't think @kyrra was suggesting that Dart would compile completely to asm.js code, just parts where it makes sense (just like normal JavaScript uses asm.js only where it makes sense).

Thanks, I agree with your comments. I was mostly just trying to poke the bear, though (http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html) :)

I'm all for simplicity, and, again, this isn't an argument against Dart. But I would still contend that merely shrinking your DOM API surface area is only of marginal significance.

Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions. We've had standardized methods for a long time now that make DOM interactions relatively trivial if you have the luxury of working with browsers that support them.