What a ride this morning. And thus, I have two tips. One for drivers. One for cyclists. Here goes:
Drivers. Three lanes with no traffic except one pickup truck and me. The driver of that truck got within inches of me, even slowing down as if to prove a point. As the driver (finally) sped away, I saw numerous HGH decals plastered on the truck. If you’re going to get that close to me, please hand out samples, alright? OK, now for the real tip: If there are 3 lanes for you to drive in and one is occupied by someone on a bike, it’s best to use one of the other lanes if at all possible. You’ll get to go as fast as you want and the person on the bike will be happy. Win-win.
Cyclists. Unless you’re trying to be a ninja on a mission of (your own) death, PLEASE PUT ON SOME LIGHTS. I know, you won’t be as aero. I also know that some of the cool kids around town might think you’re a dork. But guess what? You might actually be noticeable versus several of the riders I (just barely) saw early this morning before sunrise cruising around with zero lights. Sure, some wore “high visibility” pieces of clothing, but that does you no good in the dark. Put a solid white light on the front and a red light on the back. Give yourself a prayer out there. HGH pickup truck driver will probably still get within inches of you, but most other drivers won’t because they’ll see you before it’s too late.
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”.
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 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. ❤️