I often get asked about recommendations for resources to learn Ruby (and how to program, generally). This list is intended to catalogue the various resources I have shared over the years and be an easy reference point for future learners.
This is my go to recommendation for learning the Ruby language from scratch. You'll complete a number of exercises in the form of tests. Your goal is to get each test to pass by writing Ruby code. As with most $language Koans library, it starts off very easy and then ramps up in complexity.
Specifically the Ruby portion of the "Full Stack Ruby on Rails" course. This course covers off almost all of the basics that you would need to be productive with Ruby in a project that isn't super complex.
One of the joys of the Ruby world is that someone is coming out with a Cool New Thing™ almost all the time. This can be hard to keep track of, and I have found Ruby Weekly a great resource to keep on top of all of the happenings in the world of Ruby. There are similar newsletters from the same publisher for other languages, too.
These timeless videos from Avdi Grimm illustrate the why behind a lot design patterns we employ every day, using real examples to help solidify the benefit of following these patterns.
Garry Bernhardt — Watch
Thinking about the boundaries of and within systems can be tricky for new programmers. This talk does an excellent job of introducing the topic and providing concrete examples to take with you throughout your career.
Jim Weirich — Watch
A detailed introduction to functional programming with Ruby, via first principles of lambda calculus.
Tom Stuart — Watch
Dealing with unwieldy code using monads to help simplify presence or absence of data in our apps.
Sandi Metz — Watch
Another journey through a hairy refactoring, this talk takes an ugly section of conditional code and converts it into a few simple objects. It bridges the gap between OO theory and practice and teaches straightforward strategies that all can use to improve their code. Also, checkout Sandi's book at Practical Object-Oriented Design, An Agile Primer Using Ruby.]]>
I have a couple of small hobby apps that were on Heroku's free tier (RIP) that I have now moved over to Fly.io. Fly.io has a migrate from Heroku process for Rails apps, but as far as I could see, not for any Ruby app. So I had to do things manually, and while deploying to Fly.io is super simple, there were a couple of small things that tripped me up that I thought I'd write about here in case any one else is also trying to deploy a Hanami 2.0 app to Fly.io.
After you've setup an account on fly.io and have installed the command line app, you can then follow the docs for setting up a Ruby app.
While running through the
fly launch setup, you should get the option to setup a Postgres database. If you do, the URL will be available as an environment variable in
fly launch has completed, you should have a new
fly.toml file in the root of your project.
Before deploying your application, you'll need to make a couple of changes specific to Hanami 2.0. The
fly.toml below is where I landed in terms config for a small, simple app. The biggest changes from the generated file are as follows:
bundle exec puma -C config/puma.rb
["web"]) and the internal port to listen on
Once you've filled out your
fly.toml, you can run
fly deploy to send your first build to fly.io.
If you're familiar with Heroku, there's a similar build and deploy log on fly.io. Though I have found it to be not as detailed as Heroku, it has been enough to surface any config errors and correct them, so keep an eye on it as it'll surface any obvious issues.
Once your deploy is working, you likely wont need to change anything for a little while, so, if you're hosting your code on Github, you can setup an action to build and deploy on a successful build.
An example GitHub action to build and deploy a Hanami 2.0 to fly.io]]>
It's not often that I get a new computer, but on the odd occasion that I do, I like to have all of my config prepared and ready to copy over!
To achieve this, I am using chezmoi and GitHub to keep an up to date snapshot of my dotfiles. My previous tool of choice for managing dotfiles was rcm, but chezmoi offers things like password manager integration, scripts, and templates to customise dotfiles based on the machine I am setting up, making it just that little bit more useful.
The initial setup of chezmoi is super straightforward, just:
chezmoi init chezmoi add ~/.my-first-file chezmoi cd # follow your usual git workflow to add a remote and push
Then, to pull down and apply your dotfiles on another machine, run:
chezmoi init --apply $github_username
From here, the workflow of adding and updating files is essentially:
- Edit the source file on your machine
chezmoi add ~/.file to commit and push to GitHub
The chezmoi FAQ lists a couple of other ways you can keep a file in sync, including
chezmoi edit and
chezmoi merge, but I have found
add to be the simplest.
Chezmoi also makes it simple to run scripts when you run
You can decide whether a script is
run_once_ when you first run
chezmoi apply, or
run_onchange_, which will run every time, provided the file has changed.
The scripts I have at the time of writing are:
run_once_00_install-xcode-devtools— Does what it says on the tin, installs Xcode's devtools
run_once_01_install_homebrew— Installs Homebrew if it's not already installed
run_onchange_after_brew-bundle— To run
brew bundlewhenever the
run_onchange_after_configure-macos— To configure a bunch of
macOSand LaunchBar defaults.
Having a look through the chezmoi docs, you'll see there's a bunch more you can configure to meet your specific requirements, but hopefully this has provided a brief insight in to what is possible, and how easy it is to get started with a simple setup.]]>
Like most people*, I like to name the various devices in the house after a theme. For the longest time, my devices were unnamed, until I moved to Apple's ecosystem and picked up my first external SSD for time machine.
My chosen theme was the Metal Gear series, so naturally, the drive was named Solid Snake, and my MacBook was Roy Campbell. Fast forward a couple years and now the lineup looks like:
The only annoying thing is that Air Drop shows the device name as a destination (which makes sense), but doesn't show who owns the device. A solution to this would be to leave everything as "Daniel's Whatever " — but where is the fun in that.