poutine

This is not arbitrary at all and has definition by industry standards. Passwords are used by people. Keys by machines. This requires different security policies. Passwords will have complexity rules and shorter expiration policies such as 90 days. Keys should have rollover policies around a year or so.

As an API and security professional I've found to be secure and performant one should do the following with APIs:

- Dont listen on HTTP, force HTTPS (Tune your ciphers! see https://www.ssllabs.com/ssltest/index.html)

- Ensure that any client libraries you supply for API interaction must verify the server certificate

- Only use the users password to obtain a long random key from the server either through an admin web interface where possible or by an API request that supplies the username and password and receives the key.

- Make authenticated requests of the API with the key

- Store any passwords as bcrypt hash in the DB for security

- Only store the key as SHA2-256 hash in your DB for performance

- Actually yes do use HTTP Basic as it's a convenient way to transmit the key (see how Stripe does it) making things easy for your users and perfectly secure as long as you prohibit plain HTTP.

- Stay the heck away from HMAC's and signing requests, you have SSL, properly tuned it's secure. HMAC is pointless here and really confuses the users.

This isn't a problem specifically with HTTP basic which at the end of the day is just a HTTP request header with an encoded string.

If you're using basic auth and a long random server generated key as Stripe does instead of a user supplied pasword performance is a non issue as you'd SHA2 it in your DB not bcrypt.

You also hash the two differently in your database. With passwords you want to bcrypt (or similar) them to protect against exposure of the DB and an attacker brute forcing the hashes. Since this is virtually impossible for long random strings you're able to just SHA2-256 the keys for DB storage. This becomes important because you're likely checking the key every API request and bcrypt would be a significant API rate limiter.

Seems a bit of a bother to use chopsticks and the fishing line contraption. Since it's to test what the user experience is just get another person to watch the users gestures and click or touch the computer that's powering the display to translate those gestures in to pre defined actions. Would let you test all sorts of crazy things.

Thank you. We're considering a self installed version but it'd be a large enterprise type install and further in the future.

You can see pricing here once you login: https://admin.telemetryapp.com/account/plan

We're going to put pricing on the public site too. We plan to stick around of course, the major advantage for us is that this project has almost no burn rate and is a critical component already of another one of our projects. So it's not going anywhere.

Yep, I need to make that demo board more dynamic. The technology is such that we can easily update once per second, perhaps even more frequently with some animation changes. Server sent events makes things easy.

Oops, forgot to include the link to our OSX desktop app as per the parents request, you can get it at: https://itunes.apple.com/ca/app/telemetry/id571033468?mt=12

Telemetry is just in the process of getting going. The capabilities you talk about are coming within the next couple weeks to Telemetry (I'm one of the two lone programmers behind Telemetry). Right now the app is uber geeky but we've made a killer real time HTML5 and native visualization engine with real time push. We're working on making things less geeky as we go but we currently have a native OSX app. Our iPad/iPhone app is coming in a couple weeks.

It's on their Twitter account too.

Exactly. Penn and Teller did a bit on it too: http://www.youtube.com/watch?v=2bwGsOBTlhE

So fucking what, indeed.

Agreed. Not defending pci. Nevertheless some qsa is going to get their panties in a twist if their scanning tool goes red.

BEAST causes PCI scan failures from the major scanning vendors. Therefore it's a significant practical issue for any site taking credit cards.

Try the https://www.ssllabs.com/ssltest/index.html scan and you'll see what it thinks of your SSL setup. With BEAST vulnerability you get non compliance.

I've been using the beta to navigate around Vancouver for a month or so and it works quite well. Turn by turn with voice commands through bluetooth to my car is great. The Yelp integration is pretty useful too. Big thing that's missing is the street view, but not something I've used much in the past.

Regardless of how it stands compared to standalone GPS units and Android it's a big improvement over the previous maps app.

Safari in 10.8 works in a similar way as Chrome does with the address bar. Indeed it seems to be faster too, I'm toying with switching from Chrome. We shall see.

737's don't go that fast at sea level. Air is too dense. An f4 could probably go 2-3x as fast as a 737 at any altitude. I'm too lazy to look up the specific values.

As to why they used an f4? Probably a heck of a lot cheaper than a 737 at the time.

Sometimes the government isn't out to screw you you know...

I listened. Kinetic energy is the mass times the square of the velocity. F4's go way faster than 737's. Thus kinetic energy is comprable between the two.

On the second point: http://en.wikipedia.org/wiki/Containment_building

"The containment building itself is typically an airtight steel structure enclosing the reactor normally sealed off from the outside atmosphere. The steel is either free-standing or attached to the concrete missile shield. In the United States, the design and thickness of the containment and the missile shield are governed by federal regulations (10 CFR 50.55a), and must be strong enough to withstand the impact of a fully loaded passenger airliner without rupture.[3][not in citation given]"

It's also not my nuclear reactor. My power comes from hydroelectric thank you very much.

"Probably not much" to answer your real question:

http://www.youtube.com/watch?v=--_RGM4Abv8

The US government has done the test, granted an F4 isn't a passenger jet but it probably has similar kinetic energy to a smaller passenger plane as it was going rather fast.

Heh, welcome to the learning curve :)

Yeah, it can be ugly, but once you know what's going on it all reads pretty quickly.

- No Interface builder. Really a big loss given the power of Storyboards/segues, layout of objects, complex flows.

- No syntax/error checking as you type

- No static analyzer

- No code completion (perhaps you could find a 3rd party module to do this eventually)

- No refactoring support (very important in larger projects)

- Probably longer compilations (in Xcode/ObjC the compiler will know which files are modified by looking at the included headers and only recompile what is needed, in Ruby I would expect it's gotta do them all but could be wrong).

Because I wanted to? It's the Internet.

- Objective-C is Hard to Use

It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages.

- Xcode is Unstable

It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolving.

- Xcode Hides Important Information

It has a learning curve. Some things take time to learn but once you do you're more productive.

- Objective-C Is Tedious

Matter of opinion. One person's tedium is another being explicit and reaping the benefits during refactoring, code completion and compilation speed.

- RubyMotion is Easy to Use

For sure easier than Objective-C. But so what? Can it build complex apps more quickly than Objective-C when someone becomes proficient? Probably not.

- RubyMotion is Ruby

That's great. Ruby is a great, easy to use and powerful language. I love Ruby. However given all the other things you sacrifice to get Ruby it's really not worth it.

- RubyMotion Makes Debugging Easy

Really? It sure doesn't look like it does. Xcode and LLVM save me a hell of a lot of time writing my apps because I don't need to actually run them and see the exceptions. And what about the static analyzer?

- RubyMotion Isn’t Perfect

Indeed.

- Better Than Objective-C

For trivial apps yes. For apps you'll be paid to write, in my opinion probably not.

Not case closed. Given that you lose a lot of useful tools (Interface Builder, Storyboards and such) and that Objective-C can be pretty quick to code with Xcode I would contend that given expertise in both a complex application would take less time to code in Xcode/Objective C.

You need to keep in mind that you don't actually type out the entirety of XCode's methods. For instance:

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

Was about 45 key presses in Xcode. And this is a fairly short method, take something like animating a view with a block and you're looking at way more typing to do it in Ruby Motion.

REPL seems to be a crutch for not having a visual interface builder. His example in the video wouldn't have been an issue in Xcode as you'd have positioned and named the label correctly to begin with, and would have seen it in context too.

As a long time Ruby and Objective C developer who loves both languages I'm not impressed.

Sure the REPL stuff is neat, but I would position my UI elements correctly in interface builder to begin with. I'm also not keen on typing out the code to assign properties that were done with the GUI before. There doesn't seem to be any support for Storyboards which are awesome as segue transitions save a ton of code that you'd normally have to type. Storyboards provide a visual layout and ease of inserting steps in a flow or changing connections.

Once you have proficiency in Objective-C your coding method in XCode really consists of typing 3-4 characters, hitting tab, a couple more characters, a variable name and so forth. Code completion rocks and works quite well in particular with Objective-C. I would expect all of the examples given there would be many fewer keystrokes in Objective-C than Ruby.

I find the side by side code samples somewhat humorous. I expect to see something like coffeescript to javascript which is visually obvious which one is more concise. Instead I see roughly the same code expressed differently. Sure Objective-C turns people off who don't know it, but once you do it's really not a big deal.

Xcode also gives you great tools for refactoring code that due to the nature of Ruby simply are not possible. This is pretty important for large projects.

The tough part of making non-trivial IOS apps is learning the API and the best practices in using it. That can take months or even years.

Yes, pretty much this is how I've been doing JSON API's for a couple years now. Making things all about convenience and ease of use for the API consumer, that's really what an API should be about. Afterall, API's are UI for developers.

Exactly. Everything is becoming a software problem. Dispense coffee? Make a rug? Drive a car? They'll eventually all be software problems. Businesses are being limited by their ability to understand and adopt software by the supply of talent. This will continue for a long time and it'll be people that can integrate complex systems that will solve them, not academic algorithm experts (whomever they are).