The infinite loading for account users is implemented using Turbo Streams and lazy-loading Turbo Frames with the geared_pagination gem. Here’s the complete flow:

1. Controller Setup (app/controllers/accounts/users_controller.rb)

def index
  set_page_and_extract_portion_from User.active.ordered, per_page: 500
end

The set_page_and_extract_portion_from method comes from the geared_pagination gem (version 1.2.0) and creates a @page object with:

• @page.records - the current batch of users
• @page.last? - whether this is the last page
• @page.next_param - the parameter for the next page

2. Initial Display (app/views/accounts/edit.html.erb)

<turbo-frame id="account_users">
  <%= render partial: "accounts/users/user", collection: @page.records, as: :user %>
  <%= render "accounts/users/next_page_container", page: @page.next_param unless @page.last? %>
</turbo-frame>

This renders:

• The first batch of users (up to 500 per page)
• A “next page container” if there are more users to load

3. Lazy Loading Container (app/views/accounts/users/_next_page_container.html.erb)

<%= turbo_frame_tag :next_page_container, loading: :lazy,
      src: account_users_path(page: page, format: :turbo_stream), class: "flex center" do %>
  <div class="spinner center"></div>
<% end %>

This creates a lazy-loading Turbo Frame that:

• Shows a spinner initially
• Automatically loads when it comes into the viewport (loading: :lazy)
• Makes a request to account_users_path with the next page parameter
• Requests the response in turbo_stream format

4. Turbo Stream Response (app/views/accounts/users/index.turbo_stream.erb)

<%= turbo_stream.replace :next_page_container, partial: "accounts/users/user", collection: @page.records, as: :user %>

<% unless @page.last? %>
  <%= turbo_stream.append :account_users, partial: "accounts/users/next_page_container", locals: { page: @page.next_param } %>
<% end %>

When the lazy frame loads, this:

1. Replaces the spinner with the new batch of users
2. Appends a new “next page container” to the bottom (if there are more pages)

5. How the Infinite Loading Works

1. Initial Load: First 500 users are displayed with a lazy-loading frame at the bottom
2. Scroll Trigger: When user scrolls near the bottom, the lazy frame enters the viewport
3. Automatic Request: Turbo automatically makes a request for the next page
4. Stream Update: The response replaces the spinner with new users and adds another lazy frame
5. Repeat: Process continues until all users are loaded (@page.last? is true)

Key Benefits of This Approach:

• No [Extra] JavaScript Required: Uses native browser intersection observer through Turbo’s lazy loading [This isn’t quite right. Turbo streams uses Javascript. But there definitely is the benefit that you don’t have to write any custom javascript]
• Seamless UX: Users see a spinner briefly, then new content appears automatically
• Performance: Large page size (500 users) reduces the number of requests
• Progressive Enhancement: Works without JavaScript (would fall back to regular pagination)
• Accessibility: Maintains proper focus management and screen reader compatibility

This implementation is elegant because it leverages Turbo’s built-in lazy loading capabilities rather than requiring custom JavaScript for scroll detection and AJAX requests.

Send me an email if you want access to this:

• First, you add your MTurk AWS credentials to the system. You can manage multiple MTurk accounts and sandbox accounts.
• You can then view all your HITs, their assignments, statuses, etc.

Restated problems:

1. You are given a list of “records”. Each record is a list of numbers (called “levels”). How many of the records follow both these conditions?
   1. Monotonic (always increasing or always decreasing)
   2. Levels change within a range 1-3
2. Same as 1. but you can remove one number from the record before checking the conditions.

Solution:

def each_way_to_remove_one_level(original_arr)
  original_arr.map.with_index do |_, index|
    original_arr.dup.tap { _1.delete_at(index) }
  end
end

def monotonic?(record)
  record.each_cons(2).map { |a, b| a <=> b }.uniq.count == 1
end

def small_distances?(record)
  record.each_cons(2).all? do |a, b|
    (a - b).abs.between?(1, 3)
  end
end

def safe?(record)
  monotonic?(record) && small_distances?(record)
end

def read_records_from_stdin
  ARGF.read.lines.map do |line|
    line.split.map(&:to_i)
  end
end

# Level 1
puts read_records_from_stdin.count { |record| safe?(record) }

# Level 2
puts read_records_from_stdin.count { |record|
  each_way_to_remove_one_level(record).any? { |record| safe?(record) }
}

I built it as part of the Bath Hack 2024 with my two teammates: Arnau Ayerbe and Varniethan Ketheeswaran.

Features

Title-Based Search on ArXiv: Academorphic starts by asking for the title of your dissertation or research paper. Using this title, it searches the ArXiv database, a repository of pre-print papers, to find relevant literature.

Summarization and Analysis: Once the relevant papers are found, Academorphic summarizes the key points of each paper. It then uses Retrieval-Augmented Generation (RAG) to answer specific questions about the literature.

Interactive Follow-Up Queries: If the title you provide is too vague or broad, Academorphic prompts you with follow-up questions to narrow down the search.

PDF Generation: After compiling and analyzing the relevant literature, Academorphic allows you to generate a PDF of your literature review with a click.

We used a new React library made by Vercel to build the UI. It lets you directly connect streamed LLM responses to React components, so you get snappy responses. Here’s a link:

Introducing AI SDK 3.0 with Generative UI support – Vercel

And a direct link to Gist in case the embed doesn’t work:

partition.rb

I recorded this demo video about six months ago showing my ideal todo system. Some key features:

• Capture: When you type new things into the system, you don’t see anything else. This lets you “brain-dump” without seeing anything in the system: useful!
• Process: You only see one inbox item at a time. This forces you to process every item in your mind so things don’t slip between the cracks.
• Project page: A little notes section helps you keep track of the project resources without being a full-fledged notebook. Link to Notion or another note-taking tool here. Or, for smaller projects, don’t type anything at all!
• Incubating + Waiting For: Delay tasks until a date, and you don’t see the project until that date arrives. Not quite a “start date” because the project might have already started but you just need to think about it for a few days. It’s also not a “due” date because nothing needs to happen on that day. Some use cases:
  • I need to sleep on this decision
  • I’ve got too much on my plate and don’t want to think about this for the next few weeks
  • I’m burned out on this project so I’ll rest for a few days
• Don’t forget a next action: Projects without a defined next step are highlighted as such, nudging you to add a task. And tasks can belong to multiple projects. When projects have clear next actions, it’s super easy to push them forward.
• Next actions page: When you sit down to work, you just look at the next actions page. Not a massive project/action/context window, just a list of things to do.

If you’d like to use this sort of tool, let me know and I’ll set it up properly!

Ruby on Rails is a framework for building web apps. It’s been around for 20 years and has big names like Shopify and Github using it. It’s also my favourite way to build products.

One of my clients that uses Rails also wanted to integrate with OpenAI’s ChatGPT. They make many calls to ChatGPT across the application for various use cases. Typically, standard programming techniques mean I don’t have to re-write the integration each time; I can reuse the same code for each integration.

But, specifically for ChatGPT, I noticed that I couldn’t really make this work. The reused code was either too specific or to general. When it was too specific, I couldn’t reuse the code across the integrations. When it was too general, the resulting code was ugly. I think this happened because the client has varying use cases for ChatGPT, so it’s hard to generalise appropriately.

I noticed that some of my other projects–such as my dissertation–would also benefit from using this generalised code. I talked with the client about extracting my work and publishing it as an open-source project. That way, I could spend more time coding without overcharging them; they agreed. The result is the ActiveCortex package.

From anecdotal experience, using ActiveCortex cuts down on about 150 lines of code. But I think the best benefit is how neat the new code is!

class Document
  ai_generated :summary
end

That’s all the code you need to automatically generate a summary for a document using OpenAI.

I’m hoping to add more features to this package, such as:

• Function calls
• Generating images
• Using images in a prompt

Check out the code and more examples here: https://github.com/penguoir/active_cortex

I was only responsible for verifying that the candidate could write good code. The client was responsible for everything else, like making sure the candidate wasn’t an arse, could speak English, could legally work for the company, etc. Another essential skill I was not testing is whether the developer could independently transform a loose design document into an implementation plan. This also was handled earlier in the hiring pipeline.

At first, I checked whether candidates could write good code by conducting a technical interview. All I did in this interview was ask them technical questions. I’d make sure they know about model-view-controller architecture, make sure they could use Git (ask me why!), and test-driven development. After an interview finished, I’d usually have a low-confidence rating for the candidate. My rating was low confidence because I could only base my confidence on what they said.

I eventually asked one candidate, “Can you show me some code you’ve worked on and talk me through it?” They shared their code, explained its context, and walked me through the constraints they were working under while writing it. We then had a fascinating discussion that clearly revealed the candidates’ opinions on what good and bad code looked like.

From then on, I conducted all my technical interviews using the golden question: “Can you show me some of your code?”

I didn’t mind if the code they showed me looked ugly. I only cared whether their internal classifier for good/bad code was calibrated.

Some candidates didn’t have much to say about their code, so I found a good follow-up question, “If you had time to re-write this function, how would you do it?”

I asked them to show me their code rather than show them some of my own because, as a developer, it isn’t necessary to look at code and quickly understand what it’s doing. It’s okay to take time to get acquainted with the system. I was worried that some developers wouldn’t have any side projects, but all of them did. On second thought, I don’t think a developer should apply for any role until they’ve written some code, so this makes sense.

At some point, the client wanted me to spend less time on interviews so I could divert more time to other priorities. Instead of setting up interviews, the client directly asked candidates to share some code they’d written and forwarded it to me. Although this was a faster method for assessing candidates, I lacked some of the context that often influences the code’s elegance, which lowered my confidence in my ratings.

One thing this approach doesn’t measure is the overall competency of a developer, which includes proficiency in business, product, and soft skills. For example, if the code they’re writing is entirely unnecessary (but clean), they’ll pass the “show me your code” test, even though they aren’t a competent developer. Competent developers don’t write unnecessary code. So, this test is great for measuring the developer’s coding style rather than their overall software engineering.

I want to mention that, of course, I’m influenced by many biases when using this approach to assess candidates. For example, I will likely give a higher score to a developer who writes code similar to mine. My code is neat, but I’m not perfect, so this assessment might return false positives for programming geniuses whose style differs from mine.

I actually stole this question from Andrejus K, who interviewed me a few years ago using this approach. Other than that one interview, I haven’t ever been asked this question. I don’t see why it’s not used more often in the industry. Please email me if you know!

The problems are:

• ChatGPT often responds in a long tutorial-style format when really all I want is a short response.
• ChatGPT relies on using tutorials, guides, blog posts. These are second-hand information so they are sometimes outdated, misguided or just incorrect.
• ChatGPT doesn’t have a great grasp of Rails internals. Especially bits that nobody else has written about. This makes it harder to build on lesser-known Rails functionality.

To combat these problems, I’ve taken the following steps:

• Prompted GPT to answer questions in the style I like.
• Upload all the Rails codebase into its “Knowledge”, so it can always base its answers off the latest Rails code.

I’ve pasted the full prompt below if you’d like to have a read.

OpenAI put a limit on the number of files that users can upload to custom GPTs, so I wrote a script that compresses the Rails codebase into a few files. I’ve pasted the script below. Although, I’m not entirely sure whether I managed to get the GPT to actually reference these files or whether it’s just using its existing knowledge of Rails.

Please email me if you have ideas for improving the GPT. And I hope you find this useful!

Here’s a link to RailsGPT, the custom GPT for your Rails questions.

# Copy every file from ../rails, recursively, to the current directory.
# Rename the file to just the library it's in.
#
#   /actionpack/lib/action_controller.rb
#
#   to
#
#   actionpack.rb

require 'fileutils'

Dir.glob('../rails/**/*').each do |file|
  next if File.directory?(file)

  # Skip test files
  next if file =~ /_test\.rb$/

  # Skip files that are not ruby
  next unless file =~ /\.rb$/

  # Skip files that are not in the lib directory
  next unless file =~ /\/lib\//

  # Skip fi the file is less than N lines
  next if File.readlines(file).size < 200

  # Append the file to the library name
  # e.g.
  # /rails/actionpack/lib/action_controller.rb
  # goes to
  # actionpack.rb
  library_name = file.split('/')[2]

  File.open(library_name + '.rb', 'a') do |f|
    f.puts "\n\n"
    f.puts "# #{file}"

    f.puts File.read(file)
  end
end

Full Prompt

“RailsGPT” is an expert GPT in Ruby on Rails internals, designed for professionals. Your role extends beyond just answering questions. You should also identify and address potential underlying problems in the user’s approach. In complex situations, rather than providing a direct fix, suggest alternative ways to structure programs to prevent the problem from occurring in the first place. Provide relevant Rails internal source code where relevant. Assume high user expertise. When faced with ambiguous queries, seek clarification to offer precise, context-relevant advice. Your expertise should guide users towards solutions that embody the principles and best practices of Ruby on Rails.

As I process my inbox, I sometimes encounter items that don’t have any immediate actions necessary or possible. Like when I need to wait a couple of days before filling in an application or I need some time to sit on an idea before writing it up. Recently, I’ve been sending these items to Follow Up Then, a service that sends me an email after some time has passed. Anything you send to 3days@followupthen.com gets sent back to you in three days.

Here are some of the emails I’ve received from Follow Up Then (I’m a uni student with a part-time software development job):

• “Don’t forget to apply for your university accommodation in one week’s time.”
• “Unsubscribe from this trial before it ends!”
• “Please email back over term time.” No problem, cc: october@fut.io
• “Renew your Railcard when it expires in a few months.”
• My professor promised he’d release answers for a problem sheet in a week, and I wanted to remember to check my answers against the correct ones to learn from my mistakes (I made many)
• I had coursework due in a few days but wanted to sleep on my answers before submitting it. “Submit coursework now that you’ve slept on it”
• I set myself a yearly theme and didn’t want to forget to do so next year.
• I rented an Arduino from my school department and had to return it in a few months.
• I wanted to sign up for a society once exam pressure died down (mountaineering!)
• I got an email that included information on what to do when I depart my accommodation, which was happening in one week: oneweek@fut.io
• I reached out to an old colleague on Linkedin and wanted to ensure I’d follow up in a few days if he didn’t respond, bcc: 3days@fut.io
• I got an out-of-office email and wanted to send a follow-up when they returned.
• “Set up revision schedule.” a few weeks before exams start.
• “Renew passport” sent to 10years@fut.io
• “I’ll do that when my exams are over” 7days@fut.io
• “Call when X is open after holidays” jan@fut.io

These projects are only actionable on a specified date in the future. They’re different from projects with a due date but also different from projects that have no date at all (“someday” projects). The project “finish implementation of X by wednesday” would not fit into FollowUpThen, nor would “learn Russian”, which has no specified start date.

These projects are so crucial that not addressing them would leave me feeling like there’s an ‘open loop’. Follow Up Then closes the loop for me.

The gods of productivity deal with “incubating” projects by keeping them out of sight, out of mind, until their start date arrives. For example, David Allen (last I heard) uses 43 folders to manage these incubating projects. He can send messages to himself in the future, reminding him to start the projects without bulking up his day-to-day system. However, even Allen acknowledges that this approach has limitations, such as being confined to the physical realm.

Follow Up Then achieves that same goal:

• I can send notes for the future to start up a project when its time comes.
• I only have to view or think about these notes for the future once their time comes.

I have yet to find another system that is as seamless as Follow Up Then for these goals. Please email me if you have found one!

These incubating projects come up all the time. Next time you notice one, try out FollowUpThen and let me know how it went!