In baseball, one of the most exciting points in the game comes when your team of choice trails by a run or two in the bottom of the ninth. You anticipate the bottom of the ninth during the middle inning break, wondering how the three batters will compete against their closer. Will they launch a game tying or winning run into the stands or swat at our dreams with a bat full of bluster? The anxiety builds and sometimes the magic happens and a walk-off occurs. Not often, mind you. Otherwise it wouldn’t mean much. It’s hard to win a baseball game and it’s also equally as hard to move on from a job. Will it work out with the new company? There’s the same type of anticipation, but unlike the baseball walk off, you can make a difference in the outcome.
I’ll be the first to admit that I have trouble with regular expressions. But they’re incredibly useful when used in the right way. For instance, I was recently tasked with finding a way to insert a related podcast into a story node. To do this, I gave users the ability to add a shortcode into the text that would be parsed prior to viewing, so I could inject the necessary HTML.
Sounds simple. The shortcode would come in the form of [podcast id=”1234″]. Great. That’s easy to implement and simple enough to parse with PHP if I can find it in the text string.
preg_match('/\[podcast id="\d*"\]/', $string, $podcastString);
This would work well, right? If you’ve done this type of thing before, you likely have your go-to source to test your regular expressions. I use www.regexr.com for my tests (they have a very clean and easy to use UI). So this will get all the instances of the podcast with the id if I use the /g flag in the regexr tool. But that flag won’t work with preg_match. That’s when I learned about preg_match_all. I know. I should know about this by now, but I’ve never dove into regular expression to any great length until now. So now this work just fine:
preg_match_all('/\[podcast id="\d*"\]/', $string, $podcastString);You can read about preg_match_all in the PHP docs.
If you’re requesting a user create an account, you should also allow that user to delete the account. It’s not a one-sided contract. The big guys do it for a reason. Sure Facebook would rather you turn off your account for a break, but you can still nuke the whole thing.
I tried to find a design pattern that touches on account management. UI Design Patterns had a reference to Google’s account deletion process, but nothing of substance.
I looked around and a general rule of thumb seems to mirror what Google’s message gives users — you’ve deleted your account, but you can still resurrect it. Come back whenever you like, within reason, and we’ll set that deleted flag right back to zero.
But give users that option. Here’s how the design pattern might read for user account deletion.
Design Pattern Outline for User Deletion
- Give a user a means to delete their account (not suspend, but actual deletion).
- Be explicit with the user that the deletion will be completed, in full after 30 days. They can reactivate their account prior to that date so as not to lose any data. Force them to agree to that message.
- Set a field on the user table with a delete_on date field to now().
- This now date will be checked nightly to see if it is greater than 30 days. If it is, then delete the user information from the table.
- Give the user the ability to login to the site during the grace period. If they choose, they can reinstate their account, which would purge the date from the delete_on field.
First we looked at the site from other devices. On the iPad, the problem was there, but not nearly as pronounced. Android let you scroll through the list like water. So what could the issue be and what’s the best way to find out how to solve a problem on a mobile device when those same problems don’t appears on desktop or through emulation tools?
Head to Google
That’s right. We googled the problem. Unfortunately the first couple results lead nowhere. Until we got more specific with the problem.
The issue was we had a div that was scrollable. This div held all the profiles that were returned from the API. And since the problem was unique to Apple devices, the answer came from another site, where it was clearly laid out that we need a simple CSS property on that scrollable div.
Once we had that, we loaded up the site in Chrome on our Apple iPhone and everything worked fine. One. Simple. Tag.
Have you ever experienced problems like that when programming, one that’s resolved with a really simple fix? Let me know in the comments.