So you’ve signed up to give a tech talk, awesome! You’re a subject matter expert in something and want to share you knowledge, that’s what helps make a community awesome. You’re going to be speaking in front of a room of people that you don’t know in a place you’ve likely never been, talking about something you confidently know. Sounds easy, right?

The conference started off with a heady fulfilling talk from John Allspaw about the impact of human performance in automatable systems. Wrapping the crux of his argument around the 3 Mile Island nuclear disaster, he drew parallels to how automation in software suffers from those same issues and how the automators should attack these problems.

We recently removed webpacker from our Rails 5 application. While it was a great way to bootstrap a new Rails app with a significant amount of Javascript we encountered some serious performance problems that we felt really impacted our productivity. We build our application images after every git push and we’d like to be able to deploy them quickly.

Imagine you are driving a car on a freeway. Your speedometer is telling you you’re going 62 mph. But you “gotta go fast”. Faster than then 65 mph speed limit. So you go for it: first 68mph, then 75mph, then 80mph. Then you pass a police officer hiding in a speed trap. To your dismay, they pull you over and give you a ticket. All is not lost: there is a silver lining here.

If you’re running a production application, you need metrics. There are great products out there that allow you to gain visibility into how your application is performing, give some nice graphs, and charge you for it. In the Rails community, this is commonly achieved by using NewRelic and Skylight. But for some of us, we achieve visibility by using Prometheus and Grafana that we build and host ourselves.

Istio is a hot technology right now. Giants such as Google and IBM have devoted entire teams of engineers to the project to push it to production readiness. Since 1.0 has been released recently, I wanted to write down some of the things that confused me coming from a strictly Kubernetes only world where we have Ingress controllers and Service load balancers and how Istio takes these same concepts but on stimulants.

Docker Compose is a great tool to develop your Ruby on Rails application locally. It allows you to easily isolate your ruby environment, database, and even Redis if you use something like Sidekiq.

Writing Go applications in an isolated environment with Docker comes with some great advantages. You get a clean GOPATH, the bare essentials for developing, and you can easily change which Go version you’re developing against. In this quick tutorial, we’re going to show you how to structure a Go application with Docker Compose as your development environment.

FireHydrant.io has a changelog feature with a Kubernetes integration. Building this integration was challenging because the knowledge about creating an event oriented system with the Kubernetes client-go project was not as easy to understand as I would have hoped.

At FireHydrant we use Redux Form for all of our forms. It is extremely easy to build complex form logic with all sorts of added bonuses that make using it in our React/Redux front end a no brainer. However, when we started using React Select for our select fields we started running into some issues. You are likely running into some of the same issues we did and so this blog post will help get you off the ground and integrating these two libraries together.