Jeremy Dye fyi

AWS Elastic Beanstalk Slack Notifications

Sat, 08 Oct 2022 00:00:00 +0000

If you’re like me, you use Elastic Beanstalk because it provides a nice Heroku like experience for deploying apps while still having all the flexibility of being on AWS. If you’re even more like me, you like using Slack as a hub for software engineering operations. This is a quick guide to integrate the two.

The Journey

I google’d “elastic beanstalk slack notifications” and didn’t find anything super simple to just get these darn notifications into Slack. I found a paid app that’s $5/mo per user and said “Pshhh nah, that’s almost how much I pay for my actual Slack licenses”. I found some AWS articles that talk about the built in notification SNS topic Beanstalk comes with (which is awesome), but not how to pipe it into Slack. I setup AWS Chat Bot, only to figure out it doesn’t support Beanstalk. Eventually, I came across a Lambda for sending Slack messages via Webhook. That’ll do bot, that’ll do.

The Guide

This is what I ended up doing. It’s probably not the best approach, but it gets the job done.

Slack Webhook

Open up the Slack workspace you want to integrate with and go to Tools > Workflow Builder.
This’ll open up the Workflow Builder window. From there click the green “Create” button. Come up with a name and click “Next”.
Now you’ll be prompted how the workflow gets started, select “Webhook”.
On the next screen, click “Add variable”. Set the key to “message” and the data type should be text. Click “Done” to save the variable and then click the green “Next” button.
Now you’ll be presented with a visualization of the workflow. Click “Add step” and add the “Send a message” step. Select the channel you want to send to. Click “Insert a variable”, select “message”, and click the green “Save” button.
Next click the green “Publish” button in the top right. You’ll get some lovely confetti and your webhook URL. Copy that URL.

AWS Lambda

Open the AWS console, make sure you’re in the right region for your Beanstalk, and go to AWS Lambda.
Click the orange “Create function” button. Leave it on the “Author from scratch” option, give the function a name, and select the Python runtime. You can leave everything else alone and click “Create function”.
Once the function is created, click “Add trigger”. Then pick “SNS” as your source. Next pick the Beanstalk topic you want, they’ll all start with “ElasticBeanstalkNotifications”. Now click “Add”.
Click the “Code” tab and paste in the code below.
Finally, click “Deploy” and enjoy those sweet, sweet Slack notifications.

import urllib3
import json

http = urllib3.PoolManager()

def lambda_handler(event, context):
    url = "WEBHOOK URL GOES HERE"

    msg = {
        "message": event['Records'][0]['Sns']['Message'].split('\n')[1]
    }
    
    encoded_msg = json.dumps(msg).encode('utf-8')
    resp = http.request('POST',url, body=encoded_msg)

NOTE: I split the string because there’s a lot of boilerplate in the messages. If you want everything, you can remove that and pass in the whole message.

Adding a Custom Generator to Rails Scaffold

Sat, 18 Jun 2022 00:00:00 +0000

This took me wayyy too long to figure out, so I figured I’d share an end to end guide. Shoutout to this GitHub gist.

Background

If you’re like me, you hate typing boilerplate so you use rails g scaffold Thing. Oftentimes, we come up with design patterns that aren’t covered by the Rails default scaffold. To get around this, you can create custom generators.

Create a Generator

First, we’ll create our Something generator. Note that this is namespaced under the Rails module.

rails g generator rails/something

Now that you’ve generated it, fill out the resulting USAGE and something_generator.rb files like so.

Description:
    Generates something

Example:
    bin/rails generate something Thing

    This will create:
      app/something/thing.rb

class Rails::SomethingGenerator < Rails::Generators::NamedBase
  source_root File.expand_path("templates", __dir__)

  def create_something
    file_path = "app/something/#{file_name}.rb"
    create_file file_path, "# Oh hai there"
  end
end

If you want to be extra fancy, you can create a template and spec! But I don’t feel like it so here we go.

Initializer

Next we need to create an initializer to hook into the scaffold generator. I called mine config/initializers/custom_scaffold_generators.rb.

require "rails/railtie"
require "rails/generators"
require "rails/generators/rails/scaffold_controller/scaffold_controller_generator"

module SomethingGenerator
  module ScaffoldControllerGenerator
    extend ActiveSupport::Concern

    included do
      hook_for :something, in: nil, default: true, type: :boolean
    end
  end
end

module ActiveModel
  class Railtie < Rails::Railtie
    generators do |app|
      Rails::Generators.configure! app.config.generators
      Rails::Generators::ScaffoldControllerGenerator.include SomethingGenerator::ScaffoldControllerGenerator
    end
  end
end

Note that we set it so default: true, so it’s automatically included in the scaffold. Voila, you’ve got a working custom scaffold generator.

rails g scaffold Thing
      invoke  active_record
      create    db/migrate/20220618203059_create_things.rb
      create    app/models/thing.rb
      ... a bunch of stuff we don't care about in this post
      invoke    something
      create      app/something/thing.rb

Thoughts on Hiring

Tue, 31 May 2022 00:00:00 +0000

I recently started a startup. I have experience with hiring. I’ve refined job descriptions, designed technical interviews, discussed DEI tactics, interviewed hundreds of candidates, and done many other activities. One thing I had not done prior to my startup: implement an entire hiring process from scratch.

We started WaySync on March 28th and my #1 priority from the first day was hiring our founding team of engineers. By May 13th, we had signed 3 candidates. Here’s some thoughts after going through this experience.

Know what you’re looking for.

Invest time into writing a good job description. Clearly communicate what your company is trying to accomplish, the skills + qualities successful candidates should have, and what you offer candidates. Do it in a voice that is authentic to you instead of copying a generic, sterile template. The extra effort you spend here will pay dividends by aligning your team, delivering higher intent applicants, and providing a framework for the rest of your hiring process.

This last point is crucial. How can you effectively interview candidates without understanding what they need to accomplish and the skills necessary to do so? Use your job description as a blueprint for what your interviews should be evaluating. Design your interviews to produce clear signals on whether the candidates have the skills + qualities you decided on. Need someone who can deliver features with minimal guidance? Give them a vague use story and let them build. Do you need someone who can optimize your application’s performance? Give them an architecture + data and see what they come up with.

Always be selling.

I truly believe that interviewing is a two way street. Great candidates have a lot of options, so make sure you’re selling them on working with you. I highly recommend reflecting on what you have to offer and even including it explicitly in the job description. Do you offer top compensation, a noble mission, specific technologies, growth opportunities, etc? Tell candidates!

A great job description / outreach copy will get the conversation started, but you should also look at every other step in the process as opporunity to woo candidates. Do interviews with a friendly demeanor, give the candidate time to ask questions each session (make yourself available to answer additional questions), and pay attention to their questions to understand what their concerns are so you can directly address them. Above all else, treat candidates with kindness and respect. The goal is that even if they don’t receive an offer, they leave the process with a positive impression of the company.

Create an effective initial screening process.

One mistake I made was not having an effective screening call. 90% of candidates went on to additional (more costly) rounds. I don’t have any concrete advice here. I recently read the book Who. I really wish I had read it before I started hiring, I plan to utilize their top of funnel strategies next time.

Invest in your network.

I was fortunate enough to be able to recruit a former colleague. Working with someone day to day is pretty much the best signal you’re going to get when it comes to hiring. It can be really comforting to have a known quantity come in, especially with brand new teams. Make sure to consider how the role compares to the one you knew them in. For example, someone successful at a FAANG company won’t necessarily succeed at an early stage startup. Take a stroll through your LinkedIn connections and catch up with the talented folks you know, it’s worth it.

There are no shortcuts.

Put in the work. Reach out to a lot of candidates. Aggressively pursue new recruiting channels and strategies. You can do this.

Why I Decided to Start a Startup

Sat, 09 Apr 2022 00:00:00 +0000

Why I decided to start a startup.

Why I decided to found a firm.

Why I decided to commence a conglomerate.

Why I decided to create a corporation.

Why I decided to begin a business.

Why I decided to launch a venture.

Why I decided to do a startup.

Why I decided to produce an organization.

Why I decided to setup an outfit.

Why I decided to generate an enterprise.

Why I decided to undertake a establishment.

Why I decided to make a firm.

Why I decided to instigate a venture.

Why I decided to originate a organization.

Why I decided to bring about a business.

Why I decided to embark on a journey.

Sorry, “start a startup” is such a funny phrase to me. I can’t help but think of all the different ways to phrase it. Anyways, I recently did this. I wanted to write down my thought process.

What do I want?

Ownership

I want the opportunity to die by my own sword. I’ve worked at startups my whole career. I’ve even had the privilege of leading teams with a high degree of autonomy at some of them. When I reflect on my career, the most frustrating parts were when I disagreed with the company’s direction. I want the buck to stop with me this time.

Fun

I want my day to day to be fun. I love the energy of small teams where ideas are flowing, memes are flourishing, and people are able to play off one another like a jazz band. On top of that, I find myself energized by all the minutiae you’re presented with as a founder (what’s our culture, what health plans do we offer, should we get an office, etc).

Compensation

I want to be well compensated. At a glance, this seems at odds with starting a startup. This isn’t my first rodeo though. After a decade of working at startups, I know I have the skills to win. I think you probably shouldn’t start one unless you have deep conviction you’re capable of winning. It will carry you through the moments of doubt.

Other considerations

Timing

I’m 31. I’m not getting any younger. I might have children in the near future. My window of being able to pour everything I’ve got into something seems like it’s closing. I felt the right opportunity came my way and that I should take it.

Opportunity cost

I could go work at a large tech company and make a bunch of money, but I’d be lacking in the ownership and fun departments again. I figure if this doesn’t work out, they’ll still be around after.

Summary

To be honest, this was a decision I struggled with. I was coming off really weird time at Better (a story for another day perhaps). I had a lot of interesting opportunities available. I was stuck in analysis paralysis trying to decide what to do. I asked a friend for advice. They told me to think about what I might regret not doing. After that, everything became clear.

Rails 7 and React Install Guide

Sat, 15 Jan 2022 00:00:00 +0000

I love Rails! I also really like React for complex, interactive components. I’ve found it very product to use Turbo and Stimulus (from Hotwire) with sprinkles of React.

With Rails 7, esbuild is now the default javascript tooling. In the past, I’ve used react-rails but their documentation is still aimed at webpacker based Rails projects. Thankfully, a kind soul found a working setup with esbuild. I took their working example repo and made this step by step guide.

Dependencies

Add gem "react-rails" to your Gemfile.

Add the following to your package.json.

"esbuild-plugin-import-glob": "^0.1.1",
"react": "^17.0.2",
"react-dom": "^17.0.2",
"react_ujs": "^2.6.1",

Install these using your preferred command line tools.

esbuild

Add the following to your esbuild.config.js. Below the existing require statements at the top of the file:

const ImportGlobPlugin = require('esbuild-plugin-import-glob').default;

Next, add ImportGlobPlugin() to the plugins array in your config object. It should look like this after plugins: [rails(), ImportGlobPlugin()],.

Next, add loader: { '.js': 'jsx' }, to your config object.

Components

Create the directory app/javascript/components.

Create a app/javascript/components/index.js file with the following contents:

import components from "./**/*.jsx"

let componentsContext = {}
components.forEach((component) => {
  componentsContext[component.name.replace(".jsx", "").replace(/--/g, "/")] = component.module.default
})

const ReactRailsUJS = require("react_ujs")

ReactRailsUJS.getConstructor = (name) => {
  return componentsContext[name]
}
ReactRailsUJS.handleEvent('turbo:load', ReactRailsUJS.handleMount, false);
ReactRailsUJS.handleEvent('turbo:frame-load', ReactRailsUJS.handleMount, false);
ReactRailsUJS.handleEvent('turbo:before-render', ReactRailsUJS.handleUnmount, false);

Add import "./components" to application.js.

Create a component to render. Here’s a simple HelloWorld.jsx component you can use:

import React from 'react';

export default function HelloWorld() {
  return <h1>Hello World</h1>;
}

Voila, you can use your component.

react_component "HelloWorld"

Company Values

Fri, 14 Jan 2022 00:00:00 +0000

I’ve been thinking about starting a company. Lately, I’ve found myself often having conversations where I explain the values I’d like my company to have. I’m going to write them down here, both to save myself the repetitions and to refine them.

Work Smarter, Not Harder

We set audacious goals. We count on and encourage your ingenuity so that we can reach them. We don’t reward people based on hours worked, and we don’t police when, where, or how you work. We reward people based on accomplishing the goals.

Speak Up

We hire talented people because we truly believe that the right idea, at the right time can be transformational. We make space to hear out our colleagues so that we can capture that. We provide feedback early and often to one another because small frictions can build up and ruin relationships.

Progress Over Perfection

We value forward progress over meticulous planning because we believe a rapid, iterative cycle of shipping, gathering feedback + data, and refining is how great products are built. We know everything we do has tradeoffs, so we are aggressive about identifying and collecting the right data to make informed decisions quickly.

Do the Right Thing

We strive to do right by our colleagues, customers, and the world around us even if it means less optimal business outcomes. We are tired of companies that profit off of negative externalities and know we can do better.

“Finding” Your Way to Better Security in Multitenant Rails Applications

Wed, 29 Jul 2020 00:00:00 +0000

Let’s say you’ve created a SaaS application that lets customers keep track of their vendors. Things are going well and you’re adding many customers. One day, a curious customer starts messing around with the IDs in URLs and stumbles across a vendor they shouldn’t have access to. This is Very Bad™, especially if your customers are relying on your application to store sensitive information!

You have now entered the wide world of Authorizations. We’ll spend this blog post looking at one piece of the Authorization puzzle: using the Finder pattern to ensure users only see the things they’re allowed to.

The problem, illustrated

Let’s say you’re building the application we alluded to in the previous paragraph. One may begin with a naive implementation such as:

class VendorsController < ApplicationController
  def index
    @vendors = Vendor.all
  end

  def show
    @vendor = Vendor.find(params[:id])
  end
end

This may work fine and dandy at first, but as soon as you add your second customer you’re going to have a problem: every user has access to every vendor. Let’s say you foresee this problem. You create a User model that users authenticate with, add a user_id column to Vendors, and update your controller like so:

class VendorsController < ApplicationController
  def index
    @vendors = Vendor.where(user_id: current_user.id)
  end

  def show
    @vendor = Vendor.where(user_id: current_user.id).find(params[:id])
  end
end

Great! You also remembered to add scoping to your show route. A+, problem solved, ship it. All is well, for a time…

A month later you’ve moved on to other features in the application. A new engineer on the team is tasked with adding an Agreement model to keep track of the obligations between customers and each customer’s vendors. She implements the route for creating a new Agreement like so:

class AgreementsController < ApplicationController
  def new
    @agreement = Agreement.new
    @vendors = Vendor.all
  end
end

The team is busy, as startups are, and the change slips through to production. The support tickets start streaming in with customers asking about strange vendors showing up. No bueno. What’s an engineer to do?

Example usage

The Finder pattern is a simple concept: when you want to show something to a user, use a Finder. Finders implement a base scope upon initialization so that users only see what they’re allowed to. Subsequent methods chain off of that main scope, to ensure only a subset of the authorized scope is returned.

Let’s take a look at what a simple finder might look like for Vendors:

class VendorFinder
  attr_reader :scope

  def initialize(user_id)
    @scope = Vendor.where(user_id: user_id)
  end

  def by_id(id)
    @scope.find(id)
  end
end

And how it might be used in our controllers:

class VendorsController < ApplicationController
  def index
    @vendors = VendorFinder.new(current_user.id).scope
  end

  def show
    @vendor = VendorFinder.new(current_user.id).by_id(params[:id])
  end
end

class AgreementsController < ApplicationController
  def new
    @agreement = Agreement.new
    @vendors = VendorFinder.new(current_user.id).scope
  end
end

Finders are most frequently used in controllers, but they can - and should - be used everywhere you are scoping to an authorized subset of records. Part of the security benefit is that when it is used everywhere as a convention, engineers are less likely to customize their own scoping and make an error.

Conclusion

While this was a simple implementation, it illustrated a few key benefits. The Finder pattern:

Provides a safe, consistent pattern for you to show things to the user;
Requires the information it needs to provide that safety during initialization;
Centralizes the logic of who should see what; and,
Is easy to test.

Some might say that in lieu of the Finder pattern, authorization problems could be mitigated with better code review, documentation, or in our specific case, using a /users/:id/vendors route. But, without the Finder pattern, engineers will always need to be thinking through the complexities of each individual scenario: “What vendors can this customer see?” or “Is this User an admin that can see all Agreements?”, etc. With the Finder pattern, you can instead use the simple heuristic of “Will the user see this?” when writing or reviewing code.

The important concepts here are that applications grow complex, models can be accessed from a variety of contexts, expertise in a system is spread unevenly across a team, and humans just make mistakes sometimes. It’s up to us as engineers to put in guardrails and conventions to prevent these mistakes when we can, and the Finder pattern is yet another tool at our disposal.

This post was originally published on the Aptible blog.