The term “service object” can mean different things depending on who you talk to or what project you inherited, hence why I put them in quotes. Since there’s not really a “Rails Way” to put business logic, it was common to shove everything into Active Record models. When that went awry, the concept of service objects came onto the scene and provided a pathway for storing domain logic in plain Ruby objects.
Adding rich text editors to a project has a long history of friction and frustration in development. Whenever I’m asked to add a text editor, I naturally do whatever I can do to avoid them completely. That, or make sure I do extra meditation in preparation for weeks of pain.
It’s nice to see you again. One of the toughest part of writing for me is taking the time to actually write. An unfortunate side effect of running a company (for me anyway) is the sheer amount focus it demands in order to maintain the level of successful and serve my clients the best way I can.
Why should we deploy our Rails applications to Kubernetes? Traditionally we’ve deployed our applications to the cloud using services like Heroku or on virtual private servers on Amazon EC2, Rackspace, or Digital Ocean using a custom set of Ansible scripts to automate the process. This has worked well an still continues to work well, however we run into issues with scaling our servers to meet users demands and upgrading hardware and software isn’t always easy without downtime.
In Part 1 in this series, we’ve setup our accounts, installed the required tools we need to deploy our Rails application to a Kubernetes cluster. We’ve even started working on our Rake file that we’re using to document our steps and interface with our cluster. In this post, we’ll expand our Rake file to deploy our application to the cluster. In this walkthrough, we’ll accomplish the following: