Forem: Andrew Stuntz

How long does it take for your test suite to run?

Andrew Stuntz — Wed, 02 Dec 2020 22:45:07 +0000

I think long-running test suites are the bane of the development flow. They cause friction in what is already a fairly fraught process and often times don't even lead you to the correct results.

How long does it take your test suite to run? How many tests do you have?

Do you run those tests in the cloud? How often do you run tests locally?

Let me know. How long does it take for your test suite to run? Does it take too long?

What are the pros and cons of StimulusJS and AlpineJS?

Andrew Stuntz — Fri, 16 Oct 2020 17:37:21 +0000

I've been using StimulusJS heavily on two rails apps I have been working on and honestly, I'm loving it. But, I have been reading and hearing a lot lately about AlpineJS. What are the pros and cons? Should I be using AlpineJS instead of StimulusJS?

A Future for Rails: StimulusReflex

Andrew Stuntz — Fri, 21 Aug 2020 22:53:33 +0000

If you've been in the rails community for any length of time, you've probably heard about the desire to stay away from JavaScript.

"I like JavaScript, but I don't like it that much."
David Heinemeier Hanson, Creator of Ruby on Rails

It's easy to say that most Rails developers are anxious around JavaScript. This led to the rise of Coffeescript, Sprockets, and a whole suite of tools to allow Ruby on Rails developers to build amazing applications without having to write JavaScript.

As Rails continues its path to being a larger and more complete framework, "batteries included," there have been further shifts in the community. Included with Rails is now a more modern JavaScript packager (though Sprockets is still around if you want to use it). DHH also introduced us to a whole new JavaScript Framework called Stimulus. It allows you to use modern Javascript on your Rails projects without having to go outside the "rails way".

‍‍

Phoenix, Elixir, and LiveView

As other communities have popped up to build "rails inspired" frameworks, many of those frameworks emerged as formidable competitors to single-page applications. In the Phoenix and Elixir community, Chris McChord introduced the world to LiveView, a whole new paradigm for serving and updating HTML from your backend.

At its core, LiveView is able to leverage Websockets and update the Document Object Model (DOM) based on responses from the WebSocket connection. These frameworks are fast enough to feel "real-time".

The promise of LiveView is a return to the early days of Ruby on Rails, where we didn't have to worry so much about JavaScript and we could happily focus on our business logic. Everything else to build a robust CRUD application was taken care of using "rails magic."

Some people in the Rails community have jumped ship to the Elixir/Phoenix community. To be fair, I personally think that for most problems, Phoenix is an amazing solution.

Can Rails still compete?

Rails is nothing to sneeze at and the Rails community has taken steps towards being real-time as well. DHH recently tweeted and to let folks in the community know that much of Hey was built with some sort of frontend updating system that builds on Stimulus, Turbolinks, and the "rails way". I'm excited to hear more.

There have been other efforts to push Rails in the "real-time" direction as well. Recently I came upon StimulusReflex which builds on the Stimulus framework and a gem called CableReady that enables you to build "reflexes" that work much like LiveView does in Phoenix: sending DOM updates over a WebSocket to update the UI.

StimulusReflex could be a possible future for Rails development. I'd like to share my experience building an application with StimulusReflex.

Creating a chat app with StimulusReflex

I recently wrote a chat application that is fast, responsive, and was simple to build while leveraging StimulusReflex. I also wrote a total of 24 lines of JavaScript - you can't beat that.

Setup

It's easy to get started with StimulusReflex. It's a gem and can be installed in your Rails app by running:

bundle add stimulus_reflex

To get it up and running, simply run the install scripts:

bundle exec rails stimulus_reflex:install

This generates a couple of new starter files and directories. Including the app/reflexes directory. You'll see an example_reflex.rb and an application_reflex.rb.

You also get some JavaScript out of the box, and you'll have a newly created app/javascript/controllers/application_controller.rb and an app/javascript/controllers/example_controller.rb.

The reflexes are where the magic happens. According to the documentation, a "reflex" is a "full, round-trip life-cycle of a StimulusReflex operation - from client to server and back again. The JavaScript controllers are Stimulus Controllers and StimulusReflex is designed to hook right into Stimulus and other Rails paradigms.

Up and Running

Now that we have StimulusReflex setup, let's go ahead and start setting up our chat application. I'm going to make some assumptions.

You have a Rails application that is using Devise.

You have a Message model that includes a message and user_id attribute.

Also, I won't go into the minutiae of writing the views or the styling for the application. If you're curious, I'll link out to the entire code base for you to see what I wrote.

The first thing I did was build out a link to a view that will render our reflex enabled HTML. There is no special controller needed here, I called mine the ChatController and linked to it from my routes.rb as get /chat to: "chat#index".

Here I expose my messages to the view:

class ChatController < ApplicationController
  skip_authorization_check

  def index
    render locals: { messages: Message.all.order(created_at: :desc) }
  end
end

Then consume those messages in the chat index view:

div.flex.flex-col.mx-4
  div.container.flex.flex-col-reverse.overflow-scroll.bg-white.mt-4.rounded
    - messages.map do |message|
      div
        = message.message

You should now have a nice list of messages in your view - easy peasy.

The next step is to add in some Stimulus to create messages. We're just going to get the button click working with Stimulus right now. I added a button with a Stimulus data attribute to create_message in the Chat controller.

div.flex.flex-col.mx-4 data-controller='chat'
  div.container.flex.flex-col-reverse.overflow-scroll.bg-white.mt-4.rounded
    - messages.map do |message|
      div
        = message.message
  div.mb-4
    = form_with model: @message do |form|
      div.mb-4.rounded-md
        = form.label :message
        = form.text_field :message
        = form.submit "Message", data: { action: "click->chat#create_message" }

In app/javascript/controllers/chat_controller.js you should create a create_message handler that handles the click event from your Message button.

import { Controller } from 'stimulus';
import StimulusReflex from 'stimulus_reflex';

export default class extends Controller {
  create_message(event) {
    event.preventDefault()
    console.log('Clicked')
  }
}

Now when you click the Message button you should see 'Clicked' in the JavaScript console. I love Stimulus that is easy. You don't actually have to use Stimulus here - you can add data attributes to your HTML that will trigger reflex actions straight from your HTML.

See the note here in the StimulusReflex docs.

To connect this to our Reflex we need to import the StimulusReflex module and register it in our Controller.

import { Controller } from 'stimulus';
import StimulusReflex from 'stimulus_reflex';

export default class extends Controller {
  connect() {
    StimulusReflex.register(this)
  }

  create_message(event) {
    event.preventDefault()
    this.stimulate('Chat#create_message', event.target)
  }
}

Now when we click the button you should see a big fat error saying that the ChatReflex module does not exist. Now let's create the ChatReflex and handle our create_message action.

class ChatReflex < StimulusReflex::Reflex
  delegate :current_user, to: :connection

  def create_message
    # Create the message
    Message.create(message: params["message"], user_id: current_user.id)
  end
end

See the connection delegation at the top of the class? We need to be sure to expose that to our connection.

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = find_verified_user
    end

    protected

    def find_verified_user
      if current_user = env["warden"].user
        current_user
      else
        reject_unauthorized_connection
      end
    end
  end
end

We identify our Chat reflex connection by the current_user which uses the current_user.id to separate connections. We also add a layer of Authentication here that allows us to pick up our user from Devise when we connect to our WebSocket.

After this is created, when you click your Message button, you should now see the message returned back to view and update in real-time. It's really fast, and also super easy.

Summary of where we are right now:

Bringing it all together

So now you can connect two users to the chat room and attempt to chat with one another. But there is a small problem - you only get the other users' messages when you send a message or refresh the page. That's not very real-time at all.

Currently, the view is only re-rendered and broadcast to the current_user on that connection. But, we can leverage ActionCable to tell StimulusReflex that there are new messages that need to be rendered. Easy enough.

To achieve this, we spin up a new ActionCable channel. I called it the ChatChannel.

class ChatChannel < ApplicationCable::Channel
  def subscribed
    stream_from "chat_#{params[:room]}"
  end
end

‍
This allows us to connect to a Chat room outside of the StimulusReflex paradigm and we can broadcast back up this channel that the users that are attached need to get the new messages.

To accomplish this, we add some JavaScript to initiate that connection:

In your Stimulus chat controller the initializer connects to the ChatChannel and then binds a function to the received callback of the ActionCable subscription.
‍

It looks like:

import { Controller } from 'stimulus';
import StimulusReflex from 'stimulus_reflex';
import consumer from '../channels/consumer';

export default class extends Controller {
  connect() {
    StimulusReflex.register(this)
  }

  initialize() {
    // We need to know when there are new messages that have been created by other users
    consumer.subscriptions.create({ channel: "ChatChannel", room: "public_room" }, {
      received: this._cableReceived.bind(this),
    });
  }

  create_message(event) {
    event.preventDefault()
    this.stimulate('Chat#create_message', event.target)
  }

  _cableReceived() {
    this.stimulate('Chat#update_messages')
  }
}

Now when we receive a message (any message currently) we trigger the _cableReceived callback which will stimulate the Chat#update_messages actions.

Add an update_messages action to the Chat reflex and then broadcast a message when you create the Message in the create_message action. So, now when any user creates a new Message, we will rebroadcast that message out to anyone that is connected to the chat_public_room connection.

class ChatReflex < StimulusReflex::Reflex
  delegate :current_user, to: :connection

  def create_message
    # Create the message
    Message.create(message: params["message"], user_id: current_user.id)

    # Broadcast that everyone on this channel should get messages
    ActionCable.server.broadcast(
      "chat_public_room",
      body: 'get_messages'
    )
  end

  def update_messages; end
end

Since the view gets re-rendered from the ChatController, we don't actually have to do anything with the messages in the Reflex action. We get to treat the view just like we would have in a Controller Action.

Now you should be able to attach two users and chat back and forth with one another.

The flow through the app looks like:

‍
So we short circuit the button to force stimulus to trigger the Reflex to get everyone's chat's to refresh when a new Message is created.

It's simple and very powerful. The tools that build this application are quite well known and StimulusReflex is built on well-known Rails gems and tools including, Stimulus, CableReady, and ActionCable.

I'm excited to continue exploring how to leverage StimulusReflex in apps we build at Headway, as well as other solutions in this vein including LiveView on Phoenix and Elixir. I believe it will reduce the time we all spend writing single-page applications without losing the real-time feel.

The results so far

Below is the final version of my quick and dirty StimlusReflex chat application.

Where to go from here

I remember building a chat application when ActionCable first launched and thinking the set up was lengthy and took some work. WebSockets were mysterious to me too. StimulusReflex does a great job in hiding that complexity and makes your Rails application feel even more like an SPA. There is such little JavaScript in this version it's not even funny.

More opportunities for this chat application are:

Add better Authentication and do some work to add presence notifications
Make it so you can create and join any chat room - not just the public room

Get access to the code

What would you add to my chat application next? You can see the final version of the code for this walkthrough here on GitHub. I added some styling and made it look a bit like a messenger application.

Tips for Managing Projects with Remote Development Teams

Andrew Stuntz — Fri, 08 May 2020 17:17:51 +0000

This article was originally posted on the Headway blog. Visit us at headway.io to see how we're making waves.

In this article, we share guidelines and advice for remote software development teams to more effectively manage and complete projects. These guidelines help ensure that remote meetings, communication, and team projects are productive, even when they happen remotely.

In March of 2020, Headway held a live stream with our team to discuss how product teams can work remotely successfully. We planned on having this online event long before the world migrated to mostly online work environments in the spring of 2020.

Headway's remote-first approach to managing teams, holding meetings, and running projects eased our transition. We hope that sharing our experiences and advice will help others build best practices for creating more impactful remote teams.

What we'll cover

Best practices for remote meetings
Remote project management and task prioritization
Remote communication tools
Remote collaboration tools
Leading and managing your team

Best practices for remote meetings

Due to the nature of remote work, it can be frustrating for remote workers to be involved in meetings that happen "in-house". At Headway, all meetings are remote-friendly - even when there are folks in the office. Remote friendly meetings have a few things in common:

1. Cameras on

For complex conversations, having a voice conversation is better than using Slack. And having your camera on is even better. Humans are very in tune with body language, and that includes body language over video calls. Encourage your team, and any project partners, to turn their camera on. This builds trust and improves the overall relationship. And better relationships create better products.

2. Headsets on

Clear audio creates clear communication. The best calls happen when everyone has headsets. It results in less delay when talking into the mic and most headsets filter noise around you better than the mics on your laptops.

Our team uses Jabra headsets to improve audio communication.

3. Mute when not speaking

This is a great way to prevent any disruptions from your end while others are speaking. It can prevent you from butting in before they finish a thought and prevents everyone from hearing you sneeze or cough at random. This is especially helpful if you are in a busy environment. Whether your kids are at home or you're working from a coffee shop, be kind and mute your microphone when you're not speaking. When in doubt, mute yourself.

4. Face your camera

In today's age, many of us have multiple monitors - but if you can't see my face, you're probably not going talk to me in the same way. Don't be scared or nervous. It's a little unnerving watching yourself on the camera the first few times, but trust me, you'll get used to it. The more you engage with each other, the stronger your relationships become.

5. Better lighting

Being seen in the right light is important too. Don't be the creepy person backlit by your window. Try to have light sources in front of you. If there are bright lights behind you, turn them off or reposition your desk in the room so that your face is lit more than your back.

6. Stay on track

It can be really easy to get into the weeds and talk in circles. Just like any other meeting, hold each other accountable, and respect each other's time. You can do this by having an agreed agenda at the beginning of the meeting or designate someone to help lead the group if they notice the meeting is getting off track.

Remote project management for developers

As a remote-first consultancy, Headway works on a wide variety of projects. We work with new startups, established startups, and enterprise businesses. One of the most challenging things to do with a product team is handling project management. With the right tools, you can make the process easier.

Project and product documentation

Having a collaborative resource for documentation will make a big impact on remote teams. We use Notion for documenting everything we do. It keeps everything we need accessible, secure, and easy to share.

Benefits of project documentation

Templates create consistency
Creates alignment across the team
Provides a singular source of truth
Successful project hand-offs

Learn more about Notion

Prioritizing feature development

Headway uses MoSCoW prioritization to manage feature development for products that we build. It allows project stakeholders to clearly understand what work will happen, when it will happen, and why on their product at any given time.

Learn how Headway prioritizes feature work:

Prioritizing Your Product Features with the MoSCoW Method

Managing feature development with Stories on Board

We use a tool called Stories On Board for roadmap prioritization. It helps bring the product, design, and development together and is an excellent compliment to the MoSCoW method. It provides a clear view of what is getting done, when it is getting done, and compliments agile development methods.

This storyboard tool isn't an issue tracker. Translating storyboard cards into usable tickets for a developer takes work. We don't always work with project managers, and often the role of our lead developer or designer includes project management. This is why our tools and consistent process are imperative to our success. Providing consistency for one another is critical.

Learn more about Stories On Board

Managing development projects tasks

Across all our projects, we decompose storyboard items into more consumable tickets to work in and often use a separate tracker for issue tracking. Success starts with having the right tools to achieve your goals and stay on track. Every project has different needs either because of its nature or because of the client's requirements. Here are the tools we have used to manage tasks as a team.

Task management tools we recommend

Birdseye - We're building it

Understand your needs

Our projects use different issue trackers at Headway. Depending on the clients and partners involved, the tools can change. We have used Github issues, Trello, Asana, and Jira to track project work. The important thing here is not which issue tracker you decide to use. It's how you decide to use it.

It's important to keep issues up to date and as a remote developer. This is because I can't just stop by a PM's office or a teammate's desk to see how things are moving. The place we must look at is the issue tracker.

We often include it in our Github pull request templates to make sure you check off the ticket (or update the ticket to the appropriate state) in whatever issue tracker you are using. We rely mostly on the following states: "started", "doing", "done" and sometimes we will add in "confirmed" or something else to make sure it passes through QA without any issues. It's easy to share and see what other folks are doing that way.

Communication tools for remote developers

Tools we recommend

Slack

We use Slack as our main tool for asynchronous communication. It allows us to separate and track conversations for different projects and have quick questions answered with individuals as needed. You can even hop on a quick slack call if needed.

Learn how Slack works

Zoom

We use zoom when we schedule formal meetings or when we need to go into a deeper conversation about an issue together. We also record meetings to create accountability between project partners and document meetings in case they ever need to be revisited.

Learn more about Zoom

Asynchronous communication

Struggling to communicate decisions across members of different teams is a shared failure I've seen many times. Keeping each member up to date on what is happening when and where has always been a challenge. It's one place where remote work shines.

Creating a source of truth with Slack

Headway uses Slack to facilitate our asynchronous communication. There is no siloed communication about development, design, or process as we all make those decisions by working in Slack. Even if it's easier to have communication outside of Slack or using a Zoom room. Slack is the tool we use to broadcast those decisions.

When I take a day off, the first thing I do when I return is to read through Slack messages. This allows me to catch up on decisions that were made, work that is inflight, and issues that came up while I was gone.

https://youtu.be/pQcN1xO7RdA

Using channels in Slack

Since you are unable to have one-off conversations or "just stop by" someone's desk, you have to focus on communication in other ways. An asynchronous tool like Slack solves this naturally with channels. Since there is a log of all communication and decisions being made, it's easier to communicate, discuss, and collaborate.

That means no more email forwards and weird gaps in the conversation.

When a decision is made in a Slack channel, it not only drives the decision in a way that all teammates can see and chime in on. It also lets everyone read that communication when it makes sense for them as well.

You no longer have to worry about getting everyone into a meeting or having a face to face conversation with a product owner because as long as they're in the channel, they will see or read about the decisions that have been made. Decisions can and should also be pulled out of Slack and included in project management tools. This provides the historical context you can link to in the slack conversation. This allows everyone to catch up on the project on their schedule and when it's convenient for them.

Not sure how to begin?

Check out this article for getting started with Slack channels:

How to use Slack channels to organize your work life

Managing notifications and distractions

If you don't manage it correctly, Slack can be overwhelming. It can be very intrusive into your life with constant pinging and constant updates.

Don't be scared to turn notifications off.

I usually spend at least half of my day with "Do Not Disturb", on my computer. This allows me to check Slack on my schedule and since it's asynchronous communication, you check for updates when it makes sense for you.

Another strategy is to turn off notifications unless someone explicitly mentions you in Slack. This can be helpful if you're in a Slack channel that sees heavy use but you're not directly involved. Or if you just don't want notifications every time someone mentions something.

Remote whiteboarding tools and collaboration

Besides communication tools like Slack and Zoom, we use a plethora of other tools to make our experience working together optimal. I often hear that teams moving to work remotely have a hard time communicating when they don't have a whiteboard. There are some great tools to help solve this problem.

Sharing ideas visually

One big push back many folks have about working remotely is the lack of being able to have "whiteboard sessions" or collaborate with their peers in a visual manner. So-called "whiteboard sessions" are often used to quickly better understand problems, scope, or hard to visualize patterns. As a developer it can be really tough to communicate your thoughts in writing. We have found a few tools that really allow us to communicate visually virtually that have, on occasion, saved the day.

Whimsical

From a development standpoint the first tool that I reach for is Whimsical. Whimsical allows you to draw mind maps, wireframes, and flow charts quickly with your team. Whimsical allows you to think and communicate visually without too much friction. Whimsical gets used for architecture, code organization, process management, and quick and dirty UI flows.

Learn more about Whimsical

Miro

The other tool we reach for at Headway is Miro, Miro is team collaboration software that feels like more like we are collaborating on a whiteboard. It's great for brainstorming, planning, and user story mapping. It's easy to use, fast, and extremely collaborative. Often we'll leave Miro up during meetings just to share notes. Then we can organize those notes together after the meeting.

Learn more about Miro

Between Miro and Whimsical rarely am I unable to feel like I'm missing out on collaboration without a whiteboard. Using these tools is often more collaborative, no one is hogging a marker, you can't run out of whiteboard space, and there almost infinite ways to move work into different formats for different learning styles. Another benefit is there is no "translating" step. It's already in a digital format.

Remote pair programming tools

From an integrated development environment (IDE)

As developers, we use quite a few tools to make remote collaboration with one another an easy experience. The most popular tool we use at Headway for remote pairing is Tuple.

Tuple is a screen sharing software built for developers. It allows a seamless screen share and has lots of options for the way to interact with your pairs screen. Tuple also has excellent screen annotation tools. It's the best option for pairing when developers are working in an IDE.

Learn more about Tuple

Without an IDE

If you're working on a remote server or like the idea of working from a remote server and working outside of an IDE (like using Vim) we use wemux. Wemux is a tool built with tmux that allows pairing through a remote server. It is very customizable and easy to use once it's set up. Though, if you don't already use tmux and a modal editor like Vim this one is a tough sell.

Learn more about Wemux

Headway developers are encouraged to learn Vim and Tmux as we think they are valuable tools and we can hone our craft by sharpening out tools. When we each sharpen our tools, we own that process and empower ourselves to work smarter not harder.

Headway developers have collaborated on an incredible Vim setup. Thanks Jon Kinney! It is available via open-source below.

See our Vim and Tmux Setup

Git and pull requests (PR)

You probably already use version control of some sort. We like to leverage the tools we already have on hand. Git provides a great framework for documenting the "story" of your code and we make sure that our commit messages and branching schemes match the "story" of our software as we build. Over time this allows us to use Git to understand better how our software is built, what went on in specific pull requests, and how certain features were added.

I also like to use pull requests to communicate what kind of work I'm doing. I encourage those on my team to do the same. The intent of a pull request is not to present work that is "finished" and to be added to the code base after a quick code review. The intent is to communicate the code that you are writing to the other developers to ensure that everyone agrees on the structure, libraries, and other important decisions you have made in your code. You're already going to open the PR regardless. You might as well get feedback sooner than later.

Learn more about Git and pull requests

Other options

The final tool we often use for sharing terminals with other developers is Tmate. Tmate allows you to share your terminal and ssh into another developer's terminal.

At Headway, we reach for tmate when we need to do something quick and dirty or just need someone's help for a few moments. When we have serious pairing sessions, we'll join a Wemux and happily code with everyone. Both Wemux and tmate are easy to set up and provide a lot of customization. They're great for sharing development work.

Learn more about tmate

Leading and managing your team

While process and approach can be powerful, people are the true heroes that bring projects to completion. Helping every person on your team grow to become better communicators and team players is vital.

We all have a responsibility to lead each other, even if that's not in our title.

The human element of project management is not easy or simple, but if you make efforts, you will see improvement. Below are some of the tools we use to gain a better understanding of each person on our team and how we can all work better together.

Lead Honestly

Lead Honestly is an automated tool that helps our leadership team have candid conversations about certain topics based on the person's needs. Questions are sent out once a week for our 1-1 meetings that last about fifteen minutes. These help us uncover many issues before they become a big problem. They also help each leader get to know each team member better on a personal level because they are dedicating time to that.

Learn more about Lead Honestly

Tools to understand your team

We use a few different approaches to understanding each individual on our team and how we can work better together. From personality traits, key motivators, and how people take action. The friendly folks at Navigate the Journey help us manage these efforts. Below are the tools we use to do that.

Assessments to better understand your team

DiSC Profiles

Motivational Core: MCORE Assessment

Kolbe A Index Assessment

Improve your retrospectives

Taking the time to review how what went well and what didn't go well in a project helps you continuously improve your process and relationships within a team. We wrote an article all about it. If you're interested, check out the link below.

Level Up Your Development Team with Better Agile Retrospectives

Find what works best for you and your team

The key is to take the time to evaluate the tools and methods you have and to not be afraid to try new approaches. While these tools and techniques that have worked for us, they may not be the best fit for you and your team. Our tools change as we identify issues or needs with our team or when new technologies are available. Don't be afraid to try something new.

Start small to experiment

Rather than getting everyone on a new tool, try a small team first. Listen to your team and share experiences together. See what results you get. This lowers the risk in case you don't see a positive impact. It can be hard to get a whole team onboarded to new ideas or products, but that's where leadership comes in. Become an advocate for the tool and celebrate the positive results together.

Level Up Your Development Team with Better Agile Retrospectives

Andrew Stuntz — Mon, 30 Mar 2020 21:30:30 +0000

One of the best parts about creating great software is getting to collaborate with others. It's also one of the hardest things to get right. The best software developers are not the 10x developers who know how to build everything themselves. They are the team players who know how to be a force multiplier for all the other people involved with a project.

In Agile methodology, a retrospective is run at the end of each sprint. When run properly, with a willing team, a retrospective accomplishes the core mission of enhancing collaboration across a development team and increasing the overall efficacy of the development process.

Retrospectives allow a team to identify and discuss issues within a project and work together to solve those issues.

What is the goal of a retrospective?

Retrospectives (i.e. retros) are meetings that generally uncover three things:

What went well during the sprint?
What didn't go well?
What could be done better next time?

These seemingly simple questions have a huge impact on team morale and cohesion and help teams refactor their process by learning from past mistakes and growing together.

“Greatness is not a function of circumstance. Greatness, it turns out, is largely a matter of conscious choice, and discipline.”

Jim Collins: Good to Great

Chances are, a team is a mix of different skill levels, aptitudes for social interaction, and hopefully different backgrounds. It is said that diverse teams build better software, but how does a team learn to gel? How do people know the right feedback to give or when to give it?

What happens when:

A project or week doesn't go well?
Rifts begin to build in teams?
People get angry or frustrated and have unproductive disagreements?

It would seem like stopping everything to address those concerns would make sense - however, the feature requests and bug reports don't stop, and the team still needs to deliver effective software. If left unaddressed, those ragged edges will continue to fray and eventually pull teams apart. So what's the solution? While not a silver bullet, sprint retrospectives are a great place to start.

Make retrospective meetings more productive

Meetings can often have too much unhealthy agreement vs. healthy disagreement, with retros commonly falling into the former.

So what are the pieces that need to come together for an effective retro?

Set ground rules

Instead of jumping right to the formal retrospective questions above (which can often lead to blank looks or tacit agreement), start by laying the ground rules. This frames the conversation and sets up people to think about the conflict before it starts.

Here are some ground rules that are helpful to establish:

Be respectful

Creating software and building products is much more than just putting in time and money, and having excellent features come out. Everyone is on the same team - work together, respect one another, leave egos at the door, and enter each retro with a growth mindset.

What's said in a retro stays in the retro

Retros are the time and place to push people to be their best selves, be critical, and talk about how certain behaviors impacted the team. It's a safe space to ask for help and identify areas of improvement. It's also best practice to not keep audio/video recordings, and clarify that notes of the meeting will be shared between the meeting attendees only.

The goal is to work on the process

When developers write software, it's a reasonably personal endeavor - and sometimes they feel other people are blocking their work. But it's important to realize everyone is on the same team, and it's not the time or place to make things personal. Questions about code quality are not the point of a retro and should stay in respectful code reviews.

Stay on track

In general, retros should be around an hour. Software developers are well known for "solutionizing" and over-engineering. But the goal of a retro should be to suss out issues - not come up with solutions to every problem. It's easy to break down the first problem that is presented and spend the rest of the meeting coming up with a solution. Instead, note the issues and move on. Problems that require follow up will become apparent, and solutions for those issues should happen in a separate meeting.

Focus on unity

It should go without saying that projects are more effective when team members feel safe to share their experiences and have a desire to work on growing together. Retros are not a place for anger or decision making by seniority. All ideas should be on the table, and nothing should be shot down without healthy discussion. Effective retros will elevate the entire sprint process by helping the team to work with, and not against, each other.

"If you could get all the people in the organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time."

Patrick Lencioni

Have a prepared facilitator

The facilitator should guide the meeting intentionally, not letting any one person or topic dominate the discussion in an unhealthy way. This process can often be difficult when team members are invested in their issue or point of view, resulting in lots of discussion on how to move forward. The goal here is to make sure everyone is heard and divert conversations that aren't immediately applicable to future actionable items.

The bottom line - if the facilitator senses unnecessary discussion, off-track topics, or that things are going too far, they need to get the meeting back on track.

Have actionable takeaways

It's not enough to write items down and never revisit them. Each action item should either be assigned to an individual or put in place as a new standard for the team. That way rather than only reminiscing on the tough parts of the last sprint, having clear action items and assigning them to the right people will leave everyone feeling empowered, excited, and with a sense of forward momentum. Write action items down during the retro and review them at the end to get buy-in and a sense of shared team accountability.

When retrospectives don't go well

That all sounds great...but in reality, it's not always that cut and dried. What are some common reasons retros don't go as planned?

Retros are an afterthought

This is the most common reason given from people who don't like retros. When they seem like an afterthought and little time is spent on them, of course, they aren't well received. But, just like many things in agile, the important part of sprinting is taking action to correct issues over time - not letting those issues continue sprint after sprint.

There are no effective outcomes to the retro

Retros provide a format for everyone to be heard on a development team. Sometimes being heard is enough, and retros can provide a safe space to vent. But some issues are more critical than others and require action to be taken - sometimes immediately. If those issues aren't taken seriously and no corrective measures are put in place, it can feel like a lot of wasted effort. Keeping good notes and writing down action items is a good first step to combat this issue.

There are zero or few issues brought up from the retro

There are always problems - no matter how many people tell you that everything is peachy, things can always get better. For teams that haven't seen a retro before, or have seen ineffective retros, there can often be a propensity to just ignore issues because "nothing changes".

Refresh your retros with new ideas

The solutions to these problems are not to stop doing retros. It's rare to hear, "the process is perfect, we should never change it" in any development project. So what are some ways to approach retros in new ways and unlock a better process?

Start with a light question

Developers are often stuck working in their own world. They often have to stretch their comfort zones to work well with others - but it can be hard to connect with everyone, and some people on the team may be less outspoken. One way to help set the tone is to ask an ice breaker question or a question focused on feeling. People open up more and are better able to give/receive criticism when they feel they are in a safe and trusted environment.

Some suggestions for kicking off the meeting:

Ask for a "feel color" (i.e., red if things are going terribly, green if things are going great)
Ask about weekend plans
Other ice breaker topics that can get the room talking

Change the facilitator

In the capital "A" Agile methodology, retros are supposed to be run by a scrum master. However, this choice can result in lower than ideal participation - especially if no action occurs. This meeting should not be hogged by a team lead or someone "up above" - this is to help developers increase efficiency. One way to encourage the team to be open and have a growth mindset is to have one of the developers to facilitate the meeting.

Ask for feedback before the retro

If there is a group of non-participants, it can be helpful to ask those people to write their opinions down before the retro. Then at the meeting, ask those people to share what they wrote down prior. This goes a long way to increasing participation from people who feel they can't share at the moment or need more time for preparation.

Retros at Headway

Retrospectives are crucial for us here at Headway. They not only help us hone our process and continuously improve each week as we work to bring new ideas to market - they also help improve relationships with clients and partners, and in turn, help us build better products.

Retros fit well with our Guiding Manifesto and are imperative to ensure that we grow together, rather than separately. While we still spend time individually improving ourselves and enhancing our craft, retros let us do that as a team - which improves our ability to deliver software together on a sprint by sprint basis.

Free Download - Project retrospective template

This is the retro document we use at Headway. We hope you'll give it a shot! If you find it useful, feel free to share it with your friends and colleagues.

Template for Retrospective Meetings

Thanks to Amy Marco for encouraging me to explore team building and for the structure of the awesome retro document that I continue to use to this day.

Regain control of branches with git rebase --onto

Andrew Stuntz — Wed, 15 May 2019 12:00:00 +0000

This article originally appeared on Headway's blog

Rebasing branches with git is a process that all developers work through. It can be challenging at times to get all your commits exactly where you're hoping that they will end up. While git isn't perfect, git rebase --onto can help tame your branches when you have to work with non standard rebasing. git rebase --onto let's us be a little more choosy about where and which commits we want to more easily handle complicated rebases.

How a traditional rebase works

Traditional rebases (those without the --onto flag) are pretty easy to understand. Commits get applied to the head of the branch you originally created your working brach off of this works for the majority of cases but sometimes the head of your base branch is faulty, or your doing some testing and want to move your feature branch one commit at a time.

Most of the following examples are pretty contrived, but I think git rebase --onto is applicable to a number of situations. Testing large feature branches, or moving a feature branch from one base to another base. Reasons to use git rebase --onto include fixing mistakes, or moving a feature off of a feature branch and onto a base branch of some kind. git rebase --onto can be your friend when you need a scalpel for your git rebase.

To easily reproduce a bunch of commits in a repo and make it easy to work with, here is a quick bash script that will generate a ruby file and commit a bunch of times to make our "git world" more consistent.

  #!/bin/bash

  function create_basic_git_repo()
  {
    echo 'git rebase is great'
    mkdir gitexample
    cd gitexample
    git init
    mkdir lib
    touch lib/my_thing.rb
    echo "class MyThing; def my_method; 1 + 1 == 2; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'Commit 1'
    echo "class MyThing; def my_method; 1 + 2 == 3; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'Commit 2'
    echo "class MyThing; def my_method; 1 + 3 == 4; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'Commit 3'
    git checkout -B My_Feature_Branch
    echo "class MyThing; def my_method; 1 + 4 == 5; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'My Feature Commit 1'
    echo "class MyThing; def my_method; 1 + 5 == 6; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'My Feature Commit 2'
    git checkout master
    echo "class MyThing; def my_method; 1 + 6 == 7; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'Commit 4'
    echo "class MyThing; def my_method; 1 + 7 == 8; end; end" | tee lib/my_thing.rb
    git add lib/my_thing.rb
    git commit -m 'Commit 5'
  }

  create_basic_git_repo

In this repo you should see a lib directory as well as a file called my_thing.rb with some commits on. 5 commits on the master branch and 2 commits on a feature branch that are based off of the third commit of the master branch. The SHA's between your repo and my repo will be different, but at least the commit messages will be the same to easily follow what we are doing below.

Object Identifiers

As a quick aside, let's talk about object identifiers in git for a second.

An object identifier usually identifies a commit, we often call them SHA's but we can also be talking about a branch. When we refer to set a of work by the branch name we are just talking about the collection of commits that make up and we reference the head of that collection of commits by the name of the branch.

Any object identifier is a valid argument with a rebase. We can rebase on a branch name, a SHA, a tag, as long as it identifies a commit, it is a valid argument to rebase.

Git rebase —onto

There are two versions of git rebase --onto , the binary and ternary functions. Also written as git rebase --onto/2 and git rebase --onto/3.

Git rebase —onto/2

The two argument version of git rebase onto is used to move a set of commits from one one object identifier to any arbitrary object identifier.

In words I want to move my set of commits from one commit to any other arbitrary commit.

For the most part, this is helpful if you don't want to move your commits to the top of a branch or for some reason you can't have your feature branch at the top of master . But it can also be useful if you have a release branch and need to maintain your work across multiple branches.

I like to think about git rebase --onto/2 git rebase "where I want to go" from "where I was", with "where I want to go" being the object identifier of the place you want all your commits to go to and "where I was" to be the object identifier of where your branch is currently sitting off at.

For example in this case I did git rebase --onto 2b4c572 b45626d

I want my work to be on top of commit 4 with SHA 2b4c572 and it's currently on commit 3 with SHA b45626d. Not too bad or crazy complicated. For these cases I took the changes from My Feature Commit 1 and My Feature Commit 2 to make sure the commits applied to see the example.

Git rebase --onto/3

The three argument version of git rebase --onto is a little more powerful, but not as useful always. I tend to only use it when I have really messed something up or have a pretty nifty reason to use it. In fact, I am not certain I have ever used it to do something entirely useful in git repository. Either way, it could be useful at some point.

For this one, we want to move my set of commits from one object identifier to another object identifier, but I want to only select a certain amount of commits from my branch.

Note that we masterfully and easily cut out commit G from our feature branch. This makes it pretty easy to do this.

We want to git rebase --onto "where I want to go" from "where we were" up to "my chosen commit"

For example here we could do git rebase --onto c5d6535 42fa4e5 22d71a4

We are at commit 42fa4e5 and we want just commit 22d71a4 on top of commit c5d6536.

Pretty easy if you ask me. One thing to note is that git rebase --onto/3 leaves HEAD in a detached state and to save this state, you need to name the branch something.

All of these examples were generated using a quick bash script that generates the same commits each time. Though the commit SHA's (object identifiers) will be different (thanks Git!).

Feel free to check out the bash script and play around with git commit rebase --onto it can take some getting used to but its a powerful tool that has really helped me minimize some git pain in the past.

Have any questions? Let me know below.

Learn more about Git rebasing

Git Rebase Documentation

Git Rebase —onto Tutorial

Build a Simple Static Site on Amazon S3

Andrew Stuntz — Wed, 13 Feb 2019 12:00:00 +0000

This article originally appeared on Headway's blog

Today I am going to walk you step by step on how to build a simple static website using Amazon S3. Sometimes all you need is a little HTML and CSS for a successful website. In fact, it can often be faster to develop a website without an entire web framework.

What is a static site?

A static site is a website that is a collection of HTML and other assets that does not get served from a web framework. A static site is in no way non-interactive though.

The static part just refers to the way the HTML and other assets are served to browsers when a user navigates to your website. There is no web framework serving those assets to the browser dynamically, the site loads up and then uses JavaScript to interact with other web servers and API's.

Examples of cool web applications that are static:

Mint: Budget Tracker & Planner
Dropbox

What is the value of using a static site?

HTML and CSS are all you need to get started with a simple static site.

Static sites do not need to be served by a web server. You don't need the infrastructure that is otherwise required to host a web framework. Developing a website without an entire web framework can be more efficient.

You also benefit from a separation of concerns, your front end is just that, no templating languages or calling methods on your models in your view. You get to just deal with the frontend without worrying about the backend.

The steps for building your first static site:

Build a tiny bit of HTML
Upload the HTML to an AWS S3 Bucket
Make the Bucket accessible and public
Add some JS and CSS to make your "static" site shine!

Getting started with your HTML file

The easiest way to do it, is to create an HTML file. Traditionally this is called index.html but the naming doesn’t matter too much. You can point the web server to serve whatever HTML file you want.

<!DOCTYPE html>
<html>
  <body>
    Hello World!
  </body>
</html>

Now you have some basic HTML and you need to serve that somewhere. One of the easiest options is to simply upload the HTML file to an S3 bucket on AWS.

Create a new bucket on AWS

First, head to the S3 console on AWS. You need to add a new bucket.

For this example, I just created a public bucket named "testheadway." Don’t worry about the settings yet. Just click through to get the bucket created.

Edit the bucket for hosting abilities

Next you need to turn on the ability for the bucket to host a static website. Click on the bucket to edit it.

Once we’re in the edit view for the bucket, head to the "Properties" tab for the bucket.

Then click into the Static website hosting card.

Now select "Use this bucket to host a website" and add the name of your index document this is almost always going to be your index.html it should match the name of the document you created earlier.

Easy peasy if you ask me!

Now, once this is turned on you should see an endpoint for your S3 bucket. This is the URL used to access your newly created static website.

Edit the bucket permissions

You need to adjust a few more settings to have public access to this S3 bucket. The bucket permissions need to allow everyone to getObject's from your bucket. As basic policy could look like the below. Just make sure to update the "Resource" to be the name of your S3 bucket.

Note: This is not secure nor recommended for production ready static sites. Seek an AWS security expert for recommended bucket permissions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::yourbucketname/*"
    }
  ]
}

Copy and paste the below in the Bucket Policy by heading to Permissions.

The next step is to click into the Bucket Policy.

Now, you need to save the getObject policy. AWS will warn you that you are giving public access to your objects in your bucket. This policy only allows people to access objects in your bucket, which is what you want since people are going to be accessing your index.html.

If you head to that URL now you can see that you get a giant 404.

This is expected, you haven’t uploaded your index.html file yet.

Upload the index.html

The next step is to upload your index.html.

At this point, if you head back to the bucket URL you should see your HTML rendered in the browser.

Congratulations, you’ve got a basic website being hosted from AWS!

Here are some ways you can extend the site easily with some CSS and JS.

In the same way that it was pretty easy to serve straight up HTML, it’s just as easy to add some CSS to your application.

Stick a new file into your directory called styles.css. Like other static site generators you can add some basic styling to your HTML just by referencing the CSS in your HTML.

Your HTML should now look like:

<!DOCTYPE html>
<html>
  <head>
    <link href="https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet">
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <div class='center'>
      <h1>
        Hello World!
      </h1>
    </div>
  </body>
</html>

Now you can add some styling to the styles.css style sheet like:

h1 {
  font-family: 'Roboto', sans-serif;
}
.center {
  width: 100%;
  display: flex;
  flex-direction: row;
  align-items: center;
  justify-content: center;
}

Now you just need to delete the index.html file from the S3 bucket and upload these two files and you should have a minimally styled website up and running.

It should look something like:

Using jQuery to add new elements

So far you have done all of this with no Javascript and no web server or application server. How can you interact with the world outside of your little app? Well, you need to add some JavaScript to make that happen. But, that is pretty easy too. Just update the HTML to pull in some JavaScript, you are going to use jQuery to quickly grab some weather and display it on your static site.

You only have three files. Pretty easy and simple, but very powerful.

<!DOCTYPE html>
<html>
  <head>
    <link href="[https://fonts.googleapis.com/css?family=Roboto](https://fonts.googleapis.com/css?family=Roboto)" rel="stylesheet">
    <link rel="stylesheet" href="styles.css">
    <script src="[http://code.jquery.com/jquery-latest.min.js](http://code.jquery.com/jquery-latest.min.js)" type="text/javascript"></script>
    <script src="weather.js" type="text/javascript"></script>
  </head>
  <body>
    <div class='center'>
      <h1>
        Hello World!
      </h1>
      <button id='weather_button' class='basic_button'>
        Get my Weather
      </button>
      <div class='error'>
      </div>

      <div class='weather'>
          <div class='city-name text'>
          </div>
          <div class='weather-main text'>
          </div>
          <div class='description text'>
          </div>
      </div>
    </div>
  </body>
</html>

Your slightly more complete CSS:

h1 {
  font-family: 'Roboto', sans-serif;
}

.center {
  width: 100%;
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

.text {
  margin-top: 30px;
  font-family: 'Roboto', sans-serif;
}

.basic_button {
  font-family: 'Roboto', sans-serif;
  font-size: 18;
  margin-top: 30px;
  width: 300px;
  height: 45px;
  border-radius: 4px;
  background-color: #44AAB5
}

Some JS to interact with a weather API and make your static site a little more interesting.

$(document).ready(function() {
  $("#weather_button").click(function(e) {
    console.log(e)
    e.preventDefault();
    $.ajax({
      type: "POST",
      data: 'json',
      url: 'https://api.openweathermap.org/data/2.5/weather?zip=98229,us&appid=useyourownopenweathermapkeyplease',
      success: function(result) {
        console.log(result)
        $( ".city-name" ).text(result.name);
        $(".weather-main").text(
          result.weather &&
          result.weather[0] &&
          result.weather[0].main
        )
        $(".description").text(
          result.weather &&
          result.weather[0] &&
          result.weather[0].description
        )
      },
      error: function(result) {
        console.log('error', result)
        $(".error").text(result.error)
      }
    });
  });
});

Checkout the final product here, it’s not so static after all 😉:

See the "testheadway" website

This same process stands with a single page application (SPA) with React. If you want to host your SPA on S3 all you would need to do is build your React app and then add all the static assets (HTML, JS, CSS files) to your S3 bucket.

If you built your SPA from a create-react-app application there is already a build command to build your app.

You need to run:

npm run build

This should build your static assets and compile them into the build directory for your application.

Instead of uploading a single HTML file, you'll upload the contents of the build directory to the S3 bucket.

my-react-directory/build

Now your React app will mount when it finds your index.html.

The advantages of building a static site vs a dynamic site

There are many ways to build web applications in todays day in age, and one of them is to host a static site and let it interact with your backend.

While there are certainly challenges to building websites in this manner there are plenty of positives as well, including separating concerns between the front end and the backend, more easily supporting multiple clients, and better supporting modern JavaScript SPA’s.

Overall this is a quick overview of how you can build a sample application completely from a static website that is easily and cheaply host on Amazon S3.

Let me know if you have any questions about static sites or if we can help you build a SPA, a static site, or help you deploy your static site to Amazon S3, we’re happy to help.

Recommended resources for building static sites

Deploying a create React app:

Facebook Github - Create React App: Deployment

Static site generators:
GatsbyJS
Hugo
Jekyll

Places to host static websites:
GitHub Pages
Netlify
AWS S3

I love git log

Andrew Stuntz — Mon, 20 Aug 2018 18:35:40 +0000

The title of this post should be IFLG (like IFLS, but ya know with Git).

But it's probably not great to title a post with the f*** word. Ya know.

Git is the best

Really, I love git. I think it is ridiculously useful and when used properly, it can speed up development on a team tremendously. When I was first learning git though, I always got so frustrated by not being able to see what was going on with git, like what were my teammates doing and how did my work fit in with what they were doing?

I tried a few UI's for working with git but was never satisfied, everything seemed clunky and you had to get out of the terminal to go look at the UI and then come back and figure out what you were doing again.

One of my favorite commands when I am working with git repo's is (hopefully unsurprisingly) git log.

This shows a log of all of your commits and the basic command outputs something along the lines of:

commit 8c2ca7c38f50e1d837485edd946916bfdciii20a1 (HEAD -> master, origin/master)
Author: Andrew Stuntz <andrewbstuntz@gmail.com>
Date:   Mon Aug 20 10:20:27 2018 -0700

    Fixes the resetting of form fields on the settings form

commit cc309a7cb45bfcfd7e94a49387086266dff54c05
Author: Andrew Stuntz <andrewbstuntz@gmail.com>
Date:   Mon Aug 20 10:03:46 2018 -0700

    Updates some styling issues and copy

commit 2d848cec12038475b9f12070547653ab212e4e6
Author: Andrew Stuntz <andrewbstuntz@gmail.com>
Date:   Mon Aug 20 08:17:13 2018 -0700

    Add config and format correctly

commit deec64859bc9b2ef74a987437b7864f2183940e
Author: Andrew Stuntz <andrewbstuntz@gmail.com>
Date:   Thu Aug 16 11:11:42 2018 -0700

    First commit, I never know what to put here?

So what do we have going on here?

commit 8c2ca7c38f50e1d837485edd946916bfdciii20a1 (HEAD -> master, origin/master)
Author: Andrew Stuntz <andrewbstuntz@gmail.com>
Date:   Mon Aug 20 10:20:27 2018 -0700

    Fixes the resetting of form fields on the settings form

Overall, it's pretty easy to see the ordering of the commits, top to bottom, first commit to last commit. You get the revision number which uniquely identifies the individual revision. Next to that, you see some more information about your branch in the parentheses, these reference your HEAD (which is what you have checked out now). You also origin/master which means that origin/master is at this commit as well. So your HEAD and origin/master are at the same revision. Then you get an Author and a Date. Finally, you get the commit message. So far so good. Nothing too complicated.

Diving into the `git log` command

If you do a git log --help you get ample output, in fact one reason I love git is the massive amount of documentation that allow you to really dive into and customize what you want. I'm gonna run through a few of my favorite options that let you really see what is going on in your repository.

The first is git log --graph

Which lets you see a graph of the branches.

* commit 8c2ca7c38f50e1d837485edd946916bfdciii20a1 (HEAD -> master, origin/master)
| Author: Andrew Stuntz <andrewbstuntz@gmail.com>
| Date:   Mon Aug 20 10:20:27 2018 -0700
|
|     Fix the resetting of form fields on the settings form
|
* commit cc309a7cb45bfcfd7e94a49387086266dff54c05
| Author: Andrew Stuntz <andrewbstuntz@gmail.com>
| Date:   Mon Aug 20 10:03:46 2018 -0700
|
|     Update some styling issues and copy
|
*   commit a9b263cacd3240f6d00e7ce401fc6f6c23988cee
|\  Merge: 2d848cec deec4187
| | Author: Andrew Stuntz <andrewbstuntz@gmail.com>
| | Date:   Mon Aug 20 08:19:44 2018 -0700
| |
| |     Merge branch 'master' of some/private/repo
| |
| *   commit deec398745bc9b2ef74a418287b7864f2183940e

Already we are starting to get a little more visual, you see the commit easily from one branch into the master branch. You can also see at the bottom the commit that was made onto that branch before it was merged into the master branch.

The next command I like a lot is git log --oneline

This takes the output and makes each commit a single line, so it vastly increases the amount of commits that you can see at any give time.

8c2ca7c3 (HEAD -> master, origin/master) Fix the resetting of form fields on the settings form
cc309a7c Update some styling issues and copy
a9b263ca Merge branch 'master' of https://github.com/drews256/some/private/repo
2d848cec Add config and format correctly
deec4187 Merge pull request #1303940 from drews256/some-other-branch

Now we have the same amount of information, but succinctly displayed in 5 lines.

You can even combine the two and get git log --oneline --graph.

* 8c2ca7c3 (HEAD -> master, origin/master) Fix the resetting of form fields on the settings form
* cc309a7c Update some styling issues and copy
*   a9b263ca Merge branch 'master' of https://github.com/drews256/some/private/repo
|\
| *   deec4187 Merge pull request #1303940 from drews256/some-other-branch

You get the best of both worlds, you see the graph and branching plus the commits and now its displayed succinctly.

If you have color globally turned on for your git repos, this will display in full color, with each branch having a unique color which makes it very easy to follow. If that isn't the case and you want to add some color to your output, you can run git log --oneline --graph --color and you will see each branch nicely colored for you to explore.

Now you can see what and where your branches are easily and make sure your not working in or on places you shouldn't be.

What are your favorite parts of git?

Thanks atlassian for the cover photo.

Ridiculously easy row and column layouts with Flexbox

Andrew Stuntz — Fri, 10 Aug 2018 20:29:05 +0000

Super easy responsive Row and Columns in straight up CSS

Grid layouts are the bread and butter of web development design and chances are you've reached for something like Bootstrap or Foundation to make your layouts a reality. But, like most of you, I don't have a fondness of the dependencies required to run Bootstrap or Foundation nor do I like the ding to my page load times.

In fact when I use Bootstrap for an application that I am writing, I really almost only ever use it for the grid layouts, sometimes I will use it for notifications or basic fairly sensible CSS defaults, but 90% of the time, all I want is the grid layouts.

I also don't appreciate only have options of splitting columns into 12 columns or less. It feels like you sometimes have to do some crazy work arounds to get columns in columns, or strange things like that.

How can we do grid layouts faster and easier? Flexbox is your answer. I think

Flexbox

At this point flexbox is pretty much everywhere. It's supported by all major browsers. It allows for much easier layouts and is supported by React-Native which means when I layout pages for React-Native I reach for flexbox first, but I have found my self reaching for flexbox first in web development as well.

In fact the last application I laid out, I did entirely with flexbox. I have found it that easy to use.

If you don't know too much about flex box. I like this page that gives a good run down of flexbox

Layout

First I wrap the entire page in a div.

<div class='some-page-wrapper'>
</div>

Then I define a .row and .column class that can help with the layout.

.row {
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
  width: 100%;
}

.column {
  display: flex;
  flex-direction: column;
  flex-basis: 100%;
  flex: 1;
}

Now if we want a two column layout:

<div class='some-page-wrapper'>
  <div class='row'>
    <div class='column'>
      <div class='blue-column'>
        Some Text in Column One
      </div>
    </div>
    <div class='column'>
      <div class='green-column'>
        Some Text in Column Two
      </div>
    </div>
  </div>
</div>

The CSS looks like:

.some-page-wrapper {
  margin: 15px;
  background-color: red;
}

.row {
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
  width: 100%;
}

.column {
  display: flex;
  flex-direction: column;
  flex-basis: 100%;
  flex: 1;
}

.blue-column {
  background-color: blue;
  height: 100px;
}

.green-column {
  background-color: green;
  height: 100px;
}

What if we wanna add a third column? The HTML is easily updated to:

<div class='some-page-wrapper'>
  <div class='row'>
    <div class='column'>
      <div class='blue-column'>
        Some Text in Column One
      </div>
    </div>
    <div class='column'>
      <div class='green-column'>
        Some Text in Column Two
      </div>
    </div>
    <div class='column'>
      <div class='orange-column'>
        Some Text in Column Two
      </div>
    </div>
  </div>
</div>

And we get a third column added. That seamlessly nests itself in our row.

Now what if we want more complicated layouts?

We can just add more rows, that is pretty easy.

<div class='some-page-wrapper'>
  <div class='row'>
    <div class='column'>
      <div class='orange-column'>
        Some Text in Column One
      </div>
    </div>
    <div class='column'>
      <div class='blue-column'>
        Some Text in Column Two
      </div>
    </div>
    <div class='column'>
      <div class='green-column'>
        Some Text in Column Three
      </div>
    </div>
  </div>
  <div class='row 2'>
    <div class='column'>
      <div class='green-column'>
        Some Text in Row 2, Column One
      </div>
    </div>
    <div class='column'>
      <div class='orange-column'>
        Some Text in Row 2, Column Two
      </div>
    </div>
    <div class='column'>
      <div class='blue-column'>
        Some Text in Row2, Column Three
      </div>
    </div>
  </div>
</div>

Or we can resize our columns.

To have a double column we can add a .double-column class. This can work with any sized column though, you can do 60/40, you can do 10/10/10/10/10/10/10/10/10/10, honestly any combination is possible here. You can do 1 X 100. Or 10 x 1, then 20 x 3, then 30 x 1. The options are endless!

On one layout, I added a large margin around my "column" and since the row will wrap down, I have one row with as many "columns" as I need. The columns were fixed width cards so they just wrap to the next line and flexbox neatly responsively wraps the cards down the screen.

.double-column {
  display: flex;
  flex-direction: column;
  flex-basis: 100%;
  flex: 2;
}

This isn't very responsive though? We can add some responsitivity using media queries.

Just move the flex: 1 and flex: 2 into a media-query (size depends on application I'm just giving an option)

@media screen and (min-width: 800px) {
  .column {
    flex: 1
  }

  .double-column {
    flex: 2
  }
}

At > 800px:

At < 800px:

The final codepen, hint click the 1x or 0.5x buttons in the lower right corner to see the difference in the "responsive" layout.

Essentially we just blew the row/columns of bootstrap out of the water with 20 lines of CSS. We have a way to create row/column layouts quickly and since we use flexbox we barely have to worry about the layouts breaking, or anything going wrong. It's easily adapted to a wide variety of uses and allows a large amount of customizability. What do you think about flexbox? Have you tried it yet?

Another hidden benefit is that if I layout React components in this way, its pretty easy to layout React-Native components very easily to look similar.

I usually use SCSS in my projects so if you see something that isn't perfect CSS let me know!

Keeping API interactions sane while co-developing a React and React Native Application

Andrew Stuntz — Wed, 08 Aug 2018 18:46:19 +0000

React and React-Native oh my!

A tale of two applications

I recently worked on an application that had two separate public facing applications. One part was a web application, the other a phone application. Written in React and React-Native respectively. This use case is not that uncommon. It was fairly apparent from the get go that eventually we would need most features to be present in both the web application and the phone application. I figured we'd use Redux for state management but was pretty lost when it came to "interactions" with our back end from React and React-Native.

The nice part is that its just Javascript so there is nothing fancy going on here.

React-Native lifecycle hooks are the same and overall we wanted to make our mobile app experience much like our web app experience.

After some research we decided to use Redux-Saga to make our lives easier and we were able to copy most (if not all) of the api interaction between the two apps. There is even a thought that we may be able to get away with completely separating the API interaction from our views. Though, that may be a little more difficult than it sounds. Either way to the code examples!

But only a single backend

Currently the back end is written in Rails and was built as an API only application. This lets us completely separate the back end and front ends. We were able to statically host all of our JS and CSS for the web application. We serve zero html from our web server. How cool is that!? (I guess it's not that cool it is an SPA after all...) While the entire API does not follow the JSON API spec it does serve JSON API compliant JSON. Which I think adds a sense of consistency to our API. I'd like to continue to build out the JSON API compliance of the API but that is neither here nor there.

Here is an example of a Saga that we used to interact with the back end.

src/sagas/inventory.js

import { call, put, takeLatest } from 'redux-saga/effects'
import { defineTypes } from '../helpers'
import ProductsEndpoint from '../persistance/ProductsEndpoint'

// I use a custom Fetch implementation that wraps my requests to force
// authorization when required, it also forces JSON responses to be camelCased and // returns a consistent response from each request that we make.
import { fetch } from '../http/reduxFetch'

// This helper lets us have consistent reducer names, though it ended up not being perfect. 
const inventoryTypes = { ...defineTypes('INVENTORY')  }

export const initialState = {
  loading: false,
  loaded: false,
  stocked: false,
  error: {},
  products: [],
  inventories: []
}

// Each sagas exports actions and a reducer, which lets us combine them together // or use them across the app. Since they are all called 'actions' and 'reducer' // consistently it's super easy to import them at any point or from any component.

export const actions = {
  getInventory () {
    return { type: inventoryTypes.REQUEST }
  },
  toggleStock () {
    return { type: 'TOGGLE_STOCK' }
  }
}

export const reducer = (state = initialState, action) => {
  switch (action.type) {
    case inventoryTypes.REQUEST:
      return { ...state, started: true, loading: true }
    case inventoryTypes.DESTROY:
      return { ...state, loading: false }
    case 'TOGGLE_STOCK':
      return { ...state, stocked: !state.stocked }
    case inventoryTypes.FAILURE:
      return { ...state, loading: false, error: action.error }
    case inventoryTypes.SUCCESS:
      return { ...state, loading: false, loaded: true, inventories: action.inventories, products: action.products }
    default:
      return state
  }
}

// JSON API led to some heavy selectors. It would be prudent to add an inventory // selector or an attribute selector, but add it to the list!

export const selectors = {
  inventories: (store) => {
    return store['inventory'] && store['inventory']['inventories']
  },
  products: (store) => {
    return store['inventory'] && store['inventory']['products']
  },
  stocked: (store) => {
    return store['inventory'] && store['inventory']['stocked']
  },
  loaded: ({ inventory }) => {
    return inventory && inventory['loaded']
  },
}

export function * inventorySaga () {
  try {
    const products_response = yield call(fetch, ProductsEndpoint.index())

    if (products_response['data'] ) {
      yield put({ 
        type: inventoryTypes.SUCCESS,
        products: products_response.data 
      })
    } else {
      yield put({
        type: inventoryTypes.FAILURE,
        error: products_response['error'] 
      })
   }
  } catch (error) {
    yield put({ 
        type: inventoryTypes.FAILURE, 
        error 
    })
  }
}

// All our top level Saga's are exported as a rootSaga. This lets us import and 
// combine all of our sagas in a rootSaga file so we can keep everything 
// organized and check name spacing.

export function * rootSaga () {
  yield takeLatest(inventoryTypes.REQUEST, inventorySaga)
}

Overall this is pretty simple it looks like a Redux with some fancy yielding and generator functions. The most complicated thing going on above is the Saga itself. If you don't know too much about generator functions, you should check this guy out, it explains things nicely.

https://davidwalsh.name/es6-generators

In simple terms though, they basically step through functions and allow you to call .next() on them to run the function until it hits the next yield keyword.

Redux Saga is a side effect library for Redux that runs generator functions based on action calls. So you don't have to have your business logic in your reducers. It lets you run any Saga on any call to any action, you can also use many types of effects that let you take just one Action (so you don't repeat the API call), or just the last action call (so you can call multiple times and it just takes the latest), there are many options but these are the basic ones.

Here is some Redux-Saga documentation: https://github.com/redux-saga/redux-saga

Another cool thing about Redux Saga is that your Component has to know nothing about it. Since your expose your selector to the Component via Redux. Convenient eh!? They're API calls that are not dependent on Component Lifecycle hooks* or call backs. In fact we could hydrate the entire store and then render views one at a time, and the components would be none the wiser. We can also call the API endpoint once and then just select out what we need from the response as we go instead of recalling the API multiple times.

*Note at some point we do have to make API calls that have dependency's on components being rendered, but this vastly reduces the amount of lifecycle hooking we are doing. I also tend to have parent components that I hook into and the children components then select out of the store that is filled based on the API call from the one lifecycle hook in the parent component.

Now that we have the data how can we use this? Well, just need a connected component and all of a sudden we can pull data out of our selectors.

In a strictly React application:

src/components/Inventory.jsx and src/components/Inventories.jsx

import React, { Component } from 'react';

class Inventory extends Component {

  render() {
    return (
      <div>
        <div>
          { this.props.inventory && this.props.inventory['name']
        </div>
        <div>
          { this.props.inventory && this.props.inventory['attribute']
        </div>
      </div>
    )
  }
}

import React, { Component } from 'react';
import { selectors, actions } from '../sagas/inventory';

class Inventories extends Component {
  componentDidMount() {
    this.props.getInventory()
  }

  render() {
    return (
      <div>
        { this.props.inventories && this.props.inventories.map(inventory => {
          <Inventory inventory={inventory} />
        })
      </div>
    )
  }
}

// Since 'Inventories' is connected, any time we change inventories in our store,
//they're gonna get updated through the component. 

const mapStateToProps = (store) => ({
   inventories: selectors.inventories(store)
});

const mapDispatchToProps = (dispatch) => bindActionCreators(actions, dispatch);

export default connect(mapStateToProps, mapDispatchToProps)(Inventories);

Or in a React-Native Application

src/components/Inventory.jsx and src/components/Inventories.jsx

import React, { Component } from 'react';
import {
  View,
  Image,
  Text,
  StyleSheet,
  ScrollView,
} from 'react-native';

export default class Inventory extends Component {

  render() {
    return (
      <View>
        <Text>
          { this.props.inventory && this.props.inventory['name']
        </Text>
        <Text>
          { this.props.inventory && this.props.inventory['attribute']
        </Text>
      </View>
    )
  }

import React, { Component } from 'react';
import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';
import {
  View,
  Image,
  Text,
  StyleSheet,
  ScrollView,
} from 'react-native';

import { selectors, actions } from '../sagas/inventory';
import Inventory from './Inventory'

class Inventories extends Component {
  componentDidMount() {
    this.props.getInventory()
  }

  render() {
    return (
      <View>
        { this.props.inventories && this.props.inventories.map(inventory => {
          <Inventory inventory={inventory} />
        })
      </View>
    )
  }
}

// Since 'inventories' are connected, any time we change inventories in our store, they're gonna get updated through the component. 

const mapStateToProps = (store) => ({
   inventories: selectors.inventories(store)
});

const mapDispatchToProps = (dispatch) => bindActionCreators(actions, dispatch);

export default connect(mapStateToProps, mapDispatchToProps)(Inventories);

Almost the same exact components between React-Native and React. But all the business logic is thrown into the Saga so you don't have to worry too much about what is going on outside of the Component. Pretty easy to share the logic of the Saga and display what we want.

Overall we run through a quick example of sharing API interactions between a React-Native and React application using Redux-Saga's. It allows you to build out React and React-Native apps quickly against a single API but encapsulate and share business logic between the two applications even though the Components are completely separate.

*I'm by no means a JS/React or React Native expert. Let me know if you see anything funky or have any tips to help me elevate my JS or React game.

Rails and the Single Responsibility Principle

Andrew Stuntz — Thu, 02 Aug 2018 19:45:02 +0000

Single Responsibility Principle

The Single Responsibility Principle states that:

"every module or class should have responsibility over a single part of the functionality provided by the software"

This is fairly confusing though. Each module or class has responsibility for a single part of functionality of the software. Let's break this down a little bit. The functionality of software could be to display

Robert C Martin says it this way,

"A class should have only one reason to change."

Which is succinct. But complicated. A class should have only one reason to change. What exactly is a reason, and what is a change to a class. There are many ways to change a class. We won't dwell on these questions right this second.

How does Rails handle the single responsibility principle? How can we as developers uphold the single responsibility principle with the code that we write on top of the familiar Rails API?

Rails models can be tough to extend. One of the tenets of writing good RoR is to keep controllers "skinny" and people often move that excess code back into the model. Models tend to get complicated, and they get complicated quickly. As you extend them to do different things, we have to test each method, as side affects pile up and we end up with unmanageable models. Which are arguably worse than unmanageable controllers.

If you have been in the Rails community for almost any period of time I am sure you are familiar with the classic "Blog in 15 minutes Rails app". That allows you to post a new blog post and write comments about that blog post. It is simple and easy, traditionally, we have three models in this app. A Post, a Comment, and often a User or an Author.

The separation seems reasonable, in that there are two major things we need to do here and something needs to do those things.

The Post is the blog post, it includes:

an author
some information about when it was created
the text about the blog post

The Comment is just as simple it includes:

a reference to the post you are commenting on
some information about the person that posted the comment
the text of the comment

The Author/User that includes:

identifying information
magical rails associations that let you author comments and posts

The question here lies in what you expect the "Responsibility" here to be for each of these models.

Is it the Rails models responsibility to know where it is stored? What data is associated with itself. What to do you have a missing reference? What happens when each of the individual parts of a Comment or a Post are missing? How those models interact with other models.

Or you could take a bigger view, and say that the "single" responsibility here is that the model handles everything associated with the data that is the model.

We clearly know that it is not the responsibility to handle viewing itself, or to handle serving itself up at the correct end point.

Mr. Martin would say there should only be one reason for a Post or a Comment to change. What does this change entail? A change to the underlying data?

Rails is pretty good at this. A quick example could entail, the reason being that we updated, created, read, or deleted an instance of this model:

new_post = Post.new(user_id: 1, body: some_giant_wall_text)
# new_post is now a brand *new* instance of the Post class. 
new_post.save
# new_post is now persisted to the database
new_post.update(body: some_other_giant_wall_of_text)
# new_post is now persisted to the database again!

What just happened? The same instance of the class was persisted twice? Did we just break the SRP in three lines of Rails code?!

We did in fact mutate the instance of the class. A quick sanity check does show that:

new_post.body == some_other_giant_wall_of_text

The instance of the class changed. The reason behind this change was that we persisted the data to the database.

Why would rails do this? It sorta feels like the model was doing two things here. Saving and updating. But let me rephrase what it was doing. The Rails model was handling the CRUD operations to the database. That is all. We created the model, but passing in a hash of some attributes, which is succintly saved to the database, we then updated those attributes and it also succinctly saved these attributes to the database.

The responsibility of the Rails model is to handle object in the database. The model allows developers to quickly handle CRUD operations against a database.

I think its safe to say that the reason for changing is that the Rails model was persisting something to the database. An attribute of the model changed, therefore the instance of the class can change and still fit the SRP.

The point is, that in many cases Rails Models are consistent with the SRP and you don't have to be scared that you're Rails app is not SOLID outta the box.

Our Rails Models inherit from ActiveRecord::Base for a reason. ActiveRecord handles the reading, creating, updating, and deleting of objects in a database. Nothing else.

But.

Rails models are hard. They get complicated. We all know this. We have all broken a model in a Rail app with unexpected consequences.

Often times business rules want our models to do other things, interact with other objects. When we want to allow our Post to suddenly infer who the author of the Post is. Or we want to only allow certain Users to see and interact with certain Comments. Or a Post suddenly needs to be a part of a posting board. Or you need to add Tags to a Post.

Rails does allow you to do this safely. It is quite trivial to add a new column to the database and create associations in the database safely.

This is seen on our Comments and Posts relationship.

post = Post.find_by(author: 'me') # an instance of a post from our Database
post.comments # responds with a collection of Comments that match the Post ID
post.user # responds with an instance of the author
post.tags # responds with and error since we have no `Tag` table

Once again most of this is an extension of letting us persist information to our database. We still have yet to break the SRP. Furthermore, we were able to extend our model in many ways and not break SRP.

We get pretty far doing this. Very far.

Now what happens when you come back with a requirement like, each Author should have a summary of the Posts they have made. Easy enough you say.

author = User.find_by(name: my_name) # find an author
author.posts # find all the posts

🎉 I have a collection of posts for that Author. Easy peasy.

Now I don't want the entire post! That is a lot of text for a summary. I only want the first 200 characters of each posts. Its a summary!

We end up reaching for a method on Post since that is the most convenient way to handle the data manipulation that must happen to display certain posts.

We end with a method on the Post model like:

class Post < ActiveRecord::Base
...

  def body_summary
    body[0..200]
  end

...
end

So to get a Posts summary we can then call:

author = User.find_by(name: 'my_name') # find an author
author.posts(&:body_summary) # grab all the post summaries

But wait! What is the goal of ActiveRecord and our Rails model!? To Read, Update, Create, and Delete information from a database! Not to transform the data that we retrieve from the database.

Yes, now we have broken SRP in our Rails model. It was as simple as adding a single method. We have now modified the instance of the object, for a reason besides reading, updating, creating, and deleting values from the database. The database will never see nor care about the body_summary.

We are mutating an object that exists for a single reason, CRUD in a database, so that we can use it in a very different way, to display that information in a particular way in the view. This is a very, very common pattern to do in Rails. It is bad. :slaps hand away from writing crappy methods:

ActiveRecord models are for creating, reading, updating and deleting information from a database.

The body_summary itself is not the worst method in the world. My favorite Sandi Metz quote seemingly supports the existence of this code. In fact. I would encourage this effort in certain situations.

“The code is not perfect, but in some ways it achieves a higher
standard: it is good enough."

In this very simple example I would stop here and not really worry about it. Its not harming anything. Sure you could get into the N+1 query getting really heavy and taking a long time to generate the body_summary but chances are that is not a realistic possibility.

Besides the point. The code does break the single responsibility rule that we have defined so far. What are some Rails like ways that we can clean this code up?

Let's look at some other solutions so that our Post doesn't break the single responsibility rule. Starting from simple implementations to more complex solutions.

A simple and slightly better option here is to add a body_summary column to the Post table. Which would allow us to use a callback to add a body_summary each time we updated the Post.

class Post < ActiveRecord::Base
  ...
  after_save :build_body_summary

  def build_body_summary
    update({body_summary: body[0..100]})
  end
  ...
end

This is pretty simple. Personally I like the simplicity here and it keeps all the information in a single table and for use on the Post now when we want the body summaries we can access them like any other attribute on the Post object. But we are also assuming alot about the body here. What happens when build_body_summary fails? We need two validation cycles just to save the Post once.

Thinking about the single responsibility principle with respect to this solution the Post does save itself and all its own data. But does a Post need to be responsible for saving itself!? Does the Post class even have enough information to save itself each time? It must recall itself and then change by transforming itself into something that is close to, but not quite itself. Did it change with the express purpose of creating, updating, deleting, or reading? No, it changed to generate a body_summary that it then persists to a database.

Another option is to define a BodySummary class that is backed by a database table.

class BodySummary < ActiveRecord::Base
  belongs_to :post
  belongs_to :author
end

and extend the Post class with a callback. This would be a very Rails only way to keep the SRP in check. I would advocate the after_save callback because it would eliminate the need to overwrite the initialize method or overwrite other methods on the Post class.

class Post < ActiveRecord::Base
  ...
  has_one :body_summary

  after_save :persist_body_summary

  def perist_body_summary
    BodySummary.new(post_id: id, author_id: author.id, summary: body[0..100])
  end
  ...
end

This would allow us to use standard rails forms to build out a collection of summaries for each of the Posts. But there is now a pretty major dependency of BodySummary smack dab in the middle of the Post class.

This is almost worse than having a body_summary method on the Post class. Heading back to the single responsibility one could in fact argue that it is outside the responsibility of the Post class to persist anything in the database beyond itself and therefore we are breaking SRP here too. I don't totally agree that BodySummary itself constitutes an explicit break in the SRP if the intent of the Post class is to create, read, update, and delete data for the Post. It just happens to be in a different table than the Post. What are your thoughts on this?

A lot of people have talked about service objects lately. In fact there has been some recent kerfuffles by some heavy hitting Rails enthusiasts about the use of Service Objects.

The discussion on Service Objects and their overall necessity in Rails is a topic for an entire other post with many people on all sides advocating for both options.

I do enjoy a good service object and we could easily write a PORO that took a collection of Posts and returns the body summary.

class PostBodySummary
  attr_reader :posts

  def initialize(posts:)
    @posts = posts
  end

  def perform
    summaries = []
    posts.each do |post|
      summaries << post.body[0..200]
    end
    summaries
  end

end

Calling PostBodySummary.new(posts: user.posts).perform is very trivial and does the trick. One fall back here is we have a pretty limited understanding as to what is exactly going on with this model. If we don't crack open the PostBodySummary its pretty unapparent what we are doing. One way we can alleviate some of this pain is be renaming the perform method to something like generate_summaries. But ymmv in this simple case.

This is easily reusable and extensible. We could define a different method and it would return shorter summaries. Easily enough we could write:

class PostBodySummary
  ...
  def shorter_summaries
    posts.each do |post|
      post.body[0..100]
    end
  end
  ...
end

This is cleaner and follows our pattern above of explicitly returning what you call.

We should check in on the single responsibility principle here for a moment. What does the PostBodySummary class do? It takes an ActiveRecord Collection and returns the summaries of the bodies of the Posts. When does the PostBodySummary change? It only changes when we want a different ActiveRecord collection of Posts. This seems reasonable. One Author's set of Posts is different than a different set Author's Posts and each instance of the service object would reflect this change. This solution is probably the solution that I think follows the single responsibility principle the most. PostBodySummary changes when the collection of Posts changes. The one reason to change, is that the collection of Posts changes and this object reflects this.

Overall thinking about the single responsibility principle is tough. Especially when we are ready to extend the API that Rails exposes for us. Some people would say that I missed the point by talking too much about Rails models and that the single responsibility principle isn't so much about instances of objects and the way we use them as it is about the actual code in the class. I digress.

Rails models are tough to extend when they get complicated, part of the reasoning is that they continually break the single responsibility rule even in simple cases. Generally the goal of a Rails model is to handle the data and the database. I think this is complicated enough that, that is all it needs to do.

There are many options that let us encapsulate the complications of Rails models outside of the actual model. Some of my favorite are presented including utilizing callbacks to set an attribute on itself, using a Service object to completely remove the code, adding a new ActiveRecord object itself, and some options that fit in between.

Let me know what you think about the single responsibility principle!

-------- Some more commentary on the SRP by the man himself:

Uncle Bob's clarification to what he actually meant when he said:

"A class should have only one reason to change."

https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

-------- Some more info on Service Objects and the articles I mentioned earlier:

Aaron Lasseigne's piece on using service objects in response to Avdi's post:

https://aaronlasseigne.com/2017/11/08/why-arent-we-using-more-service-objects-already/

Avdi Grimm's piece on service objects and procedures:

https://avdi.codes/service-objects/

One thing to note, Aaron is the author of a very popular Service Object gem called ActiveInteraction. So that could possibly jade his overall opinion.