Forem: Yechiel Kalmenson

Who's Going To RubyConf?

Yechiel Kalmenson — Fri, 05 Nov 2021 19:00:05 +0000

RubyConf is starting next week (November 8-0), both in person in Denver and remotely online.

This year it's especially exciting for me; it's my first in-person conference in exactly two years (the vaccine mandates and mask policy helped me feel safe with the decision to attend in person), AND I'll be giving a talk (which you should totally come watch if you'll be there)!

Who else is planning on attending?

Come say hi (either in person or in the discord)!

Talmudic Gems For Rails Developers

Yechiel Kalmenson — Thu, 20 May 2021 01:40:59 +0000

A few weeks ago, I gave a talk at RailsConf titled Talmudic Gems For Rails Developers.

In the talk I discussed lessons I learned from a lifetime of Talmudic study that helped me in my journey as a developer, and which I felt could benefit other developers in their growth.

The talk is geared at any developer looking to grow using the timeless wisdom of the Talmudic sages, not just Rails developers.

I shared a transcript of the talk in the Torah && Tech newsletter issue #123 (if you haven’t yet, you can sign up to the newsletter, and get the first year’s worth of newsletters in book format, at the Torah && Tech website: torahandtech.dev).

The talk has just been posted to YouTube, and I’m happy to share it with my audience!

If you would like to delve into some of the sources I mentioned, you can find links in the source sheet I prepared here.

Happy Learning!

Part 3: Add A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Sun, 07 Feb 2021 18:47:58 +0000

Bonus Round!

In part one and part two of this series, we created a working deadman's switch in our rails app.

This part isn't necessary, but it can be helpful.

The deadman's switch we wrote will trip if it isn't reset after seven days (or however long you set it for). That may seem like a safe interval, but it would be nice to have a reminder if you haven't reset it in a few days and the deadline is coming up.

I set my switch up to send me an SMS reminder if I didn't reset it in 4 days, and then every day after that until the switch is either rest or if it trips.

That's what we will do in part three of this tutorial.

Note: this part of the tutorial uses Twilio to send SMS messages. You will need to sign up for a Twilio account. If you use my referral link to sign up, you will get $10 of credit, which should be last a while for our use-case.

Getting Started

The first thing we need to do before getting started is to make sure we have a Twilio account. For our purposes, a "demo" account is enough. A demo account is free; it means you will have to register your phone number to receive texts, and you can't send SMS messages to other numbers, which is fine. Sending an SMS costs money ($0.0075 in the US); the $10 you get at sign-up by using my referral link should cover that for a long time.

After creating an account, follow the instructions to create a new project.

On the dashboard, you will need three pieces of information: The Account SID, Auth Token, and the account phone number.

Save these credentials in a safe place; we will need them for the next part.

Note: It's a bad idea to put API keys in your code as plaintext, especially if you put your code somewhere that's publicly accessible like GitHub. Someone can find them and use them to rack up quite the phone bill! Store them as environment variables instead. Heroku makes it easy to set environment variables.

Text me, maybe?

Now we have everything we need to set up our script to text us when it doesn't hear from us in a while.

First, put the following near the top of your rake task:

include ActionView::Helpers::DateHelper

This isn't strictly necessary, but it will let us use ActionView's time_ago_in_words method to format a nice human-readable message.

Next, let's set up a conditional to send the message only after the specified time that the app didn't hear from you. I set mine up to start bugging me after three days:

if 3.days.ago >= Deadman.last_reset

end

(though for testing purposes, you can make the interval as small as a few seconds so you can trigger the SMS to send and make sure everything is working. Just remember to change it back before pushing to production).

Now, inside the if block, the first thing to do is to construct a message that the script will send:

time_to_trigger = time_ago_in_words(Deadman.last_reset + 7.days)
message_body = "Your deadman switch will trigger in #{time_to_trigger}, please log in to your account and reset it."

You can, of course, edit this to fit your needs and taste.

Next, let's set up a Twilio client using the credentials we got from the Twilio dashboard:

twilio_client = Twilio::REST::Client.new(ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_ACCOUNT_TOKEN'])

Finally, you can use the client to send an SMS message to your phone:

twilio_client.messages.create(from: ENV['TWILIO_PHONE_NUMBER'], to: ENV['PHONE_NUMBER'], body: message_body)

The from: field is the Twilio phone number you got from your Twilio dashboard, and the to: field is your personal phone number (make sure to register it with your Twilio account if you're on the free "Demo" tier). The body: field is the message we constructed earlier.

The complete code should look something like this:

include ActionView::Helpers::DateHelper

if 3.days.ago >= Deadman.last_reset
    time_to_trigger = time_ago_in_words(Deadman.last_reset + 7.days)
    message_body = "Your deadman switch will trigger in #{time_to_trigger}, please log in to your account and reset it."
    twilio_client = Twilio::REST::Client.new(ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_ACCOUNT_TOKEN'])
    twilio_client.messages.create(from: ENV['TWILIO_PHONE_NUMBER'], to: ENV['PHONE_NUMBER'], body: message_body)
end

And that's it! That's all there is to it!

My Favorite Bash Tips, Tricks, and Shortcuts

Yechiel Kalmenson — Mon, 11 Jan 2021 22:23:39 +0000

If you're on DEV, chances are you spend at least some time in the terminal, maybe even a lot of time.

Over the years, I've picked up a number of tips and tricks from fellow developers. Almost every time I pair program with someone new, chances are I'll notice them doing something neat and ask them how they did it.

Here are some of my favorites.

I use bash as my default terminal, but most of these tips translate to other terminals as well.

Note: This post isn't meant to teach the basics of using the terminal. There are many great resources online (I remember doing Codecademy's Command Line course when I was starting out.

The `-` operator

Do you find yourself switching back and forth between two directories often?

You can use cd - to change to the last directory you were in like this:

~ $ cd directory1
~/directory1 $ cd directory2
~/directory2 $ cd -
~/directory1 $

This also works with git when switching between branches:

~/my-project(main)$ git checkout feature-branch
~/my-project(feature-branch)$ git checkout -
~/my-project(main)$

The `!!` operator

This happens a lot!

You type a command, only to get a "Permission denied" so you have to retype the command again, this time using sudo.

The !! operator echoes the last command you typed into your terminal.

You can use it like this:

$ some-dangerous-script.sh
=> Error: Permission Denied
$ sudo !!
=> Enter password for some-dangerous-script.sh:

{curly brace expansion}

If you ever need to run a series of very similar commands that differ by just a few characters (like for example, if you want to create a few filenames with lightly different extensions) you can use the characters that will be different between two curly braces and the command will run once for each one.

Like this:

$ touch file-{1,2,3}.md
$ ls
=> file-1.md file-2.md file-3.md

You can also pass in a range:

$ touch file-{1..3}.md
$ ls
=> file-1.md file-2.md file-3.md

Search using Ctrl+R

Are you like me? Would you press the up button 20 times to avoid typing out a 7 character command?

This next one was a lifesaver for me!

You can type Ctrl + R followed by the first few letters of the command you want to search through your bash history and bring up the command you need.

(Sorry, I can't think of how to demonstrate that with a code snippet. Just go to your terminal, type in Ctrl + R and start typing).

Aliases

Aliases are a great way to save time and keystrokes. If there's a command or a series of commands you find yourself typing often, it's making an alias can be very helpful.

In order to set aliases, first open the ~/.bashrc file in your favorite editor and check if it has the following lines in it:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

It should be there already, if it isn't just add it to the bottom of the file.

Next open ~/.bash_aliases in your editor (or create it if it doesn't exist) and add your aliases in the following format:

alias something="definition"

Some playful aliases I have in my .bash_aliases are:

alias please="sudo "
alias yeet="rm -rf

I also have a number of functions defined there, for more complex command series:

mk() {
    mkdir $1 && cd $1
}

gclone() {
    git clone "$1" && cd "$(basename "$1" .git)"
}

The mk alias takes a directory name as an argument, mks the directory and then cds into it.

The gclone alias takes a git repo, clones it, and then cds into it.

After adding aliases to your .bash_aliases they should load automatically every time you start a new terminal session.

If you would like to use your aliases in your current session, run:

source ~/.bash_aliases

That's what I can think of for now.

Do you have any favorite tips and tricks?

Please please do share them! I always love learning new ones!

What Are Your Goals For 2021?

Yechiel Kalmenson — Thu, 31 Dec 2020 15:17:28 +0000

It's that time of year when I usually look back at the goals I set for myself a year ago, see how well I did, and set new expectations for the next year.

This past year of course has been... a year. On December 31st 2019, I don't think any of us imagined where we'd be now, yet here we are.

Looking back at my goals from last year, one thing is clear. I did not necessarily accomplish everything I set out to do, but I also had quite a few accomplishments I would never have imagined in the beginning of the year!

Let's first take a look at what I was hoping for:

Yechiel Kalmenson • Dec 27 '19 • Edited

I'll start!

In tech goals, 2020 is the year of Kubernetes for me. I plan on getting more familiar with the eco-system, and maybe even start contributing to the project!

In career goals this is not an aggressive goal for me, but if I can find a job at a company that has all the pros of where I work now, but in addition to that is a remote-first company I'll be very happy :)

And in personal goals, I'm taking up Krav Maga and organizing a course at my synagogue for next year.

Of those three goals:

Kubernetes: turns out my career took a bit of a turn, I joined a new team where the focus was on a different direction, and I did not end up learning as much as I hoped (never mind getting involved in the community). I still hope to get more into that eco-system, but that's taken a place on a back burner for now.
Finding a remote job: in an ironic twist of fate, my current job is now remote (along with many others), and my company communicated that they will be more open to people working from home permanently, even as offices begin to open. So I'll count that as a goal I fulfilled 🙂
Krav Maga: I did start this one. I put together a group in my neighborhood and we met in my house a few times, but then covid put a halt to that so we'll see when that becomes practical again.

On the other hand, there have been a number of accomplishments this year that I would not have imagined a year ago!

My friend Ben Greenberg and I, published the Torah && Tech newsletter for two years now.

In June, we published the first year's worth of newsletters in the Torah && Tech book:

Announcing Torah && Tech; The Book.

Yechiel Kalmenson ・ May 19 '20

#showdev #books #learning #coding

In personal news, also in June, my family grew as we welcomed our son Meir to the family.

So yes, 2020 has been a year. Here's hoping that 2021 only improves.

What about you? What were your 2020 goals? How did you do on them? What are you hoping to accomplish in 2021?

Looking forward to hearing from you in the comments!

Part 2: Add A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Fri, 18 Dec 2020 04:57:34 +0000

Ah Yes, Where Were We?

In part 1 of this tutorial, we learned how to set up the part of the deadman's switch that allows us to reset the switch.

In part 2, we will get to the main part; how to set up a script that will run if something happens and the switch isn't reset in a given amount of time.

Rake It In

The standard way of running scripts in Rails apps (and Ruby environments generally) is using Rake tasks.

Rake tasks are, in their most basic form, Ruby scripts that you can run using the command rake [task-name].

In fact, chances are you've run quite a few already! If you've run commands like rails db:setup, rails db:migrate, these are rake tasks that come built-in with Rails for setting up your database!

We can write our own Rake tasks as well. They usually live in the lib/tasks/ directory of our Rails app, and the files use the .rake extension instead of the `.rb extension Ruby scripts usually use.

Let's start by creating a file lib/tasks/deadmans-switch.rake.

In the file, let's put the following:

`ruby
desc "Deadman's Switch"

task :deadman_switch do
puts "Our first task!"
end
`

At this point, we have a very basic Rake task. If you run rake -T in your terminal, you should get a list of all the Rake asks you have available, including this one:

shell rake deadmans_switch # Deadman's switch

On the left side, we have the name of our task, and on the right, the description that we gave it in the first line following the desc keyword.

If we run rake deadmans_switch in our terminal, we should see the following:

shell $ rake deadman_switch => Our first task!

Of course, at this point, our task does nothing more than print a line to let us know it's there, but we can replace that with any Ruby code we want, so let's do that!

Replace the contents of the task with:

ruby if 7.days.ago < Deadman.last_reset puts "Still alive!" else puts "Executing Deadman Switch!" # whatever you want to do goes here end

This script now uses the .last_reset method we put on our DeadmansSwitch class to check when you last reset the switch. If it was less than seven days ago, it just prints "Still alive!" and exits; if you didn't reset the switch in over a week, it'll execute whatever script you tell it to.

Note: I put a week in my script because I figured that was a reasonable timeframe for my needs. You can change that to 2 days, two weeks, a month, a year, whatever you feel the right timeframe for your needs. Ruby's Time class offers great methods for denoting a timeframe, which you can use similar to the 7.days.ago that I used.

Now if you run rake deadmans_switch in the console, you should get:

shell $ rake deadman_switch => Still Alive!

At this point, you can start working on the actual body of the script, which will be different depending on what it is you need a dead man's switch, so I'll leave you to it.

If you want to test and debug the script by running it and don't want to wait seven days for the switch to expire, you can change the 7.days.ago in your if statement to something more reasonable like 7.minutes.ago. Just don't forget to change it back when you're done.

Have You Been Triggered?

Now that we have a script and a way to ensure it only runs after a given time, there's one more thing we need to do. We probably don't want this script to run more than once.

For local scripts that run using a cron job, this isn't such an issue. You can probably use the script to reset the crontab. But this is a script running on Heroku where we don't have access to the scheduler from within the script, so we'll have to get creative.

One option I explored, which turned out to be a dead-end for reasons I'll explain soon, but I'll include it here anyway purely for its entertainment value, was to put the following on the last line fo my script:

ruby File.delete(__FILE__)

__FILE__ is a Ruby constant representing the current file, so what that line of code does is it deletes the current file once it reaches that line. Sort of like those spy movies where you get a note telling you to destroy it once you're finished reading it.

At first, I didn't think it would work. Spending the better part of last year developing for Windows servers and battling numerous "file in use" errors, I was sure Linux wouldn't let me do it either. But I did it just for kicks, and it turns out Linux is a lot more trusting! You can even try it yourself; create a test file, paste the above line of code, run it using Ruby, and watch it disappear!

While that's a pretty fun solution, unfortunately, it won't work for our purposes. Heroku, as mentioned in Part 1, uses an ephemeral file system, so even if we delete the file containing the script, the next time the app deploys, Heroku will do a fresh pull from GitHub, and our file will reappear.

If we want to keep track of whether our script ran, we will need to use something that persists, like a database entry. Fortunately, I'm a psychic who can see into the future, and if you remember, in Part 1, when we created our deamans_switches table, we added a triggered column, and we will now make use of it.

The first thing we will do is add two more methods to our DeadmansSwitch class in app/models/deadmans_switch.rb:

`ruby
def self.triggered
create(triggered: true)
end

def self.triggered?
    where(triggered: true).size > 0
end

The first one, .triggered, creates a new row in the database, but unlike a regular row, we set the triggered column to true.

The second method, .triggered?, queries the database and checks if there are any rows where triggered is set to true and returns true if there is at least one such row.

Now let's go back to our Rake task and put those to use.

The first thing we will do is add the following line at the end of the script after everything we wanted to run ran:

ruby Deadman.triggered

This will enter a row in the database with triggered: true.

Next, all the way at the beginning of our script, in the very first line, we will put the following:

ruby abort if Deadman.triggered?

This will check the database and see if there are any rows where triggered: true and abort the script if it finds any.

Getting Scheduled

At this point, we have a working deadman's switch. The only thing left is to deploy it along with our Rails app and set up a scheduler to run it.

My app is deployed on Heroku, so the instructions will be for getting set up on Heroku. If you have a different setup, things will work differently for you.

So once you've written up all the code, committed it, and pushed it off to Heroku, here is how to go about scheduling your script.

From the Heroku dashboard, navigate to the "Resources" tab.

Once in the "Resources" tab, find the button that says "Find more add-ons" and click on it.

Search for Heroku Scheduler and install it and provision it to your app.

Once it's installed properly, you should see it under add-ons in your resources tab. Click on the link to the Scheduler and then on the button that says "Add Job."

You will be prompted to set a schedule to run your task (I set it to run every night at midnight) and which command to run, which you should set to rake deadmans_switch.

Hit "Save Job," and that's it, you're all set!

Part 1: Adding A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Mon, 14 Dec 2020 02:05:09 +0000

Content Warning

The subject of this post is a bit morbid and deals with contemplating our mortality. If that upsets you, feel free to skip the introduction and go straight to the technical parts of the implementation in the section titled "The Good Stuff."

Introduction

I was recently thinking about the concept of a dead man's switch.

For those who are unfamiliar, a dead man's switch is a process that is designed to run automatically unless someone steps in to stop it. The idea is to increase the resiliency and/or safety of a system by having a safety mechanism that will stop it unless someone consciously steps in and overrides it.

One of my favorite examples is in trains where the breaks are engaged by default. To release the breaks, the conductor has to lift a handle or a pedal and keep holding it. The moment the conductor lets go of the pedal, the breaks will engage and stop the train. The idea behind the switch is that if something were to happen and the conductor was to pass out, the train won't continue barreling down the tracks; instead, it would come to a screeching halt immediately.


A ‘deadman’ pedal in a diesel-electric railway locomotive

Many other systems have similar concepts, even if they don't contain physical switches.

For example, a computer might contain a script designed to run automatically after a few days unless the timer gets reset.

For example, many of us have things we might want to happen in the event that something terrible happens to us. Maybe we want to pass on the passwords to important accounts or notify loved ones about a life insurance policy, or perhaps to wipe out some deep dark secret we want no one to find out about.

One way we could go about it is to set a cron job on our computer to run every day. The cron job could look at a file and see when it was last updated, and if it wasn't updated in, say, over a week, it'll run a script that sends an email or does whatever else it is we want it to do.

There's a limitation with that, and that is that it assumes your computer will be on, which is not a given for my personal computer.

The next best option is to have my switch hosted in the cloud somewhere, though that comes with some expenses, and access to reset the times is a little more complicated than updating a file on my computer.

The idea I came up with was to add the switch to my portfolio site. It's the only website I own, so I could do whatever I want with it. I'm already paying for hosting, so there's no extra expense for the switch, so it made sense for me.

The Good Stuff

This post assumes you already have a Rails app and that you have a rudimentary knowledge of Ruby and Rails.

My Rails app is hosted on Heroku. The tutorial's Rails portion should apply to any Rails app no matter where it's hosted, but some of the parts around running the sitch are Heroku specific. However, there are probably parallel mechanisms for other hosting options as well.

There's one part of the tutorial that requires a Twilio account with an associated project. It's not completely necessary, but if you want your switch to send out reminders as it gets closer to triggering, you might want to create a Twilio account.

Creating the account is free, and if you use my referral link, you'll get $10 SMS credit, which should be more than enough for our purposes.

Our dead man's switch will need a few components:

A way to reset the switch.
A script that will run every day and check if you reset the switch.
- If you did reset the switch recently, the script would abort.
- If you did not, the script would do whatever it is you want it to do.
- Once the script runs, we want a way to keep track of that, so it doesn't run again.

We'll start with the way to reset the switch.

If we were hosting this switch locally, a simple way to do this would be to look at the last time a given file was updated, and then keep updating that file every day.

Unfortunately, that wouldn't work for a script hosted on Heroku. Heroku uses an ephemeral filesystem for its apps, and every time the app gets redeployed, or if it crashes and has to be restarted, or even if it's taken down for routine maintenance, Heroku makes a fresh pull on the repo and any changes you made to the filesystem get overwritten.

We have to find a way to keep track of when the switch was reset, and a way that will persist.

I did it by creating a database table where I could enter rows containing a timestamp and then check the timestamp of the last row added.

Once I was already making a table, I figured I could add an ActiveRecord model to my app. That would give me some built-in ActiveRecord methods to interact with my table to read and update it.

Let's Start Generating!

So let's start by opening up our terminal and generating our migration:

rails generate model CreateDeadmansSwitch triggered:boolean

This command created a number of files. The ones we care about are db/migrate/[migration-id]_create_deadmans_switches.rb containing our database migration for a deadman_switches table that has the standard timestamps columns (as well as a boolean column called triggered) we will discuss later).

The second file we care about is in app/models/deadmans_switch.rb that creates our DeadmansSwitch class.

Let's open up db/migrate/20201211142929_create_deadmans_switches.rb:

class CreateDeadmansSwitches < ActiveRecord::Migration[5.2]
  def change
    create_table :deadmans_switches do |t|
      t.boolean :triggered

      t.timestamps
    end
  end
end

Before we run this migration, let's make one small change:

-    t.boolean :triggered
+    t.boolean :triggered, default: false

We added a default value of false to the triggered column, so that is the value it will contain unless we specify otherwise.

Now we can go back to our terminal and run:

rails db:migrate

That will run our migration and add the deadmans_switches table to our database schema.

Models Models Everywhere

Now that we have our database set up let's look at our model in app/models/deadmans_switch.rb.

Currently, our model is pretty empty:

class DeadmansSwitch < ApplicationRecord
end

Let's add two class methods to our class; one to reset the switch and one to check when it was last reset:

class DeadmansSwitch < ApplicationRecord

    def self.reset
        create
    end

    def self.last_reset
        last&.created_at || Time.now
    end

end

We added two class methods.

The reset method creates a new instance of the DeadmansSwitch class, adding a new row to the database.

The last_reset method looks at the last row in the database and, if it finds one, returns the date and time it was created on; otherwise, it returns the current time (this is to protect against an edge case where we run the app before we rest the switch for the first time).

Routing

Next, we need a route that will listen for, and trigger our switch.

My setup relies on two assumptions that apply to my app.

First, I have an AdminController that handles all the admin-related routing in my app.

Second, in my AdminController, I have a helper method called is_admin? that checks if the current user is an admin.

The details of your app may vary, so adjust accordingly.

In config/routs.rb add the following:

get 'deadman/reset', to: 'admin#reset'

This sets up a route at /deadman/reset and routes it to the reset function in my AdminController and gives us access to a deadman_reset_path function that points to the new route.

If you have your app running, don't forget to restart it in the terminal for any routing changes to take effect.

Next, let's add that function in AdminController (or whichever controller you decided to use for your app):


    def reset
        if is_admin?
            DeadmansSwitch.reset
            redirect_to admin_root_path
        else
            redirect_to login_path
        end
    end

This checks if the current user is an admin (you don't want just anyone who happens upon the URL to have the ability to reset your switch).

If the user is an admin, we call DeadmansSwitch.reset and redirect back to the page that called it; in my case, to the admin page (again, the routing in your app might be different, so adjust accordingly).

What A View!

Now that we have that in place let's use it in our app.

Where exactly you put this in your app depends on the layout of your app. Ideally, you would put it in a part of your app that only you can access, like an admin console or something.

This is what I have in my app, feel free to style it as elaborately, or plainly, as you wish:

<%= link_to "Reset Switch", deadman_reset_path %> <small>(Last reset <%= time_ago_in_words Deadman.last_reset %> ago)</small>

This creates a link to our reset route, followed by a small helpful note which uses the time_ago_in_words helper method to display when the last time you reset the switch.

Here is what it looks like on my portfolio:

So now we have part of our dead man's switch in place, the part where we can reset it every day, so it knows we're still around and doesn't trigger our script.

In part 2, we will speak about how to write the script that checks our switch and runs if we haven't reset it in a while.

What are your favorite Kotlin resources?

Yechiel Kalmenson — Mon, 26 Oct 2020 13:01:57 +0000

Hey all!

I recently joined a new team and we do most of our work with Kotlin.

It looks like a great language to work with, and I'm looking for resources to help me ramp up.
Something for someone familiar with programming concepts, and looking to ramp up on the Kotlin specifics, conventions, and best practices.

I'm a hands-on learner, and I learn best by trying thongs out and breaking them, so those are the resources I'm mostly looking for.

Something like Go's A Tour Of Go.

Any ideas?

Automating Google Form Submission In Ruby

Yechiel Kalmenson — Thu, 10 Sep 2020 18:22:58 +0000

Like many children around the country, my kids started school this week.

Due to COVID-19 regulations, my kids' preschool requires that we fill out a form every morning, certifying that our kids haven't developed any COVID symptoms and haven't been exposed to anyone COVID positive.

Being that I have two kids in preschool and my wife teaches there as well, that means filling out the form three times every morning. Something no programmer worth their salt would be willing to do without automating it!

My first instinct was to look if Google Forms had some sort of API for Forms that I could use to write a script, but it turns out that it wasn't even necessary!

Google forms are, at their base, HTML forms. So sending a POST request to the form's URL with the form's data is all you need to do.

The first step you need to do is determine the URL you need to POST to. One way to do it is to open your browser tools to the "Inspect" tab, find the form element, and find the action attribute.

For Google Forms, however, that isn't necessary! All you need is the URL of the form you are filling out.

Google Form URLs are of the format https://docs.google.com/forms/d/e/[a-long-form-ID]/viewform.

The URL you need to submit the form to is the same, except you need to change the /viewform at the end to /formResponse (Really, Google? You couldn't name them consistently? Either both lowercase or both camelCase?) so the final URL should look like this: https://docs.google.com/forms/d/e/[a-long-form-ID]/formResponse.

Next, you will need a list of the form's inputs and your responses.

Here Google obfuscates a bit.

Every HTML form is made up of inputs; each input has a name attribute, and when the form is submitted, those inputs get submitted in the format [input-name]=[value]. The name attribute is usually something descriptive, like "age", "date-of-birth", etc. but Google gives each input an ID and uses that as the name attribute, so it looks more like:

<input name="entry.[input-id]" value="">

You could go through the form and collect the input IDs one by one to figure out what each one stands for, but I took a short cut.

In the "Inspect" tab of your dev tools, find the form element for the form and edit the action attribute so it's set to a random string like this:

<form action="xxxxxx">

This way, the form won't submit to your school when you hit "Submit" in a moment.

Next, fill out the form the way you usually would with all of the correct answers.

Next, head over to the "Network" tab in your browser's dev tools. Once you're there, hit "Submit" on your form. You should see several requests show up in your browser tools. You're looking for the one that failed and got a 400 status (if you didn't edit the form's action in the previous step then it will not have failed, in which case you're looking for the one that was a POST request and says "formResponse" under "domain").

If you click on the request, you should see information about the request populate on the tab's right side. Click on the "Request" tab, and you should see a bunch of key/value pairs representing the form's inputs and the values you entered. Right-click and chose "Copy All" and paste it into a text file.

Here's what I got when I did that:

{
    "entry.1634501314":"child+name",
    "entry.1876184383":"parent+name",
    "entry.338135299":"Toddlers Class",
    "entry.464151171":"No",
    "entry.1301996500":"None+of+the+Above",
    "entry.46633140":"None+of+the+Above",
    "entry.693698665":"Yes",
    "entry.227426312":"No",
    "entry.1433839005":"No",
    "entry.338135299_sentinel":"",
    "entry.464151171_sentinel":"",
    "entry.1301996500_sentinel":"",
    "entry.46633140_sentinel":"",
    "entry.693698665_sentinel":"",
    "entry.227426312_sentinel":"",
    "entry.1433839005_sentinel":"",
    "fvv":"1",
    "draftResponse":"[null,null,\"1394368204515955404\"]\r\n",
    "pageHistory":"0",
    "fbzx":"1394368204515955404"
}

We can clean that up a bit by getting rid of all of the entries ending with _sentinel (they're an artifact of how Google Forms represent checkboxes and radio buttons) as well as the few fields at the bottom (I'm not sure what they do, but I confirmed that the form works without them).

We also want to convert this JSON object to a Ruby hash, which I did by find/replacing all of the ":"s with hash rockets "=>".

One last thing you'll want to do is replace all the "+" signs that were put instead of the whitespaces (e.g. "entry.1301996500":"None+of+the+Above") and change them back to spaces.

My final form data looks like this now:

    form_data = {
        "entry.338135299" => "Toddlers Class",
        "entry.1634501314" => "[child name]",
        "entry.1876184383" => "[parent name]",
        "entry.464151171" => "No",
        "entry.1301996500" => "None of the Above",
        "entry.46633140" => "None of the Above",
        "entry.693698665" => "Yes",
        "entry.227426312" => "No",
        "entry.1433839005" => "No"
    }

You can take that information and past it into a file called school-form-submitter.rb.

Note: If you would just like to see the finished code it will be shared at the end of this post.

If you only need to submit the form for one child, then that's all you need. If you have more than one child like me, you will have to add in the information you need dynamically.

In my case, the parts of the form that had to change for each child were the child's name and class ("Toddler Class" in the form above). So I extracted that information into a hash I called names:

names = {
    "Child 1 Name" => "Child 1 Class",
    "Child 2 Name" => "Child 2 Class",
    "Wife's Name" => "Staff"
}

Then I iterated over the hash and filled out the form like this:

names.each do |name, age|
    form_data = {
        "entry.338135299" => age,
        "entry.1634501314" => name,
        "entry.1876184383" => "Parent Name",
        "entry.464151171" => "No",
        "entry.1301996500" => "None of the Above",
        "entry.46633140" => "None of the Above",
        "entry.693698665" => "Yes",
        "entry.227426312" => "No",
        "entry.1433839005" => "No"
    }
    puts "Submitting form for #{name} in #{age}"
end

If you run the ruby file now, you should get a series of lines printed that look like:

Submitting form for Child 1 Name in Child 1 Class
Submitting form for Child 2 Name in Child 2 Class
Submitting form for Wife's Name in Staff

The only thing left to do now is to make our POST request.

Being that we are not trying to do anything too complicated with the returned data, I believe Ruby's built-in Net::HTTP library should be enough.

Add the following to the top of your file:

require 'net/http'

We're going to use Net::HTTP's post_form method. The method takes two arguments: a URI object and a hash of form inputs. So let's convert the URL we got earlier to a URI object like this:

form_url = URI("https://docs.google.com/forms/d/e/[a-long-form-ID]/formResponse")

We can then submit our form (and print the return status message as a sanity check) like this:

res = Net::HTTP.post_form form_url, form_data
puts "Status #{res.message}"

And there you have it! Instead of tediously filling out forms every morning, you can submit them by running ruby school-form-submitter.rb from your console, and all it took was around 25 lines of code!

Here is the complete code:

How Much Have You Made Off Of DEV Monetization?

Yechiel Kalmenson — Tue, 30 Jun 2020 15:25:04 +0000

It's now over 2 weeks since DEV announced that it added Web Monetization:

DEV is now Web Monetized

Peter Kim Frank for The DEV Team ・ Jun 10 '20

#webmonetization #gftwhackathon #coil #meta

I thought it would be fun for us to show off how much money we've all raked in!

Personally I decided to point my content at my Bitcoin ledger, so I can finally say I own Bitcoin!

As you can see, I'm currently the proud owner of about ฿0 (accurate to about 4 decimal places).

Clearly I have a ways to go before I can quit my day job.

How much have you made so far?

Announcing Torah && Tech; The Book.

Yechiel Kalmenson — Tue, 19 May 2020 19:01:30 +0000

About a year and a half ago, my friend Ben Greenberg and I were trying to come up with a project that would allow us to keep in touch as his family made Aliyah and moved halfway across the planet.

The result was Torah && Tech, a weekly newsletter that covers the two interests we both have in common: tech and Jewish laws and ethics.

The following 75 weeks (and counting!) have been loads of fun! We grew our readership from just the two of us (and our supportive spouses) to close to 200 weekly subscribers.

The newsletters covered topics ranging from office etiquette and mentorship to the future of AI and the use of pointers in Golang to coping strategies during COVID-19 imposed quarantine.

As we hit the one-year mark, the realization hit that this wasn’t just a side project that would last a month or two and that we were in this for the long-haul. The idea came up to collect the first year’s worth of Torah thoughts and publish them in a book.

The idea sounded intimidating at first, but thanks to some help from a few good friends, we are happy to announce, just in time for Shavuot, that the first volume of Torah && Tech is available for pre-order!

Unfortunately, due to coronavirus related delays, the print version won’t be available for another few weeks. Still, the e-book version is available for pre-order at most retailers and will be delivered to your favorite e-reader device on June 1st.

Just head over to torahandtech.dev and order your copy today.

Of course, while you’re there, you can use the opportunity to sign up for the newsletter so you can get a preview of volume two before anyone else. You will get a weekly Torah though in your inbox every week, just in time to share it at your Shabbat table.

If you have any comments or feedback about the book, please don’t hesitate to reach out to Ben or me on our social media. We LOVE talking about anything Torah/tech-related!

Need a hug? There's a bot for that!

Yechiel Kalmenson — Wed, 26 Feb 2020 19:22:27 +0000

Hey all!

I know I haven't posted in a while, but after a long break I finally had a free weekend and was able to work on a side project (my first one in over a year! Don't believe the gatekeepers, you can have a successful career without side projects!)

It all started a few weeks ago when I was feeling down and felt like I could really use a hug.

Not being close to anyone with whom I'm friends on a hugging basis, I did the next best thing and turned to Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1227616299548889090-44'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1227616299548889090&theme=dark" }

Sometime later, I was tweeting with a friend who was feeling down, and they mentioned that they could use a hug as well. I immediately sent them a (virtual) hug as well. And the idea came up for a bot that would help people feeling down by sending hugs at them!

I'm no stranger to Twitter bots, having written one some time ago:

Creating my first Twitter Bot

Yechiel Kalmenson ・ Dec 26 '17

#node #bots #beginners #twitter

This time I decided to write one in Python.

Python has a great library for interacting with Twitter called tweepy, and even a library around Giphy that makes things like getting a random gif of a hug pretty straightforward!

Between those two libraries, I didn't have to write much code on my own. The whole bot is about 35 lines of code!

I followed this dev.to post by @emcain for instructions on how to get my bot set up on Heroku:

How to Set up a Twitter Bot with Python and Heroku

Emily Cain ・ Jun 24 '18

#python #heroku #flask #twitter

And by the end of the weekend, @ICanHazHugzPlz was born!

Scope Reduction

Of course, no project comes out the way you expect it.

I had initially envisioned that the bot would reply to people asking it for hugs with a gif of a hug.

It turns out that to implement that, I would have to work out a queue that could keep track of which tweets the bot already replied to. That queue would need to maintain state between restarts; otherwise, the bot would keep spamming anyone who tweeted at it every time the script restarts (multiple times a day on Heroku's free dyno), as my bots earliest followers found out the hard way (sorry!!!)

I wasn't planning on spending more than a weekend on the project, so in the end, I settled on a bot that tweets a hug at the world every few hours.

Show Me The Code!

If you would like to take a look at the code for the bot, you'll find it here (including the failed implementation of the replying version of the bot on a separate branch):

achasveachas / hug-bot

A twitter bot that gives out free hugs.

Hug Bot

Hug Bot is a Bluesky bot (it was originally written as a Twitter bot) written in Python that posts a random hug gif every few hours.

You can follow @hugbot.bsky.social on Bluesky for all your huggy needs.

License

This bot is licensed under the MIT license.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/achasveachas/hug-bot/issues.

This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

Contact

Feel free to get in touch with me if you have any suggestions or comments at yechiel.me

View on GitHub

And of course, if you'd like to bless your Twitter timeline with wholesome hugs, please give my bot a follow at @ICanHazHugzPlz!

Until next time!

Forem: Yechiel Kalmenson

Who's Going To RubyConf?

Talmudic Gems For Rails Developers

Part 3: Add A Dead-Man's Switch To A Rails Application

Bonus Round!

Getting Started

Text me, maybe?

Further Reading

My Favorite Bash Tips, Tricks, and Shortcuts

The - operator

The !! operator

{curly brace expansion}

Search using Ctrl+R

Aliases

What Are Your Goals For 2021?

Announcing Torah && Tech; The Book.

Yechiel Kalmenson ・ May 19 '20

Part 2: Add A Dead-Man's Switch To A Rails Application

Ah Yes, Where Were We?

Rake It In

Have You Been Triggered?

Getting Scheduled

Part 1: Adding A Dead-Man's Switch To A Rails Application

Content Warning

Introduction

The Good Stuff

Let's Start Generating!

Models Models Everywhere

Routing

What A View!

What are your favorite Kotlin resources?

Automating Google Form Submission In Ruby

How Much Have You Made Off Of DEV Monetization?

DEV is now Web Monetized

Peter Kim Frank for The DEV Team ・ Jun 10 '20

Announcing Torah && Tech; The Book.

Need a hug? There's a bot for that!

Creating my first Twitter Bot

Yechiel Kalmenson ・ Dec 26 '17

How to Set up a Twitter Bot with Python and Heroku

Emily Cain ・ Jun 24 '18

Scope Reduction

Show Me The Code!

achasveachas / hug-bot

A twitter bot that gives out free hugs.

Hug Bot

License

Contributing

Contact

The `-` operator

The `!!` operator