Lassoing the Clouds: Best Practices on AWS

I recently had the pleasure of speaking at Atlanta PHP and php[tek] 2017 where I presented a new talk, "Lassoing the Clouds: Best Practices on AWS."

As you might be aware, the Amazon Web Services offering is massive.  Between the details of running virtual private servers and AWS's managed services, understanding the best practices when running a production workload can be difficult to grasp.  This talk hopes to point out just a few of the key practices to ensure long-term maintainability and reliability of your infrastructure.

There are a handful of animations in the presentation itself, so I'm posting three versions of the slides below.  Enjoy!

One slide per page

One page per animation transition

One page per animation transition, with presenter notes

Five Years of FloodWatch

Since August 2010, I've had an app in the iOS App Store named FloodWatch.  It's an app that can be used to monitor rivers, creeks, and other bodies of water all over the United States and its territories.  Its data is sourced from the US Geological Survey.

Specifically, all ~8,000 river gauges in the United States with real-time data capabilities can be accessed from within the app.  The app hits USGS web services directly to retrieve its data.

USGS gauges can report on a variety of data, such as current river height, amount of precipitation that has fallen, and current water flow amount ("discharge"), among other values.  FloodWatch surfaces height, precipitation, and discharge values.  If the National Weather Service has defined flood stages for a particular gauge, those are presented within the app, too.

Who's my target market?  People living within the United States who are residing or have property near rivers, streams and creeks that might be prone to flooding.  These customers have either experienced a flood that affected their property in the past, or they're aware of the possibility and want to keep an eye on their nearby rivers as a result.

First, we'll talk about some history and motivation behind FloodWatch.  Next, we'll talk about how it's performed revenue-wise and against its goals.  This is the story of the past five years.


The idea for it was born out of our home being flooded in September 2009.  I really never paid any attention to the nearby creek, but once it ended up running through our living room, I figured that it deserved a bit more attention.  So, what's the old adage?  "Build an app that you'll find useful, and others will find it useful, too."  That's exactly what I did.

First, let's talk about a little history.  I've been a web developer since 2000, focused primary around PHP and open source technologies.  In 2009, I started feeling like I wanted to branch out a bit by gaining exposure to other languages and platforms.  There was more to life than web development.  iOS was a growing platform at the time, and I had been using a Mac for about four years.  Objective-C and the iOS platform were so wildly different than PHP and web development.  I wanted to challenge myself, and do some development that helped me develop new skills in other areas of technology.

So, I picked up a few books and started to learn.  I spent February - August of 2010 building FloodWatch in the evenings and on weekends.  I figured if I could pick up some new skills, and maybe make a little bit of money, then it's a win-win.

In the early days, I'd strive for "just make it work," with little concern for if I was doing things The Right Way(tm).  This was back in the days of retain/release, and I can't say that I truly understood the ownership aspects of memory management, so I was just retaining things all over the place.  :)  I cleaned up all that mess in later releases, shortly after ARC was introduced.

It's worth remembering that I'm a developer.  I can implement things, but I'm not a designer.  So, the app is generally using stock iOS views and controls.  It's clearly designed by a developer!

FloodWatch went live in the iOS App Store on August 17, 2010.

I stood up a super basic, ugly web site for it shortly after launch.  It's in dire need of some updating.

Motivations and goals

First, I wanted to use this app to grow my skills with Objective-C and the iOS platform.  I've maintained the app over the past five years; it's had a small part in helping me keep my iOS skills up.  For example, I'll always update it around major iOS releases by adopting new frameworks when it makes sense.

Secondarily, I wanted people who also lived near rivers and creeks that might have flooding concerns to find it, and hopefully find that it was a useful tool.  That goal was definitely met, as you'll see below.

FloodWatch has always been free.  It was ad-supported, with Apple iAds running within the app.  I never expected to make a ton of money off of it, and I haven't.  I've added in-app purchases over time to further monetize it, though.


I've done very little marketing over the years.  I've run a few Google AdWords, Facebook, and Twitter ad campaigns around major flood events, but that's it.  If there's flooding happening in the US, I'll tweet about it from @d5gtech.

App Store search is the largest driver of downloads, at least as far as I can tell.  There aren't many relevant results for keywords like "flood", "floods", "flooding" and the like.

It is mentioned on the US Geological Water Web Services Showcase.  It was featured in a book, Death, Decomposition, and Detector Dogs: From Science to Scene as a useful tool for police dogs when searching rivers in search and rescue operations.  Crazy, right?!

I've received emails from members of the US Geological Survey, National Weather Service, Red Cross, tugboat captains, firemen, and recreational fishermen, just to name a few.  The app has been used by many different types of people for many different reasons.  That said, it's my belief that the vast majority of users have real reasons to monitor their local rivers and creeks.


FloodWatch has been used by someone in every state within the United States.  Here are some high-level figures:

  • Total installations, all-time: 28,000
  • Average number of unique users per month: 2,270
  • Total revenue: ~$2,600 (after Apple's cut!)
    • In-app purchases: $720
      • Ad removal units sold: 320
      • Tip jar level 1, units sold: 24
      • Tip jar level 2, units sold: 8
      • Tip jar level 3, units sold: 2
      • Tip jar level 4, units sold: 2
    • iAd proceeds: ~$1,880
  • Approximate number of support / feedback emails received: 250

In general, my purchase conversion rates are terrible.  I'm clearly not doing this for the money.  Instead, it's a pet project, and if you include my time spent in development, it's not profitable at all.  I should've killed this app years ago, but people find it useful, so I keep taking care of it.

My only annual costs to support the app are my Apple Developer Program membership ($99), my LLC renewal ($50), and AppFigures ($108/year).  So, it's "profitable" if you don't include my time.  On average, my Apple deposits are $30-$60/month.  In good months, it's climbed to $100-$120/month.

Diversifying revenue

My user base grew over time, especially during and following major flood events.  People have found the app to be useful, so I've tried to monetize it differently over time.  Along the way, I have added the following sources of revenue and exposure:

  • iAds: [with initial launch]
  • iPad-optimized UI: January 2014 (universal app)
  • IAP to remove ads: January 2014
  • IAP for four "tip jar" levels: April 2015

The in-app purchase additions made a big impact to revenue, but iAds have always been the largest share of revenue annually.  It's an app that people use when flooding is on their minds, which obviously has a strong correlation with mother nature.  Flood events can happen anytime, of course!

Now there's news that Apple will be discontinuing the iAd network.  If that ends up being the case where ads stop running after June 30, 2016, then, needless to say, I'm going to need to change my monetization strategy!

So, why keep it up?

You might be asking yourself "Bah, a lousy $2,800 or so...why bother?"  Great question.

Why do I keep maintaining the app?  Because its goal of helping people has been clearly accomplished.  Sales spike around major flood events in the United States, which tells me people are finding it useful.  They may not use it every day, and only a tiny percentage of them pay for an in-app purchase, but...that's not the point.  The point was to build a useful tool.

Here's a timeline of monthly app downloads directly from iTunes Connect, with flood events annotated.  Click to enlarge the image below:

Here's the breakdown of total number of sessions by state over time in the United States:

What can I say?  I'm huge in Texas and Louisiana.  :)

So, that goal of other people find it as a useful tool?  Mission accomplished.

What's next?

In terms of future development for FloodWatch, I have a few things in mind for 2016.  Among them:

  • Preparing for the iAd network retirement if ads will indeed stop running after June 30, 2016
  • Add social sharing of river status (Facebook, Twitter, etc.)
  • Redesign the UI from the ground up -- move beyond stock views and controls!  This might give it a better chance of being featured by Apple, too.
  • Add Push Notifications when a river's flood status changes (possibly a monthly subscription model)

Obviously this iAd situation would have me completely reconsider the app's strategy.  Frankly, it might be worth killing.  Otherwise, I would have to consider options like:

  • Take it to the paid upfront model; $1.99?
  • Remain free, but move to a monthly subscription model
  • Remain free, and rely on the "tip jar" other other patronage model

Someday, I'd like to spend a greater portion of my time focusing on iOS and Mac development.  FloodWatch has enabled me to develop and further my skills on iOS and Mac platforms, so it's been a very rewarding effort in terms of experience.

The reward

All of the revenue considerations aside, it's great to have played a small role in helping potentially thousands of people all over the US, some of whom may have had their homes and property flooded just like I did.  As you might imagine, going through a natural disaster that affects your home can be a taxing, traumatic experience.  I like to think that my app has been truly useful for at least a few hundred people across the US.

When you consider that, develop and maintaining FloodWatch has been worth it.  It may not be the most profitable venture ever, but it sure is a noble one.

I like that old rule of thumb from above: "Build an app that you'll find useful, and others will find it useful, too."  It's true!

Day of surgery: The Rainbow Passage

Took a video the morning of surgery to compare my speech before and after today's jaw surgery. 

Here I am, reading The Rainbow Passage. 

Virtual surgery planning

Went over virtual surgery planning today. The photo below shows my current state, the state after my lower jaw is done, then the final result after my top jaw is done. 

Dr. Keim and Dr. Blair are going to do a great job!  Looking forward to being done, awake, and them telling me that all went well. 



Double jaw surgery soon: November 6, 2015

In one week, I'll be undergoing double jaw surgery to correct my Class 3 underbite.  My lower jaw will be moved backwards a few millimeters, while my upper jaw will be moved forward a few millimeters and widened by cutting it into three pieces.

After 23 hours of recovery in the hispital, I'll start a few-week recovery process where my teeth will be held together by elastics of varying tensions.  I'll be restricted to a liquid diet during the first few weeks.

I'm going to try to chronicle my journey here in hopes of helping others going through similar procedures.  I have found other jaw surgery-related sites and blogs, such as Graham Swan's, and Jordan's, to be useful in my recent research. While I haven't been great at blogging consistently for the past few years, this effort can help others, so sitting here a week away from the surgery, my intentions are good!

Let's see if I can stick to it!  I plan to kick this week off with a video of sorts, and some "before" photos.

Technical New Year's Resolutions: 2015

Well, 2014 is on the way out.  What a year.  I like to do these posts every year to reflect on the passing year, and set some goals for the next.

Let's reflect on my resolutions for 2014:

  • Ship great products:  I did a lot of this in 2014.  Between some sizable new features at CrowdTwist, some major new additions at ShootProof, and additional features being added to my iOS app, FloodWatch, I'd say that I shipped quite a bit this past year.  Ninety percent of my focus continues to be on the web application side of things, which is still a ton of fun.
  • Find fun and satisfaction in all that I do: I joined ShootProof in July, which spoke directly to this goal.  I've found working in a smaller team to be much more satisfying, and our team is incredible.  It's truly a joy to go to the office everyday; I believe in the team and the direction we're headed.
  • Say "no" more: I've done a good job on this, being sure not to bite off more than I can chew.  As a result, I've been largely absent from blogging, speaking at conferences, and writing articles.  This is a bummer, but has been necessary to keep a good balance.

Now, what to tackle in 2015?

  • Continue to help propel ShootProof forward: we've got a lot of great things in store for 2015, and I'm so thrilled and honored to be a part of it.  I'm going to keep giving 110% so we can keep improving our products, and further solidify ourselves as the most comprehensive online solution for photographers.  It's been a great six months, and the next 12 are going to be incredible.
  • Continue to improve FloodWatch: my little iOS app, FloodWatch, has been near and dear to my heart since I started on it in early 2010.  With over four years in the iOS App Store, it still continues to be discovered and useful to thousands of people throughout the US each year.  It's not super lucrative, but there are a few more key features needed for it to reach its peak utility.  I plan to add some features early in 2015, and ultimately want to feel 100% satisfied with its feature set in the coming year.
  • Blog and/or speak more: I've done a lousy job of this in 2014, as exhibited by the fact that I published two posts last year.  It's so easy to write, yet I've failed to make it a priority.  This has to change in 2015.  Less talk, more action!  I also need to speak a time or two, either at Atlanta PHP, or maybe even a PHP-centric conference.  It's been far too long.
  • Launch a new iOS or Mac app: I'd like to branch out a bit in 2015, hopefully launching a second iOS app, or my first Mac app.  I continued to find this to be an enjoyably platform in which to work, mainly because it's so vastly different from web development.  The introduction of Apple Watch also seems to be a great opportunity on many levels.  I'd love to attend WWDC, too.

On a personal note, 2015 should finally bring about my jaw surgery where my underbite will be corrected by moving my lower jaw backward, and my upper jaw forward in order to close the discrepancy with my bite.  This will involve a few months-long recovery process, but it is a worthwhile pursuit in terms of my long-term health.  I'm not looking forward to the procedure, per se, but I am looking forward to it being over and having recovered.  This past year was quite disappointing on this front, due my experience with an unethical and irresponsible Atlanta-based oral surgeon's office (more on that later).

I'm also looking forward to finally having flying cars, Hoverboards, and food rehydrators.

Happy New Year!

Joining ShootProof

As of today, I'm joining my friends at ShootProof as Director of Engineering.

My move to ShootProof is about getting back to what I love most: building products.  I'm looking forward to working with a small team in a nimble environment.  iOS and web development, infrastructure, technical leadership ...all of my skills are going to go to good use at ShootProof.  I'm thrilled to be embarking on this journey with them.

In addition, I get the added benefit of working with some of my most favorite developers ever: Robert Swarthout and Ben Ramsey.  The three of us worked together at Schematic (now POSSIBLE) on our Atlanta-based Open Source Platforms Group team (essentially, the PHP team).  I also get to join the ranks of many others that I'm excited to work with, such as Kevin Bandy, Terry Allen, and Colin Breece.  The entire team at ShootProof is incredible -- A+ players.  I'm going to learn an enormous amount from this team.

I've enjoyed the past two and a half years at CrowdTwist, and I believe I've made a positive impact on the business.  I've refactored some core areas of the platform, built a number of significant features, and just generally had a hand in many significant advancements during this time.  I've also helped grow and lead the development team in many ways.  I've gained so much from this experience; it's allowed me to further my skills and career in many ways.  It's truly been an incredible ride, and I depart very proud of what we've all accomplished together.

The ShootProof team is going to continue to impact the lives of photographers around the world, and I'm very proud to have a chance to make my mark.  Buckle up.

Technical New Year's Resolutions: 2014

In reviewing my 2013 Technical New Year's resolutions, I give myself a solid B-, maybe a C+.

I've been completely slammed and overwhelmed with my day job at times, which has contributed to my lack of focus on things outside of work. It's also worn me down at times, and left me with little motivation. That's no excuse, but a human being can only take so much.

If I reflect on my goals...

  • I did some more speaking, this year at Atlanta PHP, CoderFaire, and Emory University.
  • I built some great software at work, which I'm really proud of.
  • I shipped some decent updates to FloodWatch, but not a major 2.0 version. However, I will ship a major update (with iPad support) to it in the first few days of 2014, so this goal is 75% complete.
  • I didn't blog much at all, which is disappointing. This one evades me every single year. I need to be better about it.

So for 2014, I'm keeping it simple:

  • Ship great products: Nothing else matters. I'm going to ship the best stuff I can all year, both at my day job, and in my spare time.
  • Find fun and satisfaction in all that I do: Not all work is fun all of time (which is why it's called "work"), but I need to strive to find positives in all that I do, or if I can't, cease doing them. If it's not fun and satisfying in some way, then it's not worth doing. Period.
  • Say "no" more: I'm a chronic overachiever who tends to overcommit myself. This year, I'm going to guard myself from being overcommitted. If I can focus on the goals above, shipping and focusing on enjoyable work, then this should be easy.

Wish me luck. Happy New Year! 2014 is going to rock.

Top Ten List + CoderFaire Atlanta 2013

Back in March, I gave a new talk at Atlanta PHP: "Top Ten List: PHP and Web Application Performance". This talk is a culmination of my ~14 years of experience primarily as a web application developer, but also as a systems administrator / DevOps-type.  After working with PHP and web applications for so many years, I have amassed quite a few tricks for squeezing maximum performance out of web applications, PHP or otherwise. I'll be presenting it again at CoderFaire Atlanta on April 20, 2013.  CoderFaire is organized by a fantastic crew of Cal Evans, Kathy Evans, Chris Spruck, Kevin Roberts, and Jacques Woodcock, so it's going to be a great event. I've never attended a CoderFaire event before, but I've only heard positive things. Because it's not limited to a single technology platform, you're sure to meet a wide array of technical minds from all different backgrounds. I'm sure we'll all walk away with some fresh, new ideas from this diverse crowd.

At only $50 per ticket, you're not going to find a better deal on a technical conference this year. Register now!

As a little teaser, here are each of the 10 guests introducing the topics.  Come on out for the juicy details. Be prepared to go home, sit down, and optimize some aspects of your web application, though!  See you there.

10. Elizabeth Naramore, GitHub: Tweak your realpath cache settings

9. Scott Rocher, Tonx Coffee:  Whenever possible, use offline processing

8. Matthew Turland, Synacor: Write efficient SQL queries

7. Scott Lively, 3SI Security Systems: Don't execute queries in loops

6. Jed Lau & Maggie Nelson, Findery: Know what your application is doing

5. Robert Swarthout, ShootProof: Use gzip compression on responses

4. Ian Myers, Findery: Do not use .htaccess files

3. Ken Macke, RockIP Networks: Cache all the data that you can

2. Davey Shafik, EngineYard: Use a content delivery network

1. Ben Ramsey, Moontoast: Use APC and set apc.stat = 0