Thoughts on Engineering, Photography, and Design.

I’m at the point in my career where keeping things simple is a top priority, even if that means a little sacrifice in other areas. In this particular case, as part of redesigning rpheath.com, I wanted to pull in the latest N posts from this blog. Given that I’m working with a static site, that meant using JavaScript. A young whippersnapper may immediately turn to React, Vue, Svelte, or (gasp!) Angular, which is reasonable. Those frameworks make this type of thing clean and easy. But I did not want to deal with integrating webpack and/or babel into my builds, as I’ve been down that road plenty, and it’s (shockingly!) still pretty annoying to deal with. Besides, each redesign of my personal site strives for more and more simplicity, so that would go against the grain.

I chose to use vanilla JS for this. Let’s talk about it! It all starts with a fetch-based function to grab the data from the blog’s API:

function fetchPosts(url, callbackFn) {
  fetch(url)
    .then(response => response.json())
    .then(data => callbackFn(data))
    .catch(error => console.error(error));
}

The fetchPosts() function grabs data from an API and hands it over to a callback function that I define for processing. This is all so simple because fetch() is built on the Promise, which in modern JavaScript, is an expectation for asynchronous calls.

Since we don’t have a framework to do stuff for us, the next “problem” we need to take care of is ensuring that our code runs at the right time. Meaning, after the DOM has loaded. Old school folks may remember jQuery’s $('document').ready(...) or $(function() { ... }) helpers! Yeah, it’s that, but with vanilla JavaScript. There are two ways to approach it:

 // (1) wait for the DOMContentLoaded event
 document.addEventListener("DOMContentLoaded", (_e) => {
   console.log("The DOM is ready!");
 });
 
 // (2) a self-executing function
 (function() {
   console.log("The DOM is ready!");
   console.warn("...but only if this JS is included at the bottom of the page");
  console.warn("...also, I ignore deferred scripts!");
})();

Both work, but notice the caveats with option (2) above. If you go with a self-executing function, it’ll execute whenever the browser reaches it, so it must be after your HTML is parsed, top-down (and even then it still ignores deferred scripts). We’ll go with option (1) for our purposes.

The next bit to work out is what to do with our data once we get it back from the API. In React, for example, we’d make a component that spit out some HTML for the browser. Well, that’s exactly what we’ll do, only we’ll use JavaScript’s Template Strings instead.

 const renderPosts = (data, container) => {
   let posts = [];
 
   data.forEach((post) => {
     const html = `
       <div class="post">
         <div class="post-date">
           <time>${post.date}</time>
         </div>
        <div class="post-link">
          <a href="${post.url}">${post.title}</a>
        </div>
        <p class="post-caption">${post.summary}</p>
      </div>`;

    posts.push(html)
  });

  container.innerHTML = posts.join("\n");
};

I bet any youngsters who stumble onto this won’t even know what innerHTML is. But essentially, we just take the data and iterate over the response, creating an array of string-interpolated items. Once we’re done “looping”, we just set the container’s HTML to render our posts.

It’s a nice touch to put some kind of default text or loading indicator into your “container” element:

<div id="blog-posts">
  [spinner svg] Loading Posts...
</div>

Then once the DOM loads and your function executes, innerHTML will replace your loading content with the interpolated response from the API.

Now that all of our pieces are in place, the result looks like this:

document.addEventListener("DOMContentLoaded", (_e) => {
  const blogContainer = document.querySelector("#blog-posts");

  // we only want to do this for the "blog" section of the site
  if (blogContainer) {
    fetchPosts((response) => renderPosts(response.data, blogContainer));
  }
};

You can see this in action by going to rpheath.com/blog.

The important lesson here, if there is one, is to avoid defaulting to complexity because “that’s what the internet does”. If I wanted to use React for this, I totally could, and the outcome would look very clean and satisfying. But the complexity involved with integrating React into my builds was just not worth it. I have the same result, but with zero configuration or headache. I’m just using what browsers already know and understand. And for me, that’s the reward.

I’ve been a young engineer, mentored young engineers, and now I manage (some) young engineers. One of the best perspectives a young engineer—or any engineer—can have is being proactive.

Engineering is complicated. There are often multiple teams and departments coinciding with ever-changing requirements. This can provide engineers with a tempting out (or “pause button”) when working on a problem because they feel blocked on some level. Does something like this sound familiar?

We can’t work on that yet because there’s no API.

Quite often, though, there’s more an engineer can do than claiming blockers. With minimal additional effort, let’s see how much more helpful a response like this might be:

We can’t work on that yet because there’s no API. But I spent some time thinking about what inputs and outputs we would need to properly build X feature, and wrote up my notes as a proposal for the backend team’s consideration.

Makes a difference, right?

It’s easy to throw things over the fence. It takes intentional effort to avoid it. But when you do, that proactive mindset can go a long way within a team and helps nurture a problem solving culture. It’s not about you, me, or them. It’s about solving a problem and helping everyone involved come up with the best outcome for the situation.

We all want to work with helpful, caring individuals… a proactive brain can help convey that to others.

I don’t think I fully believed in AI building software until fooling around with ChatGPT. Maybe it won’t affect software development like it feels like it might, but I don’t think it can be ignored any longer.

I like to imagine that all of us in software development, as it looks today, are busy making beautiful kerosene lamps in all shapes and sizes. We’re improving the burn efficiency. We’re finding ever clearer forms of glass to let the light through. We’re tinkering with a formula that’s been around for a long time. But as we do, Edison and Tesla are busy inventing electricity in the other room.

There’s a common pattern in a lot of applications to track who did what. Who created this post? Who was the last person to update it? Maybe it’s for accountability, maybe it’s because your client is nosy.

There are gems for this, but it’s such a simple thing, that extra dependency isn’t really worth it. So let’s take a look at a pretty simple way to achieve this in Rails 7 using a concern:

 module Ownership
   extend ActiveSupport::Concern
 
   included do
     before_validation :set_ownership
 
     scope :created_by, ->(user_id) {
       where(creator_id: user_id)
     }
    scope :updated_by, ->(user_id) {
      where(updater_id: user_id)
    }

    belongs_to :creator, class_name: 'User',
      foreign_key: 'creator_id', optional: true
    belongs_to :updater, class_name: 'User',
      foreign_key: 'updater_id'

    validates :creator_id, :updater_id,
      presence: true
  end

  private

  def set_ownership
    current_user = Current.user

    if new_record?
      self.creator_id = current_user.id
      self.updater_id = current_user.id
    else
      self.updater_id = current_user.id
    end
  end
end

Now, for any model that has creator_id and updater_id columns, you just have to include the Ownership module:

 class Post < ApplicationRecord
   include Ownership
 
   # ...
 end
 
 >> @post = Post.find(1)
 >> @post.creator
 # => #<User id: 10 ... >
>> @post.updater
# => #<User id: 20 ... >

And whenever a Post is created, the creator is automagically set; similarly, whenever any Post is updated, the updater is automagically set. This, of course, assumes your application has user sessions, since you obviously need to know who’s logged in doing the creating and updating.