alexjeffrey

I read this post as less "don't reinvent the wheel", more "if you're building a car, don't build your own wheel when you could buy one from a wheel manufacturer" - maybe if you did it yourself you could make improvements, but it's far more likely that a company where the problem you're trying to solve is their bread and butter will provide a better solution.

I'd hardly equate lack of abundant electric car chargers with poor infrastructure. The example I was thinking of is the UK where I live, where electric cars aren't as common as in SF or the east coast.

note, I didn't downvote your comment.

I'd love to see this technology being incorporated into Tesla's batteries. With super-fast and long lasting charges their cars might become viable in countries where charging stations are either incredibly rare or nonexistent.

Javascript is getting better with at least the latter thanks to typed arrays - https://developer.mozilla.org/en-US/docs/JavaScript/Typed_ar...

it's mentioned in the post that the author reported the facts a number of times.

I completely agree that the current spike will be largely speculative, driven most likely by Reddit and Mega accepting bitcoins now (a PR ploy no doubt).

However, the inherent cap on the quantity of coins available means that if a market fit is found for bitcoin, and that market grows, the only way is up.

not for bitcoin.

assuming this is even a peak - the economics of bitcoin are ideal for the price to just keep on rising. That's probably what the seller here's banking on - that the 6-figure dollar-equivalent bitcoins he now holds will be worth 8 figures in a few years.

In the words of Churchill: it has been said that democracy is the worst form of government except all those other forms that have been tried.

Relevant Bruce Schneier: http://www.schneier.com/blog/archives/2008/04/sql_injection_...

if the idea of the chess captcha is to be used once on a single site, (ignoring the fact that it's a chess captcha for a chess community) it's very over engineered. Jeff Atwood gets away with a captcha where all you have to do is type "orange" to post a comment[1] and even that manages to mitigate a lot of spam.

http://www.codinghorror.com/blog/2008/03/captcha-is-dead-lon...

by this argument, the captcha would become useless as soon as it saw widespread adoption. The idea of a captcha is to be strong against bots even if it was directly targeted by spammers.

I think you may have missed the main point of this article. As an example, I can code to a reasonable standard in Ruby, C and PHP but I mainly work in PHP because if time or budget is low I can speed up development by writing horrible procedural code or other hack-jobs. I'd love to build MVC applications with well-structured architecture all day but many clients just won't pay for backend nicety. From an engineering perspective this is a horrible trade off but from a business point of view it's just what needs to be done sometimes, and I don't believe any other platform offers this.

PHP generally allows developers to just get up and go, both in terms of installing it on a server and building an application, and requires minimal learning. Unfortunately that does mean you end up with a large number of substandard developers, but at least they're getting things done.

EDIT: it's also perfectly possible to clean PHP up using e.g. autoloaders and the builtin interfaces and spl classes, if you want to work cleanly - this capability seems wholly underused outside of frameworks and I hope it gains more attention soon.

"best" is a very subjective term. PHP is not the best language for making in-house web app stacks like many people on HN build, but it is the best language to deploy a basic marketing web page for the chip shop down the road. That's the point I believe this article is trying to make, and basically just boils down to "the right tool for the right job".

Of course, and these are problems I will be working to solve very early on. The kind of users I'm aiming for should be rightly concerned about the security of their passwords and I will be providing as many mechanisms as possible, both socially and technologically, to prove said security in a transparent way.

OK you caught me - I don't have any relevant examples :)

that's a crying shame - the world needs a secure-by-default and easy-to-use crypto library. Someday...

that's true, but it's the highest-profile encryption drama I could think of - a more appropriate example would probably be the onslaught of companies which are storing passwords in plaintext or simple MD5 hashes.

In what way is NaCL difficult to integrate into existing dev environments? I've not personally used it before, but I've been looking for a library that abstracts away some of the difficulty of cryptography (granted you can't hide it all) and NaCL appears to label itself as such.

If it works as suggested, this library binding will be a godsend to frontline developers. Cryptography is exceedingly hard to get right and unfortunately existing libraries often tend to be written for developers who are already familiar with cryptography. Hopefully this will see the adoption it deserves and we'll see less incidents like the Mega encryption scandal.

I'm working on something like this at the moment, which will be released within the next few months. I can email you when it's ready if you're interested?

the only issue you're likely to run into with this approach is leaky abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...) which will leak at least some implementation detail out of the container. This can be minimised though.

Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.

To append a relevant quote from Einstein "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."

my mistake, I didn't follow the events particularly closely; thanks for the correction.

The only problem here is that because the Javascript is delivered by the server which is supposedly offering privacy from itself, nothing is stopping the developers from simply changing the Javascript and stripping away the encryption through either capturing keys or not applying it in the first place.

see: http://www.matasano.com/articles/javascript-cryptography/

technically your example is incorrect unless the same attribute name is used quite a few times. Regardless, premature optimisation is the root of all evil, especially in places that are highly unlikely to be a bottleneck and even more so when it's used to remove valuable documentation.

this is part of the popular svbtle blog network theme and the obtvse theme copied from it. You'll see this theme used on at least 1/3 of the blogs posted on here, I've always been against the whole "mouseover-as-action" thing too.

arguably, google are well positioned to see where improvements to traffic protocols can be made due to both chrome's large market share and their massive traffic requirements for google search et al.

Later on if/when their protocols are finalised and released, I'm sure one standards body or another will work to integrate them.

I hate to think what would happen if tesla's user database was hacked. Not that that's a reason not to have a REST API of course, I hope to see a lot of car-app innovation come from this!