I recently listened to an interview with Seth Davidson on The SoCal Cyclist Podcast. Definitely worth a listen. Seth is the proud owner and author of the Cycling in the South Bay blog. He has no shortage of opinions on all things cycling, most likely because he loves riding his bike. He loves it so much that he participates in this strange sport known as bike racing. His interview got me thinking a bit about racing. My (random) thoughts follow.
I’m not sure how many of us in tech are hunting werewolves, witches, or monsters, but there are A LOT of us looking for silver bullets. Take one look around at the world of software development and operations today and it’s baffling. A perfect example of what I’m talking about can be found in this CircleCI blog post, which sounds like nonsense but actually sums up the current state of software development and operations quite nicely. Maybe we’re not looking for silver bullets. Maybe we’re looking for the gold bullet, then the platinum bullet, then we move onto missiles, bombs, etc. It never ends.
I’m not talking about the evolution of technology as a whole. We have a desire to always learn and progress. What we have in software development and operations today is a hyper spin cycle of the next shiny object. Very little of it gets mature enough before it’s thrown out in favor of the new-new silver bullet. Unlike the last silver bullet, this one will kill werewolves AND witches. If you’re a software engineer caught up in this never ending hype you can find yourself using all the latest and hottest tech with so much complexity it will melt the minds of mere mortals. This happens rather easily because the hottest tech often comes from companies like Google, Facebook, Netflix, etc. who are solving extremely large and complex problems. They are generously (and often strategically) open sourcing a lot of that work, which turns into the hottest tech of the month club. But most of us are not solving problems at that scale. When we take their tech and apply it to our problem we can easily find ourselves with a lot of moving parts when only a few would likely suffice for our problems. Multiply this problem by the output of the firehose of “innovation” happening. I put innovation in quotes because what comes to us in the guise of innovation is often a company’s hope to ever so slightly improve upon a good enough solution and take away market share in the process. Even when there is legit innovation, the benefits of adopting a brand new stack or even layer in the stack are questionable when weighed against building upon a solid foundation.
Again, to get the best grasp of what I’m referring to, read the CircleCI blog post. It’s short, funny, and maddening all at once. We need to stop the never ending pursuit of the silver bullet and figure out a more sustainable way to build great services people find value in. Otherwise, I’m afraid we’re spending too much of our time porting or, worse, figuring out how to port existing stuff that works well onto something that is now deemed “better”.
Fred Wilson has a short post on the state of chat bots. Surprise, surprise – chat bots haven’t taken over the world. One of the main culprits? Artificial intelligence (AI) and natural language processing are not there yet. I’m happy to see these posts that combat much of the hype surrounding chat bots and take a more realistic look at where we’re at and where we might be headed.
I do think chat bots will continue to see growth, both in the number of people using them and in the capabilities of the bots and platforms that host them. With so many people using text messages (in whatever their choice of messaging service is), it makes sense that a lot of interactions should happen within the messaging/chat context. I’m mostly impressed with bots targeting teams/groups at this point, but I might be biased. Bots make a lot of sense in that setting because they can quickly help everyone in the group. A simple example would be the group lunch. Getting agreement on when and where to eat can take a miracle. There are bots to help simplify that process. Again, a simple example, but there are many more out there where teams are more productive due to having information and the ability to take action on something within the flow of a chat. Little to none of this requires AI or natural language processing. Those technologies are getting a lot of attention and investment. It’s only a matter of time before chat bots make use of them in a way that makes sense.
Are chat bots THE NEXT BIG THING? Probably not. They’re a nice step in making chat smarter and better. I think they’ll grow in importance for some use cases and shrink for others. As Fred pointed out in his post, it’s (already) past the hype cycle for chat bots and into the figuring it out phase.
I’m not sure who obsesses more over their weight – the covers of popular magazines displayed in grocery store checkout lines or road cyclists. My bet would be on the latter. Unlike the magazines, cyclists point to fancy sounding terms like, “power-to-weight ratio”, which basically translates to: how much power you can generate pedaling your bicycle versus how much you weigh. Power-to-weight ratio is particularly important to those who ride up hills on their bicycle, aka “climbing”. The less weight you have to haul up the hill the better. Makes sense. Nevermind the weight obsession.
At the beginning of this year I determined I was only going to target one main cycling event, The Ultimate Challenge in Utah. It’s the sixth stage of the Tour of Utah and it’s full of climbing. Over 10,000′ in total.
I was at 180 lbs in January, 2016. I’m 6′ 2″, so that weight is not bad. But, I wanted to do better on the bike when it came to climbing and knew that the most significant improvement I could make was losing weight. I also knew how to do that. The question was how much weight I should target to lose. I was concerned about losing weight while training at the same time. As absurd as that sounds, it can be legitimately awful to restrict your calories while putting in miles on the bike on a consistent basis. Losing weight and cycling don’t necessarily go hand in hand. I knew I’d have to balance getting stronger on the bike with losing weight so that I didn’t burn out or make my body vulnerable to every sickness known to man.
Ever the healthy example, enter pro cycling. (Done laughing yet? Me either.) I learned that most pro cyclists are in a height-to-weight ratio of 2.1 to 2.3. That means you take your height in inches and multiply it by those numbers. I’m 74″ tall, so I was looking at a target range of 155 to 170 lbs. The thought of 155 made me laugh a little. 170 was very doable and didn’t seem like it would push me quite enough, so I targeted 165 lbs. as my ideal weight to get to by the end of June. Since I started losing weight in earnest in February, that gave me 5 months to lose 15 pounds. Losing 3 pounds a month is very reasonable. I felt comfortable with that goal being attainable while not pushing me to reach an impossible balance at meal time and training on the bike.
I lost the first 10 pounds fairly quick and I was feeling good on the bike. I don’t have a power meter for my bike, so the whole “power-to-weight ratio” was going to have to be measured in less scientific ways. I went by feel and some far less scientific measurements in regards to my times up various climbs in the area. Sure enough, I was seeing results and I felt really good. I decided I would set my weight loss target to 160. While the first ten pounds came off fairly quick with small changes in my diet, the next ten didn’t come off so easy. I had to tighten up on my calorie counting and there were a number of nights I went to bed and felt hungry. By the end of June I was in the range of 160-162. In July I was able to settle into my weight. Perfect timing.
The ride is over. I’m happy with my effort, had fun out there, and my body feels good overall.
In regards to my weight loss in preparation for this ride, my takeaways are:
- Target a healthy and attainable weight several months in advance of the event
- Don’t try to lose more than 1 lb. per week
- Be prepared to be hungry when you train
- Don’t starve on long (2+ hour) rides – hydrate and eat (I target ~60g carbs per hour after the first 2 hours)
- Do closely pay attention to what and how much you eat throughout each day, even (especially?) on hard training days
- Plan on hitting your target weight weeks in advance of the event
- Stabilizing weight at this time is important so that the focus is on peak strength in regards to conditioning, recovery, and nutrition
I recently built (on top of the Botkit framework) and launched a Slack chat based game, emojination. I started out running emojination on Heroku. It was cheap and fast to get up and running there. Heroku does some really nice things for developers that shields the complexity of Amazon’s AWS. However, once I had emojination running well enough on Heroku, I wanted to learn AWS better. I knew about some of the services at a high level and used some of them on projects operationally, but I had never built anything on top of them myself.
I could run everything on “native” Amazon AWS services except Redis, which I was using for Botkit’s storage. While Amazon has a Redis based service, it is meant for caching. I could run Redis on EC2, either running the setup myself or using a 3rd party that makes it simpler to setup and maintain. While those options were reasonable, I wanted to see if I could make use of Amazon’s DynamoDB, since it’s a perfect match for the job (a key/value store), doesn’t require ops overhead on my part, and comes with some AWS free tier incentives. Yep, lock me up in the trunk and throw away the key.
The only problem was that there wasn’t a Botkit storage module for DynamoDB. There was one for Redis, MongoDB, Firebase, etc. but no DynamoDB. Seeing as I have near zero Node.js skils, I thought, “how hard can it be to create the DynamoDB Botkit storage module?” Not too hard, as it turns out, except for the part where I need to still figure out how to get the tests passing where promises are involved. The bulk of my time was spent figuring out how DynamoDB worked and what the options were in regards to npm DynamoDB modules. I ended up using the Dynasty module, which has a nice promise based approach. I found a few surprises along the way working with DynamoDB, but everything is running smoothly now, with emojination using it for both read and write operations.
The end result is there is now a botkit-storage-dynamodb module available for all who are interested in using DynamoDB with their Botkit based bot. A small contribution that has helped me learn quite a bit in a short period of time. ❤️