---
title: "The importance of examples"
date: 2015-12-18T12:16:16+02:00
description: "First blog post!"
tags: ["musings"]
draft: false
---

Here's my first post on here. I wrote it before I ended up setting up my blog. I figured I had to start writing blog posts some point, and by writing my ideas on things as I encountered them, I'd remember my ideas better.

## Inspiration:

I started writing this after looking at <a href="https://developer.github.com/v3/repos/contents/">some GitHub API docs</a>, and not understanding how to read files from a private repo. I ended up looking around, realizing the answer after looking at a <a href="https://gist.github.com/Integralist/9482061">GitHub gist</a>, and thought I was an idiot for not realizing it sooner. But I realized that even if I was being an idiot, I had read the page and the OAuth page, and knew they needed to fit together somehow: all I needed was an example.

## Do we really *need* examples?

When writing documentation for our own programs, we're biased. Very biased. Not only do we know how to write code or use our software efficiently, but we also know exactly how it works the way it does and the processes it takes.

We sometimes even assume that our software is meant to be used in a specific way and will never be used in inefficient/impractical method X. Why? Because X is insecure, or X would never happen if documentation was followed, or there are more efficient tools than the one we've made, that are actually built for doing X.

### But that's not always the case.

Sometimes, or more often, almost always, the user won't be reading all of the documentation. Maybe barely any of it. Or maybe the docs you wrote were bad, or incomplete, or assumed the user knew things they didn't.

That's what examples are for

Examples at their most basic level are beginner friendly. For beginners, writing a program, and walking through it, explaining as you go, is more important and valuable than providing each function call along with a detailed desicription of what it does.

We all learn by being given examples. Like babies learn from hearing adults talk, we learn how to use a language, library, or framework, from seing well-structured, thought-out examples and their given or implied use cases. And babies babble before they learn to talk, just like we understand small bits of code before we understand a program as a whole. But sentence structure, proper word usage, etc., take much longer.

It's clear that the solution is more frequent and more thorough examples. You don't need to give five examples for every new concept you introduce. But you could.

## As an example...
Since I'm writing about giving examples, it's only fair that I give an example on how to give examples. I started out learning JS, and no other resource was as consistently thorough and complete in its documentation as the Mozilla Developer Network.

Consider for example, the ternary operator. It's simple enough, if you're used it multiple times. It's just an if/else statement with a different return value on true/false. It's dead simple, right? Not to all beginners. Ask a friend who's just started programming if they can understand it and use it properly just by you explaining it to them. Chances are, they won't.

If you look at the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator">MDN docs</a> on it though, it looks like 2/3 of the relevant words are examples alone. And half of the other words are explaining exactly what the examples are doing. This is great documentation, and it's not because of just the description of the functional requirements, because you probably included something along those lines when you explained it. It's the examples, the walkthrough of what the example does, the thoroughness of the examples, and the sheer number of them, which helps them cover so many use cases.


---
title: "An intro to hackathons"
date: 2015-12-31T12:16:16+02:00
description: "A (now slightly outdated) introductory guide to hackathons"
tags: ["guide", "hackathons"]
draft: false
---

This isn't just for people who haven't gone to hackathons before, but also for people who went to one and had an underwhelming experience. Hackathons are all different, so don't let one bad experience shy you away from them.

## What are they?
So you're going to a hackathon. You've signed up, and you don't know quite what it is, but you're interested, maybe because you've heard good things about them or they sounded like fun. They're all pretty similar in concept, but when I think of hackathons, I think of coroporate hackathons and collegiate hackathons.

### Corporate hackathons
Corporate hackathons are generally smaller than collegiate hackathons. Both in size, and in time spent working. That's not to say they're bad, some of the ones I've been to have been better than some of the collegiate hackathons that I've been to, despite their size. These hackathons will generally be 50 people or less, and all the ones I've been to have been less than 24 hours, and they've also had participants go home for the night and come back in the morning. They also usually have no problem with providing enough food and snacks.

They're also much different from collegiate events in that professionals are allowed to these events, so you'll most likely end up working with people from companies with local branches. If you're around the Dallas area, the AT&T Foundry usually hosts a few of these every year.
There are also larger corporate hackathons, which I can't say too much about, as I haven't been to more than a couple with much more than 50 people.

### Collegiate hackathons
Collegiate hackathons usually only allow current students to participate in them. If you're in high school, they might require you to be above 18 as well. They usually give out more swag (read: goodies, so be prepared to carry lots back), and are generally either 24 hours or 48 hours. If you want to sleep, you'll generally sleep on the floor. They usually have lots of sponsors, lots of prizes, and generally are much larger events overall.

Another difference is that while corporate hackathons usually have a theme (IoT, mobile apps, big data, etc.), collegiate hackathons usually don't. They're also almost always fully organized by college students, which is pretty impressive considering the huge amount of money that goes into them.

The rest of this post is about collegiate hackathons, but some of it can be applied to corporate hackathons as well.

## What to bring?

I'm a hardware hacker, so I usually bring my own hardware, which I've written about more <a href="http://cyrusroshan.com/blog/2016/01/02/a-hardware-hackers-kit.html">over here</a>. I'll also bring a day's worth of clothes, my phone, wallet, device chargers, plane tickets, headphones (nice for listening on long flights), deodorant, shampoo, and toothpaste/toothbrush, all in one duffel bag. I'll also bring a backpack with my hardware kit, laptop, and free space for free stuff. Feel free to bring resumes, as well, recruiters are there for a reason. It's also a good idea to bring a blanket, or clothes warm enough comfortably to sleep in. I usually go with jeans/sweatpants and a hoodie.
(Side note: bring and use those toiletries. After a couple days without them you're going to reek and that's no fun. Also, shoutout to hackathons with showers, y'all are the best)

## What to do?

### Before you go

So, from the start, book your plane tickets early, arrive early (get there early and you get good spots), and make sure you have all your stuff packed the night before. It also helps to have a team and idea of what you're going to work on before you get to the event. If you don't, that's fine too, there are almost always team-building events beforehand to help people who don't have teammates connect and form a team.

### When you get there
Talk to the recruiters, don't be afraid to ask questions or take the free stuff they're giving out, a lot of the goodies they give out will be gone quickly. If you're interested in a company, you can take time to talk to their recruiter, and give out a copy of your resume. For large hackathons I usually spend almost an hour at the beginning for just going through the booths, looking around, asking questions, and talking. Then, after the opening ceremony, it's time to start working on your idea. At most collegiate hackathons, hardware checkout will open after the opening ceremony. If you want a big-ticket item to borrow from the hardware checkout, it's best to get there early before it gets taken.

While working on your hack, be sure to grab snacks and take some short breaks. Hackathons are usually very well stocked as far as snacks go, and they'll often have events like smash tournaments, either set up by the hackathon organizers themselves or sponsoring companies. And while some people like to brag about how much sleep they didn't get, getting a few hours of sleep can definitely help refresh you and give you a new mindset when tackling coding errors. On that note, don't be afraid to ask for mentors if you're having trouble.

In the final few hours before presenting, you'll usually want to make sure that you upload your submission to whatever website the organizers are using, as well as make some finishing touches. You'll usually be presenting expo-style, where you have an assigned table and judges come and walk through and look at everyone's project like they would at a science fair. You'll also usually have to pack up all of your stuff before you go to your table, and after presenting, head to the closing ceremony.


## Where to find them?
That's all great, but where do you find out about hackathons? Look no further, <a href="http://www.hackalist.org/">hackalist</a> is my personal favorite for finding out about new hackathons I mean, you can sort by travel reimbursement, and it has them in order by month. This really only includes collegiate hackathons, though. If you want to find out about corporate hackathons, the best way I've found is by looking through EventBrite, asking around, or Googling.


---
title: "A hardware hacker's kit"
date: 2016-01-02T12:16:16+02:00
description: "What I carry in my bag on the flight to a hackathon"
tags: ["hardware", "hackathons"]
toc: true
draft: false
---

So you're a beginner to either hackathons or hardware hacking, and you're not sure what to bring? Well, at HackDFW, we've got a pretty solid hardware setup, so you should have everything you need. At hackathons that aren't as focused on hardware though, here's an example list of what to bring. There's also a section on helping you figure out which board to use for a project, and some cool hardware projects to inspire you.

You won't need everything on this list; you'll probably use less than a third of it for a single project, and you'll probably have projects that might need something more than what I've listed. It's always good to be prepared, though, and you can't slap on another sensor in a hardware project as easily as you can download and require another library in a software project.

## What you'll want:

### Basics:

Here are some things that it'd be hard to really make a hardware project without:

- Dev Board (an Arduino, Raspberry Pi, Photon, NodeMCU, etc.)
- Cable (whichever your board needs)
- Breadboard
- Jumper wires (optionally include alligator clips)
- Resistors

### Tools:

Some things that'll make working with hardware a lot easier:

- Needle nose pliers (with built in wire cutters)
- Screwdrivers
- Superglue
- Electric tape
- Multimeter (this might be too bulky, I don't always bring one)

### Input and Output:

You can't do much with just the list of above items. You'll need some of the following, depending on what you're working on, to get a solid project.

#### Small components:

These are smaller, more basic components, which aren't mounted on a board of their own.

- LEDs
- Photoresistors
- Reflective IR
- IR Transmitter/Reciever LEDs
- Transistors
- Capacitors
- Piezos
- Humidity sensor
- Temperature sensor
- Hall sensors
- Vibration Motors
- Tilt/vibration sensors
- DC Motors
- Push button switches
- Flex sensors (a bit more expensive, I'd only get one)
- Force sensitive resistors (same as above)

#### Larger Components:

- Servos
- Pulse sensor
- Ultrasonic range sensors
- Gyro/Accelerometer (usually have both on the same breakout board)
- LCD screen (preferably with I2C for less wires)
- Bluetooth module (you'll need one with BLE support for iPhones)

#### Additional Power:

For powering your board or components that require more voltage

- Relay module
- Breadboard psu
- 9v Batteries (not for your dev board, for powering a motor that needs more than it can handle. Use with transistor to switch on/off)
- Rechargeable power bank (for when you want to power your dev board without having it hooked to your laptop)

## Where to get them?

So now that you know what to get, where do you get it? If you're looking for reliability, use <a href="http://www.amazon.com/">Amazon</a>, <a href="https://www.adafruit.com/">Adafruit</a>, or my favorite of the three (because of their nice guides and docs), <a href="https://www.sparkfun.com/">Sparkfun</a>. If you're looking to save money (and it does cost a decent amount), check out <a href="http://www.aliexpress.com/">Aliexpress</a> for components, and your local dollar tree for superglue/electric tape/pliers/etc.

## Which board to use?

So, each board is useful for different things. For this, I'm just going to be comparing the three most popular: Arduino UNO, Raspberry Pi 2, and Particle Photon.

There are a few factors that I consider when picking a board:

- Setup time
- Usage
- Language

### Setup Time:

- A Raspi has a decent setup time. You need to be able to set it up to ssh into it, which means you'll need an OS on an SD card, the necessary cables, and a monitor/keyboard/mouse to be able to use it. If you've already set it up before, though, you can just bring it with an ethernet cable (you'll need an ethernet to thunderbolt adapter for macs though). If you're renting one out, though, that's not really an option.
- An Uno is generally plug and play, so setup time is nil
- Photons are pretty nice, _if_ you aren't in a saturated wireless airspace. The problem is, a lot of hackathons are. There's a solution to this, though, which is using serial setup. Particle uses the node-serial package though, so if that gets a bit funky (like it did with the El Capitan update on OS X), then you won't be having any fun.

Basically, for setup time, Uno > Photon > Raspi.

### Usage:

- A Raspi can do a lot of stuff, should be able to handle a lot, but it has some trouble with analog input. You can solve that with an analog to digital converter, or by having an arduino as a go-between. I'd use Raspi for anything where you want a small, local server, where you can directly interface with hardware. However, in a hackathon setup, an Uno or Photon can do almost everything, if not more, with the right libraries, so it generally comes down to preference.
- An Uno can do everything a Photon can do, but it lacks wireless connectivity. However, you can use a node package such as <a href="https://github.com/voodootikigod/node-serialport">node-serial</a> or <a href="https://github.com/rwaldron/johnny-five">johnny-five</a> (the latter also uses node-serial, but check it out as well) to interface with your computer while it's connected over USB, which opens up so many options (and also makes the Uno my go-to board). This does, however, make your setup a bit more complicated, if you're using it for the first time.
- A Photon can do everything an arduino can do, but with less ports, less libraries, and less guides. It makes up for that, though, with its incredibly easy setup _(when it works)_, and Particle's servers, which you can use as a limited backend. It also has a smaller form factor, if that matters in your application.

### Language:

- A Raspi is basically a full computer, soooo you can do pretty much anything. Most people perfer python on it, though.
- An Uno can be programmed with C/C++, however, if you use something like <a href="http://pyserial.sourceforge.net/">pySerial</a> or <a href="https://github.com/voodootikigod/node-serialport">node-serial</a>, you can write python or javascript programs to communicate with the arduino on your computer, and even just use it as a data-collector if you want (which, out of the three devices, it's the best at). There's also <a href="https://github.com/rwaldron/johnny-five">johnny-five</a>, if you want to use literally nothing but javascript (these options require the arduino to be tethered to the computer via USB for them to work).
- A Photon can be programmed with C/C++, however, you can just send and recieve the data to and from Particle's servers, have all of the benefits of node-serial/pyserial, except just using REST and any server, so it doesn't even need to be local.

## Some cool hardware projects!

If you're looking for inspiration, here are a few hardware projects to check out:

- <a href="https://dheera.net/projects/sesame">Sesame</a>, which lets you remotely unlock your door via a smartwatch voice command.
- <a href="https://www.reddit.com/r/arduino/comments/3ygf5s/i_made_a_mini_handheld_tetris_console/">A simple tetris game</a>, amazingly small, powered with a LiPo battery, and controlled with push buttons.
- <a href="http://devpost.com/software/brailleware">FifthSense</a>, a tool to for blind people to send and recieve data. Uses buttons for input, vibration motors for output.


---
title: "Making a 3d scanner for under $20"
date: 2016-04-05T12:16:16+02:00
description: "My hackathon project, a 3d scanner made out of cardboard"
tags: ["technical", "hardware", "hackathon", "walkthrough"]
latex: true
toc: true
draft: false
favorite: true
aliases:
  - /2016/04/05/Spin-to-Win-a-3d-scanner-for-under-20.html # hn submission
---

At this Spring's HackPrinceton, my friend <a href="http://yarabarla.com/">AK</a> and I built a fast and efficient 3d scanner out of spare parts. I think it's very cool.

<centered-content caption="The final product. The slower the motors run, the more accurate the scan.">

<iframe title="YouTube video player" width="480" height="300" src="https://www.youtube.com/embed/6dSABwcAYv8?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

Both the <a href="http://www.devpost.com/software/spin-to-win">project submission</a> and the <a href="https://github.com/CyrusRoshan/Spin-to-Win">source code</a> are online.

# How does it work?

For measurement, we used a reflective IR LED. More detail on this later, but basically I'm using it here as a close-range distance measurement tool.



In order to measure a 3d surface, two other components come into play, each adding a separate dimension to the scan. The first is a vertical shaft which raises and lowers the reflective IR LED. The second is a DC motor, which rotates the scanned object, allowing the scanner to measure its sides.



# Scan accuracy

You're probably wondering how accurate this project's scans actually were. It's literally a _ten-cent RIR LED on a stick_, held together by cardboard.

I wondered that too, as we were building it. I hadn't seen examples of reflective IR LEDs being used for measuring distance before. And even though it showed promising results when I tested it before starting, I couldn't be sure how accurate it was, given that the data was definitely not a linear function of distance.

<centered-content size="size3 mobileSize1" caption="Some example scans generated when plotting the raw data through Wolfram">
<centered-content caption="A scan of a paper cone">
<img src="https://i.imgur.com/j5cpdgI.png">
</centered-content>
<centered-content caption="The same paper cone, but a judge we were demoing to wanted to wave his hand between the cone and the scanner for a bit while it was running.">
<img src="https://i.imgur.com/V9x8UgY.png">
</centered-content>
<centered-content caption="A scan of a slightly deformed paper cylinder.">
<img src="https://i.imgur.com/RqP5HQi.png">
</centered-content>
</centered-content>

As it turns out, the scans were _pretty darn accurate_. In fact they were so clean, we had a judge doubt that the data was live. He waved his hand in between to see, and you can see the results above (middle picture, compared to the original on left).

# Is it really under $20?

Yup. I source most of my electronics from Aliexpress, so that helps. Here's the breakdown:

- Reflective IR LED - 10 cents
- DC motor - $3
- Breadboard - $3
- Continuous rotation servo - $7
- Arduino clone - $3 to $10
- USB A Male <-> USB B Male adapter - Free (usually included with the Arduino, even cheap ones)
- Plastic gears - $3 for a bag, probably $0.20 for parts used
- Cardboard - Free
- Electrical tape, wires, resistors - around $2 worth of parts

And this isn't even pricing at scale, or with efficient use of parts (e.g. using a PCB instead of breadboard + wires).

# Ideation process

Akhilesh and I flew into Philadelphia early, so we went to a Public Library to kill time before the hackathon started. He goes to the bathroom, and comes out wondering how hard it'd be to scan his poop. I look at my kit and see if we have the parts. And here we are.

# Prototype process

After some fairly basic tests, I decided that a Reflective IR LED was probably our best bet as a scanner. Our alternative was an ultrasonic rangefinder, and I didn't think it'd have enough granularity at low distances to work as a close-range 3d scanner.

Next, we needed to move the object or the scanner such that the entire object could be scanned. We focused on the vertical dimension first. I tried using a pulley-like system with a DC motor, and of course without a smooth pulley it'd occasionally slow or snag, and we couldn't get a consistent speed.

Looking for an alternative, I looked in my tackle box of hardware and found a rack to use in a rack and pinion gearing, and that actually worked perfectly, once we secured it into place. I attached the RIR LED, and also put a cylinder of electrical tape on it to try and make it pick up less noise, which actually worked pretty well.

<centered-content caption="Testing out the rack-and-pinion gearing for vertical scanner movement">

<iframe title="YouTube video player" height="300" src="https://www.youtube.com/embed/fmdrBJvw8gc?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

Then we tried making a flat base and attaching it to a dc motor. We first tried taping a few pieces of cardboard together and using the hole in a zip tie to attach it to the dc motor and hold it in place. It didn't work; it ended up too wobbly to actually get any decent measurements on, though.

<centered-content caption="Rotating the base was the easiest way to get an even scan, but attaching the base wasn't easy.">

<iframe title="YouTube video player" height="300" src="https://www.youtube.com/embed/kzbxL6kLE_0?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

We were lucky, though: the dc motor I used had basically the exact same diameter as one of the gears in the gear set, so we were able to tape cardboard circles to the gear in order to provide a larger base, and this gave us less wobble than our earlier design.

<centered-content caption="Fairly stable and ready to scan!">

<iframe title="YouTube video player" height="300" src="https://www.youtube.com/embed/jmB9qMBHB-o?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

Once we got this working, we also needed to hold the rack and pinion together using a bunch of zip ties, cardboard, and duct tape. The motor also broke apart a couple times, requiring the metal inside to be repositioned. And of course, we needed to calibrate everything, to get near-usable results!

# Calibration process

In this process, we figured out a function to convert the Reflective IR LED's raw analog output to units of distance. We also figured out the function to get vertical distance (vertical scanner movement) and degrees of rotation (horizontal base rotation) as a function of time.

Figuring out position of the z-axis was simple, we just measured the distance/time to get the speed of the motor when moving vertically, which given the initial value of 0 (measuring starting at the object's base), gives the z position as a function of time.

To find the angle of rotation, I measured the length of time it took for 10 rotations (to reduce error from starting/stopping time) and divided by 10.

To find the distance from the object to the scanner, we needed to fit the data given by the reflective IR LEDs. And for that we needed some data points to get a curve best fit. Using Chrome dev tools as a substitute for a ruler, I recorded the scanner's analog output values, while moving a piece of cardboard away, centimeter by centimeter.

With this data, we were able to estimate the function best fit using Wolfram alpha:

$$$ f(x) = -600 + \frac{19169 \times x}{30} + \frac{30433 x^2}{360} - \frac{1751 x^3}{16} + \frac{4009 x^4}{144} - \frac{727 x^5}{240} + \frac{89 x^6}{720} $$$

Glad we didn't have to calculate that by hand. Unfortunately Wolfram didn't give us the inverse, which we needed (in a scan, we have raw analog values and want estimated distance). So I just plugged in the range of input values, which is a limited range of ints (0-2048), and made a lookup table instead.

Combining these functions, we were able to determine y/z coordinates given distance and time. (Remember, our scanner rotates and moves up at the same time, so it's moving in a spiral shape.)

And with this, we could generate point clouds (seen above in earlier sections)! From this, you can estimate the shape of the object, and generate a STL file to send to your 3d printer, in order to print the object you just scanned!

# Want to build it yourself?

## Caveats

Want to build this on your own? It's very cool, and very cheap! But if you're planning on using it for anything serious, note a couple caveats:

You'll probably need 3d-printed parts for it to be calibrated well. (Though it's fun project to make by hand though, and the experience and results were pretty rewarding.) It's also not that great at scanning anything too glossy (shiny plastic/metal).

## Details you might find useful

All data is passed via USB from the Arduino to the laptop, where all of the processing is done in Node. It's much faster that way, and you can do whatever you want with it from there.

Data is sent from the Node instance to the Wolfram notebook through.... the wondrous OS X clipboard (last minute features, what can I say). It takes a long time for Wolfram Notebook to graph the data, but I think it's just slow frontend javascript, not optimized for large datasets. It might be faster on other software.

I don't have any good pictures of the circuit, but the only complicated part is wiring the Reflective IR LEDs, which you can do like this:

<centered-content caption="The circuit we used was something like this one">
<img src="/img/spin-to-win/tcrt.jpg" alt="Example TCRT5000 breadboard layout"/>
</centered-content>

Thankfully no signal amplifiers are needed (I didn't have any), and the wiring for the servos and dc motor are also pretty standard. Have fun!

---
title: "Building an electronic banjo out of paper plates"
date: 2016-11-15T12:16:16+02:00
description: "Guitar Hero IRL"
tags: ["technical", "hardware", "hackathon", "walkthrough"]
draft: false
favorite: true
toc: true
aliases:
  - /2016/11/15/hackprinceton-part-2-electric-boogaloo # hn submission
  - /post/electric-banjo # wrong rename
---

This weekend at HackPrinceton, my teammate <a href="http://bearcott.com">Benny Yan</a> and I made a <a href="https://devpost.com/software/electric-boogaloo-6vuwx0">prizewinning</a> electronic banjo. It's not an _electric_ (amplified) banjo. The difference is when you hold down frets and strum strings, the sounds it plays are mp3 files, not amplified string vibrations.

<centered-content size="size2 mobileSize1" caption="Final software and hardware, side by side">

<div><img src="/img/electric-boogaloo/frontendFinal.jpg"></div>
<div><img src="/img/electric-boogaloo/hardwareFinal.jpg"></div>
</centered-content>

In addition, there are LEDs under the fretboard that light up to show you where to place your fingers (in our demo, we showed chord positions, but I have a few other ideas for it that I think would be cool). We also had a nicely designed UI that you could use to show which strings and frets were being pressed down, as well as selecting chords to view and have displayed on the banjo's fretboard, and a list of songs to go through and show chords and lyrics for in realtime.

<centered-content size="size2 mobileSize1" caption="A very short demo that shows frets lighting up and being pressed">
<div><video controls><source src="/img/electric-boogaloo/finalDemo.mp4" type="video/mp4"> Your browser does not support the video tag </video></div>
<div><img src="/img/electric-boogaloo/1479053512277.jpg"></div>
</centered-content>

Before I get into it though, I'd like to thank the HackPrinceton organizing team, especially all of the hardware lab mentors. Those guys are some of the nicest people I've met, and I'd probably have either spent an extra 5+ hours debugging hardware or just not been able to finish without their help debugging two hardware bugs.

# What we used

- Frontend:
  - React
  - Babel
  - SASS
- Backend:
  - Go
  - gin-gonic/gin
  - tarm/serial
- Hardware:
  - Electronics:
    - Arduino Uno x2
    - White LED x12
    - 1k Resistors
  - Materials:
    - Wire (lots)
    - Paper clips (brass plated)
    - Paper plates
    - Cardboard
    - Springs
    - Foam

There's not a whole lot of complicated electronics here, and realistically you could probably use one arduino mega instead of two unos. Most of the time I spent on this was painstakingly soldering everything together, placing all of the layers down precisely, hardware debugging (encountered the weirdest hardware bug I've seen yet), and figuring how to orient everything properly (springs, clips, wires). The backend code itself was written pretty last minute, which looking back on it, could have gone pretty badly, but thankfully it ended up working out.

# How we made it

I worked on the hardware and backend, and had very little to do with the frontend, which Benny made, but here are the steps I took for the hardware:

First, it was important to have an idea for how the fretboard worked. There are a few ways to do a fretboard which immediately come to mind, but the way we finally implemented it was by far the best way to do it in my opinion. I have a lot of projects that I've done with reflective IR LEDs, so at first I thought of using those as a range finder since we could use those to find the range on small instruments (7cm from a uke or banjo head is a decent amount for demo purposes) or to use a system with force or light sensitive resistors under each fret, but these methods all have issues with emulating how a real string instrument would have its audio affected.

I ended up going with a system with much less complicated components. Simply using 4 strings with 5v out and different resistances on each string (not grounded), and having each metal fret piece connected to an analog input pin on the arduino means that you get lifelike and accurate strings. Based on which analog pin you're reading from, you can figure out the fret number, and based on what the voltage reading is, you can figure out which combination of strings is being pressed. It's also very accurate in how it works compared to a real string instrument because the way this reads string/fret combos is by the string being touched to the fret, which (aside from a few techniques), is how notes are normally played on string instruments.

<centered-content caption="The wiring for the neck--each string has a different resistance, and each fret measures voltage independently, allowing multiple string-fret combos to be read without conflict.">
<div><img src="/img/electric-boogaloo/fretWiring.jpg"></div>
</centered-content>

So after hashing out how I wanted the frets to work (since without the frets, there's not a whole lot you can do) I moved on to making the strings for detecting strumming. I first tried reading analog input on all of the strings and putting 5v through a wristband on my hand, but it's much easier to reverse that and put 5v through all of the strings and ground my hand, since my hand isn't very conductive. This is pretty similar to how a makey-makey works, actually. I used a 1k pulldown resistor and analog input, since I was going to need two arduinos for this project anyways, but you could change the resistor value and use digital pins instead.

<centered-content caption="The wiring for the strumming side. This one's a bit more simple, it just checks if I've touched a string.">
<div><img src="/img/electric-boogaloo/stringWiring.jpg"></div>
</centered-content>

The fretboard was made by first hollowing out the space for the LEDs on two layers of cardboard, inserting them, and placing a cut sheet of paper plate on top (Benny did this), then the LEDs had to be wired up, cut, soldered, covered with electrical tape, and the next layer (frets) had to be added, cut, soldered, wired, then the strings on top of those had to be added, cut and soldered and wired to the arduino as well. I'm not the quickest, so at one point I spent 4 hrs straight just cutting, taping, and soldering wires.

<centered-content caption="It took hours to solder LEDs, layer frets, and connect it all to the arduino without breaking any wiring.">
<div><img src="/img/electric-boogaloo/wiringLEDs.jpg"></div>
</centered-content>

During this time, I was also testing the wires to make sure I didn't miswire something before soldering. At one point I taped all of the thin LED wires (that took up less space on the fretboard) to the thicker ones that would go inside the arduino pins after twisting them together, and had to untape, solder, and tape again, since they would lose connections at some angles after being taped. So there were a few other things that took up some time.

# The code

I didn't write any of the frontend code, but basically how it works is the frontend continuously sends a GET request to the server to get which strings/frets to highlight on the webapp, and sends a POST request telling the server what LEDs to light up when it wants to light up the fretboard. This allows you to do things like select different chords and have them displayed on the banjo in realtime, as well as showing the tab for the chord on the screen. There was also a feature for playing songs and having the webapp show the user which chords and lyrics to use in realtime.

Benny's design and frontend code were nice and polished; the backend on the other hand, was incredibly rushed. The arduino files were written as I went and weren't too bad since I had to write them to test the code. The server itself however, was written pretty quickly, and I would reccomend restructuring large amounts of it if you're going to actually use it. It basically opens up one serial connection to the fretboard uke, one to the string uke, and starts reading in data and parsing it as JSON. The server's running at the same time in a goroutine and basically just serves up the last read data, formatted properly into JSON for GET requests, and for POST requests, simply writes the correct LED to light up to the fretboard arduino over serial.

The wonky part is the math used to calculate which frets are being played. It was getting pretty close to presentations, so I used some hackathon quality logic to go with my hackathon quality code, and didn't bother using math to calculate which string combination would create which analog value on the fretboard. I ended up just getting a few combinations of frets (e.g. 0, 1, 2, 3, 01, 12, 23, 012, 123, 0123), manually pressing those down, getting an approximate value, and giving it a short range around that, and just checking which range a fret read in, and seeing if it was in one of those ranges. As a consequence, since I forgot 03 as a combo, holding down the top and bottom strings on a single fret worked, but I don't think we even thought to test that, it was more like testing the first fret on the first string and the third fret on the fourth string, so it worked out all right.

# The results

We presented pretty well to the judges prior to the closing ceremony, and HackPrinceton actually had a private judging prior to the closing ceremony, so the results were decided before we went on stage, and we did well in that. For the closing ceremony though, we had 2 minutes to present, went on stage, immediately tangled wires with the hdmi, usb, etc., wires on stage, took about a minute to plug in the hdmi, and fumbled through that presentation so badly that if we were judged based off of that, we wouldn't be finalists. We ended up doing pretty well though, Benny won us the best design prize, I won us the best DIY prize, and together we got best overall. A great ending to HackPrinceton part 2: Electric Boogaloo.

# The weirdest bug ever

So while I was working on wiring the fretboard, I was also testing the wires to make sure I didn't have to undo the whole thing after I was done and realized I made an error. After I got to the stage where I put the LEDs on, connected them to a single ground, wired the positive ends up to individual thin wires into individual thin wires into the digital ports on the fretboard arduino, I moved on to the frets themselves. I placed a layer of electrical tape on the wire, and added the paper clips, which went on the front of the neck and wrapped around to the back, and actually looked pretty solid as frets. When reading input from the frets, however, it turned out that all three frets gave nearly the same reading... (nearly the same reading as opposed to exactly the same reading, I assume because of the built in delay on analogread).

<centered-content caption="Quickly testing all the LEDs after wiring them.">
<div>
<video width="100%" controls>
<source src="/img/electric-boogaloo/wiredFrets.mp4" type="video/mp4">
Your browser does not support the video tag.
</video>
</div>
</centered-content>

After ~~some~~ lots of hardware debugging, it turned out that the three frets were grounded together... through the wire that grounded the LEDs. That wouldn't be so crazy, except each fret had a layer of electrical tape covering it entirely from the LEDs and their wires. Adding two more layers of tape did the trick, so I can only assume that a combination of the tape being on the thinner side, being stretched, and firmly pressed (the paper clips held on pretty tightly to the neck) caused a leak.

# Future Ideas

Here are a few ideas that I had thought of while making this project. Keep in mind that these are untested, and I'm just a CS major who does hardware at hackathons, so these might not be 100% accurate in implementation. These were ideas I discarded because I knew we didn't have the materials/time, and they were plans for muting the strings and using springs for analog strums.

Muting strings is a pretty big thing in playing guitar, and probably also in banjo playing, and it's where you put your finger on top of a string and press gently but not hard enough to touch the string to the fret. As a result, you dampen the strings by causing almost all of the vibrations to travel through you. This would be checked for by checking the voltage that comes through the other side of the string. You could probably check for this by grounding yourself, and also reading in voltage from the end of the strings on the neck of the banjo. Then the strings you were touching would have different values than the ones that didn't. You'd also be grounded if you were touching the strings to push them down to the frets, but you'd know that they were pushed to the frets, and there wouldn't be any scenarios where they'd be pushed to a fret but not touched.

For using analog strums (e.g. to know how loud to play an mp3 based on the strength of the strumming), using something similar to how an electric guitar works would probably be the best method. Placing pickups under strings would allow you to see if the string was being pulled up or down, and how much, based on the motion of the magnetic field generated, and the resulting current that would go to the amp (or in this case the voltage-reading analog inputs on the arduino, since v = ir). You could alternatively attach springs to the very end of the strings, and use a hall sensor to determine the change in magnetic field caused by the spring's expansion and contraction. Again, these are untested, so they may not work exactly how I describe.


---
title: "Why I built the wrong blog publishing workflow"
toc: true
description: 'or, "Publishing static sites from mobile, via AWS Lambda"'
date: 2020-06-14
tags: ["technical", "software", "blog", "walkthrough", "product"]
favorite: false
---

I used to find writing for a public audience to be a taxing process. _I wasn't sure why_, but I thought it might be because my workflow was bad. To tackle that, I built a small project. I hoped it'd be an end to my writing troubles.

This post goes over how I built that project (it is kind of a cool project). But it also goes over **why it was the wrong solution.**

# Misdiagnosing the root issue

To decide what I "needed" to build, I started by comparing workflows: I looked at the way I wanted to write, and contrasted it to the way I _did_ write.

My previous workflow had me spend a lot of time in my text editor. Which I thought was bad for writing, because when I'd start writing, I'd try live previewing my blog, and only an hour later realize I was knee deep in minor CSS changes.

So I thought it was the _text editor_ that made it easy to get off-track. I wanted a simpler workflow. And I was actually so fed up with my previous workflow, I wanted to cut my laptop out entirely. **I wanted to write and publish posts just using my phone.**

<note type="thought">
What a mistaken conclusion. Looking back, _the text editor itself wasn't my problem_. I was just uncomfortable writing about something I was unsure of to a public audience. So changing how my blog looked was easy, but _writing carefully thought-out content and exposing it to public judgement_ was hard.

So, much like I'd procrastinate large projects in college, I wound up procrastinating writing by cleaning up my blog's styling.
</note>

# Over-engineering the technical solution

On my laptop, after I wrote a post in Markdown, I would:

- build my blog using Hugo
- `git push` changes to Github
- which then deployed the contents of the `docs` folder via Github Pages

I decided that to deploy from mobile, I would make a Lambda that did the same thing as my laptop. Meaning that after I wrote the post on my phone, I would:

- send it to the AWS Lambda
- which would then `git clone` my blog repo
- then insert the post, build the repo using Hugo, commit the changes
- and `git push` changes to Github
- which would then deploy the contents of the `docs` folder via Github Pages

This meant that the Lambda would need to run Hugo and Git. Naturally, instead of adding a small amount of vendor lock-in with [AWS Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) to manage binary dependencies, I opted for a [mostly-academic seeming library](https://github.com/grycap/scar) to run Docker in a Lambda. I'm ashamed of how long it took me to get all this working.

(Note: There's also AWS's [img2lambda](https://github.com/awslabs/aws-lambda-container-image-converter), to convert Docker images to Lambda layers, but it didn't work in this case)

<note type="thought">
An interesting thing I noticed in retrospect: When I build projects for work, I tend to start with the absolute minimum, look for existing solutions before building them on my own, and use well-tested dependencies. But for side projects, I do the opposite.

I don't think this is a bad behavior, actually, because it lets me try out more risky decisions in a safe environment. But it does mean that I shouldn't expect the same results.
</note>

# The architecture

So the architecture I built had three parts:

- A text editing app of my choice, to draft the post
  - This app was just for me to edit posts on. Any app would work, as long as it could export plain text. I chose [iA writer](https://apps.apple.com/app/id775737172?ign-mpt=uo%3D4) because it had nice markdown preview support.
- An AWS Lambda function, which published the post
  - The most important part of this project. [Source code](https://github.com/CyrusRoshan/blog-lambda) is here.
  - I wanted to use a serverless platform, because I felt the frequency of my posts didn't merit a full-time server.
- An iOS shortcut, which took the post from the app and sent it to the Lambda
  - I think iOS shortcuts are underrated, specifically for simple ETL tasks like this. [Source code](https://www.icloud.com/shortcuts/185164a491484e5db3dfa769510fe614) is here (only viewable on iOS).

# The Results

And this is what my new workflow looked like, from start to finish. I could write a post, export it to the shortcut, which would send it to the Lambda function, which would publish it.

<centered-content caption="The full publishing workflow, with the Lambda doing a cold start">

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/iWOOQtYB1rE?rel=0&modestbranding=1" frameborder="0" allow="autoplay; encrypted-media; picture-in-picture" allowfullscreen></iframe>
</centered-content>

But while it looked nice, it didn't address my problems. Months went by before I felt I could publish this very post. When I finally edited it, I realized why it took so long to publish. And so I changed this post from a longer technical overview, to a shorter commentary on where I went wrong.

I still have a mobile post pipeline, but it doesn't look like this. It's just [git app](https://workingcopyapp.com/) for iOS, and a [Github action](https://github.com/peaceiris/actions-hugo). I didn't write anything more complicated than a config file to use it.

But more importantly, I pushed myself to address the issues. I didn't like how my blog looked---so I made it look clean and scale well on mobile. I was worried about presenting my opinion---so I took time writing my opinions before subjecting them to judgement. I didn't have enough time to write---so I set aside a full day for a post, instead of a couple hours.

So that's a start. Now, I'll have to keep writing to turn these behaviors into habits.


---
title: "My home infrastructure setup with Ansible"
date: 2020-10-24
---

Having a home server has many benefits:
* Spotify-connected speakers 🔈
* wifi printing 🖨
* automated laptop backups over wifi 💿
* and more! 😱

And you might find this useful, when you have:

* unused speakers
* a wired, usb-only printer
* and a laptop that hasn't been backed up in a year

And I did. And I had an unused Raspberry Pi I could use as a home server. But I kept procrastinating on setting it up.

Because I knew that _not only_ did I have to do a lot of initial configuration, I'd have to **repeat the entire process** if my server's storage failed. And Paspberry Pis use SD cards, which have a reputation for higher failure rates.

Of course, there are software solutions to this. They're all some form of configuration and deployment, and I'd loosely categorize them into three areas:

* Push-based systems
    * [Ansible](https://docs.ansible.com/ansible/latest/index.html)
* Pull-based systems
    * [Chef](https://docs.chef.io/), [ansible-pull](https://docs.ansible.com/ansible/latest/cli/ansible-pull.html) [(example)](https://docs.ansible.com/ansible/latest/index.html)
* Docker-based, pull-based systems
    * [Balena](https://www.balena.io/), [Deviceplane](https://deviceplane.com/)

Each has their merits, and these are just a subset of the tools that exist.

For my home setup, I opted for Ansible. I did this because I:
<ol type="a">
  <li>don't want to host anything</li>
  <li>want a fairly simple solution</li>
  <li>can easily change Ansible to ansible-pull, if I want devices to pull updates from a git repo</li>
  <li>don't care about docker--I won't be using a variety of architectures or OSes (I just have a few Pis)</li>
  <li>can easily figure out the IP of all of my Pis and connect to them directly (a requirement, for Ansible)</li>
</ol>

This solved my problems, and even though though it took a bit of extra time to set things up with Ansible, it was maybe 2-3x the time it'd take me to run the plain bash commands. And setting up my second Raspberry Pi was much faster as a result.

My config sets up the following:
* SSH via your public key instead of password
* ZSH/ohmyzsh set up with Agnoster as the default theme when you SSH in
* Spotifyd set up (just plug in a speaker and you've got Wifi speakers)
* Hostnames match your pi's inventory name

And I've made it open source. [Here it is on Github](https://github.com/CyrusRoshan/personal-pi), feel free to fork it for your personal setup.

---
title: "Two cable SSH: the fastest Raspberry Pi setup"
description: "Just ethernet and USB"
date: 2020-10-25
---

Fiddling with monitors is annoying. This method lets you get an SSH connection to your Pi without having to connect it to a monitor, find an external keyboard, or manually type in your wifi password.

<centered-content caption="Simple and portable enough that you could do the entire process at a cafe">
   <img width="70%" src="/img/two-cable-ssh/setup.jpg">
</centered-content>

Taking out the manual process and sending everything over the wire makes it much easier to automate initial config, and I found it very useful when setting up [my home servers with Ansible](../home-infra-with-ansible).

## The two-cable SSH

Here's how to do it with a macOS host:

1. Start with a copy of Raspbian on your SD card. You can install the [Raspberry Pi imager](https://www.raspberrypi.org/documentation/installation/installing-images/), which makes it a painless process.
2. Re-insert the SD Card, then create an empty file named "ssh" into its boot partition. This should be the partition that auto-mounts, so you can simply `cd` into it, then `touch ssh`.
3. Insert the SD card into your Pi, and connect the ethernet and microUSB cables to your laptop.
4. Open System Preferences and go to the Sharing tab. [Enable internet sharing](https://apple.stackexchange.com/a/143519) through your ethernet port. If you're using an adapter, your ethernet port may be called by the adapter name, such as "USB 10/100 LAN".
5. Open System Preferences, and go to the Network tab. Enable DHCP or DHCP with manual address on your ethernet port. Wait for it to get connected.
6. In your terminal, run `ifconfig`, then find your bridge interface, `bridge100` in my case, and get its network address under `inet`.
7. Usually, you can just assume the Pi's IP address will be allocated to the next IP bridge interface's IP + 1. In my case, this is 192.168.2.1 + 1, so 192.168.2.2.
8. Or to be really sure, you can find the Pi's IP by scanning the range of IP addresses in your [subnet](https://en.wikipedia.org/wiki/Subnetwork).
   - In my case, my bridge interface address is 192.168.2.1 and mask is 0xffffff00, which is a /24 block.
   - So `sudo nmap -sS -p 22 192.168.2.1/24` will list out all devices under this block.
9. Simply SSH in! In my case, `ssh pi@192.168.2.2`, with default password `raspberry`.


---
title: "The harmful assumptions we make about tasks"
date: 2020-12-12
description: "What they cause and how to correct them"
draft: false
favorite: true
toc: true
aliases:
  - /ic-task-managment # hn submission
---

Most task managers make two assumptions. Do you make them too?

1. _A task manager needs to remember all of your tasks_ <br>(Would you buy a task manager that lost data?)
2. _All tasks can use a similar creation workflow_ <br>(You hit the 'create issue' button, and fill in some fields. Simple, obvious, how could it be better?)

It's not obvious that they're wrong---they actually seem _useful_. But both at work, and at home, making these assumptions will reduce your effectiveness.

And if you have trouble context-switching, procrastinate tasks, or have an ever-growing task backlog that looms over your head, these assumptions have likely caused you unnecessary pain.

Here's how they hurt us, and how to stop it from happening.

## Permanent tasks cause fatigue

Before starting Tandem, my manager Tim previously co-founded [Astrid](https://techcrunch.com/2013/05/01/yahoo-acquires-to-do-app-astrid/), a personal task manager, which he later sold to Yahoo.

At Astrid, Tim tried an interesting re-engagement email. Users who had been inactive for 6 weeks were asked: "want to delete all your tasks and start fresh?"

The hypothesis was that these inactive users had tasks that overwhelmed them. Either the amount, the complexity, or the low importance of backlogged tasks, caused users to put tasks off. So every time these users visited Astrid, they saw tasks they couldn't do, felt bad, and eventually stopped visiting---procrastination in action. Astrid's re-engagement email offered the users a chance to start fresh.

It was impressively compelling. Most re-engagement emails get a 1% response rate. This email had about 5%.

I imagine those users had the same feeling you get when you move from one browser to another, or from one task manager to another, and leave your bookmarks, open tabs, backlogged tasks, to start fresh in the name of increased productivity.

But simply deleting the backlog doesn't end the cycle.

---

Nowadays, Tim uses a simpler task manager---a notebook. He uses a page a day, adds some tasks from JIRA, and when tasks come in during the day, he writes them down and works on them when he's available. These are mostly small tasks, things that are easy to forget. If he gets a bug (important to track) or a task he can delegate, he puts it in JIRA.

The notebook isn't meant to store issues forever. The pages get turned, and previous information becomes less accessible. So the next day, if he needs to carry over something that hasn't been completed, he needs to make the conscious decision to do so.

This solution solves task-management fatigue. And incidentally, it solves another problem:

## Not all tasks are created the same

There is a gap in task management. When we look at the tools used for tracking tasks and goals, there's something for every level of the company:

<br>

| Level                 | Goal            | Tool                     |
| --------------------- | --------------- | ------------------------ |
| Company quarter-level | Quarterly Goals | Notion/Gdocs             |
| Org quarter-level     | KPIs            | Notion/Gdocs, JIRA Epics |
| Team sprint-level     | Tickets         | JIRA Tasks/Bugs          |
| Personal day-level    | ???             | ???                      |

Except at the personal day-level, where you're working on tickets, getting requests for feature updates from your PM, bug discoveries from QA, and breaking down your actual tickets into different tasks, which may require subtasks that weren't anticipated.

One proposal is that you should track all of these tasks, no matter how small, in JIRA. But the teams I see successful at implementing this are those that can afford to work at a slower, more "enterprise" pace. Which isn't a problem---at least for engineering---but it's often not an option at smaller startups, when learning cycles must be fast.

_Even if you work at a larger company, at a slower pace, you may relate when it comes to personal life: tasks come from a variety of directions, at all times. You can't toss every minor task in a task manager._

You can't fix every task before the next one comes in. If you only use JIRA, you choose between possibly forgetting these small tasks, or breaking your train of thought to search, categorize, and fill out a form every time you get a small task.

On the flip side, quickly writing these down in a temporary place means that **you don't need to**:

- Spend mental effort remembering minor tasks,
- or take significant time to file minor issues.
- Have your task manager filled with minor issues you've forgotten to close,
- or leave hastily-written issues for later, when you forget what the vaguely titled issue is for.

## Correcting for the mistakes

The solution is not complicated: use a temporary, personal task manager.

Don't go out and buy something new. You already have something you can use at home. Tim's notebook is a good example. I personally message myself on Slack (and iMessage, for personal use).

<collapse summary="An example of how I Slack myself">
<indent>

#### Using Slack for daily personal tasks

When I'm working, and get a non-urgent task that would otherwise interrupt me, it goes in my Slack DMs. This is what it looks like:

<centered-content>
<centered-content caption="Some days are quiet"><img src="/img/task-management-assumptions/IMG_7647.jpg"></centered-content>
<centered-content caption="And some are hectic"><img src="/img/task-management-assumptions/IMG_7644.jpg"></centered-content>
</centered-content>

In the morning, to re-build yesterday's context, I just look at yesterday's list. If there are unfinished items, I can carry them over. But it's a conscious decision. I don't need to carry over optional, low-priority tasks.

And if you've got a bad memory, there's a huge benefit for team stand-ups. I used to write JQL filters to search JIRA (doesn't work---and misses tasks), now I just take a look at Slack.

</indent>
</collapse>

The important requirements are just that your task manager:

1. Requires effort to carry over old tasks.
2. Makes writing down tasks quick.
3. Isn't used for notes _(anecdotally, this adds noise, and forces you to parse notes from tasks)_.

If a task is critical, long term, or requires cooperation, file it in your normal issue tracker. Otherwise, it's probably a daily, personal task, and you can file it in here.

So take out a notebook, open Slack, pick what works for you. And see if you don't feel calmer and more in control of your tasks.

<br>

<br>

---

<br>

## Relevant tools

I think these tools have interesting ideas to help individuals manage tasks.

### Amna

Ravi, my old college roommate and friend since high school, left Microsoft to build [Amna](https://www.getamna.com), a personal task manager with tight browser integration.

I resonate with the thesis: recently I switched away from Firefox Tree Style Tabs, because I noticed that by organizing my tabs (which were part of tasks), it inadvertently became a de-facto task manager. But it wasn't built for that!

Amna solves that exact problem: each task you do spawns a browser that keeps all of your relevant tabs.

<centered-content caption="All the tabs in this browser window are related to the same task, and Amna keeps their state when I close the browser."><img src="/img/task-management-assumptions/amna1.jpg"></centered-content>

<centered-content caption="After I'm done with a task, I can go back and look at the tabs I had open."><img src="/img/task-management-assumptions/amna2.jpg"></centered-content>

It helps prevent:

- Muscle-memory opening HN, clicking an interesting blog post, and leaving it open "to read later" for several weeks
- The pain of trawling through bookmarks and browser history, when you realize you forgot something
- The clutter of leaving tabs open to prevent forgetting something

If you've forgotten a time when you had less than five tabs open, [try using Amna](https://www.getamna.com/).

### Jam

Two of my ex-Cloudflare friends, Dani and Irtefa, started [Jam](https://jam.dev/). It's probably the fastest way for PMs/designers to directly make comments on a website. So you get less minor interruptions, and more clarity on the requested change.

<centered-content caption="All you do is type `jam` on the page, click an element, and type the comment"><img src="/img/task-management-assumptions/jam2.jpg"></centered-content>

But I don't include Jam here just for that. Jam also allows you to [offload the actual copy changes](https://words.jam.dev/introducing-jam-wand/) to your PM, which flat-out decreases your minor tasks. If this sounds exciting, get on the waitlist [here](https://jam.dev/).

---

_A big thank you to Calvin French-Owen, Zack Bloom, Tim Su, and Tejas Manohar for their thoughtful feedback on earlier drafts of this post._


---
title: "Bypassing hotspot limits on iOS"
date: 2021-01-25
description: "How to hotspot without a plan"
toc: true
draft: false
mermaid: true
---

My parents live in a fairly rural area of Texas. There's no cable internet, and fiber is out of the question--they're the target demographic for Starlink. When I was in high school, we used our phone landline for a very-flaky, too-expensive DSL. Nowadays we use hotspots.

So if there's no hotspot, there's no internet.

And when I flew in this winter to visit, my paid hotspot plan didn't activate on time. So there I was, sitting in quarantine, trying to use my laptop with no internet. But annoyingly, I already had _unlimited_ phone data.

I wondered: why can't I use my phone's LTE data to hotspot? As it turns out, it's not that you _can't_---it's just that _iOS doesn't want you to_.

Here's how I managed to get a DIY hotspot working on a regular, non-jailbroken iPhone.

<centered-content nowrap="">
<centered-content caption="Logs from sshd -d -d">
<img src="/img/phone-data-hotspot/ssh_debug.jpeg"></centered-content>
<centered-content caption="And the speed's not bad! <br>Note: Cloudflare Warp is the VPN app I use on iOS">
<img src="/img/phone-data-hotspot/warp_detailed_speed.png"></centered-content>
</centered-content>

## How does it work?

When you use a hotspot on iOS, your device treats your hotspot's network packets differently than the network data that apps use. Hotspot packets get routed differently, and they get metered. And if your hotspot plan isn't activated, your device won't even let you hotspot at all.

<centered-content caption="Connecting through my built-in iOS hotspot doesn't route traffic through my iOS VPN">
<img src="/img/phone-data-hotspot/verizon_hotspot.jpeg"></centered-content>

In order to prevent that, this custom hotspot tunnels your laptop's network packets through an app (in this case, [iSH](https://ish.app/)). This way, your laptop's traffic gets treated as if it's just an app making network connections.

Here's a quick technical overview of the process:

<style type="text/css">
@media screen and (max-width: 800px) {
	.mermaid svg {
		height: 300px !important;
	}
}
</style>

<centered-content caption="After setting this up once, subsequent runs take under a minute">
<mermaid>
sequenceDiagram
participant $P as iPhone 📱
participant $L as 💻 Laptop

    autonumber
    % Note over $L: Creates an ad-hoc WiFi network
    $L->>$L: Creates an ad-hoc WiFi network

    $P->>$L: Connects to Laptop's wifi network
    $L->>$P: iPhone assigned an IP address

    % Note over $P: Sets up SSH server
    $P->>$P: Sets up SSH server

    $L->>$P: Laptop SSHes into iPhone
    $P->>$L: SOCKS5 proxy established

    $L->>$L: Configures applications to use proxy

</mermaid>
</centered-content>

At this point, the custom hotspot is configured. Data from this hotspot is treated just like normal app data!

## Setting it up

Here's a loose idea of how I got this working. I estimate it'd take 15-30m.

1. **Download** [iSH](https://ish.app/), an interactive shell, to proxy connections through an iOS app
   - If you previously had an old version of iSH installed, you will need to [manually enable](https://github.com/ish-app/ish/) its built in `apk` for package management. New downloads have it enabled by default.
1. **Create** a new adhoc wifi network from your laptop, connect to it from your phone, and get your phone's IP
   - you can quickly verify that the connection works using something simple like `python3 -m http.server`
1. **Send** your SSH public key from laptop → phone
   <collapse summary="This was a bit harder without wifi. Here's the quick-and-dirty way I did it">**On my laptop**, I ran `cat publickey | base64 | pbcopy`, then pasted the result into `http://$PHONE_IP/$RESULT`. This hit the server on my phone (run using `python3 -m http.server`), which showed it in the URL path of the server logs on my phone.
   <br/>
   **Then on my phone**, taking that result from phone logs, I copy → pasted it into a shell command, `echo "[paste here]" | base64 -d > publickey`.</collapse>
1. **Install** `sshd` on iSH
   - Add your public key from the previous step to the `/.ssh/authorized_keys` file
   - Configure the ssh server settings. The changes I made were:
   ```
   Port 2222 # Custom port, 22 won't work
   ListenAddress 0.0.0.0 # Allow the laptop to connect via wifi
   PermitRootLogin prohibit-password # Allow root login
   PubkeyAuthentication yes # Allow public key auth
   AuthorizedKeysFile /.ssh/authorized_keys # Allow access from your public key
   PasswordAuthentication no # Disable passwords
   PermitEmptyPasswords no
   Compression no # CPU is a concern more than bandwidth, when we're doing this emulated + local network
   AllowTCPForwarding yes # Allow port forwarding
   GatewayPorts yes # Allow port forwarding
   UseDNS no # Not useful
   PermitTunnel yes # Allow our reverse tunnel
   ```
1. **Test** an SSH connection to the app from the laptop
   - You should be able to get your phone's IP from the settings page
   - SSH in from your laptop with `ssh root@$PHONE_IP -p 2222`

Now, on your laptop you should be able to run `ssh -N -D 1080 root@$PHONE_IP -p 2222` to create a SOCKS5 proxy server on port 1080! You can open your browser (Firefox, Chrome), configure this as a proxy, and use this to route traffic!

If you only need to use your browser, you're good! But you might also want to use other tools, and many of these tools don't respect system proxy settings. For that, we can use proxychains.

### Using Proxychains

[Proxychains](https://github.com/haad/proxychains) and [proxychains-ng](https://github.com/rofl0r/proxychains-ng) are tools that allow you to use a proxy with software that isn't configured for it.

Since I'm on macOS, and proxychains-ng has better support, I used it here. Here's the setup:

1. **Install** with `brew install proxychains-ng`
2. **Edit** the file `/usr/local/etc/proxychains.conf` to use `socks5 127.0.0.1 1080` as the proxy
3. **Run** the program you want to use with `proxychains4 program_name [arguments]`

## Limitations

Though this is a great backup internet solution, it's not as good as a normal carrier-enabled hotspot. Here's a little more depth on what its drawbacks are and why they occur.

### Desktop limitations

On an unrooted iPhone, you can't modify iptables or _truly_ run as root, so setting up a VPN server on the phone and connecting to it on your laptop doesn't work. You'll have to route the traffic through SSH or another protocol whose server can be run in iSH.

I spent a couple hours, but for whatever reason, I couldn't get [sshuttle](https://github.com/sshuttle/sshuttle) working. Proxychains works fine, but it means you need to manually launch every program you'd like proxied, and UDP traffic isn't supported, just TCP.

Note that you may be able to work around these limitations on Linux, where you have more control over the network stack than on macOS.

### App limitations

There are a couple of limitations to this method from the app side, as well. Though they're both bearable as-is.

#### 1. Backgrounding

When your phone locks, or you switch apps, iSH will get backgrounded, and your connection to the server will be lost.

To allow iSH to run into the background, you can run `cat/dev/location > dev/null &`, which polls your location, though it's still a bit flaky. You could also disable auto-lock screen, though remember to re-enable it after you're done.

#### 2. Heat

After an hour or two of constantly running `sshd` on iSH, your phone gets warm and toasty. This is because iSH emulates all of its commands---but for good reason, App Store approval!

<br>

However, with effort, a custom app could solve the above limitations by:

1. Allowing more control over backgrounding behavior, including [abusing background music for unlimited backgrounding](https://yifan.lu/2013/12/17/unlimited-backgrounding-on-ios/).
2. Running arm64 sshd [without requiring x86 emulation](https://news.ycombinator.com/item?id=24862329), reducing CPU usage.
3. And doing both of the above without requiring App-Store approval, since you can load custom apps locally.

Until then, this is a proof-of-concept that leaves productionization as an exercise to the reader.

Enjoy!


---
title: "Why I don't feel like writing."
date: 2021-07-05
# longform: true
---

_I don't know._ Maybe it's because I've got lots of things to do. Maybe that's just something I tell myself when I procrastinate work that seems hard. Why is writing hard? Because it's vulnerable? Or because vulnerable work is held close-to-heart, and the standards are higher, so I truly _do_ need to do more work to get it out?

Why don't I feel like writing?

I don't know! Sometimes the words come out, and sometimes they don't. I guess this is one of the times where they just don't. Would I be better at editing right now? Why don't the words come out easily? Is it because I'm stressed, is it because I'm frustrated? Is it because I'm too tired and have exhausted all of my thinking potential earlier in the day? Should I not be writing late?

Why don't I feel like writing?...

Okay, this title-repetition has worn off. I can't keep going the whole way, should I scrap it? Should I just delete the whole thing and start again? Sometimes, when I delete the whole thing, I feel that the next time, I might be less inclined to start it in the first place.

What a hamper.

So I _do_ think that the editing standards are higher to get something out for publication. But when I'm writing, I'm just writing for my own blog! Why is it hard to post something that's difficult to write? Oh wait, that's not what I mean. Oh wait. _It is._ I have to write something that's difficult, and then I have to edit it, to make it something that's good, and then--unsatisfied with its blemishes--I have to make it into something that's producable. I have to publish it. How can I?

Oh, that wasn't bad, actually.

I think this style feels fairly freeing. [oh god, I just accidentally deleted the whole work, why is iA writer so bad]. Ah, yes, that's the problem. When I write with my inner dialogue, it's literally the thoughts that go through my head. There's very little editing, and the structuring isn't well-thought-out. A sentence could be confusing. Or the whole argument could be ordered with a structure that makes it confusing. Do I stop and edit? Do I backspace? Oh wait, I did, and now I don't remember the rest of what I'm saying! It's difficult!

So, maybe that's why I don't write as often as I want to.

Except, _I do._ I just discard all the drafts that don't make it. And oh, _so many_ of them end up as just drafts. Never making it to production. Never seeing the light of day. But yes, that does put me in a rut. If I feel like I'm writing another draft that won't make it, I might just give up. If I spend too much time editing, I might just give up. If I have to make _stylistic_ changes that require _code_ changes in my CMS platform, I might just give up. How do I make sure I don't just give up? The only way that's pretty much guaranteed: I just ... hit ... send.

...

[fin]

This blog post was edited less than once, or not at all. This blog post was reviewed by no-one[0]. But I still like it. Enough to hit submit, at least.

0. Though, it _was_ based off of a conversation I had with a friend


---
title: "Introducing Portal Windows"
date: 2021-08-25
longform: true
canonical: https://blog.tandem.chat/portal-windows/
---

<center>
_(This post originally published on [Tandem's blog](https://blog.tandem.chat/portal-windows/))_
</center>

What’s the piece of technology that reduced your headache the most in the last year?

For me, it’d be [Portal Windows](https://github.com/cryptagon/portal-windows). It's a library we made at [Tandem](https://tandem.chat) that lets you render and position native windows as simply as you render and position tooltips in your React app.

<centered-content caption="tired: juggling your free time. wired: juggling some portal windows">

<iframe title="YouTube video player" width="480" height="300" src="https://www.youtube.com/embed/p6m2zotGy-g?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

A year ago, making changes to other windows was a slog.

To trace the flow of data through our app, you would have to jump from file to file. Stores in the renderer sent messages to the node process, which then forwarded them to the renderer process for the window that was displayed. If you wanted to add a small icon to a row on our tooltips, users would have to download a new desktop app to see it.

And worst of all, these changes took _so long_ to make.

Today, every single one of those problems is gone, and I _enjoy_ window-related tickets. I don't have to write a single line of desktop code, or do any message-passing. I mostly just write React components, as if there were no windows involved.

Not only that, but behavior we didn’t consider a year ago, because it was prohibitively difficult, is now simple.

- Rendering a window onto multiple screens, even as screens are added/removed,
- doing complicated bounds correction,
- positioning a window relative to an _element_ on another window, even as the parent window moves and gets resized?

All covered. You too can feel great while writing complex window-management code.

Now, here’s a high-level of how Portal Windows work, a few simple examples, a few examples of how we use them today in the Tandem app, and then the source code.

## Structure

Portal Windows are made up of a three-layer system:

- Integration with React, allowing you to treat a window as a component in your tree, change its props, render elements inside it (thanks to React Portals)
- A window management store, which keeps track of window and screen state, allowing relative positioning of windows, bounds correction, and multi-screen rendering support
- Desktop-side code that enables the frontend to apply and receive updates, and create and address windows

What does this let you do? Great things!

## Examples

If you enjoy using Tandem, you might be familiar with these windows, and their use cases:

<centered-content>

<centered-content caption="Meeting reminders: get reminded of your meeting before it starts, and have Tandem automatically launch it for you at the start time. Shown on every screen.">

<iframe title="YouTube video player" width="480" height="300" src="https://www.youtube.com/embed/Ptz3m7Pu_7U?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

<centered-content caption="Chatbox: when untoggled, new messages pop up to the left of the callbox, and slowly fade. When toggled, it remains open and shows chat history.">

<iframe title="YouTube video player" width="480" height="300" src="https://www.youtube.com/embed/Ifea3a8HHcQ?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

</centered-content>

<centered-content caption="Screenshare: fetches windows + screens, and lets you share them. Once you screenshare, 'end screenshare' window appears on the bottom of the screen you're sharing to let you end it quickly.">

<iframe title="YouTube video player" width="480" height="300" src="https://www.youtube.com/embed/CX0xMNzHkEY?rel=0&amp;showinfo=0" frameborder="0" allowfullscreen></iframe>
</centered-content>

Being able to use portal windows means that the "End Screenshare" window ended up being only ~100 lines of code total, and took <1hr to build.

## Using Portal Windows

Remember the swarm of windows in the video at the top? [Here's the code](https://github.com/cryptagon/portal-windows/blob/main/examples/src/app.tsx) behind it, and [here's a simpler version](https://github.com/cryptagon/portal-windows/blob/main/examples/src/simpleApp.tsx) that only has one portal window.

You can follow the steps to get it integrated in your existing Electron app [here](https://github.com/cryptagon/portal-windows), or copy a [fresh project](https://github.com/cryptagon/portal-windows/tree/main/examples) to play around with.

This tech has cut down on the time it takes to ship new features drastically, and we’re open-sourcing it as a gift to the community. Check out the [source code here!](https://github.com/cryptagon/portal-windows) (licensed MIT)

<breakdots>
</breakdots>

Does this interest you? Let us know, we're hiring! [jobs@tandem.chat](mailto:jobs@tandem.chat)!


---
title: "To my teachers"
subtitle: "A thank-you letter"
date: 2021-12-16
ending_gap: true
---

Do you know how some kids want to be teachers when they grow up?

Do you know _why?_

I do. When I was in fifth grade, I was shy, short, and quiet. I had skipped two grades, and so I was two years younger than the other students. My parents had moved five times (Vermont, Pennsylvania, Indiana, New Mexico) before we had come back to Texas, and I didn't have a lot of friends. Or, for that matter, experience making them.

But in the mornings, before school, every day, I would get dropped off at around 6am by my parents. I would wait with the crossing guard until my teacher came to school, and then go sit with her in the classroom and write in my journal, and do my work, until school started. I still remember her name was Mrs. Hill.

In that class, I went from being a very-quiet, very-unsure, very-shy child, to being a mostly-quiet, mostly-unsure, mostly-shy kid. And, as anyone who's been in that situation can tell you, that's actually a lot of improvement. I felt proud when I could shape a spoon out of aluminum foil for our hands-on science demonstration, I felt good about writing, in a way I thought was interesting. And at Camp Tyler, an outdoor school that each 5th grade class in our public school distict visited for a week, I had fun.

That's the change a teacher can cause. You might say, "that's what they're told to do". But I remember Mrs. Hill would spend her own money to buy supplies and other things for the classroom. She didn't need to wake up so early for school to let me in. Neither did the crossing guard.

I haven't had a long career, but I've been exceedingly lucky to meet people like Mrs. Hill. People that made me want to be like them, when I grew up.

## Teachers are Mentors

My first internship was exceptional. It shaped my career in the same way that Mrs. Hill's fifth grade class shaped my educational path.

That summer I had a great time, learned a lot, and grew as a person. I left that internship better-equipped to solve problems.

Not just because the tech was robust, or the team was skilled, or because I had real responsibilities. But also because of who I sat next to.

My manager, Zack, was more of a mentor than anything else. When we had discussions, we had them as peers. When we had 1-1s, we would talk about life, and I knew I could ask difficult questions. The type you would ask a friend, when you needed advice.

To some people, I'm describing their current manager-direct relationship. To others, I'm describing something unfathomably impossible. For me, it was my first internship, and I kind of figured I had found something good.

Zack mentored as a peer, and by that, I mean imagine you had time-traveled to see yourself 10 years in the future. Would you expect them to look down on you? Hand you quick answers, instead of expanding your understanding? Or would you imagine them to do everything they could in their power to increase your knowledge and independence, assuming they would be better for it?

## Paying it forward

Nowadays, when I need to be a mentor, I try to imagine how Zack would approach it. Last winter, I helped my sister as she built and programmed a RC car with an arduino, and she actually had a good time. This summer, I mentored two of our interns at [Tandem](https://tandem.chat), and I actually did well.

I say _actually_, because I historically haven't been a great mentor. Back when I was in college, I set expectations too high, and I looked down on people I mentored if I didn't feel they met them. I probably had an overall discouraging effect on my sister, or friends I tried to teach programming to, instead of accelerating their learning.

If I hadn't been other side of the table, and learned how to be a mentor _from my mentors_, I don't know how I would've ever improved.

## A grateful thanks

I feel incredibly lucky to have these people in my life. People with no prior connection to me, who still care that I learn, and do well.

To Mrs. Hill, to Zack, and to all my other teachers:

Thank you for instilling a learning spirit in me.


---
title: "Patching dependencies is easier than forking"
date: 2022-04-20
---

Oftentimes, it feels like we overengineer the solutions we build. Patching packages never feels this way.

When I use patch-tool, it's often the best solution.

It may not be the best long-term solution, but it's so darn fast. And at a startup, speed of development directly translates into product velocity.

So let me tell you how to use it. With an example: Patching Datadog.

## What patch-package does.

When working with javascript, you naturally have file access to the contents of your imported NPM packages. So you can modify them locally. If your code needs a dependency changed, you can make that change, rebuild, and try it out.

What [patch-package](https://www.npmjs.com/package/patch-package) does _then_, is it lets you check those patches into version control. So when your teammates or CI systems pull the repo, as part of running `yarn` to update deps, they reapply those patches. That way you can modify your dependencies, without having to take on the weighty burden of forking them.

## Why make a patch?

So here's the context. I work at a company called [Jam](https://jam.dev), and we make the best QA tool for websites and webapps. We care about our users' experience, so we want to keep track of unexpected errors that users hit. We use Datadog for this.

The problem is that a portion of our Chrome[^1] extension is a content-script, which gets loaded alongside pages that users report bugs on. When our content script sends updates to Datadog, these updates live in the context of the host page. So they pollute the user's network requests tab in devtools. And when a user closes the page, requests that were buffered could be lost!

[^1]: Firefox support coming soon, Safari support is intended after that.

---

So that's the issue. We don't want Datadog requests to go be sent by the pages that our users browse. But Datadog's `browser-logs` and `browser-rum` packages don't let you proxy messages with a proxy function! You [can](https://docs.datadoghq.com/real_user_monitoring/faq/proxy_rum_data/?tab=npm) set a URL to proxy them through, but that doesn't help in our case. What do? Fork it?

No! Patch-package to the rescue!

## The patch itself

The Datadog packages we use have all of their requests go through one file:

<centered-content size="size1 mobileSize1" caption="note: in this case, this file lived in a third-package, `@datadog/browser-core`, which is the package I patched directly, after elevating it to a top-level dependency.">
<img src="/img/easily-patch-your-javascript-deps/original_code.png">
</centered-content>

What we need to do now is modify this file to allow us to proxy these requests. After that, we'll be able to proxy these requests over postMessage, from our content script to our background script.

But first, we need to figure out what version of the file we're modifying! For this file, there's a `cjs` and an `esm` version. Easiest way to figure out which one we're importing? Just sprinkle some log statements in, clear webpack's cache, and reload!

<centered-content size="size1 mobileSize1" caption="`THIS IS ESM!`">
<img src="/img/easily-patch-your-javascript-deps/cjs_vs_esm.png">
</centered-content>

We've found our file! Next step: modify it!

Since Chrome extension content scripts live in a separate context from their host page (`window` objects aren't shared), we can simply have our patched package read from the `window` object, to figure out where should send the message data, without worrying about intereference with/from the host page.

<centered-content size="size1 mobileSize1" caption="And if we don't add a `'DATADOG_REQUEST_PROXY'` function to the `window`, our logger falls back gracefully. This is useful, because we'll be using this dependency in our background script as well, where we want to use default behavior!">
<img src="/img/easily-patch-your-javascript-deps/modify_dep.png">
</centered-content>

Amazing! Last step, proxy the messages and execute them on the background script.

<centered-content size="size1 mobileSize1" caption="in the content script, it looks like this">
<img src="/img/easily-patch-your-javascript-deps/original_code.png">
</centered-content>

And in the background script, we execute the messages as regular network requests:

<centered-content size="size1 mobileSize1" caption="That `HttpRequest`? Imported from the same file we patched, which thankfully already exported it.">
<img src="/img/easily-patch-your-javascript-deps/background_handler.png">
</centered-content>

The end result: Datadog logs are smoothly sent through our background script!

Now that we're satsified with our changes, we run `yarn patch-package` to generate a patch file, and commit it to version control:

<centered-content size="size1 mobileSize1">
<img src="/img/easily-patch-your-javascript-deps/patchfile.png">
</centered-content>

## Try it at home!

Next time you consider forking a package to change a few lines, don't forget you have another option!

Patch-package even makes it easy to contribute back, by providing an easy way to submit your patch as a PR!

<br>

---

<br>

One more thing: care as much about user experience as we do? Hate how long it takes to file bugs?

[Try Jam today](https://chrome.google.com/webstore/detail/jam/iohjgamcilhbgmhbnllfolmkmmekfmci)! Our users file bugs in seconds, directly to their issue tracker, with all the details engineers need. Learn more [here](https://jam.dev)!

<centered-content size="size1 mobileSize1" caption="Seriously, Give your engineers something to be excited about, when you hand them a bug.">
<img src="/img/easily-patch-your-javascript-deps/network_tab_screenshot.png">
</centered-content>

<br>
<br>
<br>

my stack of papers

by Cyrus Roshan

2022

Patching dependencies is easier than forking

2021

Bypassing hotspot limits on iOS

Why I don't feel like writing.

Introducing Portal Windows

To my teachers

2020

Why I built the wrong blog publishing workflow

My home infrastructure setup with Ansible

Two cable SSH: the fastest Raspberry Pi setup

The harmful assumptions we make about tasks

2016

A hardware hacker's kit

Making a 3d scanner for under $20

Building an electronic banjo out of paper plates

2015

The importance of examples

An intro to hackathons