Nicolas___
Joined 15 years ago
Joined 15 years ago
Micro-optimisations are worth it when everything else is optimized in your application. You might get way better results by focusing on your database structure or the way you store, retrieve and cache your data.
What's listed here doesn't lead to "highly efficient code". More like "A tiny little bit more efficient code". Doesn't hurt doing it though.
First annoying thing about OpenId is that most providers make an awesome job of hiding their entry point, or the exact URL that is each user ID. Except for Google, I had to extract URLs from various authentication pages (StackOverflow has a nice one) and plug-ins (http://jvance.com/pages/JQueryOpenIDPlugin.xhtml among others).
Second annoying thing about OpenId is consistency. Some providers provide a distinct URL for each user, and some have a unique URL for every users. This makes your auth form an UX nightmare where users have to paste their URL instead of just clicking a button.
Add to this the fact that each providers has it's own understanding of the spec, which leads to some weird implementations of the protocol (once again except for Google's). That and the not-so-occasional errors from several providers (these raw "Error 500 - contact our administrator" we all love).
At this point, I had spent almost 20% of the time I had to make the whole prototype, trying to figure how openId could fit in. So I changed my mind and switched to FB Connect...which can be integrated in about 20 minutes.
I'm no FB fan, really. But I have to admit it just works...
The second rule of the cloud is : Paying for a service to get a "private" option doesn't mean the data you store is and always will be 100% unreadable/unusable by the company providing the service. Targetted ads is based on exactly that.
Finally, the most important rule of the cloud is : If you're sad/annoyed/chocked when you realize that companies like Google, Facebook, GitHub, Dropbox, and thousands others have priorities that could conflict with yours at some point and threat your business or your privacy, just don't work with them, just don't rely on them.
Is the paper still available online ? Do you have an alternate URL ? Thanks :)
==> Web Application Hosting : http://d36cz9buwru1tt.cloudfront.net/architecturecenter/AWS_...
==> Content and Media Serving : http://d36cz9buwru1tt.cloudfront.net/architecturecenter/AWS_...
==> Batch Processing : http://d36cz9buwru1tt.cloudfront.net/architecturecenter/AWS_...
==> Fault tolerance and High Availability : http://d36cz9buwru1tt.cloudfront.net/architecturecenter/AWS_...
==> Large Scale Processing and Huge Data sets : http://d36cz9buwru1tt.cloudfront.net/architecturecenter/AWS_...
These are the main usages a startup can make of AWS. Of course, depending on your core business, you will need to focus on specific parts.
Of course, sending passwords in an unencrypted email is bad practice, but that's another story.
- receive SMS Allows application to receive and process SMS messages. Malicious applications may monitor your messages or delete them without showing them to you.
- read contact data Allows an application to read all of the contact (address) data stored on your device. Malicious applications can use this to send your data to other people.
- read phone state and identity Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
What is the point of having these privileges, in a trivia app ?
Care to share the tech behind the site, and how it works ?
Your idea could be very good or very bad, depending on how your service works. But right now, there is no way to tell because it shows nothing at all.
You basically asked for some feedback on the content of some <title> tags.