Forem: Lee Jarvis

Interactive Shells in Capistrano

Lee Jarvis — Wed, 16 Oct 2019 15:57:41 +0000

Capistrano is a very popular deployment tool written in Ruby. If you've deployed Ruby or Rails applications, chances are you've heard of it even if you haven't had the chance to use it.

Capistrano was a crucial part of our deployment process at Loco2 long before overhauling our hosting infrastructure with Terraform and Docker.

Having recently left Loco2, I found myself back on a project that uses Capistrano. As powerful as it is, it frustratingly doesn't include support for interactive shells. Whilst this is by design, it's a bit annoying if you want to boot a rails console or run another command that allows input from the user.

After doing some Googling I managed to piece together something that calls ssh directly, allowing us to run a command in an interactive shell:

namespace :rails do
  desc "Start a rails console"
  task :console do
    exec_interactive("rails console")
  end

  desc "Start a rails dbconsole"
  task :dbconsole do
    exec_interactive("rails dbconsole")
  end

  def exec_interactive(command)
    host = primary(:web).hostname
    env = "RAILS_ENV=#{fetch(:rails_env)}" # add other ENV variables
    command = "cd #{release_path}; #{env} bundle exec #{command}"

    puts "Running command on #{host}:"
    puts "  #{command}\n\n"

    exec %(ssh #{host} -t "sh -c '#{command}'")
  end
end

The primary(:web).hostname just fetches the hostname for the first/primary web host. It's worth mentioning this because it might not be desirable. You could quite easily fetch all of the remote hosts and provide a menu that allows the user to select the host they want to connect to. For my purposes though, I just wanted to run a rails console without having a custom script that fetched our hostname via the AWS command line tools.

You may want to consider safeguarding production access by adding a warning message when fetch(:rails_env) == "production", or perhaps add the --sandbox option to protect your data.

I believe developers should be trusted to have direct access to all live
environments, including production. These sorts of small convenience scripts really help to avoid friction when troubleshooting or debugging data issues on non-local environments.

Clean Ruby Codebases

Lee Jarvis — Tue, 02 Jul 2019 15:51:00 +0000

original article: https://leejarvis.me/posts/2019/clean-ruby-codebases

I enjoy reading code. Even the smallest snippet from a distant corner of
an obscure library or plugin could be enough to spark a new idea, and
at the very least it might evoke interest, repulsion (usually when reading my old code), or simply teach me something new.

As the saying goes, code is read much more often than it is written. It takes many years of experience to write great code, and nobody gets there without having read a lot of it.

I started writing code before JavaScript became popular, when learning
HTML meant copying the contents of your favourite website's source code
and tweaking it to fit your purpose. New websites introduce new HTML tags and CSS rules, long before the prominence of w3schools.

Naturally I became a bit stuck when I started learning server-side
languages. At the time I couldn't really afford the books; I really
wanted to sample everything and see what sticks.

Reading code I couldn't understand became regular, even nuking several
OS installs during my frivolous experimentations didn't stop me. I learned to appreciate clean, well-written code before I could really write it myself. GitHub eventually came along to make this experience effortless.

When speaking to new developers I have a few examples I use to
demonstrate what I appreciate as well-readable Ruby code. There's
a level of subjectivity to this of course, but for me, clean code:

Is straightforward and obvious
Is easy to digest
Generally follows common style best-practices
Is well structured
Avoids too much magic/metaprogramming
Contains comments only where they are helpful

So, without further ado, here are a few of my favourites:

Sidekiq

Sidekiq is a library for processing background jobs. It's pretty much
considered the go-to tool for Ruby and Rails developers who want to store
their queue data in Redis. What is a fairly complex piece of software
is written so well that it basically holds your hand along the way.

Sequel

Sequel is a database toolkit for Ruby. It's a strong replacement for
ActiveRecord and is my ORM of choice for non-Rails projects. It's 12
years old and was one of the first Ruby libraries I ever encountered.

Oga

Oga is an XML/HTML parser written in Ruby (crazy, right?). Whilst
Oga is no longer maintained, it remains a good example of nice-to-read
code.

Hanami

Hanami is a young Ruby web framework. It's designed to combat the extreme
bloat that Ruby on Rails introduces with its "everything including the
kitchen sink" approach. The project is split into smaller pieces making
it easy to digest and poke around.

HTTP

HTTP is my go-to Ruby library for making HTTP requests. It's fast, easy
to use (who on earth remembers the net/http syntax?), and with a lack
of "magic" code, it's really easy to understand what's happening under
the hood.

Do you have any favourite codebases?

What's your ideal software stack?

Lee Jarvis — Thu, 20 Jun 2019 18:52:15 +0000

With technology moving as quickly as it does, this question rarely fails to elicit interesting conversation.

From frontend JavaScript frameworks to infrastructure; what's your ideal software stack and why?

SwiftUI ScrollViews

Lee Jarvis — Thu, 20 Jun 2019 08:08:55 +0000

Original post: https://leejarvis.me/posts/2019/swiftui-scrollviews

I recently wrote about my WWDC highlights, and how SwiftUI was a huge surprise announcement for me. I decided to have a play and build something small.

A few years ago I created an iOS app that tracks gift ideas for family and friends. It's not something I ever published to the app store, but I do keep it for personal use.

The app isn't particularly exciting. It stores gift ideas and keeps track of birthdays, anniversaries, etc. On the app homescreen I have a
horizontal scroll view that shows some of my upcoming events; "Mum's birthday", "My Wedding Anniversary".

These event "cards" were made up of a name and a custom emoji/background colour. To drastically simplify, they looked something like this (but better, I promise):

The ScrollView wasn't especially difficult to build, but asking AutoLayout to
play nicely across all devices in any orientation wasn't exactly my idea of fun. Not only was it tedious and time-consuming, it was really sucking
the fun out of creating the app.

With SwiftUI, I was able to re-create a similar ScrollView with just several lines of code:

import SwiftUI

struct Event: Identifiable {
    let id: Int
    let name: String
    let emoji: String
    let color: Color
}

let events = [
    Event(id: 0, name: "Jon's Birthday", emoji: "🥳", color: Color.red),
    Event(id: 1, name: "Wedding", emoji: "👰", color: Color.blue),
    Event(id: 2, name: "Aimee's Birthday", emoji: "🎉", color: Color.green),
    Event(id: 3, name: "Christmas", emoji: "🎄", color: Color.purple),
]

struct ContentView : View {
    var body: some View {
        ScrollView {
            HStack {
                ForEach(events) { event in
                    VStack {
                        Text(event.emoji)
                            .font(.system(size: 50))
                        Text(event.name)
                            .font(.system(.caption))
                    }
                    .padding(40)
                    .background(event.color)
                    .cornerRadius(10)
                }
            }
        }
        .padding()
    }
}

This is the entire file. Go ahead, paste it into Xcode 11 beta.

No AutoLayout constraints, no Storyboards, no testing across every device just to be sure I didn't break something. The UI exists right here in the code.

The declarative syntax really makes the code easy to read and write, and
using Xcode's powerful built-in documentation and suggestion tools,
I found myself creating the user-interface is a very natural way.

This was built on macOS Mojave, which doesn't have access to the live
preview canvas and drag+drop behaviour. This meant I had to rebuild the
app each time to preview my changes. No bother, I've been doing that
for years. I can only imagine how much better this is on macOS Catalina.

I've been watching some of the WWDC session videos too. Here's some good ones on SwiftUI:

All WWDC videos can be found here.

I'll be continuing to play with SwiftUI and may write a post or two in
the coming weeks. I am incredibly excited for this technology; it makes
building mobile applications much more accessible. Finally, for me, iOS
development is fun again.