So you don’t give a crap that your data gets exposed or hacked? You don’t have anything to hide, so the potential leak isn’t worth the added effort of complex passwords and password management systems. You want a simple, easy to remember password. Fair enough. I get it. You don’t give a crap, but here’s the thing… Your mom might. Or your dad, or your sister or your great Aunt Bertha or your Cousin’s best friend that you just recently added on Facebook. And that’s the point!
Let’s say you’re one of the few who don’t give a rip because you have nothing to hide. Stop being selfish! Most of this password protection junk has nothing to do with you. It has to do with the information you have access to, like my email address, my phone number, the names of my kids and that picture I shared with you from my best friends bachelor party!
You are most likely passively collecting information in the services you use every day. It might just be people's names, but it also could be more serious information like their addresses and phone numbers. A data leak because you used a stupid password exposes all kinds of things that your friends and family don’t want everyone under the sun to know. And not just because it’s private information, but because it effects their safety!
It can get worse then just the revealing of address and phone numbers though. How you say? Consider the fact that that Facebook app on your phone posts where you go. Maybe it’s a restaurant, church or even the grocery store. You’re a hip social media rock star and you’ve been capturing your geo-coordinates and checking in wherever you go. So have I, your mutual friend on Facebook, as well as your neighbor’s 16 year old daughter. Now ALL of that information about where you’ve been and the trends of your daily activity is accessible to some low life hacker that cracked your stupid-simple password. Is this sounding scary yet? Let’s keep going… That hacker might decide to pay one of us (you, me or or your neighbor’s teenage daughter) a visit. Or maybe the hacker sells that valuable data information to a petty thief or a pedophile. Now is it scary? It ought to be. This is what happens when the flood gate known as your weakly protected account is opened.
You are just a gateway drug for a hacker. Your credit card, social security number are low hanging fruit compared to the peripheral data you are toting in those web based accounts you login day in and day out. Protecting your accounts with unique and complex passwords isn’t just about you. It’s about everyone you engage with using those services. It’s about personal protection, for you, your family and your friends. So I get it, you don’t have anything to hide that you’re worried about a hacker exposing. But I do.
Google's 12/12 cleaning eliminated a product called Google Sync. This was an extremely handy product for folks going mobile who want to stay connected to their email. It essentially allowed you to setup your Gmail account using Microsoft's Exchange protocol. What's significant about that is that it enabled instant push notifications for new email messages. This meant that when Google got an email for you, if you were using the Exchange protocol you got it instantly. When Google dropped support for this the best you could hope for was getting your email in a 15 minute window, hardly instant.
In a world of instant not having your email as soon as it's available is a huge deal. But why did Google do this? Presumably to get more people to adopt their Gmail iOS app. But here's the thing... Gmail for iOS SUCKS! Yeah, I said it, it's absolutely terrible! Not all of it is Google's fault, but some of it should have been resolved when Google picked up Sparrow in an acquisition - those dudes knew how to make an email account. Gmail for iOS is awful first and foremost because iOS has no concept of a default email client. If you're using Safari and you click on an email address, or maybe you click on it from your Contacts, you're going to open up the native Mail app. There are more problematic issues though that are technical in nature, like Gmail's inability to properly handle responsive email layouts. When email doesn't look right people don't want to use your product. This is where everything goes bad...
Your email looks like crap and nothing on your mobile device uses the right client. So what do you do? You start experimenting with other clients. This is fundamentally how Google is destroying the security of Gmail. Since the shut down of Google Sync for the masses you've seen a whole host of iOS email clients spring up. I'm looking at you Mailbox, Evomail, Boxer and friends. Personally I don't have a beef with these products in and of themselves, but the problem is they all offer you push notifications at a cost. Not a financial cost, a risky security cost. In order for these applications to tell you the instant you get your email you have to give them full and absolute access to your inbox. Then you have to trust that no one at that company is stupid enough to become the next Adobe. I actually like some of the products I just mentioned, but I don't use them. The reason is simple, I'm not comfortable letting someone else comb my email every single day. Quite frankly, you shouldn't be either!
What's the answer? For me it's two fold... Important email accounts use the Gmail iOS app. Non-important email accounts stay in the native Mail app. The important ones are there too, so that the rest of my iOS experience doesn't stink, but I have notifications and badges turned off for those accounts. It's not a pretty solution in my opinion, but it's the only solution that keeps your email safe. Your email needs to be safe too. There is no easier way for a hacker to gain access to everything else in your life than getting access to your email. Most services allow you to reset everything under the sun using just your email address. Keep your email safe!
Both Google and Apple can help us out too, though I don't think either of them are going to do so. Google can fix their technical problems. Most of them should just not happen, it's inexcusable. They can also work on making Gmail act more like an iOS app and less like a red-headed-Android app. Meanwhile Apple can give us the ability to select a default email app, and they can also build out APIs to allow apps like Mailbox to poll an IMAP service like Gmail in the background of the device. Yes, it's going to hurt your battery life but that's a price I'm willing to pay for security. I just wouldn't expect Apple to do that anytime soon...
There's one other option I haven't mentioned... Ditch Gmail altogether. If Google is content to encourage users to risk their email security then maybe it's time to look elsewhere? Any Exchange based service will work, and quite honestly the dudes over at Microsoft have built a solid product with Outlook.com. If that doesn't float your boat, Yahoo Mail also has a solid email solution. And guess what... you can get push notifications for both!
Someone may be quick to point out that Apple's own iCloud solution does push too. This is true, but anyone who has used iCloud knows, the spam filtering and phishing protection makes it nearly the worst solution to email available on the internet today.
I've been thinking about ORMs a lot lately and I've been wanting to write something about what I consider to be the DataMapper farce. I should be clear up front, I'm big Doctrine 2 fan. BIG. It's my ORM of choice every single time, or maybe it was... On principal I love Doctrine 2. My days as a Java developer made me grow fond of Hibernate and with time I've come to really appreciate object hydration via the DataMapper pattern alongside the Repository pattern. What I've appreciated most is the fact that I can write a model with no implicit dependencies, meaning my class "Foo" does not extend ActiveFoo or QueryFoo or BaseFoo or FooTable or GatewayFoo or FooPeer or MagicHotSauceFoo, it simply stands on it's own. In the case of Doctrine 2 my model usually gets some love from annotations or maybe Yaml if I'm looking to spice up my day.
Here's the thing I've been contemplating though and why I think this notion of portability is fundamentally a ruse (for now). In the PHP universe what other library provides a DataMapper implementation that would allow you to freely move from Doctrine 2? If I choose to write stand alone models I am either stuck doing some sort of hydration myself (all kinds of time consuming icky) or I am using Doctrine 2. So this idea that ActiveRecord locks you in and Doctrine 2 doesn't, is, well simply not true... Short of a viable alternative Doctrine 2 has a monopoly on the DataMapper pattern, making it as 'locked in' as using Propel or any other ActiveRecord-styled ORM.
Now don't get me wrong... This doesn't change the fact that I will likely continue to gravitate toward's Doctrine 2. I am going to hang tight and hope for some healthy competition that will allow me to write my models portable enough to swap in Doctrine 2 for odd days of the week and LibraryX for even days.
PHP has more frameworks then I have fingers and toes, and that diversity gives developers and architects alike a lot of choices when it comes to solving a problem. It can also be a total headache sifting through the options and making sense of what seems like chaos. As of late I've found myself using Symfony 2 to solve my problems and I am increasingly a fan of it's underlying architecture and the freedom it gives developers to work in slices or components of an application.
A fair amount of debate has hit the internet about the dependency model of certain Symfony 2 components. Some argue that component A with dependencies B and C is too much, or that because component A also requires dependencies D, E and F to run it's unit tests it's not a truly stand alone component and instead represent a "coupled" library or framework. I actually think there is a lot of merit in these assessments, but I don't believe it discounts Symfony 2 from being my MVC framework of choice. Nor do I think this somehow invalidates the fact that Symfony 2 stands distinctively different from the alternatives in the PHP community. Symfony 2 is a huge step forward from the land of tightly coupled frameworks (I'm looking at you Cake!). More importantly than the dependency model though, I think Symfony 2 presents an architecture of "Bundles" that simply doesn't get enough love in the current framework debates.
A bundle in Symfony 2 is nothing more then a stand alone unit of code. It may have dependencies, but it's stand alone in the sense that it represents a functional chunk of an application. A well designed bundle could theoretically be deployed as distinct unit from an application. Think about an application where you have an internal messaging system. Wouldn't it be nice to be able to peel that message system out of the main app and to develop it independently? When I say independently, I mean completely functioning on a web server without the rest of the application. This is bundle development at its finest.
Don't get me wrong, lots of bundles are not developed this way. I've seen applications where bundle divisions are completely arbitrary and others that had a nasty web of cross dependencies such that they should have just been in the same bundle. There is a happy place however, where bundle development represents a unique sliver of a larger application, and that place is why I'm so drawn to Symfony 2.
I've been working on a reporting bundle for a little while now. It's a simple concept, take an arbitrary query and translate it into a table. When I am developing it locally I actually have it bootstrapped into a vanilla Symfony Standard edition created by composer. When I am done with changes I deploy them into two different apps I've written that both use this bundle. The apps themselves have very little knowledge of the bundle, just enough to put some links into their respective menus, import a routing configuration and that's about it. What's most important though is that the reporting bundle itself has no knowledge of the two apps, such that I can develop it independently and deploy it to both without disrupting anything. The immediate benefits of this are rapid development and deployment, allowing for changes to trickle out to actual software faster.
This sort of development, application by slice or bundle, in a big team can optimize workflow by an order of magnitude. You can have a team iterating independently at a rapid pace without disrupting the other teams. In the end you have a forward moving application of independent and highly functional units. What's not to love about that?
Symfony 2's implementation is unique in my opinion because of things like extensions, compiler passes, bundle inheritance and the power of template inheritance. These aspects of Symfony 2 really empower unique slivers of code. When done right it's completely possible to develop a bundle that doesn't even need Symfony 2. Want to bootstrap a new framework and use your bundle? You can do that - it just requires some deliberate planning at the onset (aka inject, inject, inject!). Now some will read this an appeal to the awesomeness of Symfony’s dependency injection component and argue that’s really where the power of these slivers come into play. I disagree, I think it’s a piece of the pie - but fundamentally there is an underlying architecture and set of principals that lends itself to lose coupling of pieces of an application. What I wish though, is that this bundle mentality would materialize in some other frameworks!
** After writing this I was challenged with the notion of “plugins” or “modules” as they appear in some other frameworks. In my opinion most of the “things” that use this terminology lack the looseness of a Symfony bundle. A well written Symfony 2 bundle can in my opinion be bootstrapped without using Symfony. It requires writing Controllers that stand alone and are injected and it requires having a full grasp of your dependencies (no $this->createForm() please), but it can be done and the power of that independently deployable bundle is something that plugins and modules simply have not proven they can do just yet.
When I went to order my wife a new phone I couldn't get a straight answer as to whether or not the T-Mobile full-price version would be unlocked or not. The general consensus was that the device would ship with a T-Mobile SIM and be bound to T-Mobile's prepaid service at least for a couple of months. The whole thing was terribly confusing because you could order an iPhone 5C without a SIM in it at all, which is what I was hoping I could do with the 5S.
I pulled the trigger and ordered my wife an iPhone 5S from the Apple Store online, fully intending to cancel my largest bill, AT&T and move on with the latest and greatest. I value my freedom and at the core I'm cheap, so the long term savings and the short term monthly decrease was highly appealing to me. I had pegged my eyes on StraightTalk, the details of which are destined for another post, and figured we would complete that transition in a few months.
I ordered the phone and it arrived with a T-Mobile SIM. Now I've never done a prepaid plan before so I was a rookie at this in every sense of the word. I opened the box and I could not figure out how to get service started. There was nothing in the box explaining what to do and when I called T-Mobile they basically told me I had invested in a precious paper weight and needed to take it into a store. This was simply not the freedom that I coveted.
I happened to have a StraightTalk SIM laying around and after two T-Mobile customer support calls and three AppleCare calls I came to the determination that this device was most likely unlocked and I could kick T-Mobile to the can.
So here is the bottom line... If you are ordering an iPhone 5S, as best I can tell the device is in fact unlocked. It's worth nothing that I was not transferring a number and I did not have any previous accounts with T-Mobile. I was fed up and frustrated with the ridiculousness of their customer support and took a chance by sticking a StraightTalk SIM into the device - and it worked! My advice if you want to dramatically cut a bill and sport a new iPhone 5S is to not get hung up on T-Mobile when you order as it would appear these devices are free to roam about carriers as deemed fit by their owner.
