FWIW: I seem to recall something said at the keynote (or many a discussion afterward) that the greater power of the 4s' A5 was "needed". [ correct me if I just dreamt that ]
Not that that should stop anybody from processing it with an A4-powered iPhone.
> 1. Encryption really was expensive in 1996 or so, but in the age of multicores, its questionable if there's a real cost now.
A lot of "budget-priced" hosting services are near-free for http and heavily-surcharged for https. - Pricing it to make it seem as if there were some huge cost difference. Makes a difference when shoestring clubs/nonprofits want to throw up a cheap static site.
That's because SSL is a shitty protocol, it has nothing to do with CPU.
Turns out that you can only have one SSL applied to one IP because browsers* can't tell the webserver hosting 1,000 sites which particular site you're requesting, because of, you guessed it, encryption.
Essentially, you're paying for a dedicated IP not CPU.
*theres a fix for this supported by several browsers, but it will never be backported to legacy browsers and the millions who won't upgrade for many years so its unsafe to assume you can use this method, thus one IP per SSL for the foreseeable future.
The problem is really only with IE on XP; of course, that's still a huge share. We can thank MS for that, since if other browsers support in on XP, there's no reason IE couldn't, especially considering 7+ already does in Vista and 7.
Read the NYTimes article... you learn that the two sets of pedals are 1:1 connected. Your partner pedals faster and you have to pedal faster. Maybe not harder - but you do have to keep pace.
Maybe we should design an exercise bike with motor, and you just put your feet in the pedals and let them roll around without applying any force yourself? Seriously, a fast cadence on a bike isn't even work if you're not applying any force yourself.
Alviva was wondering why the people on the back were not slacking. MediaBehavior says they were only pedaling faster, not necessarily harder. I'm pointing out that the article clearly says they were pedaling harder.
Plus, stripe.com has become visible only so recently (couple weeks) that other discussions linked here may not even include stripe. "A game changer by introducing developer-friendliness" is the takeaway that I got from the HN discussion at http://news.ycombinator.com/item?id=3053883
Sadly, if you're not in the USA this is of no use, for now, until they expand into other countries. I have a product launch soon and I'm seriously considering just extending the free trial period until they launch in Canada.
I concur about what you say (although it's not exactly an argument for teaching programming).
How different would the online world be if knowledge were universal about:
- copy/paste
- cmd/ctl +/- for resizing
- why password mgmt matters - and its basic principles
Self-educated web-surfers out there have amazing gaps in their knowledge - for things that are practically spinal reflexes to even a low-grade hacker like myself.
So the diameter more than the width of a football (NFL) field. And... one of those per each household? Besides the visual obstruction, just finding such space for each abode is daunting anywhere (not to mention somewhere with the population density of Japan).
EDIT: Or, consider the transmission costs from areas where such land is available.
Does that mean that whenever you recommend server-side solutions that the server must have Ruby set up?
[OT question that has blocked this PHP-hobbyist from dabbling in RoR: do professionals ever add a new functionality as part of a web app via RoR when the bulk of project has already been built with something like PHP? (looking for motivation to start some experimentation in Ruby)]
Nope, we don't only talk about Ruby. We have a few PHP examples as well, but there's a lot more on CSS, JS, Git, server administration, etc.
There's not a lot of server-side code in the book, to be honest. Chapters like Creating a Widget focus on the client-side code - loading content in to your page and providing an example for what the data looks like, without getting in to "here's how you'd' do this in Ruby or PHP or .NET".
Another author here - To answer your first question, no, this book is very front-end driven. We will have one server-side recipe that will use PHP. The rest of the recipes that use a backend use a "no setup required" server I wrote called QEDServer (http://qedserver.napcs.com/) which provides a JSON API full of records and a way to serve HTML pages so you can work with things like Knockout and Backbone without having to set up an API. We use it in a few recipes.
But we really wanted to keep the server-side stuff to a minimum, and while we all use Rails, it's not the answer to all web development - especially with things moving more client-side.
Your second question, yes you certainly can. I've done it and the only tricky part is making them work together, and thanks to web services, that's not terrible. I even have a new Rails app consuming some XML I wrote with classic ASP.
In reply to your OT question - does your PHP app have an API at all? You could make a small standalone app that pulls from your existing API. Or go the other direction and create a Ruby app in Rails or Sinatra that aggregates some information for you and makes it available for your existing app to consume.
The core of the project I'm working on is built in PHP. However, we found that there were a few things that would make more sense in RoR, and there are many features in the future that will be better served as RoR apps. Basically, we are using mod_proxy to redirect to the Rails app.
If you'd like to talk more about it, I'd be more than happy.
Their parliament seems to have been effective in prohibiting that use of footage of parliament be used for parody. [see recent blackout of a John Stewart segment]
Not that that should stop anybody from processing it with an A4-powered iPhone.