These tips are good practices, but they are micro-optimisations. The function strtr might be 4 times faster than str_replace, but the time saved by using strtr will represent a tiny tiny tiny portion of your script execution time.
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.
By the way, since we're on HN, there's a multi-billion dollar idea here : Create a way to add OpenId to any website, that is easy and fast to implement and friction-less for users.
I recently had to choose a way to authenticate users for a prototype web app I was building. My first choice was OpenId, because the promise behind it is awesome (1 login everywhere) and I wanted to avoid depending on FB.
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 first rule of the cloud is : If you think your data requires a high level of privacy, don't store it on someone else's platform.
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.
Being able to provide you with your password in plain text doesn't mean it's stored in plain text. There are very efficient and secure encryption algorithms that are reversible, out there.
Of course, sending passwords in an unencrypted email is bad practice, but that's another story.
- read SMS or MMS
Allows application to read SMS messages stored on your device or SIM card. Malicious applications may read your confidential messages.
- 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 ?
There are two main options, when it comes to making money from an app :
1- sell a small (cheap) app to many people
2- sell a big (expensive) app to a few people
While it is true that the most successful apps are usually pretty complex and expensive to produce, there are ways to make money with small apps. Games are a good example, as some hugely successful games are human-sized projects.
One thing : Starting a project with money as your unique goal won't lead you very far...passion is a way bigger motivation (that often leads to success, too).
The problem is that many legit people with perfectly legit businesses have seen their account frozen for 180 days without any reason and without any human being to discuss the issue with. All they could do is wait and hope they get their money back at some point.
To some it might be just an issue, but to me it's a problem that would lead my company to bankrupt.
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.