Rob Race | Writing

Programming Tutorials Are Dead

Thu, 17 Sep 2026 07:00:00 GMT

I sell programming education.

So this is not a particularly convenient opinion for me to have.

Programming tutorials are dead.

Not literally. Somebody will read a Rails tutorial today. Somebody will buy a programming book this week. I will probably write more tutorials myself. What is dying is the old contract around them: I build a clean example application, show you how I implemented something, and then you do the work of translating that example into the application you actually care about.

The revenue is already trying to tell us something

I have sold developer books and other educational products for years. I know what launches used to look like, what warm-list sales looked like, and what happened when an article started ranking and pulled somebody into the rest of the catalog. My own gross revenue from traditional developer education has been moving in the wrong direction.

That is one person’s business, not an industry report, and there are plenty of ways I could explain it away. Maybe the audience changed. Maybe the market is saturated. Maybe I should write better emails.

Then Chris Oliver published a pretty blunt update about GoRails and Hatchbox. Chris has been teaching Rails developers for more than a decade, and GoRails grew from tutorials into a business that helped fund Hatchbox development. This is not a creator who posted three screencasts, had a bad launch, and decided education was broken.

In September 2026, while explaining a Hatchbox price increase, Chris wrote that AI had been brutal to education businesses. He said GoRails had historically subsidized Hatchbox development, that this was no longer sustainable, and that GoRails would have fewer new customers in 2026 than it had in its first year.

That got my attention because it looked a lot like what I was already seeing, and like how I was already behaving as a developer.

I am part of the problem.

I do not want to build your sample app anymore

The traditional programming tutorial has a hidden translation step. The author starts with their application, reduces the problem into something teachable, and builds a sample app, article, screencast, or course around it. Then the reader has to move all of that knowledge back into their application.

The flow looks something like this:

expert's experience
      ↓
tutorial application
      ↓
your eyeballs
      ↓
your brain
      ↓
your keyboard
      ↓
your application

For a long time, that was just how technical learning worked. The sample app has User; yours has Account and Membership. The tutorial uses Devise; you are using the Rails authentication generator. The author starts from rails new; you are adding the feature to a six-year-old application that has already accumulated several generations of perfectly reasonable decisions.

The tutorial tells you what worked in its environment, and you figure out which parts survive contact with yours. You were always the integration layer.

Coding agents changed that.

The agent already lives on the other side of the tutorial

A capable coding agent can inspect the application where the work is actually going to happen. It can see your models, tests, authentication setup, jobs, naming conventions, existing abstractions, and the weird compatibility code nobody remembers adding. It can search the repository before deciding where something belongs, implement a change, run the tests, inspect the failure, and try again.

That changes what I want from somebody teaching me.

Say I want to add reliable webhook processing to an existing Rails application. I can watch somebody build it from scratch in a clean app, pause the video, copy the relevant pieces, rename everything, adapt their assumptions, notice that my queue setup is different, search for the part where they discussed retries, and eventually get the implementation into my codebase.

Or I can give my coding agent good material about the architecture, failure modes, boundaries, tests, and decisions that matter, then let it inspect the application that already exists. I still need to understand the material, review the implementation, and have enough experience to notice when the result is wrong. I just do not need to manually reconstruct somebody else’s sample app first.

Hello World is fine

The title needs an asterisk. Short tutorials and documentation are not going away. Sometimes I want to know how a method works, see one small example, or remind myself how a Rails API works after not touching it for six months.

If I want to know how broadcast_replace_to works, a concise example is great. If I want to understand an N+1 query, I do not need an agentic implementation framework and a 40-page architecture document.

Hello World is fine.

The format starts to break down once the problem looks like a real production application. The less pristine the real app is, the less useful a pristine sample app becomes.

Authentication is not hard because nobody knows how to store a password digest. Billing is not hard because nobody knows how to make a Stripe API request, and webhooks are not hard because nobody knows how to accept a POST request. The difficult part is making those things fit the rest of the application without creating three new definitions of account ownership, two billing truths, and a retry path that only works when nothing actually fails.

That is repo-specific work, and the coding agent is already in the repo.

This is not really about vibe coding

The easy version of this argument is about beginners: somebody who barely knows how to code opens an AI tool, asks for a feature, and lets the model build the whole thing. Sure, that exists. I think the more interesting change is what happens to experienced developers.

I have been building software for a long time. I usually do not need another person to explain what a background job is, and I do not need to watch them type every controller action just to understand the architecture they settled on. What I want is the expensive part of their experience.

Why did you put the boundary there, and what failed before you ended up with this shape? Which assumptions actually matter? Where does concurrency become a problem? What looks like a harmless shortcut until production traffic shows up, what should the tests prove, and what should I absolutely not let the agent “clean up” because it will quietly change the behavior?

That is the useful material. I do not want your sample app nearly as much as I want your decisions. Once I have those decisions, a coding agent can do a lot of the mechanical adaptation inside the application I am already working on.

Beginners need the expert context even more

There is a weird assumption in some AI discussions that if models can generate code, beginner-focused education becomes less important. I think the opposite problem shows up pretty quickly.

An experienced developer can look at an AI-generated implementation and feel that something is off before they can always explain why. A beginner often cannot, because they do not have enough bad deployments, race conditions, security mistakes, and regrettable abstractions behind them yet.

The agent gives them far more execution ability than they would have had a few years ago. It does not automatically give them judgment.

Agentic coding also lets somebody get surprisingly far while learning only enough to keep the agent moving. The old way was slower and often tedious, but manually connecting authentication, authorization, billing, jobs, tenancy, and everything else forced you to build at least some mental model of how those pieces fit together.

Now the agent can connect a lot of those pieces before the developer really understands why the boundaries are where they are. That does not make the resulting architecture wrong, but it makes architectural judgment easier to skip. Teaching the implementation is not enough if the developer never learns how to tell whether a locally reasonable change still makes sense for the system as a whole.

Good educational material needs to help the human understand the decisions while giving the agent enough constraints that it does not invent the important parts from scratch.

The experienced developer uses that context to save time. The newer developer uses it to borrow judgment they have not built yet. Same source material, different reason for needing it.

Developer education needs an execution layer

This is where I think the product itself has to change. Adding a chapter called “Prompts,” putting a chatbot beside a video course, or generating an AI summary of a book keeps the old product intact and bolts an AI feature onto the side.

I think implementation-oriented education increasingly needs an execution layer.

The human still needs:

the mental model
the tradeoffs
the architecture
the reasoning
the failure modes
the vocabulary needed to review the result

The coding agent needs:

repository inspection instructions
implementation constraints
architectural contracts
recipes that can be adapted instead of copied blindly
invariants and verification steps
review questions
known failure modes
explicit boundaries around what should not change

The educational product should not stop at the point where the reader understands what should be built. It should be able to make the next jump into the environment where the thing is actually being built.

I backed into this while trying to make my own products less stale

I did not start with a grand theory about replacing technical education. I was trying to make the things I already sell fit the way I actually build software now.

Webhooks in Rails has a human-readable implementation guide, but it also includes an Agent Companion. The guide explains why the boundaries exist, while the companion gives a coding agent contracts, recipes, examples, and review questions it can use while working inside an existing application.

Rails Baseline goes further. The application itself establishes patterns for authentication, authorization, tenancy, entitlements, jobs, and the other boring-but-important pieces. Its agentic material helps a coding agent discover and continue those decisions instead of re-deciding them every time a new feature is added.

I did not add those pieces because “AI-powered” looks good on a landing page. I added them because handing somebody a static implementation and saying “now go adapt this to your app” started feeling incomplete.

Static implementation steps are becoming a commodity

The business part is uglier. A tutorial whose primary value is:

Here are the steps required to implement X.

is now competing with a machine that can generate those steps on demand while looking at the actual application.

That is a rough thing to compete with. It can answer follow-up questions, explain the same thing differently, change the answer after inspecting the repository, and then start doing the work. Recording the same CRUD flow with a better microphone is not going to fix that.

The valuable part moves toward the things that are harder to regenerate from a generic prompt: judgment, coherent architecture, tested constraints, strong opinions, known tradeoffs, and context that has been maintained by somebody who has actually dealt with the problem.

The economics around free educational content get awkward too. For years, the basic trade was understandable: publish useful material, build an audience, and some percentage of that audience buys the deeper product.

Now a developer can get a useful AI-assisted answer without necessarily visiting the source, joining the list, or buying anything. The knowledge can remain useful while the distribution model around the knowledge gets worse.

Chris’s GoRails numbers are a particularly loud example, but I do not need his business to make the point. I can see the same pressure in my own sales and in my own development habits. I am consuming more technical information than ever while becoming less interested in consuming it in the old format.

The educator’s job gets better, not smaller

There is a pessimistic version of this where AI replaces the teacher because the model can generate endless explanations and code. I do not buy that version, because the parts of technical education I value most were never the typing. They were the decisions behind the typing.

A good educator has already made the mistake I am about to make. They have already tried the abstraction that looked clean and became annoying six months later, figured out which framework convention is worth following and which one stops helping in this particular case, and seen which production failure should change the design instead of becoming one more rescue block.

That is useful context for a human, and it is also extremely useful context for an agent. The job starts looking less like “record every keystroke” and more like encoding judgment well enough that both the developer and the coding agent can use it.

That seems like a better product to me.

“But I still read tutorials”

So do I. I still read articles to understand concepts, look up APIs, and buy books from people whose thinking I want more of.

What I am much less willing to do is spend hours manually reproducing an implementation in a disposable sample app before I can apply the idea to my own code.

That is what I mean by dead here. The tutorial is not gone. It just is not the whole workflow anymore.

The tutorial is being split into two things

Traditional implementation tutorials bundled two jobs together:

Teach me what good looks like.
Show me enough code that I can reproduce it myself.

Coding agents pull those jobs apart. The human still needs understanding, while the agent can handle much more of the translation and execution.

The useful loop starts looking like this:

expert knowledge
      ↓
developer + coding agent
      ↓
actual codebase

That changes what is worth packaging and selling.

Books can still have chapters. Courses can still have video. Tutorials can still have code samples. But for implementation-heavy material, I think the complete product increasingly includes something designed to travel with the developer into their coding environment.

Not a magic prompt or “build this for me,” but actual context: decisions, constraints, examples, checks, and a process for applying them to a codebase the author has never seen.

Programming tutorials are dead

The title is supposed to be annoying. There will still be tutorials tomorrow.

What I am calling dead is the assumption that a static walkthrough of somebody else’s implementation is enough for a lot of real application work. Agents can inspect the destination codebase, carry context into the implementation, run the tests, and keep working after the tutorial would traditionally have ended.

The expertise still matters. I just do not want it to stop at a sample app anymore.

Your Webhook Endpoint Is a Tiny Distributed System

Wed, 09 Sep 2026 07:00:00 GMT

Webhook endpoints always seem simple when you build the first version.

Add a route, create a controller action, parse some JSON, update a record and return 200. Pretty standard Rails stuff.

Then the real requirements start showing up. You need to verify that Stripe or GitHub actually sent the request. The provider wants a response quickly, so the useful work moves into a background job. The same event arrives twice. A worker dies after doing half of the work. Two related events get processed at the same time. Another event shows up out of order.

At some point, that little controller action has picked up a surprising amount of infrastructure around it.

Nobody starts by saying, “I need a distributed system for this webhook.” You normally get there one completely reasonable requirement at a time.

It is still a small system, of course. We are not building Kafka and twelve services here. But once a webhook is production-ready, you have an external trust boundary, durable ingress, asynchronous workers, duplicate delivery, retries, concurrency, ordering problems and a handful of failure states that all need to agree with each other.

That is the part of webhooks I find interesting. A tiny HTTP endpoint becomes a pretty good microcosm of a much larger distributed system.

First, can you trust the request?

A webhook is public ingress into your application, so before doing anything useful with the payload, you need to answer the obvious security question: did the provider actually send this?

Most providers solve this with a shared secret and a signature over the request body. GitHub, for example, sends an HMAC-SHA256 signature in X-Hub-Signature-256. Stripe signs its payload and includes a timestamp in Stripe-Signature.

The important detail is that those signatures are based on the raw request body, not a Ruby hash after Rails has parsed it.

So the order here matters:

Read the exact request body.
Verify the signature.
Parse the payload only after you trust it.

Rails gives us request.raw_post for the first part.

A minimal GitHub controller can look something like this:

class Webhooks::GithubController < ApplicationController
  skip_forgery_protection

  def create
    raw_body = request.raw_post

    return head :unauthorized unless valid_signature?(raw_body)

    payload = JSON.parse(raw_body)

    # Persist and dispatch the verified event here.

    head :accepted
  rescue JSON::ParserError
    head :bad_request
  end

  private
    def valid_signature?(raw_body)
      secret = Rails.application.credentials.dig(:github, :webhook_secret)

      expected = "sha256=" + OpenSSL::HMAC.hexdigest(
        OpenSSL::Digest.new("sha256"),
        secret,
        raw_body
      )

      provided = request.headers["X-Hub-Signature-256"].to_s

      ActiveSupport::SecurityUtils.secure_compare(expected, provided)
    end
end

There are only a few lines here, but each one matters. The signature is compared with Rails’ secure_compare, the body is not parsed until after verification, and the endpoint skips normal browser CSRF protection because this request is not coming from one of our application’s browser sessions. The provider signature is what authenticates this request.

For Stripe snapshot events, I would use the SDK instead of rebuilding its signature format myself:

raw_body = request.raw_post
signature = request.headers["Stripe-Signature"]
secret = Rails.application.credentials.dig(:stripe, :webhook_secret)

event = Stripe::Webhook.construct_event(raw_body, signature, secret)

Stripe’s verifier also validates the signed timestamp against its tolerance, which helps with replay protection. Stripe’s docs are also very specific about passing the unmodified request body to the verifier.

Stripe’s newer thin events use a different SDK entry point, so this example is specifically for the snapshot Event objects used by the rest of this article.

So even before we process the event, the webhook endpoint already has its own trust boundary and its own security rules.

Receiving and processing are two different jobs

Ok, now that we trust the request, the next problem is how long we keep the provider waiting.

The webhook provider is making a normal HTTP request to our application. It does not want to wait while we update a bunch of records, call another API, generate something, send email or do whatever the event actually triggers.

GitHub.com expects a 2xx response within 10 seconds. Stripe’s guidance is to return a successful 2xx before doing complex processing that could time out.

That leads to a fairly boring ingress path, which is exactly what I want:

verify
  ↓
validate enough to identify the event
  ↓
persist a durable receipt
  ↓
enqueue work
  ↓
return 2xx

Personally, I do not want the request itself provisioning an account, recalculating billing, synchronizing a repository or doing some other multi-step business process. The request should establish that I trust the event and that my application has accepted responsibility for it.

New Rails 8 applications use Solid Queue as the default Active Job backend in production. A dispatch job can stay very normal Rails code:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  def perform(delivery_id)
    delivery = WebhookDelivery.find(delivery_id)

    # Dispatch to provider/event-specific handling.
  end
end

That gets the slow work out of the HTTP request, but just throwing perform_later into the controller is not the whole reliability story.

If you return a 2xx and then discover that the event never made it into a durable place, the provider thinks you have the event and you may not actually have it anymore.

This is where the acknowledgement boundary becomes important.

What does `2xx` actually mean?

I like storing a durable webhook receipt in the application database before telling the provider the event was accepted.

The first version does not need to be complicated:

class CreateWebhookDeliveries < ActiveRecord::Migration[8.0]
  def change
    create_table :webhook_deliveries do |t|
      t.string :provider, null: false
      t.string :external_id, null: false
      t.string :event_type, null: false
      t.json :payload, null: false
      t.datetime :processed_at
      t.datetime :failed_at
      t.text :last_error
      t.timestamps
    end

    add_index :webhook_deliveries,
      [:provider, :external_id],
      unique: true
  end
end

With that in place, GitHub ingress can start looking more like this:

def create
  raw_body = request.raw_post
  return head :unauthorized unless valid_signature?(raw_body)

  delivery_id = request.headers["X-GitHub-Delivery"].presence
  event_type = request.headers["X-GitHub-Event"].presence

  return head :bad_request unless delivery_id && event_type

  payload = JSON.parse(raw_body)

  delivery = WebhookDelivery.create_or_find_by!(
    provider: "github",
    external_id: delivery_id
  ) do |record|
    record.event_type = event_type
    record.payload = payload
  end

  WebhookDispatchJob.perform_later(delivery.id)

  head :accepted
rescue JSON::ParserError
  head :bad_request
end

One thing to call out here: the unique database index is doing real work. An exists? check followed by create! still has a race between those two queries. Two concurrent requests can both pass the check. The unique (provider, external_id) constraint is the final guard that prevents two receipt rows for the same provider event.

The receipt also gives us somewhere to recover from the slightly awkward gap between inserting application data and enqueuing a job.

Solid Queue has an important detail here. In a default Rails 8 production setup, Solid Queue is configured on a separate database from the application’s primary database. Creating a WebhookDelivery in one database and inserting a Solid Queue job in another is not one atomic transaction.

In the controller above, create_or_find_by! has already finished its transaction before perform_later runs, so the receipt is committed before enqueueing starts. If receipt creation and enqueueing happen inside a larger application transaction, Rails gives Active Job enqueue_after_transaction_commit to defer the enqueue until that transaction commits:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks
  self.enqueue_after_transaction_commit = true
end

That prevents work from being enqueued for a transaction that later rolls back. It still does not create one atomic transaction across the application and queue databases.

If the receipt commits and the queue insertion fails, I still want that event to be recoverable. A recurring reconciliation job that looks for old, unprocessed receipts is a simple solution and gives you another chance to enqueue the work.

Now 2xx has a much more useful meaning. It does not mean all of the business logic finished. It means the application has durably accepted the event and can recover the remaining work if something goes wrong.

Duplicate delivery is normal

This is probably the first webhook problem that surprises people when they have only worked with the happy path.

Imagine this:

Stripe sends an event.
Your application processes it successfully.
The response gets lost or arrives too late.
Stripe does not know the work succeeded.
Stripe sends the event again.

That is not some wild production edge case. Two systems communicated over a network and disagreed about whether the operation finished.

Stripe explicitly documents that the same event can be delivered more than once. GitHub gives every delivery an X-GitHub-Delivery GUID and keeps that same GUID when a delivery is redelivered.

This is why the (provider, external_id) unique index is useful. It gives us delivery idempotency. Receiving the same provider event over and over does not create a new logical event in our application every time.

However, delivery idempotency is not the same as business idempotency.

Suppose two different webhook events can both lead to the same business operation. Or suppose a job calls an external API successfully and dies before it records processed_at. The unique webhook receipt does not stop that external operation from happening again on the retry.

For those cases, I like the idempotency boundary to describe the actual operation:

class CreateProvisioningOperations < ActiveRecord::Migration[8.0]
  def change
    create_table :provisioning_operations do |t|
      t.references :account, null: false, foreign_key: true
      t.string :operation_key, null: false
      t.datetime :completed_at
      t.timestamps
    end

    add_index :provisioning_operations,
      [:account_id, :operation_key],
      unique: true
  end
end

That operation_key could be based on a provider object ID and the action you are performing. If the next external service supports its own idempotency keys, I would use those too when making that request.

This is also why I try not to think in terms of “exactly once” webhook processing. We do not control exactly how many times a provider attempts delivery, how many times a job is retried or whether a worker dies at a convenient point.

What we can control is whether doing the work again is safe.

Idempotency does not remove concurrency

There is another small wrinkle in the controller example above.

Two copies of the same event can both resolve to the same WebhookDelivery, and both requests can enqueue WebhookDispatchJob.

If the job starts with this:

return if delivery.processed_at?

…that helps with a later retry, but it does not protect against two workers starting at the same time. Both workers can read processed_at == nil before either one updates it.

For work that stays entirely inside our database, a row lock can make that state transition explicit:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  def perform(delivery_id)
    delivery = WebhookDelivery.find(delivery_id)

    delivery.with_lock do
      return if delivery.processed_at?

      Webhooks::Github::Dispatch.call(delivery)
      delivery.update!(processed_at: Time.current)
    end
  end
end

That example assumes Dispatch is doing database work that belongs inside the transaction.

I would not keep a row lock open while making a slow request to another service. Once the handler has external side effects, that business operation should normally have its own durable idempotency protection instead of assuming a database lock in Rails can control what another system does.

So now our tiny webhook endpoint has a concurrency model too. Fun!

There are two retry systems

Once processing moves to Solid Queue, there are two completely separate retry loops to think about: the provider retrying webhook delivery and our application retrying the async processing.

For Stripe, the flow looks roughly like this:

Stripe
  ↓ webhook delivery
Rails ingress
  ↓ durable receipt
Solid Queue
  ↓ processing attempt
business state

If Rails does not return a successful response, Stripe can retry the webhook delivery for up to three days in live mode using exponential backoff.

Once Rails has accepted the event, the job can fail independently. Active Job does not automatically retry every failed job for you; retry behavior is something you configure. A transient network failure could use something like:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  retry_on Net::OpenTimeout,
    Net::ReadTimeout,
    wait: :polynomially_longer,
    attempts: 5

  def perform(delivery_id)
    # ...
  end
end

I would not put every exception behind one giant retry rule. A timeout to another API may be temporary. A malformed payload is not. A missing mapping or a bug in the handler probably needs a fix rather than five delayed attempts at the exact same broken code.

Provider behavior is not universal here either. GitHub does not automatically redeliver a failed webhook delivery. You can redeliver manually or through the API, but that is very different from Stripe retrying failed deliveries on its own.

That is another reason I like owning the durable receipt and having a reconciliation path inside the Rails application. Recovery should not depend entirely on whatever retry policy the provider happens to use.

And then events arrive out of order

Even after making every individual event safe to retry, you can still get the wrong result if your code assumes events arrive in the order they happened.

Stripe does not guarantee event ordering. GitHub also documents that webhook deliveries can arrive in a different order than the underlying events occurred.

A billing flow could end up looking like this:

subscription.updated
subscription.deleted
subscription.updated   # delayed older event

If each handler blindly writes its payload to the local record, that delayed event can move the local state backward.

The fix depends on the provider. Sometimes there is a useful sequence or version. Be careful with timestamps: Stripe’s snapshot Event created value only has second-level precision, and Stripe says not to use it to determine event order.

For important state, another option is to treat the webhook as a notification that something changed and then fetch the provider’s current canonical object before making a local decision. That read can fail when the object has been deleted or is no longer available, and it is not an ordering guarantee by itself. Concurrent handlers still need a provider-specific version or sequence when one exists, local serialization, or a reconciliation rule.

The main point is to make the ordering assumption explicit. “This is the webhook I am processing now” does not automatically mean “this is the newest state.”

At this point we have duplicate messages, retries, concurrent workers and events showing up out of order. The distributed-system comparison is doing a lot less metaphorical work than it did at the beginning.

Every provider has its own little rules

There is definitely common webhook infrastructure worth sharing, but I would be careful about trying to make Stripe, GitHub, Shopify, Twilio and every other provider look identical too early.

Verification happens before trust. Durable receipts can share a lifecycle. Jobs can share dispatch infrastructure. Logging and admin tooling can be normalized.

The provider details still matter.

Stripe and GitHub alone are enough to show the differences:

Signatures: Stripe uses a timestamped Stripe-Signature format and provides an SDK verifier. GitHub uses X-Hub-Signature-256 with HMAC-SHA256.
Retry behavior: Stripe automatically retries failed live deliveries for up to three days. GitHub does not automatically redeliver failures.
Ordering: both document that deliveries can arrive out of order.
Delivery identity: Stripe events have event IDs. GitHub provides a delivery GUID in X-GitHub-Delivery that stays the same across redelivery.
Response expectations: GitHub expects a 2xx within 10 seconds. Stripe recommends returning a 2xx quickly before complex processing.

I normally prefer a common ingress shape with provider-specific verification and dispatch over a generic abstraction that hides details the application actually needs to know.

In Rails, this can stay pretty conventional:

Webhooks::GithubController
        ↓
GithubSignatureVerifier
        ↓
WebhookDelivery
        ↓
WebhookDispatchJob
        ↓
Webhooks::Github::Dispatch
        ↓
provider/event-specific handler

There does not need to be a framework behind every box. The useful part is having an obvious place for each responsibility so that Stripe-specific logic does not slowly leak into GitHub processing and vice versa.

A `200` is not observability

Once the useful work is asynchronous, the HTTP request stops telling us very much about what eventually happened.

A successful webhook response can mean the signature passed, a receipt was stored and the work was enqueued while absolutely none of the actual business processing has happened yet.

Eventually you need to answer questions about the event lifecycle instead of the HTTP request.

Did we receive delivery abc123? Was it a duplicate? What event type was it? Did processing ever finish? How many times did it fail? What was the last error? Can I replay it after fixing the bug?

This is another place where the WebhookDelivery model earns its keep. It gives logs, admin tooling, reconciliation and manual replay a stable record to work from.

I usually want enough state to distinguish something along these lines:

received → processing → processed
                  ↘ failed

You do not need to build a workflow engine for this. A few timestamps, an error field and a clear job boundary may be plenty. But once processing can happen seconds or minutes after the request, “the endpoint returned 200” is not a useful debugging answer anymore.

Ok, so we built a tiny distributed system

Let’s look back at everything our original controller picked up along the way.

We now have an untrusted network boundary, cryptographic verification, a durable message receipt, database uniqueness, an asynchronous queue, concurrent workers, duplicate delivery, an internal retry policy, a provider retry policy, out-of-order events, business idempotency, failure state, reconciliation, replay and observability.

None of those are especially exotic problems by themselves. The interesting part is how many of them get packed into a feature that started as POST /webhooks/stripe.

This does not mean the first webhook endpoint needs fifteen classes and a homegrown framework. I would still start pretty small. I just want the important boundaries to be obvious:

POST /webhooks/:provider
        ↓
verify the raw payload
        ↓
persist one durable receipt
        ↓
enqueue Solid Queue work
        ↓
provider-specific handler
        ↓
idempotent business operation
        ↓
record the outcome

From there, add complexity when a real failure mode calls for it.

The controller can stay boring. That is probably the best outcome.

The complicated part was never parsing the JSON. It was accepting work from another system when you do not control how many times the message arrives, when it arrives, what order it arrives in or which process eventually finishes it.

That is a lot hiding behind one Rails controller action.

I Tested Rails Baseline by Leaving Architecture Out of the Prompt

Thu, 27 Aug 2026 07:00:00 GMT

I did something a little different before shipping Rails Baseline 1.0.

Instead of spending another week adding starter features I thought somebody might need, I took the actual packaged ZIP, opened it as if I had just bought it, and handed it to fresh coding-agent sessions.

Then I gave them product prompts.

I did not tell them to use Pundit. I did not say to scope records through the current account, use public IDs, put paid access behind Entitlements, or use Solid Queue for background work. Those were all patterns already in the repository, and I wanted to see if the agent would find them without the prompt turning into an architecture checklist.

One test used Claude. The other used Codex.

Both went pretty well.

That sentence is intentionally boring. I was not trying to figure out which model could win a Rails benchmark. I wanted to test the codebase.

Why test the starter this way?

Rails Baseline is a normal Rails application, but part of the reason I built it was for coding agents.

I have spent years building SaaS apps and eventually wrote Build A SaaS App in Ruby on Rails 8. A lot of the hard-won stuff from doing that is not a particular controller action or gem install. It is knowing where certain decisions belong and trying not to make a different version of the same decision six months later.

Coding agents make this more obvious because they can produce so much code so quickly.

If the repository has a good pattern, the agent can usually find and continue it. If the repository is silent, the agent still has to build something. At that point it either asks, guesses, or follows whatever general Rails pattern seems reasonable from training.

A starter that claims to work well with agents should probably be tested by giving an agent incomplete product instructions and seeing what happens.

So that is what I did.

Test one: build a feedback board

The first test started from the RC1 release ZIP, outside the Rails Baseline source repository. I onboarded it as a new application and gave a fresh Claude session a prompt to build a small feedback board product.

The basic product was pretty normal SaaS stuff. Accounts could create boards, anonymous visitors could leave feedback, feedback had statuses, and plan limits changed how many boards an account could have. Paid accounts also got a CSV export.

I intentionally described those things as product requirements.

I did not say something like:

Use Current.account for tenancy.
Use Pundit for authorization.
Use Entitlements.enabled? for paid capabilities.
Use Limits.value for board counts.
Use HasPublicId for URLs.

That would prove I can write a detailed prompt. I already know I can do that.

The more interesting question was whether Claude would inspect the app and reach those conclusions itself.

It mostly did.

The board records were account-owned. Authorization followed the existing policy shape. The free and paid board counts went through the application’s plan-limit boundary instead of being scattered through controllers. The paid CSV feature used the entitlement layer. Public URLs followed the existing public-ID convention.

There was also a policy-scope mistake during the build. Claude caught it and fixed it during its own pass.

Good. That is much closer to what I actually want from an agent session than a first pass that looks impressive but quietly breaks account isolation.

The useful miss

The CSV export exposed something Rails Baseline had not really answered yet.

Where should a generated file live?

It would have been easy to react by adding Active Storage, S3 setup, an Export model, and some generic file-delivery service to the starter. That felt like exactly the kind of thing I did not want Baseline to become.

A lot of products do need durable generated files. Plenty do not. A CSV that can be generated quickly and downloaded immediately may not need to be stored at all.

So the answer became documentation instead of another core subsystem. I added a generated-artifacts recipe that talks through when synchronous generation is enough and when durable storage becomes a product decision.

That gave me something else to test later.

Test two: build an endpoint monitor

The second test started from RC2 and used a fresh Codex session.

This prompt was more demanding. Build an account-owned endpoint monitor that checks public HTTP/HTTPS URLs on a schedule. Free accounts get three monitors checked every 15 minutes. Paid accounts get 25 monitors checked every five minutes. Keep recent check history, support a paid CSV export, and optionally expose a public status page.

Again, the prompt described the product. I did not name the Rails Baseline implementation pieces I expected it to discover.

Codex found most of them.

It used account scoping and the existing Pundit context. It used persisted public IDs, Entitlements, Limits, tenant-aware jobs, and the Solid Queue recurring configuration. For the CSV export, Codex found the generated-artifacts recipe from the first dogfood and chose not to invent persistent storage for a file that could be generated on demand.

That last part made me pretty happy. The first test found a missing decision. I documented it, and a completely fresh agent used that documentation in the second test.

That is basically the behavior I wanted from Rails Baseline in the first place.

The second app found harder gaps

An endpoint monitor has one security problem that a feedback board does not have: the application has to make HTTP requests to URLs supplied by users.

Codex correctly treated that as an SSRF problem instead of just checking whether the string started with https://.

Its implementation resolved DNS, rejected private and other unsafe address ranges, pinned the connection to the validated address, used explicit timeouts, verified TLS, disabled environment proxies, and did not follow redirects.

Rails Baseline did not teach any of that.

I do not really consider that a failure of the starter. Safe outbound HTTP is one of those capabilities that only some products need, and there are enough security details that “just use Net::HTTP” is not much of a recipe.

Still, the test found a real boundary where an agent had to leave the existing precedent and design something new. That became one of the small recipes added before 1.0.

The scheduling side found another one.

Baseline already showed recurring Solid Queue work and tenant context inside jobs, but it did not show the shape needed when each account’s schedule depends on product state. Codex ended up with a minute-level dispatcher that finds monitors which are due and enqueues their actual check jobs.

That also became a short recipe instead of a new scheduling framework.

And, yes, the agent still wrote a bug

The endpoint monitor app ended up calling the model HttpMonitor because Monitor collides with a Ruby constant and EndpointMonitor collided with the onboarded application namespace.

The routes still used the product-facing name:

resources :monitors

At one point, a view used Rails’ polymorphic routing shortcut:

<%= link_to monitor.name, monitor %>

Rails saw an HttpMonitor instance and looked for http_monitor_path, which did not exist. The route helper was monitor_path.

That one made it through the agent’s test suite, and I hit it manually while clicking around the app.

The fix was easy, but I liked finding this too. A coding agent following the architecture well does not mean it stops making normal implementation mistakes. It also gave Baseline one more small Rails-specific recipe: if your model class and route resource intentionally use different names, either avoid polymorphic routing there or test a navigation path that exercises it.

No framework required.

What I actually learned from the tests

The useful result was not “Claude passed” or “Codex passed.”

Both agents were capable enough that the interesting differences came from what the repository gave them to work with.

When Rails Baseline had a clear local pattern, the agents usually found it. Account ownership, authorization, plan access, limits, jobs, IDs, and normal Rails/Hotwire UI conventions all carried through into new product code without me naming those pieces in the prompt.

When the app did not have a pattern, the agent had to make a product decision. Sometimes that was exactly right. Other times it exposed a missing piece of documentation that was general enough to add back to the starter.

That seems like a healthier way to build an agent-friendly codebase than trying to anticipate every future feature with another abstraction.

I would rather have 20 boring, well-used patterns and a handful of good recipes than 80 generic service objects waiting for a use case.

I will probably keep doing this

The best part of the process was how close it felt to an actual customer using the product.

I was not running tests inside the Baseline source repo and congratulating myself because they were green. The ZIP was packaged, copied somewhere else, onboarded into a new app, and then handed to an agent that had no history from building Rails Baseline.

That caught setup issues, product gaps, documentation gaps, and one wonderfully ordinary Rails routing bug.

For future Baseline releases, I think this kind of test is more valuable than adding another sample feature just so the feature list gets longer.

Give a fresh agent a product request. See what it copies. See where it guesses. Fix the parts that should have been obvious from the repository.

Then stop before the starter turns into the product it is supposed to help you build.

If you want to see the Rails app these tests were run against, Rails Baseline is at railsbaseline.com.

Print Smarter in Ruby - Know When and How to Use Each Method

Mon, 19 May 2025 00:00:00 GMT

If you’ve ever stared at a blob of console output wondering what the hell you just printed, you’re not alone. Ruby gives you a handful of ways to print stuff, but knowing when to use which one is the real trick. In this post, we’ll go through the five most common ways to print output in Ruby, plus one gem that makes your console look like it’s had a glow-up.

`puts`: Standard Output with Automatic Newlines

puts is your go-to for dumping simple output to the console. It stands for “put string” and adds a newline at the end of each argument. It’s as friendly and low-drama as it sounds:

puts "Hello, World!"
puts 123
puts ["Ruby", "Rails"]

Output:

Hello, World!
123
Ruby
Rails

Arrays get printed line-by-line, so don’t be surprised when each item shows up on its own line.

`print`: Continuous Output Without Newlines

Want to print multiple things on the same line? Use print. It’s like puts, but without the automatic newlines:

print "Hello, "
print "World!"

Output:

Hello, World!

If you want a newline, you’ll have to add it manually:

print "Hello, World!\n"

`p`: Debugging with Inspect Output

p is the debug sibling of puts. It shows the inspect version of the object and means strings keep their quotes, and you get more detail:

p "Hello, World!"
p [1, 2, 3]
p({name: "Rob", age: 39})

Output:

"Hello, World!"
[1, 2, 3]
{:name=>"Rob", :age=>39}

If you’re debugging and want raw visibility into what you’re working with, p is your friend.

`pp`: Pretty Print for Enhanced Readability

For more complex stuff like nested hashes, pp (pretty print) makes things readable:

require 'pp'

complex_hash = {name: "Rob", hobbies: ["coding", "fitness", {sports: ["cycling", "lifting"]}]}
pp complex_hash

Output:

{:name=>"Rob",
 :hobbies=>["coding", "fitness", {:sports=>["cycling", "lifting"]}]}

Think of it like p, but with spatial awareness.

`y`: YAML Output in IRB

The y method is only available in IRB (Interactive Ruby), but it’s a great way to spit out YAML-formatted data without much effort:

# In IRB
data = {name: "Rob", languages: ["Ruby", "JavaScript"]}
y data

Output:

---
:name: Rob
:languages:
- Ruby
- JavaScript

It’s tidy, structured, and way more readable when you’re dealing with nested stuff.

Quick Summary

Method	When to Use
`puts`	General output, automatic newline
`print`	Continuous output without newline
`p`	Debugging with inspect details
`pp`	Pretty printing for readability
`y`	YAML-formatted output (IRB only)

If you just want something quick and readable, puts and p will get you far. But if you’re working with nested hashes from an API and don’t want to burn your eyes out reading the raw dump then read on.

`awesome_print`: Enhanced Pretty Printing with Style

If pp gets the job done, awesome_print gets the job done with flair. It pretty-prints Ruby objects in full color, indents them beautifully, and makes your console output feel like VS Code decided to move in.

Installation

Using Bundler:

group :development do
  gem 'awesome_print'
end

Then run:

bundle install

Or install it directly:

gem install awesome_print

Usage

require 'awesome_print'

data = {
  name: "Rob",
  hobbies: ["coding", "fitness", { sports: ["cycling", "lifting"] }]
}

ap data

Output:

{
    :name => "Rob",
    :hobbies => [
        [0] "coding",
        [1] "fitness",
        [2] {
            :sports => [
                [0] "cycling",
                [1] "lifting"
            ]
        }
    ]
}

To make it the default in IRB:

require 'awesome_print'
AwesomePrint.irb!

Once you’ve used awesome_print, going back to puts feels like reading minified JSON with no line breaks.

That’s your tour of Ruby’s printing options. Use puts and p when you’re starting out. Graduate to pp and awesome_print when your objects get gnarly. And next time you’re knee-deep in nested hashes wondering why nothing looks right, don’t forget your options.

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

Wed, 14 May 2025 00:00:00 GMT

Performance issues in Rails apps can sneak up on you, especially if you’re working with ActiveRecord and unaware of the infamous N+1 query problem. This post will walk you through what N+1 queries are, how to detect them, and how to fix them using simple techniques. If you’re a beginner or intermediate Rails developer, this is one of the easiest ways to level up your performance game.

What is an N+1 Query?

Imagine going to the store with a shopping list of 10 items and making a separate trip for each one instead of buying them all at once. That’s what an N+1 query does: it performs 1 query to fetch a list of records (say Post.all), and then 1 additional query for each associated record (like post.comments).

# N+1 problem example
Post.all.each do |post|
  puts post.comments.count
end

This triggers one query to get all posts, and then one query per post to fetch its comments. If you have 10 posts, that’s 11 queries. Scale that up to 100 posts, and you’re dealing with 101 queries, most of them unnecessary.

How to Detect N+1 Queries

1. Check Your Logs

In development, check your log/development.log or Rails server output. You’ll often see the same query being run repeatedly.

2. Use the `bullet` Gem

The bullet gem is designed to catch N+1 queries and notify you.

Setup:

# Gemfile
group :development do
  gem 'bullet'
end

Configuration:

config/environments/development.rb

config.after_initialize do
  Bullet.enable = true
  Bullet.alert = true
  Bullet.bullet_logger = true
  Bullet.rails_logger = true
end

You’ll get an alert in your browser or console when Bullet detects a potential N+1.

How to Fix N+1 Queries

Use Eager Loading with `.includes`

Eager loading tells Rails to fetch associated records in the same query using LEFT OUTER JOIN.

# Fixing the N+1 problem
Post.includes(:comments).each do |post|
  puts post.comments.count
end

Now, instead of 11 queries for 10 posts, you only make 2: one for the posts, and one for the associated comments.

When to Use `.joins` or `.preload`

Use .joins when you’re filtering or ordering based on associated data.
Use .preload when you want to load associations but don’t need joins.

Common Mistakes and Gotchas

Forgetting to use eager loading in controllers or views.
Not eager loading nested associations (post.comments.user requires Post.includes(comments: :user)).
Overusing .includes can also hurt performance if you load too much data.

Real-World Example

Say you’re building a blog app and rendering a list of posts with their comments:

<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <% post.comments.each do |comment| %>
    <p><%= comment.body %></p>
  <% end %>
<% end %>

If @posts = Post.all, you’re triggering N+1 queries. Instead, use:

@posts = Post.includes(:comments)

This change alone can dramatically cut down your query count and improve performance.

Preventing N+1s Going Forward

Use the bullet gem in development to get real-time alerts.
Build a habit of checking logs when building or refactoring features.
Write performance tests if your app grows in size or complexity.

Want to keep improving your Rails performance? There’s a performance chapter in my Build A SaaS App in Ruby on Rails 8 book that covers this and more.

How to Build a Twitter Clone with Rails 8 Inertia and React

Tue, 14 Jan 2025 00:00:00 GMT

While I have written a bunch lately about using the “Rails way” to build applications, I have been keeping an eye on InertiaJS via internet friends, especially those in the Laravel space.

InertiaJS is a way to build single-page applications (SPAs) without creating an API. Specifically, using the inertia-rails gem, you can easily make a Rails application that uses InertiaJS to add frontend libraries.

rails new blabber --main --css=bootstrap

Rails will do its thing: install the application, install the gems, and process the Bootstrap and dependencies installs.

Next, we can review the model, controller, and routing setup before proceeding to the InertiaJS and React components.

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the formerly bird app that we are cloning, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

Before going forward with the controller, now that you have the database and model set, we should install the inertia-rails gem as it will dictate some differences in the controller and view layer (through frontend components).:

gem 'inertia_rails'

With the gem installed, we can run the installer:

bundle install
bin/rails generate inertia:install

The installer is interactive and will ask a few questions:

Do you want to install Vite Ruby? This library is the build tool for handling the front-end assets through InertiaJS. I selected yes, and I assume if you choose no, you would already be running some other front-end build process.
Would you like to use TypeScript? I use TypeScript in my projects, so I selected yes. If you are not familiar with TypeScript, you can choose no.
What framework do you want to use with Inertia? [react, vue, svelte4, svelte] I selected React, as that is what we are using in this tutorial.
Would you like to use Tailwind CSS? I selected no, as we are using Bootstrap in this tutorial.

The installer will install all those dependencies and set up the Rails application to use InertiaJS. It will also create a demo controller and “Page” component to show you how to use InertiaJS. Those files are found at app/controllers/inertia_example_controller.rb and app/javascript/pages/InertiaExample.tsx.

With everything added, you should be able to run bin/dev and see the Rails server and Vite server running. You can visit http://localhost:3000/inertia_example to see the demo page.

With the inertiaJS install out of the way, we can move on to the controller and corresponding view templates!

class PostsController < ApplicationController

  def index
    @posts = Post.all.order(created_at: :desc)
    render inertia: 'Posts', props: {
      posts: @posts.as_json
    }
  end

  def create
    post = Post.new(post_params)

    if post.save
      redirect_to posts_path
    else
      redirect_to new_post_path, inertia: { errors: post.errors }
    end
  end

  def like
    Post.find_by(id: params[:post_id]).increment(:likes_count).save
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment(:repost_count).save
    redirect_to posts_path
  end

  private

  def post_params
    params.expect(post: [:body])
  end

end

Simple controller. The index action returns a list of posts to @post and renders a Posts “page” in the front-end, which we will add shortly. create creates a new Post and redirects back to the Post component or the form if it fails. InertiaJS handles the routing in the front end to ensure the correct React rendering is happening. like and repost are similar, except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial.

Rails.application.routes.draw do
  get 'inertia-example', to: 'inertia_example#index'
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check

  # Render dynamic PWA files from app/views/pwa/* (remember to link manifest in application.html.erb)
  # get "manifest" => "rails/pwa#manifest", as: :pwa_manifest
  # get "service-worker" => "rails/pwa#service_worker", as: :pwa_service_worker

  # Defines the root path route ("/")
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root "posts#index"
end

The inertia install modified the application.html.erb file to include the Inertia and Vite tags. To make sure everything is copasetic, here is the entire file:

<!DOCTYPE html>
<html>
  <head>
    <title inertia><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="mobile-web-app-capable" content="yes">
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= yield :head %>

    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path(format: :json) %>

    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

    <%# Includes all stylesheet files in app/assets/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
    <%= vite_react_refresh_tag %>
    <%= vite_client_tag %>
    <%= vite_typescript_tag "inertia" %>
    <%= inertia_ssr_head %>
    <%= vite_javascript_tag 'application' %>
    <!--
      If using a TypeScript entrypoint file:
        vite_typescript_tag 'application'

      If using a .jsx or .tsx entrypoint, add the extension:
        vite_javascript_tag 'application.jsx'

      Visit the guide for more information: https://vite-ruby.netlify.app/guide/rails
    -->

  </head>

  <body>
    <%= yield %>
    <%= console %>
  </body>
</html>

This covers most of the initial changes needed on the traditional Rails side, and we can now start adding the React components.

import { Head } from "@inertiajs/react";
import { PostForm } from "../components/PostForm";
import { PostList } from "../components/PostList";
import { Post } from "../types/Post";

export default function Posts({ posts }: { posts: Post[] }) {
  return (
    <>
      <Head title="Posts" />

      <div className="container">
        <h1>Blabber</h1>
        <h4>A Rails, Inertia, React demo!</h4>
        <PostForm />
        <PostList posts={posts} />
      </div>
    </>
  );
}

A great thing about using React is the composability of the components that you would typically not get with ERB templates. The Posts component is a wrapper for the PostForm and PostList components. You may also notice that we’re pulling in a Post type to the PostList component. This import is a TypeScript type that we will define in a moment. Lastly, as mentioned before, inertiaJS will handle routing and rendering of these components. Thus, they provide a Head component for the page’s title.

For quick reference, here is the Post type:

app/javascript/types/Post.ts

export interface Post {
  id: number;
  username: string;
  body: string;
  repost_count: number;
  likes_count: number;
  created_at: string;
}

The PostForm component is a simple form that will allow the user to create a new post:

app/javascript/components/PostForm.tsx

import { useForm } from "@inertiajs/react";

export const PostForm = () => {
  const { data, setData, post, processing, errors, reset } = useForm({
    body: "",
  });

  function submit(e: React.FormEvent) {
    e.preventDefault();
    post("/posts", {
      onSuccess: () => reset("body"),
    });
  }

  return (
    <form className="my-4" onSubmit={submit}>
      <div className="mb-3">
        <textarea
          className="form-control"
          rows={3}
          value={data.body}
          placeholder="Enter Your Blab"
          onChange={(e) => setData("body", e.target.value)}
        />
        {errors.body && <div>{errors.body}</div>}
      </div>
      <div className="mb-3">
        <button type="submit" className="btn btn-primary" disabled={processing}>
          Blab
        </button>
      </div>
    </form>
  );
};

InertiaJS does a lot of the heavy lifting for you, including form handling. The useForm hook is a custom hook that InertiaJS provides to handle form data, submission, and errors. The submit function is a simple function that will post the form data to the create action in the PostsController. The form is a straightforward Bootstrap form with a textarea and a submit button.

The PostList component is a simple list of posts:

app/javascript/components/PostList.tsx

import { useEffect, useState } from "react";

import { Post } from "../types/Post";

import { PostItem } from "../components/PostItem";

export const PostList = ({ posts }: { posts: Post[] }) => {

  return (
    <>
      {posts.map((post: Post) => (
        <PostItem key={post.id} post={post} />
      ))}
    </>
  );
};

The PostList is relatively small component as it maps over the posts prop and renders a PostItem component for each post.

Next up is the aforementioned PostItem component:

app/javascript/components/PostItem.tsx

import { Post } from "../types/Post";
import { Link } from "@inertiajs/react";

export const PostItem = ({ post }: { post: Post }) => {
  return (
    <div className="card mb-2" id={`post_${post.id}`}>
      <div className="card-body">
        <h5 className="card-title text-muted">
          <small className="float-right">Posted at {post.created_at}</small>
          {post.username}
        </h5>
        <div className="card-text lead mb-2">{post.body}</div>
        <Link href={`/posts/${post.id}/repost`} className="card-link">
          Repost ({post.repost_count})
        </Link>
        <Link href={`/posts/${post.id}/like`} className="card-link">
          Like ({post.likes_count})
        </Link>
      </div>
    </div>
  );
};

The PostItem component is a simple Bootstrap card that displays the post’s username, body, and creation date. It also includes two links to repost and like the post. The links are InertiaJS Link components that will handle the routing and rendering of the repost and like actions.

Alright! That is all the React components we need to build the clone. If you head to your Rails app, you should be able to see the posts form and a list of posts. You can create a new post, which will appear in the list. Plus, you can like and repost posts.

However, if you have followed along with any of the other clone tutorials, you know that we are missing one key feature: real-time updates. In this tutorial, we will use ActionCable to add real-time updates and a npm package called use-action-cable to handle the front-end subscription.

First, we can add the ActionCable side to get the backend ready for the front-end subscription. We’ll start by adding a new channel to handle the posts (which will, in turn, add a few new default files as well):

bin/rails g channel PostsChannel

Next, we’ll add the subscribed method to the PostsChannel class to stream from the PostsChannel:

app/channels/posts_channel.rb

class PostsChannel < ApplicationCable::Channel
  def subscribed
    stream_from "PostsChannel"
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end
end

Also, we’ll edit the Connection file to identify the Cable connection with the browser session ID:

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

    def connect
      self.session_id = request.session.id
    end
  end
end

Lastly, for the backend, we’ll add a broadcast to the Post model to broadcast the post to the PostsChannel:

app/models/post.rb

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }

  after_commit :broadcast, on: [:create, :update, :destroy]

  def broadcast
    ActionCable.server.broadcast('PostsChannel', {
      posts: Post.all.order(created_at: :desc).as_json
    })
  end
end

This change will broadcast the posts to the PostsChannel after they are created, updated, or destroyed. Yes, this is ultra simplistic by returning all of the posts, but it will work for this tutorial. You would want to scope this down in a production application.

Alright, that’s it for the ActionCable backend! Next up is the React side of the application.

We will use a more current fork of the original use-action-cable package. This package will allow us to subscribe to the PostsChannel and handle the incoming posts.

yarn add react-use-action-cable-ts

This package utilizes a few custom hooks to add a connection to an ActionCable channel easily. We’ll use the useActionCable and useChannel hooks to subscribe to the PostsChannel and handle the incoming posts.

app/javascript/pages/Posts

import { useEffect, useState } from "react";

import { Post } from "../types/Post";

import { useActionCable, useChannel } from "react-use-action-cable-ts";
import { PostItem } from "../components/PostItem";

export const PostList = ({ posts }: { posts: Post[] }) => {
  const [postData, setPostData] = useState<Post[]>(posts);
  const { actionCable } = useActionCable("ws://127.0.0.1:3000/cable");
  const { subscribe, unsubscribe } = useChannel(actionCable, {
    receiveCamelCase: false,
    verbose: false,
    sendSnakeCase: false,
  });

  useEffect(() => {
    subscribe(
      {
        channel: "PostsChannel",
      },
      {
        received: (data: unknown) => {
          const cableData = data as { posts: Post[] };
          setPostData(cableData.posts);
        },
      }
    );
    return () => {
      unsubscribe();
    };
  }, []);
  return (
    <>
      {postData.map((post: Post) => (
        <PostItem key={post.id} post={post} />
      ))}
    </>
  );
};

The changes here will start with adding useState and useEffect to the PostList component. These hooks will allow us to set the incoming posts from the PostsChannel broadcast. We’ll also add the useActionCable and useChannel hooks to handle connecting to the PostsChannel. We will connect to "ws://127.0.0.1:3000/cable" to access the local ActionCable server output. Still, you should utilize another method of getting the current host if you put this code in Production. The hook returns an actionCable object that we can use to subscribe to the PostsChannel.

The useChannel hook will use that actionCable object to set up a function to subscribe to the PostsChannel and set a few settings for the channel. Specifically, the receiveCamelCase and sendSnakeCase settings are set to false to match the Rails backend. The verbose setting is set to false to reduce the console output.

The useEffect React hook will take the subscribe function from the useChannel hook and subscribe to the PostsChannel. The subscribe function takes two arguments: the channel name and an object with a received function that will handle the incoming data. The received function will set the incoming posts to the postData state. The useEffect hook will also return an unsubscribe function that will unsubscribe from the PostsChannel when the component is unmounted.

With all these changes, you should have a fully functioning clone that uses InertiaJS and React for the front end and ActionCable for real-time updates. You can create, like, and repost posts, which will be updated in real-time across all clients.

You can head back to https://localhost:3000 and see the posts in real-time now!

There you go! I bet that with a fast enough system to work through the Rails, gem, and Javascript package installs, you could complete this tutorial in less than 10 minutes!

Adding Sign Up to the Rails 8 Authentication Generator

Thu, 03 Oct 2024 00:00:00 GMT

This article spurned from writing about the new Rails 8 Authentication Generator in my Build A SaaS App in Ruby on Rails 8 book, and I wanted to share this small tip from the chapter on Users and Authentication.

Within the book, I set up a Rails 8 application with authentication using the bin/rails generate authentication command. This command creates a User model, a Sessions controller, and a few views to get you started. However, it does not include a Sign-up process at all.

In this quick article, we will add a Sign-Up form to the application.

Prerequisites

Before we start, ensure you have the Rails 8 application set up with the authentication generator.

rails new myapp --main
cd myapp
bin/rails generate authentication
bin/rails db:migrate

To add a Sign-Up form, we will need to add a few things:

A route to the Sign Up form
A controller action to render the Sign-Up form
A view to display the Sign Up form
A controller action to handle the form submission

Route

In the config/routes.rb file, add a route to the Sign Up form in addition to the routes created by the authentication generator:

config/routes.rb

Rails.application.routes.draw do
  resource :session
  resource :registration, only: %i[new create]
  resources :passwords, param: :token
end

Controller

Create a new controller called RegistrationsController:

app/controllers/registrations_controller.rb

class RegistrationsController < ApplicationController
  allow_unauthenticated_access

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      start_new_session_for @user
      redirect_to root_path, notice: 'Successfully signed up!'
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:email_address, :password, :password_confirmation)
  end
end

It’s pretty standard stuff here. First, allow_unauthenticated_access is a method that allows unauthenticated access to the new and create actions. Otherwise, we could use this controller with a valid session. The only other thing that is not standard Rails controller CRUD is the start_new_session_for @user, which allows the app to be signed in (add session record, secure cookie, etc.) after the user is created.

View

Create a new view file called new.html.erb in the app/views/registrations directory (view assumes Tailwind was added and has some classes):

app/views/registrations/new.html.erb

<div class="mx-auto md:w-2/3 w-full">
  <% if alert = flash[:alert] %>
    <p class="py-2 px-3 bg-red-50 mb-5 text-red-500 font-medium rounded-lg inline-block" id="alert"><%= alert %></p>
  <% end %>

  <% if notice = flash[:notice] %>
    <p class="py-2 px-3 bg-green-50 mb-5 text-green-500 font-medium rounded-lg inline-block" id="notice"><%= notice %></p>
  <% end %>

  <h1 class="font-bold text-4xl">Sign up</h1>

  <%= form_with model: @user, url: registration_url, class: "contents" do |form| %>
    <div class="my-5">
      <%= form.email_field :email_address, required: true, autofocus: true, autocomplete: "username", placeholder: "Enter your email address", value: params[:email_address], class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="my-5">
      <%= form.password_field :password, required: true, autocomplete: "current-password", placeholder: "Enter your password", maxlength: 72, class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="my-5">
      <%= form.password_field :password_confirmation, required: true, autocomplete: "current-password", placeholder: "Confirm your password", maxlength: 72, class: "block shadow rounded-md border border-gray-400 outline-none px-3 py-2 mt-2 w-full" %>
    </div>

    <div class="col-span-6 sm:flex sm:items-center sm:gap-4">
      <div class="inline">
        <%= form.submit "Sign up", class: "rounded-lg py-3 px-5 bg-blue-600 text-white inline-block font-medium cursor-pointer" %>
      </div>

      <div class="mt-4 text-sm text-gray-500 sm:mt-0">
        <%= link_to "Forgot password?", new_password_path, class: "text-gray-700 underline" %>
      </div>
    </div>
  <% end %>
</div>

Form Submission

If you were to try to submit the form now, it would work, but redirect to the registration form as there is no root path or authenticated path to test this all out on. Let’s create a quick controller and route to handle this:

app/controllers/home_controller.rb

class HomeController < ApplicationController
  def index
    render plain: "Welcome to the app!"
  end
end

config/routes.rb

Rails.application.routes.draw do
  get 'home/index'
  root to: 'home#index'
  resource :session
  resource :registration, only: %i[new create]
  resources :passwords, param: :token
end

If you visit the root path of your application, you should see the Sign-Up form. You can fill it out and submit it to create a new user. Upon successful creation, you should be redirected to the root path with the message “Welcome to the app!”

Bonus Idea

Usually, when building an app, there is a different layout when you are logged in than when you are on one of the “authentication adjacent” pages. You can add a method to the ApplicationController to determine if the user is authenticated or not:

app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  before_action :set_layout

  def set_layout
    @layout = user_signed_in? ? 'application' : 'authentication'
  end
end

Then, in your app/views/layouts directory, create two layout files: application.html.erb and authentication.html.erb. In the application.html.erb file, you can add a navigation bar, footer, etc. You can add a different navigation bar, footer, etc., in the authentication.html.erb file.

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Thu, 26 Sep 2024 00:00:00 GMT

This article will explore Turbo 8’s powerful features and a little bit of code. I swear, you will be surprised by how little extra code is needed to implement all of this!

We will be starting over but using many of the same concepts from the previous article. Let’s get into it!

Setup

First, we can create a new Rails app from the main branch to get all of the Rails 8 goodies (though, soon, this will be available through alpha/beta gem releases).

rails new --main blabber

Now, as we will be adding a few features related to user interactions, we will need to create users and a way to log them in. Short of using the new Rails 8 authentication generators, we can add two quick models, a small number of controller methods, and a few view templates.

First, the models via Rails generators:

rails g model user email:string password_digest:string
rails g model post user:references message:text

These generators will create two models and migrations for the Users and Posts. Let’s add a few lines to the User model for validation and authentication:

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

end

The significant addition here is the has_secure_password line which includes code to set and authenticate passwords via bcrypt. Now, on the Post model, the user reference should exist, and we can add a quick validation:

class Post < ApplicationRecord
  belongs_to :user

  validates :message, length: { minimum: 1, maximum: 280 }
end

Finally, here is a quick bin/rails db:migrate to get those tables created.

Now, we can move on to the controller and views for logging in. We want to make this simple, just for this tutorial, so we’ll handle logging in and logging out, their responsive routes, and some basic views.

First, the routes:

Rails.application.routes.draw do
  get "/login", to: "sessions#new", as: "login"
  post "/sessions", to: "sessions#create"
  get "/logout", to: "sessions#destroy", as: "logout"

  resources :posts, only: %i[index create]

  root "posts#index"
end

These will be all the routes we need for the whole app: the first three for sessions, a resource helper for posts, and setting the root route.

Now we can add the SessionsController at app/controllers/sessions_controller.rb:

class SessionsController < ApplicationController

  def create
    @user = User.find_by(email: params.dig(:user, :email))
    if @user && @user.authenticate(params.dig(:user, :password))
      sign_in(@user)
      redirect_to root_path, notice: "You have successfully logged in!"
    else
      flash.now[:alert] = "There was a problem logging in."
      render :new, status: 422
    end
  end

  def destroy
    sign_out
    redirect_to login_path, notice: "You have successfully logged out!"
  end

  private

  def sign_in(user)
    session[:user_id] = user.id
  end

  def sign_out
    session.delete(:user_id)
  end
end

Pretty simple here. If we find a user and that user authenticates with the included authenticate method from the User model, we will call sign_in, which sets a session for the user. Real quick, we can add a helper method in ApplicationController to use current_user throughout controllers and views through the app:

  def current_user
    @current_user = User.find_by(id: session[:user_id]) if session[:user_id]
  end
  helper_method :current_user

Next, we can quickly add a PostsController that resembles much of what we used in the last tutorial, aside from now having a user_id:

class PostsController < ApplicationController
  before_action :require_login

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params.merge(user_id: current_user.id))
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

  private

  def post_params
    params.require(:post).permit(:message)
  end
end

Both the index and create actions are reasonably straightforward Rails-like methods for listing and creating Posts. The last part of the authentication puzzle here would be to add the before_action:require_login method to the ApplicationController and use the Rails Console to create two users (thus, we skipped building a signup interface).

app/controllers/application_controller.rb


## redirect to login, if there is no current_user, meaning there is no authenticated user session
def require_login
  redirect_to login_path, alert: 'You must be logged in to access this page.' if current_user.nil?
end

Lastly, we can go ahead and knock out a few views to get all of the authentication, Bootstrap, and basic Post markup out of the way

app/views/layouts/application.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="mobile-web-app-capable" content="yes">
    <% if current_user %>
      <meta name="current-user-id" content="<%= current_user.id %>">
    <% end %>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
    <%= yield :head %>

    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path(format: :json) %>

    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet" type="text/css" />
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

    <%# Includes all stylesheet files in app/views/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
  </head>

  <body class="">
    <nav class="navbar navbar-expand-lg navbar-light bg-light">
         <div class="container-fluid">
           <a class="navbar-brand" href="/">Blabber</a>
           <span class="navbar-text">
             <% if current_user %>
               <%= current_user.email %>
               <%= link_to "Logout", logout_path, method: :delete, class: "btn btn-outline-danger" %>
             <% else %>
               <%= link_to "Login", login_path, class: "btn btn-outline-primary" %>
             <% end %>
            </span>
          </div>
      </nav>

    <% if flash[:notice] %>
      <div class="alert alert-success" role="alert">
        <%= flash[:notice] %>
      </div>
    <% end %>
    <% if flash[:alert] %>
      <div class="alert alert-danger" role="alert">
        <%= flash[:alert] %>
      </div>
    <% end %>
    <div class="container mt-5">
      <%= yield %>
    </div>

  </body>
</html>

A few code blocks to note:

<% if current_user %>
  <meta name="current-user-id" content="<%= current_user.id %>">
<% end %>

…will add the user ID to the front end for use in StimulusJS later.

<%= turbo_refreshes_with method: :morph, scroll: :preserve %>

…will allow Turbo 8 to morph the incoming DOM changes sent by Turbo.

Finally, Bootstrap is added over CDN for the simplicity of this tutorial, as well as a simple navbar and alerts.

Ok, three Post templates, and we’re done with setup.

To display the list of posts, you can create an index.html.erb file in the app/views/posts directory. Here’s an example of how the index view could look like:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>

  <%= render @posts %>
</div>

This code uses the _post.html.erb partial to render each post in the @posts collection.

<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

…and then the _form.html.erb

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control',rows: 3 %>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

This code uses the form_with helper to create a form for the @post object. The text_area helper creates a textarea input for the post’s message attribute.

Ok! That’s enough setup code!

Turbo Morph

If you followed along with the previous tutorial, there are only a couple of lines to add to get morphed updates out of the box! Earlier, we pre-empted the code to add with the line to the partial. To finish this off, we will add a line to the Post model and two through the Post views.

First, the line to the model:

class Post < ApplicationRecord
  belongs_to :user

  broadcasts_refreshes ## New line

  validates :message, length: { minimum: 1, maximum: 280 }
end

app/views/posts/index.html.erb

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>


  <%= turbo_stream_from 'posts' %> <!-- This is that streams from the post collection -->
  <%= render @posts %>
</div>

app/views/posts/_post.html.erb

<%= turbo_stream_from post %> <!-- This is that streams from each post -->
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

That’s it! If you create two users in the console, log on in, and then log another in on an incognito tab, you will see each page get updated with new posts from each user!

Presence Channel

Presence channels are a great way to show who is online in your application.

In our case, we will use an indicator next to the users’ email addresses in the Post card. This indicator will be a simple green dot if the user is online and a red dot if the user is offline.

The first step here will be to include icons to use a circle and then color it based on the user’s presence. We can easily include Bootstrap icons by adding the following line to the application.css file:

@import url("https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.3/font/bootstrap-icons.min.css");

Now, we can generate a quick migration to add an online boolean to the User model:

rails g migration add_online_to_users online:boolean
rails db:migrate

Next, we can add two simple methods to the User to adjust a user’s presence status using the online boolean. We will also add a method to broadcast changes to the presence channel after a user’s status changes and check for the online_previously_changed? (a built-in ActiveRecord field status method) in that method used by the callback:

app/models/user.rb

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

  after_commit :broadcast_changes

  def broadcast_changes
    if online_previously_changed?
      Turbo::StreamsChannel.broadcast_refresh_to(:presence)
    end
  end

  def came_online
    update!(online: true) unless online?
  end

  def went_offline
    update!(online: false) if online?
  end
end

Finally, we can add a line to the application.html.erb to listen for changes to the presence channel and then update the _post partial to include the presence indicator:

app/views/layouts/application.html.erb

...
 <%= turbo_stream_from :presence, channel: PresenceChannel if current_user %>
...

The turbo_stream_from:presence will use the turbo_stream helpers from the turbo-rails gem to handle the automatic subscription to the presence channel. The PresenceChannel argument in this method sets which Channel will be specifically used in the streaming process.

app/views/posts/_post.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <i class="bi bi-circle-fill align-middle text <%= post.user.online? ? 'text-success' : 'text-danger'%>" style="font-size: .5rem"></i>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

This uses the bi-circle-fill icon from Bootstrap and changes its color based on the user’s presence status.

Lastly, we can create the PresenceChannel in the app/channels directory:

app/channels/presence_channel.rb

class PresenceChannel < ActionCable::Channel::Base
      extend Turbo::Streams::Broadcasts, Turbo::Streams::StreamName
      include Turbo::Streams::StreamName::ClassMethods

  def subscribed
    stream_from "presence"
    current_user.came_online
  end

  def unsubscribed
    current_user.went_offline
  end
end

This channel extends and includes some Turbo::Streams modules, so that it can broadcast to the presence channel and handle the stream name. The subscribed method will stream from the presence channel and then call the came_online method on the current user. The unsubscribed method will call the went_offline method on the current user. unsubscribe is a method that is called when the client disconnects from the channel by closing the window or logging out.

Now, if you tried to use the browser, you would see errors from your channel in the logs, as we have to set up one last piece, the current_user in the Connection class. This class is much like an ApplicationController but for the ActionCable connections. We can add a method to the Connection class to set the current_user:

app/channels/application_cable/connection.rb

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

    def connect
      self.current_user = find_verified_user
    end

    private
      def find_verified_user
        if current_user = User.find_by(id: @request.session[:user_id])
          current_user
        else
          reject_unauthorized_connection
        end
      end
  end
end

This module will set the current_user to the user found by the session[:user_id], which was set during the login, or reject the connection if the user is not found.

If you were to open two browsers (your current browser window and an incognito would work!) now and log into each user, you would see the presence indicator change in real time!

Typing Indicators

The last feature we’ll build here is a typing indicator, which will show when a user is typing a message, much like you see in Slack. Of course, as this is just a simple app to demonstrate the capability, the typing indicator will be shown to all users but not the user typing.

First, we can generate a channel to handle the typing events and pin a debounce library to handle the typing events in a javascript controller a few files later:

bin/rails generate channel typing
bin/importmap pin lodash.debounce

Inside the TypingChannel, we can add a few methods to handle the typing and typing stopped events from the “Cable” side:

app/channels/typing_channel.rb

class TypingChannel < ApplicationCable::Channel
  def subscribed
    stream_from "typing"
  end

  def typing
    ActionCable.server.broadcast("typing", { action: 'typing', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def typing_stopped
    ActionCable.server.broadcast("typing", { action: 'typing_stopped', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end
end

This channel will stream from the typing channel and then broadcast the typing and typing_stopped events to the channel. The typing event will include the current user’s uid and user_email. This information is needed to do two things. One, the user_id will be used to filter out the currently typing user from seeing the typing indicator. Second, the email address is used to display the message so as not to send the data to the front end differently. The unsubscribed method was added to the channel by default during the generation of the channel but can be removed as it is not needed.

With that out of the way, the next place to add some code is the markup by adjusting and adding some StimulusJS to the Posts form:

app/views/posts/_form.html.erb

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
          <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group">
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', rows: 3 %>
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', data: { turbo_permanent: true, action: 'keydown->typing#typing keyup->typing#typingStopped' }, rows: 3 %>
    <div id="typingHint" class="form-text" data-typing-target="display"></div>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

We replace two lines, adding StimulusJS markup of <div class="form-group" and action: 'keydown->typing#typing keyup->typing#typingStopped' for the StimulusJS controller to listen for keydown and keyup events. We add turbo_permanent: true so that the turbo morph updates will not clear out the form’s current state (i.e., text that has been typed or bound javascript that StimulusJS is handling). Finally, the data-typing-target="display" will be used to update the message in the view when someone is typing.

Finally, we can add the StimulusJS controller to the app/javascript/controllers directory:

app/javascript/controllers/typing_controller.js

import { Controller } from "@hotwired/stimulus";
import consumer from "channels/consumer";
import debounce from "lodash.debounce";

export default class extends Controller {
  static targets = ["display"];

  initialize() {
    this.typingStopped = debounce(this.typingStopped, 1000);
  }

  connect() {
    this.subscription = consumer.subscriptions.create("TypingChannel", {
      received: (data) => {
        if (data.uid != this.userId) {
          this.displayTarget.innerHTML =
            data.action == "typing" ? `${data.user_email} is typing...` : "";
        }
      },
    });
  }

  typing(_event) {
    this.subscription.perform("typing");
  }

  typingStopped(_event) {
    this.subscription.perform("typing_stopped");
  }

  get userId() {
    return document.head.querySelector("meta[name=current-user-id]")?.content;
  }
}

This controller has many moving parts; we’ll go through them by behavior.

First, we create a getter for the userId, which will get the current-user-id from the meta tag in the head of the document, which was added way earlier when we first modified the application.html.erb. This will be used later in the event filtering process.

Then, in the connect method, we create a subscription to the TypingChannel and then listen for the received event. The received happens when the broadcast is sent from the TypingChannel. We’ll come back to the if statement in a moment.

In the view, we used keydown->typing#typing to call the typing function when that event happens in the browser. The typing function then calls the perform method on the subscription to send the typing event to the TypingChannel. This event triggers the typing method in the TypingChannel to broadcast the typing event to the typing channel, which is handled by the received handler.

Additionally, we used keyup->typing#typingStopped in the view to call the typingStopped function. Here, we debounce the typingStopped function to only call it once every 1000 milliseconds or one second. This function will prevent the typingStopped method from being called too frequently and basically allow the controller to wait for the typing to be stopped. Using a debounce function is a common pattern in JavaScript to prevent a function from being called too frequently. We are using debounce from the lodash library to do this and was added in the import statement at the top of the file. The trick to getting the StimulusJS-based keydown event to use the lodash debounce is to set the controller’s typingStopped function in the initializer to itself inside the debounce function call.

The typingStopped function then calls the perform method on the subscription to broadcast the typing_stopped event to the TypingChannel much like the same round trip for typing.

To get the controller ready to display text, we added data-typing-target="display" in the view to display the typing indicator and then added a static targets = ["display"]; to allow this controller to interact with that element.

Now, finally getting back to the code inside the received handler, we check if the uid in the data object does not equal the userId from the meta tag. If the uid is not equal to the userId, then we update the displayTarget with the user’s email and a message that they are typing. Inside the innerHTML setter, we use a ternary operator to check if the action in the data object equals typing. If it is, we set the innerHTML to the user’s email and a message they are typing. If the action is not equal to typing, then we set the innerHTML to an empty string which clears the message in the browser.

Now, suppose you were to open two browsers (again, a current browser and an incognito would work!) and log into each user. In that case, you would see the typing indicator change in real time as one user types; the other would see the indicator on their browser!

Conclusion

Anyway, closing out these tutorials always feel weird. Hope you learned something from this and leave a comment with any questions or feedback!

Rails Console in the Browser (on-demand)

Tue, 24 Sep 2024 00:00:00 GMT

Why in the browser?

While doing some research and working on some details for my new book Realtime Rails, I came across an issue where making changes to ActiveRecord objects in the terminal’s rails console were not showing up in the web browser. When working in development, based on default settings for ActionCable and the Rails server, for the broadcast to show up, it needs to be using the same process instead of the separate process spaned by the rails console in the terminal.

Also, having the console show up in the browser on demand is a pretty cool setup. You can see the changes in real time and interact with the objects in the browser.

How to set it up

If you need to set up the Rails console in the browser yourself instead, you will need to add the web-console gem to your Gemfile:

gem 'web-console', group: :development

Then, run bundle install to install the gem.

Once installed, you can add a web console to any view file by adding <%= console %>, then interact with the Rails console in the browser.

Taking it a step further

If you want to add some convenience to this process, you can add route, controller, and view (that are development only) to have the browser show up in the browser on a specific page in your application.

First, adding the development-only route:

if Rails.env.development?
  get '/console', to: 'console#show'
end

Then, create the controller:

class ConsoleController < ApplicationController
  def show
  end
end

And finally, the view:

<h1>Rails Console</h1>
<%= console %>

Now, when you visit /console in your development environment, you will have a console in the browser.

Alternate Idea

Another idea is to add a link to the console in your application’s footer. This way, you can easily access the console from any page in your application.

Then, add the link to the console in your application.html.erb layout file, but since we’re not relying on the route to show the console in the development environment only, we will need to add a conditional check in the template:

<% if Rails.env.development? %>
  <%= console %>
<% end %>

Personally, I’d rather have the console appear on a specific page, but this is a good alternative if you want the console available on every page in your application.

How to Build a Twitter Clone with Rails 8 and Turbo 8

Mon, 16 Sep 2024 00:00:00 GMT

Hotwire, StimulusJS, and Turbo have been out for the better part of half a decade, and there have been sweeping changes in the Turbo Broadcast and Stream patterns this past year. All of this gets bundled with Rails 8, plus other new features to make development even quicker, such as SolidQueue, SolidCache, and SolidCable. Two of those three make it dead simple to get this clone up and running super quick!

Without further ado, let’s get started with a new app:

rails new blabber --main --css=bootstrap

Rails will do its thing:

Install the application.
Install the gems.
Process the Bootstrap installation.
Install the yarn packages.

Hotwire and Turbo are now part of Rails, so installing anything extra is unnecessary! Just fire up bin/dev and start writing some code.

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the previous article, we’ll add the same validation in the Post model:

app/models/post.rb

class Post < ApplicationRecord
  broadcasts_refreshes

  validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the broadcasts_refreshes line. This line is part of Turbo 8, where the backend changes (here, changes to the model) are broadcast as a refresh event in Turbo, to be picked up by the turbo.js front end. Hidden behind the scenes is all the work Rails does to connect browsers, expecting that particular model instance to have updates and all the connecting parts such as ActiveJob, ActionCable, SolidQueue, and SolidCable.

We’ll make the same few minor adjustments to the generated migration file to add some database-level defaults (and allow us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
    t.string :username, default: 'Blabby'
    t.text :body
    t.integer :likes_count, default: 0
    t.integer :repost_count, default: 0

    t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

Another change with this process of refreshes and streams is that our controller can now be unaware of the streams and does not need to have format-based responses or template files that closely resemble the same partials used for the non-dynamic part of the app.

class PostsController < ApplicationController

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params)
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

  def like
    Post.find_by(id: params[:post_id]).increment(:likes_count).save
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment(:repost_count).save
    redirect_to posts_path
  end

  private

  def post_params
    params.require(:post).permit(:body)
  end
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and redirects back to the index template. like and repost are similar, except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) POST requests did not get the other browser window to update with the changes in my small app here. (If anyone knows why, I’d be happy to hear!)

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We can now add the “magic sauce” to the application layout to listen for refresh broadcasts.

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="mobile-web-app-capable" content="yes" />
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
    <%= yield :head %>
    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path %>

    <link rel="icon" href="/icon.png" type="image/png" />
    <link rel="icon" href="/icon.svg" type="image/svg+xml" />
    <link rel="apple-touch-icon" href="/icon.png" />

    <%# Includes all stylesheet files in app/views/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head by the rails new command, and just above it, we added <%= turbo_refreshes_with method: :morph, scroll: :preserve %> to tell the application to listen for refreshes.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>
  <%= turbo_stream_from 'posts' %>
  <%= render @posts %>
</div>

The view is a relatively simple Rails template. It uses a render @posts method to render the collection of @posts using a posts/_post partial. The turbo_stream_from:posts hooks up the view layer to listen to the Post model’s broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half-decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right"> Posted at <%= post.created_at %> </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <%= link_to post_repost_path(post), { class: 'card-link', data: { turbo_prefetch: false }} do %>
      Repost (<%= post.repost_count %>)
    <% end %>
    <%= link_to post_like_path(post), { class: 'card-link', data: { turbo_prefetch: false }} do %>
      Likes (<%= post.likes_count %>)
    <% end %>
  </div>
</div>

Another turbo_stream command is used to listen for broadcasted updates and deletions, and the dom_id helper is used to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
          <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group">
    <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
    rows: 3 %>
  </div>

  <div class="actions"><%= f.submit class: "btn btn-primary" %></div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form’s render call. Thus, we included the dom_id to allow the controller’s create action to enable Turbo to manage the streams’ markup.

Now we’ll head back to the controller to talk about the create action in depth:

def create
    @post = Post.new(post_params)
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

Previously, at this point, we’d discuss returning streams in the markup to be appended to the top-level frame, but Turbo 8’s refreshes and broadcasts manage all of that without any extra changes.

At this point, you should have an app that you can open in two browsers, which should look like this!

There you go! If everything went well, this was the fastest Twitter clone tutorial yet and probably required the least lines of code! Time will tell how all of this will play well together and scale in complex real-world Rails applications, but for now, the reduction in developer complexity is a huge win!

How to get a User's Timezone into Rails

Thu, 27 Jul 2023 15:00:00 GMT

You may have noticed most applications that you interact with and care about your timezone will, at one point, as you for your timezone and normally prepopulate the dropdown with your location’s timezone.

However, if you look for this functionality out-of-the-box in Rails, it does not seem to be there (or at least through all my sleuthing for My new app I am building). Though, I have the answer for how you can add this in about ten lines of code through one StimulusJS controller and your neighborhood Rails helpers.

First thing first, you will want to ditch the time_zone_select helper as the values used in there are not the same as what the browser will use in identifying time zones (I think Rails is not using the standard here, but I didn’t dig into too much while solving the technical issue). Instead, we will use a regular select and modify the array sent to a select tag:

<div data-controller="timezone">
  <%= f.select :timezone, ActiveSupport::TimeZone.all.collect {|tz| ["(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}", tz.tzinfo.name]}, {}, data: {"timezone-target" => "tz"} %>
</div>

When using a select tag, you can provide the second argument an array of strings to represent the “text” and option “value” in the dropdown options. Here "(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}" will construct a string with the offset and Rails timezone name (i.e., (UTC-08:00) Pacific Time (US & Canada)) and have the options value as the more accepted America/Los_Angeles. Additionally, at the very end, you can see where we are setting up the StimulusJS controller to interact with our select element, data: {"timezone-target" => "tz"}, which will produce data-timezone-target="tz" in the markup. Lastly, this select tag was wrapped in a div with an attribute to use the Timezone controller, data-controller="timezone".

Next, we can jump to the StimulusJS controller, which will also be simple. It is easiest to use the Rails CLI command to create the controller and update any other files that include controllers into the application.js:

bin/rails g stimulus timezone

Note - If you do not have Stimulus installed, you can do so with instructions here: https://github.com/hotwired/stimulus-rails.

In the new timezone_controller.js, you can add the following code:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {

  static targets = ['tz']

  initialize() {
    this.tzTarget.value = Intl.DateTimeFormat().resolvedOptions().timeZone;
  }
}

The Intl.DateTimeFormat().resolvedOptions().timeZone; is the browser’s javascript command for retrieving the timezone. Then, this.tzTarget.value = sets the dropdown value when the StimulusJS controller initializes.

That’s it! About five lines of custom code and another handful of edits to existing Rails tools to pre-select the user’s timezone in your Rails application!

This code, as-is, will not work for select boxes that need to be updated as it does not account for not overwriting an existing selected timezone provided by the backend. That’d be as easy as checking for the selected target’s value in Stimulus.

How to Build a Twitter Clone with Rails and Hotwire

Sun, 27 Dec 2020 00:00:00 GMT

Hotwire is fresh out of the Basecamp Github and has set the Rails community ablaze. This quick write up is an update from How to Build a Twitter Clone with rails, ActionCable, and React to show a comparison between the two approaches.

Now, this doesn’t mean to throw away any React code you may be using or StimulusReflex if you have already gone down that path. Those approaches are both more mature and widely discoverable.

I may follow this up with a video to do a more side-by-side look at these two approaches.

Without further ado, let’s get started with a new app:

rails new blabber --no-spring

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages.

Next, we will want to add the hotwire-rails gem to get the libraries needed:

gem "hotwire-rails", "~> 0.1.1"

Bundle and run the installer command for Hotwire:

bundle install
rails hotwire:install

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex/React article, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  after_create_commit { broadcast_prepend_later_to 'posts' }
  after_update_commit { broadcast_replace_later_to 'posts' }
  after_destroy_commit { broadcast_remove_to 'posts' }

  validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the callbacks. When using Hotwire, the prevailing convention is to use ActiveRecord callbacks. While working on the model collection, you can set up callbacks for create, update, and destroy broadcasts.

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

def index
  @posts = Post.all.order(created_at: :desc)
  @post = Post.new
end

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) } ## New for this article
    end
  end
end

def like
  Post.find_by(id: params[:post_id]).increment(:likes_count).save ## New for this article
  redirect_to posts_path
end

def repost
  Post.find_by(id: params[:post_id]).increment(:repost_count).save ## New for this article
  redirect_to posts_path
end

private

def post_params
  params.require(:post).permit(:body)
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and addresses some Turbo::Stream usage (more on that soon), and redirects back to the index template. like and repost are similar except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) Are GET requests making sure we do not have to worry about AJAX/fetch/CSRF in the front-end. You would work around these issues in a production application.

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quickly!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= yield :head %>
    <%= turbo_include_tags %>
    <%= stimulus_include_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head, turbo_include_tags, and stimulus_include_tags were all added earlier by the hotwire:install command.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= turbo_frame_tag 'post_form' do %>
    <%= render partial: 'form' %>
  <% end %>

  <%= turbo_stream_from :posts %>
  <%= turbo_frame_tag 'posts' do %>
      <%= render @posts %>
  <% end %>
</div>

The view is a relatively simple usage of Rails, with a render @posts method, rendering the collection of @posts, using a posts/_post partial. The turbo_frame_tag’s will allow the Turbo libraries to instantiate the “frames” that will manage the HTML partials sent over the wire from the broadcasted changes. A lot is going on with that process, but Hotwire and Rails are taking care of it all and merely managing the markup. Specifically, turbo_stream_from :posts hooks up the view layer to listen to the Post model’s broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted at <%= post.created_at %>
      </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <a class="card-link" href="<%= post_repost_path(post) %>">
      Repost (<%= post.repost_count %>)
    </a>
    <a class="card-link" href="<%= post_like_path(post) %>">
      Likes (<%= post.likes_count %>)
    </a>
  </div>
</div>

Another turbo_stream command to listen for broadcasted updates and deletions, and the dom_id helper to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form’s render call. Thus we included the dom_id to allow the controller’s create action to enable Turbo to manage the streams’ markup.

Now we’ll head back to the controller to talk about the create action in depth:

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) }
    end
  end
end

On a failed save, it will instruct the form’s partial to update the form frame with the form template, but this time with the errors markup triggered.

At this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

How to Build a Twitter Clone with Rails and Hotwire

Sun, 27 Dec 2020 00:00:00 GMT

Now, this doesn’t mean to throw away any React code you may be using or StimulusReflex if you have already gone down that path. Those approaches are both more mature and widely discoverable.

I may follow this up with a video to do a more side-by-side look at these two approaches.

Without further ado, let’s get started with a new app:

rails new blabber --no-spring

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages.

Next, we will want to add the hotwire-rails gem to get the libraries needed:

gem "hotwire-rails", "~> 0.1.1"

Bundle and run the installer command for Hotwire:

bundle install
rails hotwire:install

Now, let’s make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex/React article, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  after_create_commit { broadcast_prepend_later_to 'posts' }
  after_update_commit { broadcast_replace_later_to 'posts' }
  after_destroy_commit { broadcast_remove_to 'posts' }

  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

def index
  @posts = Post.all.order(created_at: :desc)
  @post = Post.new
end

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) } ## New for this article
    end
  end
end

def like
  Post.find_by(id: params[:post_id]).increment(:likes_count).save ## New for this article
  redirect_to posts_path
end

def repost
  Post.find_by(id: params[:post_id]).increment(:repost_count).save ## New for this article
  redirect_to posts_path
end

private

def post_params
  params.require(:post).permit(:body)
end

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quickly!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= yield :head %>
    <%= turbo_include_tags %>
    <%= stimulus_include_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head, turbo_include_tags, and stimulus_include_tags were all added earlier by the hotwire:install command.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= turbo_frame_tag 'post_form' do %>
    <%= render partial: 'form' %>
  <% end %>

  <%= turbo_stream_from :posts %>
  <%= turbo_frame_tag 'posts' do %>
      <%= render @posts %>
  <% end %>
</div>

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted at <%= post.created_at %>
      </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <a class="card-link" href="<%= post_repost_path(post) %>">
      Repost (<%= post.repost_count %>)
    </a>
    <a class="card-link" href="<%= post_like_path(post) %>">
      Likes (<%= post.likes_count %>)
    </a>
  </div>
</div>

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

Now we’ll head back to the controller to talk about the create action in depth:

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) }
    end
  end
end

On a failed save, it will instruct the form’s partial to update the form frame with the form template, but this time with the errors markup triggered.

At this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

Using Action Mailbox in Rails 6 to Receive Mail

Sun, 12 Jul 2020 19:00:08 GMT

Sending mail from a Rails application has been covered by hundreds or thousands of articles, however, there is not a ton of articles about receiving, parsing and using the new ActionMailbox.

The following is an excerpt from my book Build A SaaS App in Rails 6 and is used in a new product I am building Mail Buffer. Thus, I am standing by the tutorial here with real world usage!

Lastly, as this is an excerpt, this takes into account the chapter leading up to this section where the reader will have created an application, models for a Standup, Todo/Did/Blockers (which are Tasks) and a few mailers for outgoing mail.

Here goes nothing…

Another aspect of email within a SaaS application is receiving mail. While this is far less normal or used in comparison to sending, it can be a great way to make end user’s responses to email or action items quicker.

At a high level, there are a few different layers to this. The topmost layer is the email service, and this book’s case, Sendgrid. This service handles sending outbound emails, as well as routing incoming emails to an address/domain name specified in their interface. Once the email is routed, it will be redirected to a route and processor file in your application. This file will be responsible for parsing the incoming email address and using logic to decide what to do with it.

In the case of the Standup App we are building, we can have directions to respond to an Email Reminder to create a new standup right from their email response! Some of the tools that we will be using are Sendgrid’s email routing service and ngrok, an HTTP tunneling service. ngrok is very useful for a few solutions throughout the remainder of this book. It allows you to have a web-accessible URL, which tunnels(connects) to ports within your local machine. Meaning, that you will have a http://somesubdomain.ngrok.com that will forward to your computer and a specific port specified when you start ngrok. This allows you to test with external services such as Sendgrid, Stripe(later), Github(later), and more!

Let’s get started with some setup:

Download and use ngrok
- Download ngrok
- Unzip and move the executable file to where you would like.
- In *nix OS’s, open ngrok with: path/to/ngrok HTTP start 3000. This will be dependent on the port you are using for your Rails server. ngrok will now fire up a tunnel service with a randomly generated URL.
- Add config.hosts << "yoursubdomain.ngrok.io" to config/environments/development.rb
- Optionally, if you upgrade to a paid version of ngrok, you can set a subdomain, so you do not have to change your settings elsewhere every time you restart ngrok.
Follow your domain’s DNS provider’s instructions for adding an MX record for the subdomain or domain name you have chosen to use for inbound email. The MX record will be mx.sendgrid.net, with a priority of 10.

Now, before we head to the next part, we need to create and store a password for the incoming mail. You can use any method you like to create a password, and if you just can’t think of any way to do so, you can run SecureRandom.alphanumeric in Rails bash.

Now, to store this password you just came up with, we will need to introduce a new small, but powerful, feature, Rails Credentials. Since Rails 5.2, Rails provides a built-in way for storing secure credentials, that are encrypted.

To start using Rails Credentials, you will want to fire off the edit command:

EDITOR="atom --wait" rails credentials:edit

The editor I am using in this example is Atom. However, you can use any editor you like, and it’s command line caller. Also, --wait is used to make sure that the editor will wait for Rails to finish decrypting the file before opening it in the editor.

Now that we have the encrypted file open, add the following lines:

action_mailbox:
  ingress_password: *password you just made*

Save the file and close the tab/editor to make sure Rails saves the file and encrypts it. You will notice when Rails first opened the file, there was some output text in your terminal. Which includes the master key, DO NOT LOSE THIS KEY. It will need to be used a the only text in a config/master.key to be able to encrypt and decrypt the credentials.

Now, with that out of the way, there is a little bit more setup we need to do for Action Mailbox.

First, two commands to get Rails and some tables set up for inbound email:

bin/rails action_mailbox:install
bin/rails db:migrate

Lastly, add the following line to the config/application.rb file to let Rails know we’re using Sendgrid:

config.action_mailbox.ingress = :sendgrid

Ok, back to Sendgrid’s setup:

In Sendgrid, go to the Inbound Parse link, under settings, to create the email route that will send the email. Enter the following settings:
- Enter app.yourdomain.com for the domain field. You can optionally choose an additional subdomain to receive emails within the Inbound Parse.
- Enter http://actionmailbox:THEPASSWORDFROMBEFORE@yoursubdomain.ngrok.io/rails/action_mailbox/sendgrid/inbound_emails as the destination URL.
- Check POST the raw, full MIME message, before pressing the submit button.

Ok, we’re getting nearly done with the setup here. Next, we will need to set up the applications inbound email route and run a command to generate that mailbox class. First, in the application_mailbox.rb file that was created just a few commands ago, you will add routing /standups\.[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}@/i => :standups. This says when an incoming mail matches that email address syntax, it will be routed to the standups mailbox class for processing.

After that, to create the mailbox file, you will just need to run a Rails generator:

bin/rails generate mailbox forwards

A few changes will be needed to allow Action Mailbox and its files to capture text from incoming replies.

First, we will update the EmailReminderMailer to create a unique reply-to address and include that email address as part of the outgoing email:

class EmailReminderMailer < ApplicationMailer
  def reminder_email(user, team)
    @user = user
    @team = team
    reply_to = "'Standups App' <standups.#{@user.id}@app.yourdomain.com>"
    make_bootstrap_mail(
      to: @user.email,
      subject: "#{team.name} Standup Reminder!",
      reply_to: reply_to
    )
  end
end

Here we are adding the reply_to string to so when someone replies to a reminder email, the reply will be routed through Sendgrid, to Action Mailbox, and then finally by the Standup Mailbox class.

Next, we will update the mailer template to have ##- Please type your reply above this line -## and some text letting the email recipient know they can add a standup by replying:

<div class="container">
  <span class="text-secondary text-center" style="font-size:8px">##- Please type your reply above this line -##</span>
  <h1 class="text-center mb-4">
    Standup App
  </h1>
  <div class="card mb-4">
    <div class="card-body">
      <h3 class="text-center mb-4"><%= @team.name%> Reminder! </h3>
      <p class="mb-4">
        Just wanted to remind you to add your standup for
        the team: <%= @team.name %>
      </p>
      <%= link_to "Add Your Standup", new_standup_url(), {class: "btn btn-primary btn-lg mx-auto mt-2", style: "width:95%"} %>
    </div>
  </div>
</div>

Lastly, we will need to add an extra column to the Standups table to track the Message-ID coming from the Mailgun routed emails. As you can not count on an email service to provide “just once” delivery, we will need to track these unique IDs ourselves on the Standup table.

rails g migration AddMessageIdToStandups message_id

Next, before the end of the newly created migrations change method, you will want to add add_index :standups, :message_id. This index will allow quick lookups as the Standups table grows. Finally, migrate the actual change:

rails db:migrate

Lastly, to make sure sidekiq picks up the queues that Rails uses for Action Mailbox, we will need to adjust the worker in the Procfile.dev to:

worker: bundle exec sidekiq -q default -q mailers -q action_mailbox_routing -q active_storage_analysis

With those changes out of the way we can now add the new StandupsMailbox class that will parse the incoming email:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  def process
    # Get a user id from reply-to or bail
    reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
    return if reply_user.blank?

    # Find a user by the id or bail
    user = User.find_by(id: reply_user)
    return if user.nil?

    # Bail if standup with incoming message-id exists
    return if Standup.exists?(message_id: inbound_email.message_id)

    # Bail if a standup for today exists
    today = Date.today.iso8601
    return if Standup.exists?(standup_date: today)

    # Get content or bail
    safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
    tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
    return if tasks_from_body.blank? || tasks_from_body.empty?

    build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: inbound_email.message_id
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end

  def mail_body
    @mail_body ||= begin
      if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
    end
  end
end

The class is relatively simple, but let’s go over it section by section:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  ...

Here we are setting up the StandupsMailbox to inherit from the ApplicationMailbox class, which handles the routing. Additionally, we are creating a hash to later use in the text content to Task type conversion.

...

def process
  # Get a user id from reply-to or bail
  reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
  return if reply_user.blank?

  # Find a user by the id or bail
  user = User.find_by(id: reply_user)
  return if user.nil?

  # Bail if standup with incoming message-id exists
  return if Standup.exists?(message_id: inbound_email.message_id)

  # Bail if a standup for today exists
  today = Date.today.iso8601
  return if Standup.exists?(standup_date: today)

  # Get content or bail
  safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
  tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
  return if tasks_from_body.blank? || tasks_from_body.empty?

...

Here we are grabbing some information used in the parsing, as well as giving the process method chances to exit early if the incoming email is not sufficient for processing and Standup creation. In the first section, the incoming email address is parsed to find the user’s id. That string is then used to find a User. If there is no user, the method returns without adding a Standup.

The next line will exit the method early if there is already a standup with the current Message-ID. Again, this is making sure to guard against email providers, not guaranteeing “just once” delivery. That is followed up by generating a variable for the current date and making sure there is no standup with the current_user and current_date.

To get the mail’s content, we will want to do two things, make sure we get the correct body from the mail object as email clients can send both an HTML and plain text version. Then we will want to make sure we only grab the content above the ##- Please type your reply above this line -## string by using the split method (which splits a string into as many parts based on the separator specified in the argument):

def mail_body
    @mail_body ||= begin
      body = if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
      body.split('##- Please type your reply above this line -##').first
    end
  end

Finally, the actual email content is parsed with a regular expression. Regular Expression is a programming language that allows you to pattern match on a string and even capture parts of the pattern matching. This particular pattern(which you can get a more thorough syntax explanation here) searches for lines that begin with [d], [t] or [r]. If those are present, it captures the content to the end of the line. The .scan method on the content’s body allows it to catch all occurrences of the above pattern. If the scan’s output is empty, the process method exits.

  build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: email.headers["Message-ID"]
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end
end

The last section here is a culmination of all of the stored information so far to be saved into a new Standup. The user, tasks_from_body, today, and message_id are all passed into a method that will hand the actual save. The build_and_create_standup method creates a new Standup, with the user’s ID, date, and message_id. Once the object is created, the task’s strings are iterated over to build the Task with a type and assigned as child objects with the << syntax. Finally the new Standup object with children Tasks will be saved with standup.save

Lastly, you can test this all works if you reply back to an email(that was sent through Sendgrid SMTP and not letter_opener) with the following text:

[d] Did a thing
[d] And Another
[t] Something to do
[b] Something in the way. Some really long line about something or another

Testing this will require a new spec file with a few it blocks to test all the branches the StandupMailbox may encounter.

First, we will need to add one small change to the rails_helper.rb file to make sure RSpec has access to the Rails Action Mailbox test helpers. I’ll add the new lines and a few lines above each, so you know where to put the new stuff:

...

require 'support/system_macros'
include Warden::Test::Helpers
require 'action_mailbox/test_helper' # <-- new line

...

RSpec.configure do |config|
  config.include Devise::Test::ControllerHelpers, type: :controller
  config.include Devise::Test::ControllerHelpers, type: :view
  config.include ActionMailbox::TestHelper, type: :mailbox # <-- new line

...

…and now the actual spec file itself:

require 'rails_helper'
include ActiveJob::TestHelper

RSpec.describe StandupsMailbox, type: :mailbox do
  let(:user) { FactoryBot.create(:user) }
  let(:to_email) { "standups.#{user.id}@app.buildasaasappinrails.com" }
  let(:body) do
    %Q(
      [d] Did a thing
      [d] And Another
      [t] Something to do
      [b] Something in the way. Some really long line about something or another

      ##- Please type your reply above this line -##
    )
  end

  subject do
    receive_inbound_email_from_mail(
      from: user.email,
      to: to_email,
      subject: 'Re: Reminder',
      body: body
    )
  end

  before do
    ActiveJob::Base.queue_adapter = :test
  end

  it 'saves standup record' do
    expect { subject }.to change(Standup, :count).by(1)
  end

  it 'saves task records' do
    expect { subject }.to change(Task, :count).by(4)
  end

  context 'fails on bad to email' do
    let(:to_email) {"standups@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on no user' do
    let(:to_email) {"standups.9a859af8-30ca-4473-b073-47105352d936@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on useless body' do
    let(:body) { 'asdj;oisaduaskd' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on empty body' do
    let(:body) { '' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end
end

While long and containing six examples, this spec is actually pretty straightforward. It is first testing the happy path where everything is set up and working. Then checks each failing path that doesn’t create a standup, in order as those paths appear in the StandupsMailbox’s .process method.

How to inspect a Ruby Object

Sun, 31 May 2020 00:00:00 GMT

Imagine this, you adding a new object in your view, you reload the page, and you are greeted with Undefined method for nil:NilClass. “Ok, I’ll just print the object”, you think to yourself:

puts AwesomeObject.new
#<AwesomeObject:0x00007fd9a142a748>

Well, that didn’t help. Let’s go over the ways to print and inspect Ruby objects.

Printing an Object

First, what happens when you print an object?

When you puts an object instance it will call .to_s method on that object. In the cases of built-in Object types in Ruby, this is handled for you. Such as when you puts a number:

puts 7
7
=> nil

When you do that on an object, like above, the default behavior of to_s on an object is to print the Object’s class name (this part AwesomeObject) and the object_id (this part 0x00007fd9a142a748>).

We can update the class to include a to_s to control the output of an object’s instance in a puts statement:

class AwesomeObject
  def to_s
    "This is some awesome output"
  end
end

Then, once you run puts on it, the output from the to_s method will be used:

puts AwesomeObject.new
This is some awesome output

Inspecting an Object

Another method defined on all objects and usually overridden by the specific uses-cases of the individual classes is the inspect method.

Let’s make out AwesomeObject a little more complicated:

class AwesomeObject

  def initialize(name, age)
    @name = name
    @age = age
  end

  attr_reader :name, :age

  def to_s
    "This is some awesome output: #{name}, #{age}"
  end
end

To go back over the puts which uses to_s and is customized in the class above:

puts AwesomeObject.new("Rob", 42)
This is some awesome output: Rob, 42

Now, by default, the inspect method will print out the class name and object_id, much like the build in to_s method on the Object class. Then it will display the attributes/instance methods on the object. This it would display the name and age, like so:

AwesomeObject.new("Rob", 42).inspect
#<AwesomeObject:0x00007fd9a15720b0 @name="Rob", @age=42>

Just like the to_s method used in puts, you can also customize and override the inspect method in your own class. Imagine we used the following inspect method and called inspect on the object’s instance:

class AwesomeObject

  def initialize(name, age)
    @name = name
    @age = age
  end

  attr_reader :name, :age

  def inspect
    "This is some awesome output: #{name}, #{age}"
  end
end

Then, in your IRB or console, you can run .inspect on the instance:

AwesomeObject.new("Rob", 42).inspect
 => "This is some awesome output: Rob, 42"

There you have it! Two ways to get the data from an object and how you can override them! I implore you to use puts and .inspect on the objects you may use daily, such as ActiveRecord objects, instances from gems, or clients such as HTTP clients or API clients. You will usually be able to see relevant information to debug any issue you come across.

Integrating Bootstrap 4 into Rails 6

Wed, 27 May 2020 19:00:08 GMT

We’ve all been there, you start building a new Rails application and you realize there is no style on any of your generic Rails pages. So you know in the back of your head you can grab Bootstrap and an Admin theme to get things moving. You may then find yourself asking, “What’s the best way to get Bootstrap into Rails?” and “How do I add the theme itself to the application?”. Let’s did into those questions and more in this post!

To install the a Bootstrap theme, we are going to be adding some packages, updating some configuration and adding a few additional gems/libraries to make life developing easier.

The first thing to do is to add another version manager! Since we are using Yarn/NPM/Node, it is a good idea to manage the version of Node a particular application or directory will be using. To do so, we will use NVM, and you can install NVM with the following line. If you are one to look at the github repo or the install scripts, you can here.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

That line grabs the install script from Github and runs it as Bash.

Now the current LTS (Long Term Stable) version of Node is version 12. LTS versions in the OSS (Open Source) communities is the version in which you can rely on long term stability. To install Node use the following command:

nvm install 12

This line installs the latest updated version of version 10. Meaning, as small updates and bugfixes are released to the version 10 pipeline, they bump the version numbers under 12 (i.e., 12.3.4 -> 12.3.5). Once installed, you can tell your terminal window/pane to use node 12 with the following command:

nvm use 12

When you created your new app, Rails should have made sure brew and yarn were added. Thus, you should now be able to install AdminLTE, Bootstrap, and a few other dependencies needed to get AdminLTE up and running in your application.

First, to install a version of AdminLTE that is compatible with Bootstrap 4, we will need to install through Yarn on a specific Github branch

yarn add admin-lte@3

This command is saying, install admin-lte and use the version 3. Next, we also install the packages for Bootstrap, jQuery and Popper.js to make sure they are available to the Rails application:

yarn add bootstrap jquery popper.js

That should take care of making sure all of the packages we need for the theme are there, but it seems as though Rails does not entirely install everything needed for Webpacker to get up and running. To remedy this issue, let’s run the Webpacker install.

rails webpacker:install

Alright, we are getting close to being done with setup! However, we should digress a bit in regards to Webpacker.

Webpacker

Webpacker is the Ruby (Rails mostly) wrapper gem around the Javascript tool, Webpack. Webpack is a tool that allows you to pre-process, bundle and use ES6 like syntax inside Javascript. Webpacker then takes all of those features and starts to merge the ES6 Javascript world with the Asset pipeline for CSS and other more static assets.

Webpacker introduces a concept of “packs” which are ES6 syntax Javascript files that you can then include in any template with a pack_tag helper. Think of packs as entry points of javascript files into specific spots in a Rails app.

The most basic pattern is the /app/javascript/application.js pack file, which is then included in the applications’ layout file by default.

As your application grows, using packs to specify specific libraries and functionality within specific templates or sections of your application helps make sure your Javascript stays modular and compartmentalized.

Running A Webpack Dev Server

If you have used Heroku or other hosting vendors, you may see reference to Procfile. The simplest definition of a Procfile is that it allows you to specify a list of different process types and lets another system(Heroku, Foreman gem, etc.) handle startup and shutdown. Allow all of that to be dealt with one line and one terminal session/tab/pane.

When developing locally, the easiest step to take is to use the gem Foreman. To add this gem, add it to the development group in your Gemfile and bundle install:

...

group :development do
  gem 'foreman'

...

Once added, you can add your Procfile to the root of your app’s folder structure. Meaning the same level as your Gemfile.

web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}

You may notice that instead of rails s, you see bundle exec puma. This change is due to how you would want to run Puma directly in most environments.

If you were to start your environment with Foreman and this procfile, you would use the following on the command line:

foreman start

That command starts up a process for each line in your Procfile. Thus, in this case, a process for Puma, to run the Rails server. However, if you visit your instance of the app, first you may notice it is now at http://localhost:5000, and it is also not outputting development logs.

So, how can we make development use rails s to keep the fancy logs? We can create a secondary Procfile that is utilized just for development.

web: bin/rails s -p ${PORT:-3000}
webpacker: ./bin/webpack-dev-server

What is webpack-dev-server?

Very simply, it is a server that runs in the background that allows you to develop your Javascript, handles automatic reloads and makes sure packs are served to you your development Rails server.

To get this Procfile running instead, you simply just need to add a field to your command line syntax:

foreman start -f Procfile.dev

We’re getting closer! Now if you visit http://localhost:5000, you should see the output in the terminal from your request. However, we’re still on port 5000. This problem is easy to fix, just supply the command line with the environment variable used in the command to choose the port.

PORT=3000 foreman start -f Procfile.dev

Now, you can quickly start everything up and get it running in one terminal tab.

Final Webpacker Setup

Ok, we’re getting so close to getting everything up and running. We’re down to adding just a few additions to the Webpack javascript configuration.

config/webpack/environment.js

const { environment } = require("@rails/webpacker");

const webpack = require("webpack");

// Add an additional plugin of your choosing : ProvidePlugin
environment.plugins.prepend(
  "Provide",
  new webpack.ProvidePlugin({
    $: "jquery",
    jQuery: "jquery",
    jquery: "jquery",
    "window.Tether": "tether",
    Popper: ["popper.js", "default"] // for Bootstrap 4
  })
);

module.exports = environment;

One of the additions are the 8 lines of plugin code that is used to make sure jQuery, Popper.js and Tether are available throughout the bundled javascript.

The Application Pack

When adding Javascript to a Rails application, there are javascript libraries, setup or variables you want throughout the application. In the world of Rails 6 and Webpacker, these items go in the Application Pack, located at app/javascript/packs/application.js. The good news is that this file is created when you used the Rails command to create a new Rails app. Let’s go over the additions to get AdminLTE’s needs fulfilled.

// This file is automatically compiled by Webpack, along with any other files
// present in this directory. You're encouraged to place your actual application logic in
// a relevant structure within app/javascript and only use these pack files to reference
// that code so it'll be compiled.

require("@rails/ujs").start();
require("turbolinks").start();
require("@rails/activestorage").start();
require("channels");

var jQuery = require("jquery");

// import jQuery from "jquery";
global.$ = global.jQuery = jQuery;
window.$ = window.jQuery = jQuery;

require("bootstrap");
require("admin-lte");

// Uncomment to copy all static images under ../images to the output folder and reference
// them with the image_pack_tag helper in views (e.g <%= image_pack_tag 'rails.png' %>)
// or the `imagePath` JavaScript helper below.
//
// const images = require.context('../images', true)
// const imagePath = (name) => images(name, true)

The commented code and the first four lines of requires are added by default. These are libraries or packages that Rails needs for most applications. The new lines are adding jQuery and variables that other packages or libraries may expect to exist. Lastly, bootstrap and admin-lte are required to make available to the entire Rails application.

Why require and not import

If you have done any recent javascript development, you may question why we are using require and not import. The answer here is rather simple. Based on the packages we are using and adding in, they expect other’s to have loaded first. Most specifically, admin-lte expects the global variable jQuery to exist when it loads. Using require guarantees code is executed in the order of the file, whereas import usually is pre-processed and executed out of order.

The Application Stylesheet

Lastly, we need to add some imports to the bottom of the automatically created Application Stylesheet. If you have done any Rails development in the last few years, you may have interacted with the Asset Pipeline, which is the way Rails handled the inclusion of javascript, stylesheets and any other static assets.

You’ll notice that the name of the file is different than what was generated by Rails. For import the extension scss needs to be used, signaling the Asset Pipeline to run the file as Sass, then CSS.

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 * Any CSS and SCSS file within this directory, lib/assets/stylesheets, or any plugin's
 * vendor/assets/stylesheets directory can be referenced here using a relative path.
 *
 * You're free to add application-wide styles to this file and they'll appear at the bottom of the
 * compiled file so the styles you add here take precedence over styles defined in any other CSS/SCSS
 * files in this directory. Styles in this file should be added after the last require_* statement.
 * It is generally better to create a new file per style scope.
 *
 *= require_tree .
 *= require_self
 */

@import url("https://fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700&lang=en");

@import "bootstrap";
@import "admin-lte/dist/css/adminlte";

In Sass CSS, you can include other stylesheets or fonts by using the @import syntax. In this stylesheet above, we are adding a font from Google Fonts that are referenced in AdminLTE’s stylesheets. Next, we include stylesheets for Bootstrap and AdminLTE.

In the following section, we are going to add some Controllers and Templates to added the necessary markup to structure the application.

Before we begin implementing the layout, we need to apply a route and controller to bypass the default welcome page. We also will be using this controller in the application as we go along.

Let’s also pause to mention that Rails comes with built-in command line generators to generate controllers, models, mailers. As well as generating database migration file or even generating a scaffold of all of those combined. In our case, let’s focus on the controller generator. The general format for this generator is:

rails generate controller Activity mine feed

It created a controller with empty methods for the actions we included in the command line. It created template files, test files, and other auxiliary files.

Let’s make one quick edit to the route file to define a default route, adding “root to: ‘activity#mine’” to the bottom of the route file, as follows:

Rails.application.routes.draw do
  get 'activity/mine'
  get 'activity/feed'
  root to: 'activity#mine'
end

As we had set up the theme package, application javascript file and application stylesheet file earlier in the chapter, we can get into writing the markup needed to implement this theme rather quickly.

First, we can modify the main layout file to include the necessary elements and classes to wrap the content that will be provided by routed templates.

File: app/views/layouts/application.html.erb:

<!DOCTYPE html>
<html>
  <head>
    <title>Some App</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%=  javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <script src="https://kit.fontawesome.com/6d90f39943.js"></script>
    <-- Make your own FontAwesome Kit on their site -->
  </head>
  <body class="sidebar-mini">
    <div class="wrapper">
      <%= render partial: "layouts/header" %> <%= render partial:
      "layouts/sidebar" %>
      <div class="content-wrapper">
        <%= yield %>
      </div>
      <%= render partial: "layouts/footer" %>
    </div>
  </body>
</html>

The details of this file are not all pertinent to the addition of the Bootstrap theme, so we’ll only touch on those that matter. First, a class is added to the body element, “body class=“sidebar-mini”“. Next, “

” and “

” are added as wrapping elements to the first the page and then the inner content. You may notice there is some included Ruby code in there as well. Those render partial: calls allow us to add markup from other template files, in that position. In this case, it adds various larger parts of the application template such as the header, sidebar or footer. Plus, it keeps the layout to only the most necessary foundational elements to build the page structure. Then, “<%= yield %>” which is the Rails’ template method for adding the template from the controller and action called.

Since we are using partial templates, we go ahead and create the header file next.

One thing to note here is the use of the underscore in the template file’s name. In Rails, partial template files are designated with an underscore at the beginning of the file name. What are partials? Partials are simply a way to break down templates into smaller chunks. This approach comes into far greater play in situations such as looping over a collection of items. There, you would make the template chunk to display item information a partial. For example, the header template is titled _header.erb.

app/views/layout/_header.erb

<nav
  class="main-header navbar navbar-expand navbar-white navbar-light border-bottom"
>
  <!-- Left navbar links -->
  <ul class="navbar-nav">
    <li class="nav-item">
      <a class="nav-link" data-widget="pushmenu" href="#"
        ><i class="fas fa-bars"></i
      ></a>
    </li>
    <li class="nav-item d-none d-sm-inline-block">
      <a href="index3.html" class="nav-link">Home</a>
    </li>
    <li class="nav-item d-none d-sm-inline-block">
      <a href="#" class="nav-link">Contact</a>
    </li>
  </ul>
  <!-- SEARCH FORM -->
  <form class="form-inline ml-3">
    <div class="input-group input-group-sm">
      <input
        class="form-control form-control-navbar"
        type="search"
        placeholder="Search"
        aria-label="Search"
      />
      <div class="input-group-append">
        <button class="btn btn-navbar" type="submit">
          <i class="fas fa-search"></i>
        </button>
      </div>
    </div>
  </form>
  <!-- Right navbar links -->
  <ul class="navbar-nav ml-auto">
    <!-- Messages Dropdown Menu -->
    <li class="nav-item dropdown">
      <a class="nav-link" data-toggle="dropdown" href="#">
        <i class="far fa-comments"></i>
        <span class="badge badge-danger navbar-badge">3</span>
      </a>
      <div class="dropdown-menu dropdown-menu-lg dropdown-menu-right">
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 mr-3 img-circle"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                Brad Diesel
                <span class="float-right text-sm text-danger"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">Call me whenever you can...</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 img-circle mr-3"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                John Pierce
                <span class="float-right text-sm text-muted"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">I got your message bro</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <!-- Message Start -->
          <div class="media">
            <img
              src="http://placehold.it/128x128"
              alt="User Avatar"
              class="img-size-50 img-circle mr-3"
            />
            <div class="media-body">
              <h3 class="dropdown-item-title">
                Nora Silvester
                <span class="float-right text-sm text-warning"
                  ><i class="fas fa-star"></i
                ></span>
              </h3>
              <p class="text-sm">The subject goes here</p>
              <p class="text-sm text-muted">
                <i class="far fa-clock mr-1"></i> 4 Hours Ago
              </p>
            </div>
          </div>
          <!-- Message End -->
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item dropdown-footer">See All Messages</a>
      </div>
    </li>
    <!-- Notifications Dropdown Menu -->
    <li class="nav-item dropdown">
      <a class="nav-link" data-toggle="dropdown" href="#">
        <i class="far fa-bell"></i>
        <span class="badge badge-warning navbar-badge">15</span>
      </a>
      <div class="dropdown-menu dropdown-menu-lg dropdown-menu-right">
        <span class="dropdown-item dropdown-header">15 Notifications</span>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-envelope mr-2"></i> 4 new messages
          <span class="float-right text-muted text-sm">3 mins</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-users mr-2"></i> 8 friend requests
          <span class="float-right text-muted text-sm">12 hours</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item">
          <i class="fas fa-file mr-2"></i> 3 new reports
          <span class="float-right text-muted text-sm">2 days</span>
        </a>
        <div class="dropdown-divider"></div>
        <a href="#" class="dropdown-item dropdown-footer"
          >See All Notifications</a
        >
      </div>
    </li>
    <li class="nav-item">
      <a
        class="nav-link"
        data-widget="control-sidebar"
        data-slide="true"
        href="#"
        ><i class="fas fa-th-large"></i
      ></a>
    </li>
  </ul>
</nav>

This template contains the structure to have the app title/logo, dropdowns and any additional links you may need for navigation. To get the app template structure setup, we can leave in some of the demo data and elements to show how the dropdowns would look and work.

The next partial to create is the _sidebar template:

app/views/layouts/_sidebar.erb

<aside class="main-sidebar sidebar-dark-primary elevation-4">
    <!-- Brand Logo -->
  <a href="index3.html" class="brand-link">
    <span class="brand-text font-weight-light">Standup App</span>
  </a>
<!-- Sidebar -->
  <div class="slimScrollDiv" style="position: relative; overflow: hidden; width: auto; height: 652px;"><div class="sidebar" style="min-height: 652px; overflow: hidden; width: auto; height: 652px;">
    <!-- Sidebar user panel (optional) -->
    <div class="user-panel mt-3 pb-3 mb-3 d-flex">
      <div class="image">
        <img src="http://placehold.it/160x160" class="img-circle elevation-2" alt="User Image">
      </div>
      <div class="info">
        <a href="#" class="d-block">User Name</a>
      </div>
    </div>
<!-- Sidebar Menu -->
    <nav class="mt-2">
      <ul class="nav nav-pills nav-sidebar flex-column" data-widget="treeview" role="menu" data-accordion="false">
        <!-- Add icons to the links using the .nav-icon class
             with font-awesome or any other icon font library -->
        <li class="nav-item has-treeview menu-open">
          <a href="#" class="nav-link active">
            <i class="nav-icon fas fa-tachometer-alt"></i>
            <p>
              Activity
              <i class="right fas fa-angle-left"></i>
            </p>
          </a>
          <ul class="nav nav-treeview">
            <li class="nav-item">
              <a href="./index.html" class="nav-link active">
                <i class="far fa-circle nav-icon"></i>
                <p>Mine</p>
              </a>
            </li>
            <li class="nav-item">
              <a href="./index2.html" class="nav-link">
                <i class="far fa-circle nav-icon"></i>
                <p>Feed</p>
              </a>
            </li>
          </ul>
        </li>
      </ul>
    </nav>
    <!-- /.sidebar-menu -->
  </div>
  <!-- /.sidebar -->
</aside>

As you see, the sidebar partial is a bit smaller and more straightforward. It contains a little bit of user information and links to other parts of the application that we change later.

The last major piece of the layout is the footer. It is simple, and it is short. Again, it is another partial. Here is the ERB markup:

app/views/layouts/_foooter.erb

<footer class="main-footer">
  <strong>Copyright © 2019 Your Stuff.</strong>
  All rights reserved.
</footer>

Now, to have all of this show up on a page, you can edit the root controller action’s template to use the theme’s div classes

app/views/activity/mine.html.erb

<div class="content-header">
  <div class="container-fluid">
    <div class="row mb-2">
      <div class="col-sm-6">
        <h1 class="m-0 text-dark">Some Page</h1>
      </div>
    </div>
  </div>
</div>
<section class="content">
  <div class="container-fluid">
    <div class="row">
      <div class="col-lg-12">
        <div class="card">
          <div class="card-body">
            <span>Stuff</span>
          </div>
        </div>
      </div>
    </div>
  </div>
</section>

That’s about it to get set up with Bootstrap 4 and Rails 6.

19 Must-Have Gems for 2020

Tue, 19 May 2020 19:00:08 GMT

An application can only be as good as the features it is providing for its end-users. Every developer toes the line between indiscriminately adding gems and building new functionality themselves. When time is of the essence, these are the gems I reach for:

local_time - An relatively older gem and stable, but this is a gem that includes a view helper and javascript helper to display relative time (i.e. ‘updated 2 minutes ago’)
devise - Devise is still the go-to gem for authentication in most Rails apps. Its ease of use and existing features make it dead-simple to add authentication. For those looking for a simpler gem with a smaller footprint, Authlogic gets a runner up in this list for authentication.
Interactor - When you start to follow the Service Object pattern, adding Interactor can help guide your context and result of those objects through a common interface.
rolify and cancancan - Rolify allows us to assign roles such as User or Admin then CanCanCan will enable us to take those roles and apply authorization policies. However, there is a case for Pundit for those who like the Policy Object approach’s simplicity.
Lockbox - When you need to encrypt data in your database for compliance or even client security, Lockbox makes it very easy to do. Working with plenty of types out of the box, such as most database types, other Rails tools(ActiveStorage), and third-party gems(Shrine).
Sidekiq - This is the gem when it comes to running asynchronous tasks. Sidekiq is backed by Redis and has been long supported by the ActiveJob Rails abstractions.
Kaminari - A simple yet powerful approach to adding pagination into your Rails applications. In many places, it is as simple a few drop-in changes, but can be used to on anything from ActiveRecord collections to plain Arrays. It also has templates to be used in many of the most known CSS frameworks such as Bootstrap.
Bootstrap Email - Take the guesswork out of email design and CSS inlining inside of Rails Mailers. This gem allows you to use Bootstrap-like HTML structures, use a Bootstrap like design, and inline the CSS to work in most email browser/apps. Quite the timesaver!
money-rails - This will help standardize around common issues found when calculating money as well as providing a few template helpers.
Rack Mini Profiler - Everyone should know what their application is doing and where it is spending its time. This gem adds a profiler to the development pages and can include some nifty flame graphs when you really want to dig into the data.
rspec-rails, factory_bot_rails, simplecov - I personally like to use RSpec over the default Rails test framework. Though, the community can be quite divisive on testing tools! With every test suite, I include FactoryBot to easily spin up objects for those specs and SimpleCov to dig into my test coverage.
letter_opener - Still my #1 gem for working with email in a Rails app. In your local development, it catches the outgoing mail and opens in a browser, rendering it as it would an email.
Faraday or HTTParty - When I am looking to handle an extensive HTTP API or system, I will reach for the infinitely configurable Faraday. Still, when there are only a few HTTP interactions needed, HTTParty is super simple to use to make HTTP calls.

How to Build a Twitter Clone with Rails, ActionCable and React

Mon, 04 May 2020 00:00:00 GMT

Let me start by saying I think the things the teams working on CableReady and StimulusReflex are pretty awesome. They are aiming to make working with Reactive web applications as easy as the first Rails Blog tutorials during Rails’ infancy.

With all of that being said, I am someone who prefers a bit more explicitness and work with tools I already know (and well, a lot more developers in the ecosystem).

I am not a video guy, don’t have a video set up, and really prefer not to hear the sound of my own voice. So this will be done through words!

Without further ado, let’s get started with a new app:

rails new blabber --no-spring --webpack=react

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages needed for React.

We can jump right into making a model to hold the data to clone what would be a tweet in this Twitter clone. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex, we’ll add the same validation in the Post model:

class Post < ApplicationRecord
  validates :body, length: { minimum: 1, maximum: 280 }
end

We’ll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we’re ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

class PostsController < ApplicationController
  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    Post.create(post_params)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  def like
    Post.find_by(id: params[:post_id]).increment!(:likes_count)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment!(:repost_count)
    ActionCable.server.broadcast(
      'PostsChannel',
      Post.all.order(created_at: :desc)
    )
    redirect_to posts_path
  end

  private

  def post_params
    params.require(:post).permit(:body)
  end
end

Simple controller. The index action returns a list of posts, to @post. create uses StrongParameters, creates a new Post, broadcasts a message over Websockets (more on that soon), and redirects back to the index template. like and repost are similar except they increment the respective count columns.

Let’s wire up a few routes to match up to those controller actions. Yes, these aren’t perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) Are GET requests making sure we do not have to worry about AJAX/fetch/CSRF in the front-end. You would obviously work around these issues in a production application.

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We’ll start by adding the action_cable_meta_tag and Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quick!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
    <%= action_cable_meta_tag %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

First up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Actioncable and React demo</h4>

  <%= render partial: 'form' %>

  <%= react_component("PostsWrapper", { posts: @posts }) %>

</div>

react_component( is a view helper that is included in react-rails, a gem we will install in a minute. Even if you don’t use every feature in the gem, it offers a great way to include a component into an existing view file and the props for its first load.

Up next is a straightforward Rails form:

<%= form_with model: @post, local: true, html: {class: 'my-4' } do |f| %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

Alright, that is all we need with ERB files, no we can move onto the ActionCable pieces.

First, we’ll edit the Connection file to identify the Cable connection with the browser session ID:

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

    def connect
      self.session_id = request.session.id
    end
  end
end

Next, we’ll create a new Posts channel:

rails g channel PostsChannel

…and specify the channel we will be using in the stream by a string, PostsChannel:

class PostsChannel < ApplicationCable::Channel
  def subscribed
    stream_from 'PostsChannel'
  end
end

That does it for the Actioncable backend!

Next up us the React side of the application. As we installed React with the Rails application command, we can jump to making sure that react-rails gem in installed:

gem 'react-rails'
gem 'webpacker', '~> 4.0'

With the Gemfile update, we can install the gem, use its installer, and add a package to helper connect to ActionCable in functional React components.

bundle install
rails generate react:install
yarn add use-action-cable

Almost there! We have two React components to add. First up, is a wrapper component that will allow you to wrap your true child component in the ActionCableProvider, which provides access to ActionCable through a React Context:

import React from "react";
import Posts from "./Posts";
import { ActionCableProvider } from "use-action-cable";

export default function PostsWrapper(props) {
  return (
    <ActionCableProvider url="/cable">
      <Posts {...props} />
    </ActionCableProvider>
  );
}

Inside the provider, there it passes the props to a Posts component. The Post component:

import React, { useState } from "react";
import PropTypes from "prop-types";
import { useActionCable } from "use-action-cable";

const Posts = props => {
  const [posts, setPosts] = useState(props.posts);

  const channelHandlers = {
    received: data => {
      console.log(`[ActionCable] [Posts]`, data);
      setPosts(data);
    }
  };

  useActionCable({ channel: "PostsChannel" }, channelHandlers);

  return (
    <React.Fragment>
      {posts.map(post => {
        return (
          <div key={post.id} className="card mb-2">
            <div className="card-body">
              <h5 className="card-title text-muted">
                <small className="float-right">
                  Posted at {post.created_at}
                </small>
                {post.username}
              </h5>
              <div className="card-text lead mb-2">{post.body}</div>
              <a className="card0link" href={`/posts/${post.id}/repost`}>
                Repost ({post.repost_count})
              </a>
              <a className="card0link" href={`/posts/${post.id}/like`}>
                Likes ({post.likes_count})
              </a>
            </div>
          </div>
        );
      })}
    </React.Fragment>
  );
};

Posts.propTypes = {
  posts: PropTypes.array,
  header_display: PropTypes.string
};

export default Posts;

This might be the most complicated file in the whole tutorial! First, we set up some internal state for Posts. This allows us to set the incoming posts prop as the state, to update when ActionCable passes new posts from a broadcast. channelHandlers sets up the handler for this ActionCable subscription to handler new data. Finally, for ActionCable setup, useActionCable ties the handler and channel name into a new front-end subscription.

The return statement returns the JSX template for each post. It is mostly Bootstrap markup but does include two links to reach the earlier created controller actions. As GET requests, they will follow the redirect and reload the index template.

There you go, at this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

Installing Ruby through RVM

Wed, 29 Apr 2020 19:00:08 GMT

I recommend visiting the RMV website (https://rvm.io/). Upon the browser rendering the RVM website, you find two simple bash commands you can use to install RVM. I opted not to print the commands in here as 1) a digital security measure and 2) may change as time goes on.

Once installed, we can begin installing the latest version of Ruby.

rvm list known

This command lists the current versions of Ruby available to install. There may be a lot on the list, but we can focus on the primary interpreter MRI plus, the latest version(2.6.x as of writing). Now, the command to install:

rvm install 2.6.5

Now sit back or grab a coffee as the install can take anywhere from 1 to many minutes to complete. This wait is based on Ruby package availability, system speed, and plenty of other factors.

Once the gems are installed, you can now set up a gemset. A gemset is a way to group installed gems into a particular RVM based folder. Gemsets keep different projects and their various versions of gems from interfering with each other. Although with Bundler, this isn’t a huge issue, it doesn’t hurt to take the extra step and keep your gems tidy. Additionally, this command instructs RVM to use the recently installed version of Ruby at the same time:

rvm use 2.6.5@sample_app --create

The extra --create flag tells RVM to create the gemset if it doesn’t exist(which it doesn’t).

Now that we finally have our Ruby and Gemsets in order we can install Rails. We are starting a new sample project to show you the basics of a new Rails app. Later we rerun this command for the SaaS app’s creation. Please refer to the RVM documentation if you want to dig deeper into any other features of RVM past the basics in this chapter.

Setting up Rails and PostgreSQL

Wed, 29 Apr 2020 19:00:08 GMT

When building a production-ready application with Rails, the most popular database to use is PostgreSQL. However, Rails via ActiveRecord does support a few databases out of the box. These databases include PostgreSQL, MySQL, and SQLite3. Rails can support other databases through gems and their ORM.

Since it is most likely you are using both PostgreSQL and MacOS(OSX), I recommend just installing Postgres.app. Simply head to the postgres.app site. Then download and follow the simple instructions to have a PostgreSQL server and library installed on your box.

Another option you may use if you are skilled in the terminal is to install through Brew. Once you have Brew on your system, you can run brew install postgresql and follow the post install prompts.

`rails new` with pg

By default, Rails uses SQLite3 for development databases. This database type is used to ease install and development. However, since you are building an app that you intend to deploy, you are going to use PostgreSQL in all of your environments. When initializing a new Rails app, it is quite easy to change the default database type or other default settings.

rails new app_name -T --database=postgresql

After a minute or two, Rails will have installed all the required files for the base application. Rails then installed the base gems and ran a few other shell commands to get your application started.

Database Configuration

If everything in the install went correctly, you would be able to use a Rails command to create the database on your local PostgreSQL instance.

To be safe, take a look at the database configuration file and see what is in there. The database configuration file config/database.yml comes with information about installing the pg gem. Along with other option settings, you may change if you deviate at any point with your PostgreSQL setup. Here is the relevant development connection information:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: app_name_development

Here Rails is setting up a shared configuration between all environments setting the adapter type, encoding, and connection pool settings. None of this is relevant to the default usage of Rails, but you may need to change this at some point in your application’s lifetime.

The development block specifies to use the default settings and also use a database_name of app_name_development. The default naming for Rails databases is appname_environment. Meaning your test database name would be app_name_test and so on.

Now, let’s change our directory to that of the Rails app and create the database for Rails to use.

cd app_name
rails db:create

Rob Race | Writing

Programming Tutorials Are Dead

The revenue is already trying to tell us something

I do not want to build your sample app anymore

The agent already lives on the other side of the tutorial

Hello World is fine

This is not really about vibe coding

Beginners need the expert context even more

Developer education needs an execution layer

I backed into this while trying to make my own products less stale

Static implementation steps are becoming a commodity

The educator’s job gets better, not smaller

“But I still read tutorials”

The tutorial is being split into two things

Programming tutorials are dead

Your Webhook Endpoint Is a Tiny Distributed System

First, can you trust the request?

Receiving and processing are two different jobs

What does 2xx actually mean?

Duplicate delivery is normal

Idempotency does not remove concurrency

There are two retry systems

And then events arrive out of order

Every provider has its own little rules

A 200 is not observability

Ok, so we built a tiny distributed system

I Tested Rails Baseline by Leaving Architecture Out of the Prompt

Why test the starter this way?

Test one: build a feedback board

The useful miss

Test two: build an endpoint monitor

The second app found harder gaps

And, yes, the agent still wrote a bug

What I actually learned from the tests

I will probably keep doing this

Print Smarter in Ruby - Know When and How to Use Each Method

puts: Standard Output with Automatic Newlines

print: Continuous Output Without Newlines

p: Debugging with Inspect Output

pp: Pretty Print for Enhanced Readability

y: YAML Output in IRB

Quick Summary

awesome_print: Enhanced Pretty Printing with Style

Installation

Usage

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

What is an N+1 Query?

How to Detect N+1 Queries

1. Check Your Logs

2. Use the bullet Gem

How to Fix N+1 Queries

Use Eager Loading with .includes

When to Use .joins or .preload

Common Mistakes and Gotchas

Real-World Example

Preventing N+1s Going Forward

How to Build a Twitter Clone with Rails 8 Inertia and React

Adding Sign Up to the Rails 8 Authentication Generator

Prerequisites

Adding Sign Up

Route

Controller

View

Form Submission

Bonus Idea

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Setup

Turbo Morph

Presence Channel

Typing Indicators

Conclusion

Rails Console in the Browser (on-demand)

Why in the browser?

How to set it up

Taking it a step further

Alternate Idea

How to Build a Twitter Clone with Rails 8 and Turbo 8

How to get a User's Timezone into Rails

How to Build a Twitter Clone with Rails and Hotwire

How to Build a Twitter Clone with Rails and Hotwire

What does `2xx` actually mean?

A `200` is not observability

`puts`: Standard Output with Automatic Newlines

`print`: Continuous Output Without Newlines

`p`: Debugging with Inspect Output

`pp`: Pretty Print for Enhanced Readability

`y`: YAML Output in IRB

`awesome_print`: Enhanced Pretty Printing with Style

2. Use the `bullet` Gem

Use Eager Loading with `.includes`

When to Use `.joins` or `.preload`

What is `webpack-dev-server`?

Why `require` and not `import`

`rails new` with pg