When a service user completes a blood test, there are some reactive results which require the service user to be sent to a clinic for a retest. As the system stands, we store these retest results for all HIV tests. Last week we were hit with a feature request to roll this out across all other blood tests.

In this blog, I will outline the approach we took and how we applied concepts of Domain Driven Design to do so.

How do we model referring Service Users for a clinic retest?

When a service user receives an reactive blood test result, we refer them to a clinic to get a retest, and then the clinic report the results back to us.

We need to break this down into requirements:

• When the Service User receives an reactive blood test result, we refer them to a clinic for a retest.
• The clinic reports the retest result back to us and we store this against the Service User’s order.
• The referral to clinic only applies to blood tests.
• Should be compatible with any future blood test types.

Let’s map this out on a diagram:

From the diagram above, we can begin to workout how we can implement this:

• Upon the first reactive result being delivered to the user, we can create a clinic retest result, with either a blank result or a result which represents a “default” state.
• Keep the default state until more information is received.
• The retest result has been received and is logged in our systems — update the clinic retest result to the correct result.

With the above, let’s update our diagram:

A few assumptions:

• At some point, the user will attend the clinic. If this does not take place, the retest result will stay in the default state indefinitely.
• The default state is set automatically but once the retest has been done, this will be updated manually by a system user.
• Once it has been updated by a system user, it will not be changed again. Of course, unusual circumstances like incorrect results can happen, but in this case the retest result will not be updated via the UI.

Database Structure

Armed with the above requirements, we can now create the database structure:

With this underlying database structure, we can use this to build our UI.

To summarise: take the feature, think closely around where each small part fits into the larger domain; this small amount of fore-thought makes the implementation easier and ultimately faster too.

From concept to reality: clinic retest results was originally published in SH:24 Product & Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At SH:24, we use ViewComponents in most aspects of our UI. It has helped us to make reusable UI elements, and have a consistent UI across our application.

What is ViewComponents?

ViewComponents is a framework for building and testing reusable UI components. According to the documentation, ViewComponents is an evolution of the presenter pattern, inspired by React.

Why we use ViewComponents?

Single responsibility

In the worst case, Rails scatters logic across views, models, controllers, services and helpers, this can make it hard to follow logical chains and distinguish what is responsible for what.

With ViewComponents, all the logic related to a particular view is encapsulated within a ViewComponent, which can then be added to any part of your application.

Testing

As all the logic is encapsulated within a ViewComponent, we can write separate and uncomplicated unit tests for a ViewComponent, with special cases covered at a unit test level. This also allows us to leverage the Capybara matchers library too.

We’re now free to test the end-to-end assertions in integration or feature tests, without checking for the pesky special cases covered by the unit tests.

These ViewComponent unit tests are also quick. As mentioned in the ViewComponents documentation: “In the GitHub codebase, ViewComponent unit tests are over 100x faster than similar controller tests”.

Reusable

One of the biggest reasons why we use ViewComponents is the ability for us to create reusable UI components across the application. This allows us to have a standardised UI across the application, and also helps us to build an internal design system and style guide.

How do you implement a ViewComponent?

Let’s take a look at this simple view below, which renders a header and a list of blog posts:

h1 This is the header for my BlogPost website
- @posts.each do |post|
  p= post.title

We can move the part which renders the blog post list into a ViewComponent. First, we will create the ViewComponent ruby class:

# app/components/post_list/component.rb

class PostList::PostList::Component < ApplicationComponent
  def initialize(posts:)
    @posts = posts
  end
end

Now we have the class, we can move the view logic, within this directory:

#app/components/post_list/component.html.slim

- @posts.each do |post|
  p= post.title

We can now replace the post lists, in our view, to render this newly created component:

h1="This is the header for my BlogPost website"
= render(PostList::Component.new(posts: @posts))

This allows us, to drop the PostList::Component anywhere in our application, and the UI is consistent throughout!

So, should you use ViewComponents?

There are a few cons to using the ViewComponents library:

• As ViewComponents is a separate gem, it does mean adding another dependency to the applications, and setting this up. However, the setup is not complex.
• You can do encapsulate view logic, using partials, service classes and presenters. However, unit testing this logic separately is tricky. This is not an issue with ViewComponents.

We’ve definitely found that the pros of using ViewComponents outweigh any cons, as encapsulating view logic in a separate area of the app is good for maintenance, reusability and overall developer happiness!

Have you used ViewComponents in your applications? Do you prefer partials? Something else? Start a (respectful) argument in the comments!

ViewComponents For UI Happiness was originally published in SH:24 Product & Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Brighton Ruby?

Brighton Ruby is a Ruby conference held in Brighton, England. The day comprised a single track event of talks, as well as a great opportunity to speak to the sponsors and, of course, a whole lot of other people who use Ruby in different ways.

Why did we decide to go?

Personal development and training is very important. I went last year as part of a smaller team and we soon realised everyone could benefit from attending, and besides, it’s a day away from our desks and a chance to meet in person; a rarity as a fully remote team.

Highlights

The importance of documentation — Kaitlyn Tierney

I’ll talk about three talks that leapt out at me specifically: the first of which was around documentation. I’m pretty sure most developers would agree it’s something we tend to neglect, and also I probably wouldn’t be alone saying it’s one of the less fun parts of our job.

However, this talk really opened my eyes as to why we should keep documentation at the forefront of everything we do, as well as being a good guide on how to get started. The speaker demoed the layouts they use and showed us the importance of accessibility, as well as how quickly and easily you can take small steps to achieve it, like adding clear titles and headings.

Hanami 2.0 — Tim Riley

Hanami is another framework built with Ruby. This talk demoed the new features of Hanami 2.0 and it was done in the style of Ricky Martin! The way it was demoed was through the evolution of the song Livin’ la Vida Loca. It was a unique take, to put it mildly!

What stood out for me was how conceptually different it was to Ruby on Rails. I’m not sure if it’s yet mature enough to adopt at scale, but Hanami is gaining traction and I can see it potentially kicking off in the future.

Game writing using Ruby — Joe Hart

This talk was interesting and involved a lot of audience participation. The speaker played Pacman on stage, playing as the titular Pacman, and the audience were all ghost characters. All done by connecting to a server from our phones and playing live. It was an amazing way to end the conference, and proved Ruby had the chops to do something massive(ish)-ly multiplayer.

There was one key message which the speaker mentioned that stood out to me: “Build anything, but build it for fun”.

What I got out of the day

Even though the talks were excellent, and I enjoyed discussing them with the team, I think the thing that hit me most was a new optimism for the Ruby language and my career in general.

It is often loudly announced that Ruby is a dying language. But after attending this conference it made me realise that Ruby is well and truly alive, and the future is still bright for this language.

What the team got out of the day

I asked the team, to write one highlight from the day. Here are their responses:

• A great day out catching up with the team again
• Loved the talk on documentation
• Left with a boost of ruby enthusiasm! A fun day with the team

As a fully distributed remote team, we often don’t meet up for months on end. Going to Brighton Ruby was a chance for us all to meet up in person, have some lunch, catch a drink after the conference and reflect on both the day, and how we can apply what we have learned to our day-to-day life at SH:24. Additionally, a team member was leaving the company, and attending this conference was a great way for us to send them off in a social, offline way. Perfect!

Brighton Ruby 2023 was originally published in SH:24 Product & Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pair programming is a common working practice in software engineering. It involves two or more developers working together on a given problem. Usually, programmers would sit in front of the same computer.

Here at SH:24, the development team is a fully remote and distributed team. And pair programming can be challenging sometimes but we make it work.

Utilising huddles in Slack

The huddle tool in Slack has been amazing for us, and has changed the way we work. Whenever we are stuck on a problem, and want some help, depending on what we are working on. We would either shout on in the wider team channel or shout out in our sub team channel.

Once someone is available, we would start a huddle on the team channel and get pairing. Where possible, we always try to do huddles on the team channels, as anyone can jump in if they are curious

Driver and navigator role

When we pair program we use the driver and navigator role. Simply put, the driver writes the code, and the navigator reviews the code and plans. We find this works seamlessly while working remotely.

When pairing with junior members of the team. Where possible, we always try to let them be the navigator.

Every 30 minutes or so, we switch roles to get different perspectives.

Benefits of pair programming

Consistent feedback

The person writing the code (the driver) receives constant feedback. As the code is written in a collaborative way.

Less frustration

We have all been there, we have been trying to crack a problem for a long time and not getting anywhere. What better way to crack this, than getting a fresh pair of eyes onto the problem?

Focus

When pair programming, there are no distractions, as you and your pairing partners will be so engrossed in the problem. Which, in turn, leads (sometimes) to more productivity.

Social interaction

Remote working can get lonely, pair programming allows you to work with others. Also, it gets you talking and communicating with others, which always helps.

How we pair program as a remote team was originally published in SH:24 Product & Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.