When I was building Discode, I needed a reliable way for customers to update their applications without downtime. Traditional deployment approaches often require stopping the old version before starting the new one, creating service interruptions that can be problematic for production systems.
For years I have had a small collection of Rails projects sitting in private GitHub repos. Some were weekend experiments, other launched without any marketing before I moved on to the next idea. They all shared the same fate: running nowhere and earning nothing. Earlier this year I finally decided to solve my own problem and give those projects a second life. The result is Discode.
Today I read about GitHub’s release about their “GitHub Copilot Workspace”.
Recently an increasing number of companies have been on a hunt to remove unnecessary meetings from employee calendars. All of this is done to protect the time of employees and improve efficiency of the businesses. The thought being is that some recurring meetings were created, eventually become unnecessary, but never purged.
Docker is a widely known containerization strategy. One of its main use is to provide developers with a consistent environment for building, packaging, and deploying applications. I’ve used Docker containers to build and deploy many service oriented architectures. Most containers are based on the ruby:3.1-alpine image (and other close variants). While there are many resources describing how Ruby on Rails projects can be setup and run using Docker, I’d like to talk about it’s other uses.