So one of the things I have been seeing more and more are meat-space kiosks that are enabling (and encouraging) you to interact with them by sharing the activities you participated in via your social media identities.
How are they doing this? By having you type your credentials directly into the kiosk. Not only is this a Really Bad Idea(tm) but even the act of encouraging the generally non-security-savvy population that this is a “thing” is horrifically scary. No longer do you need to click on a phishing email to lose your password, all you have to do is buy something from a kiosk which has this configuration in it, from a kiosk which has been hacked. Oh wait, it’s not like that ever happens, right? Certainly Target would never get hacked, and if Target is safe, well, maybe the little guys will be fine too.
This is a patently Really Bad Idea but I don’t think it’s going away, so what I propose is this: sites and services that consider themselves identity providers (a.k.a. you offer OAuth login credential verification for third party sites/apps/projects/whatever), with their mobile app, should provide an easy way to generate a limited-time-use OAuth token, and then provide a way to display it via QR code, or similar.
Granted, this would require adding a webcam to the kiosks, but webcams are dirt cheap, and the net positive for everyone involved. Heck, I bet it turns out to be so much more user friendly that the rates of those social participation options becomes more frequent. Imagine Retailers could even, with this new, nearly painless, option, even offer users a chance to tweet, or post a status, about their in-progress transaction to receive some sort of discount, or special offer.
Bottom line: let’s get real and not encourage the general population to foster insecure password management choices. Entering your password (which is statistically likely your password to everything) into a public kiosk which exists in an unknown state of security is a bad idea, every time. Making it normal is an even worse idea. Let’s wrangle this under control before it becomes even more wide spread.
Would you believe that a year and a half ago, today, I don’t believe I had even considered actually attending a conference?
Then through a twist in fate, I ended up at Symfony Live 2012 in San Francisco, and something clicked.
In the 6 months that followed, I became co-organizer of the Ann Arbor PHP user group, went job hunting, and accepted a position at Mashery. Exactly 1 year ago yesterday, my wife and I said goodbye to the house we bought to build our family, and my daughter said goodbye to the only home she had ever known. Exactly one year ago today, we arrived in California, in the Bay Area, our lives changing, irrevocably. We knew it would be an adventure, but we didn’t know quite what we had in store for us.
Nothing symbolizes that change more, actually, than how we ended tonight. For those of you who don’t know, I am traditionally a very, very, very picky eater. Vegetables were the enemy, and trying new things was extremely rare. Through very careful introduction and an enormous amount of patience, my wonderful wife has gotten me to (relatively) vastly expand the range of foods I am willing to eat and try. So how did we celebrate tonight? We walked down the street to the local indian restaurant, where I enjoyed some Chicken Tikka Masala. Ok, actually I enjoyed a lot of it.
My family and I eating at Sargam Indian Cuisine
I also ended up going to a lot more conferences, speaking at them, even – which unfortunately puts extra stress on my wife, who has consistently been above and beyond far nicer about how that deal works for her than I would be in her shoes. Raising a child with someone is hard enough all on it’s own. When one of them is out of it completely, not only does your only backup go away, but the child may get upset as well. I’ve watched my daughter alone for at most, I believe 4 days straight. My dear wife has had several multi-week stretches, one of which lasted for 6 weeks. I just landed Thursday from 5 days away and I’m headed out for nearly a week and a half on Thursday. I say near enough because I get to see them over-night next Wednesday. Woohoo!
The one constant in all of this is my wonderful wife, backing me up, and constantly performing amazing feats of ex parte parenting. I’ve heard stories that leave me surprised I even have a daughter still.
One year ago today we leaped, together, into the future. It’s amazing how fast the time has gone.
It occurred to me this morning that there are actually quite a few parallels between functional programming and infrastructure design and management.
It all started by what I realized that I said while talking about environments: Production is meant to go from one stable, working, vetted version of code to another stable, working, vetted version of code. Any state between those two is invalid and should (preferably) never occur.
If you cycle on that again, you start to see that most deployment processes you know about violate this One Basic Rule(tm).
I posit that if you are deploying new code to currently running hosts that are handling traffic, you are doing it wrong.
Think about it like this: what is the one core feature of every highly scalable functional programming language? Every one has (or has developed patterns which essentially create) immutable values.
So when we scale this out of software and apply it to infrastructure, your code is the value of your server. If you are changing the value of your server while other processes are trying to access it, you’re going to run into concurrency issues. Ask any developer about sharing data between threads, and they’ll quickly tell you it’s difficult. Why, then, do we improperly share data between releases of our software?
The simple answer is that you have two options for atomic deployments that follow the rules of immutability:
- Drop the servers you are deploying to out of the flow of traffic. This is the easiest, but still fails to honor the spirit of immutability because the value of the server is still changing, it’s just changing while nobody is looking.
- Spin up new instances, and slowly work them into live traffic, confirming along the way that you are in fact getting the expected behavior out of the code.
Now, I know this is all hand-wavy because it glosses over the important aspect of data migration: I don’t have an answer there, yet. I suspect the true answer to that part of the solution would be something to the effect of being able to seamlessly decouple your entire system from write traffic (using a request proxy which could ‘pause’ calls) for some period of time while data updates are done.
What if, to create a truly fault tolerant design, you simply create a nearly 100% asynchronous API. All requests come in and go into a process queue, and are handled from there. This way you are never required to turn off traffic to do an atomic update of your software because you can simply tell it to stop processing while the update progresses.
This week, I am in Louisville, KY at Code PaLOUsa! Next week, I leave for SXSW Interactive in Austin, TX. Right as I get back from SXSW, I take off for Midwest PHP in Minneapolis, MN.
I’m speaking at Code PaLOUsa and Midwest PHP, so if you’re around, be sure to come check out why you should care about development environments, and how to go about implementing them in your organization.
I love to meet new people, so if you see me, please come say “Hi!!” and introduce yourself.
This weekend I was invited by a few friends from the Ann Arbor PHP User Group to join them on Saturday night and figure out something to work on together.
TLDR: I need to do this more. It was immensely fun.
So it started off with a few ideas flying around on what to build, and then I’d mentioned that I have wanted to build an app for estimation poker since forever. Also — it seems I can be somewhat persuasive.
So the four of us sat down (Jonathan, Kelly, Jason and I) and we sorted out what our MVP (Minimum Viable Product to those of you who don’t live in startup land) was going to be. We settled on features and the basics of the protocol, and then had to pick technology. I’d seen that Ember.js seems particularly well built for building a multiple concurrent user system, so I suggested that, and I believe it was Jonathan who suggested Node.js for the back end, and of course — socket.io for communication. Jonathan and Jason would pair to build the back end, while Kelly and I would take the divide and conquer approach for the front end. With all of that decided, there was only one other choice to make…
Because it’s a fun name to say, that’s why.
So as of today, the minimum viable pieces are actually working. You can check out the github repository, or even see the live demo up on Heroku. I’m hoping we can maybe look at using it at work to help encourage participation during planning meetings perhaps, but even if that never comes to fruition, it has certainly been a fun project to work on, even just as far as it is now. It still has a lot of rough edges, but you can see it starting to come together.