chrisfarms

That game got a lot more fun when I found out the number keys work ... it's like playing a hexadecimal piano!

Is "ACH" basically the same as what we call "Direct Debit" in the UK?

If so I'd also love stripe support for Direct Debit ... like GoCardless[1]

[1] https://gocardless.com/

    "Between now and 2038, there’s a 99.7% chance of a
    6.7-or-larger earthquake striking somewhere in 
    California"

I can't see that date without thinking a 32bit timestamp prevented them from calculating over a larger range. :)

The step by step expansion are really great, and I'm sure this will help many.

I think I prefer the learning by doing approach like talentbuddy[1] personally.

[1] http://www.talentbuddy.co/

Would I be correct in saying this is kind of like Docker?

I mean, I know it's not a "container" system exactly... but it seems almost like a platform for encouraging developers to containerize/package their web apps and maybe help distribute (sell?) them.... and also to allow end-users to have increased control over their apps.

Looks like it's going to suffer from the classic marketplace problem. I like the idea, but I'm not sure the benefits from the developer/business side are strong enough.

This is where you want 2FA really.

Each time the user logs in from a new "client" ask for a 2FA code from something like their phone.

Things like Authy and Google Authenticator make this relatively painless to implement.

Can't remember which talk it was from but I remember enjoying Joe Armstrong speaking about the importance of a language being "correct" rather than fast:

    The performance problem is solved. You just wait 20 years.

Detecting the location of the client by IP is not going to be very reliable, it's a false sense of security at best. You want to make it impossible to hijack, not detect it when it's too late!

Even tieing a session to a single source IP is not great (think stealing sessions in a coffee shop behind NAT).

Use HTTPS.

Sign requests with a MAC (message authentication code).

Make sure your tokens expire fairly quickly and you have a method to refresh them.

This is the "Tab ID". It is not sent over the network as I understand and is only available from the local js context. It's the result of a bit of hackery Chrome does to map requests to the webview.

EDIT: Found the bug report... https://code.google.com/p/chromium/issues/detail?id=355541

Let just all agree that Nix is the way forward and start migrating every linux distro, language repository and app to Nix expressions.

sigh I can dream.

Finally someone really tackling the big issues of today.

With the help of the state, maybe we can stop headphones from falling out of our ears and put a stop to unopenable plastic packaging!

~~

This seems pretty unenforceable, and Micro-USB seems to be taking over anyway.

That page chomps away at a good 15-18% of one of my cores ... what the hell is it doing?!

sqitch is the only approach to version controlled migrations I've found that actually works long term. I wish more people would invest time into learning it so that it would become more commonplace.

    > fn = function(){ var key = "shhhhh" }
    > fn.toString()
    'function (){ var key = "shhhhh" }'

Nothing is sacred in JS.

At least in ties in with the brand. The website actually reminds me of the inside of the shop :)

Hehe, you've got to fix it working on that page! ... everyone is going to press that button.

As soon as my file is readable by javascript it could be sent anywhere by your code. I'm not saying you do, but it could. Therefore this adds an unnecessary risk. I would have to disconnect my machine from the network and clear all the browser storage before reconnecting to even begin to think this was safe.

Just to be clear: I'm not saying it's useless, just that if the file I was encrypting was so important that I needed to encrypt it, doing it in a sandbox that is directly connected to an untrusted third-party wouldn't be a very bright move.

Should this technique technically work for the failure of two motors too (assuming the remaining motors are opposite)? Or would it be impossible to build up the inertia for a stable spin? If motors could rotate, could it even fly on one? ... so many questions, maybe I should just build one.

I find there is often a need for a relative inverse relationship between screen width and the size of an element.

The most obvious of which is buttons. As screen width decreases the probability of the user being on a touch device increases, and you tend to want relatively larger fat-finger-friendly buttons at smaller screen sizes.

I guess calc() with rem sizing could work well here. But calc() always feels like cheating to me.

Dear Busy Person,

I know you get so many emails that it takes you a while to reply, so I thought I'd help you out by sending you more emails.

Regards.

Rebump.

------

Jest aside, nagging does work, so this technique probably would too, but I can imagine if someone started using it on me, it'd just filter the messages to the bin.

The product does look very well executed. Best of luck.

Thanks. I'd totally missed that.

Take it this is Rhino under the hood somewhere, or has someone written a new js engine?

You are of course quite right. It wasn't a ban in any legal sense. Though I do think it highlights that the method is already frowned upon... and as and when the public becomes more aware of the fact they are walking around broadcasting their location there will be more pressure to restrict the collection of the data.

That said. CCTV does not appear to be going anywhere, and there is very little difference between processing video footage to track people and tracking a MAC address. The only difference in this particular case is that 'sharing' of the data between retailers is touted as a feature (which of course it is).

Or rename "Airplane mode" to "Shopping mode"

Risky. MAC address tracking is definitely a legal 'grey area' at the moment. I can imagine mining/fingerprinting in this way could easily become illegal in the not-to-distant future.

In the UK, City of London already banned the wifi-enabled bins that were tracking MAC addresses.

It would be really easy to tie a name to MAC address (from point of purchase with a credit card), then see exactly where that person went via the 'sharing' of data with other retailers. This is certainly something you would expect to need 'opt in' to.

Just had a quick port of his example to Go.

https://bitbucket.org/pkg/passwd/src/27f970fbcc05c0c6c258600...

Anyone fancy taking a look to see if I understood correctly?

EDIT: Specifically, should the PBKDF2 "key", not be used for something (like HMAC) rather than being used as the hash itself?

I'd also add that SPA[1]/client-side applications are also an important consumer of databases with decent JSON support.

The "backend" for these types of applications are often relatively thin API wrappers around a database, with the bulk of application logic on the client-side.

Postgres' JSON improvements over the last couple of years have made it a pretty good choice already for these sorts of things, but the JSON indexing improving would make this a no-brainer.

[1] http://en.wikipedia.org/wiki/Single-page_application

Free quota limitations are listed here:

https://developers.google.com/appengine/docs/quotas

I thought they had really stepped up the interactivity.

EDIT: --snip--

I certainly wasn't saying the feature should not exist because it's hard.... merely, do it right or not at all.

The culture on the Postgres development side has always taken a very conservative approach, which carries with it much trust that the features that exist work very well.

Introducing a half-baked feature would break this trust. And so I would rather wait.