DEV Community: George Mandis

OpenAI Charges by the Minute, So Make the Minutes Shorter

George Mandis — Tue, 24 Jun 2025 00:00:00 +0000

Want to make OpenAI transcriptions faster and cheaper? Just speed up your audio.

I mean that very literally. Run your audio through ffmpeg at 2x or 3x before transcribing it. You’ll spend fewer tokens and less time waiting with almost no drop in transcription quality.

That’s it!

Here’s a script combining of all my favorite little toys and tricks to get the job. You’ll need yt-dlp, ffmpeg and llm installed.

# Extract the audio from the video
yt-dlp -f 'bestaudio[ext=m4a]' --extract-audio --audio-format m4a -o 'video-audio.m4a' "https://www.youtube.com/watch?v=LCEmiRjPEtQ" -k;

# Create a low-bitrate MP3 version at 3x speed
ffmpeg -i "video-audio.m4a" -filter:a "atempo=3.0" -ac 1 -b:a 64k video-audio-3x.mp3;

# Send it along to OpenAI for a transcription
curl --request POST \
  --url https://api.openai.com/v1/audio/transcriptions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-Type: multipart/form-data' \
  --form file=@video-audio-3x.mp3 \
  --form model=gpt-4o-transcribe > video-transcript.txt;

# Get a nice little summary

cat video-transcript.txt | llm --system "Summarize the main points of this talk."

I just saved you time by jumping straight to the point, but read-on if you want more of a story about how I accidentally discovered this while trying to summarize a 40-minute talk from Andrej Karpathy.

Also read-on if you’re wondering why I didn’t just use the built-in auto-transcription that YouTube provides, though the short answer there is easy: I’m sort of a doofus and thought—incorrectly—it wasn’t available. So I did things the hard way.

I Just Wanted the TL;DW(atch)

A former colleague of mine sent me this talk from Andrej Karpathy about how AI is changing software. I wasn’t familiar with Andrej, but saw he’d worked at Tesla. That coupled with the talk being part of a Y Combinator series and 40 minutes made me think “Ugh. Do I… really want to watch this? Another 'AI is changing everything' talk from the usual suspects, to the usual crowds?”

If ever there were a use-case for dumping something into an LLM to get the gist of it and walk away, this felt like it. I respected the person who sent it to me though and wanted to do the noble thing: use AI to summarize the thing for me, blindly trust it and engage with the person pretending I had watched it.

My first instinct was to pipe the transcript into an LLM and get the gist of it. This script is the one I would previously reach for to pull the auto-generated transcripts from YouTube:

yt-dlp --all-subs --skip-download \
  --sub-format ttml/vtt/best \
  [url]

For some reason though, no subtitles were downloaded. I kept running into an error!

Later, after some head-scratching and rereading the documentation, I realized my version (2025.04.03) was outdated.

Long story short : Updating to the latest version (2025.06.09) fixed it, but for some reason I did not try this before going down a totally different rabbit hole. I guess I got this little write-up and exploration out of it though.

If you care more about summarizing transcripts and less about the vagaries of audio-transcriptions and tokens, this is the correct answer and your off-ramp.

My Transcription Workflow

I already had an old, home-brewed script that would extract the audio from any video URL, pipe it through whisper locally and dump the transcription in a text file.

That worked, but I was on dwindling battery power in a coffee shop. Not ideal for longer, local inference, mighty as my M3 MacBook Air still feels to me. I figured I would try offloading it to OpenAI’s API instead. Surely that would be faster?

Testing OpenAI’s Transcription Tools

Okay, using the whisper-1 model it’s still pretty slow, but it gets the job done. Had I opted for the model I knew and moved on, the story might end here.

However, out of curiosity, I went straight for the newer gpt-4o-transcribe model first. It’s built to handle multimodal inputs and promises faster responses.

I quickly hit another roadblock: there’s a 25-minute audio limit and my audio was nearly 40 minutes long.

Let's Try Something Obvious

At first I thought about trimming the audio to fit somehow, but there wasn’t an obvious 14 minutes to cut. Trimming the beginning and end would give me a minute or so at most.

An interesting, weird idea I thought about for a second but never tried was cutting a chunk or two out of the middle. Maybe I would somehow still have enough info for a relevant summary?

Then it crossed my mind— what if I just sped up the audio before sending it over? People listen to podcasts at accelerated 1-2x speeds all the time.

So I wrote a quick script:

ffmpeg -i video-audio.m4a -filter:a "atempo=2.0" -ac 1 -b:a 64k video-audio-2x.mp3

Ta-da! Now I had something closer to a 20 minute file to send to OpenAI.

I uploaded it and… it worked like a charm! Behold the summary bestowed upon me that gave me enough confidence to reply to my colleague as though I had watched it.

But there was something... interesting here. Did I just stumble across a sort of obvious, straightforward hack? Is everyone in the audio-transcription business already doing this and am I just haphazardly bumbling into their secrets?

I had to dig deeper.

Why This Works: Our Brains Forgive, and So Does AI

There’s an interesting parallel here in my mind with optimizing images. Traditionally you have lossy and lossless file formats. A lossy file-format kind of gives away the game in its description—the further you crunch and compact the bytes the more fidelity you’re going to lose. It works because the human brain just isn’t likely to pick-up on the artifacts and imperfection

But even with a “lossless” file format there are tricks you can lean into that rely on the limits of human perception. One of the primary ways you can do that with a PNG or GIF is reducing the number of unique colors in the palette. You’d be surprised by how often a palette of 64 colors or fewer might actually be enough and perceived as significantly more.

There’s also a parallel in my head between this and the brain’s ability to still comprehend text with spelling mistakes, dropped words and other errors, i.e. transposed letter effects. Our brains have a knack for filling in the gaps, and when you go looking through the world with magnifying glass you'll start to notice lots of them.

Speeding up the audio starts to drop the more subtle sounds and occasionally shorter words from the audio, but it doesn’t seem to hurt my ability to comprehend what I’m hearing—even if I do have to focus. These audio transcription models seem to be pretty good at this as well.

Wait—how far can I push this? Does It Actually Save Money?

Turns out yes. OpenAI charges for transcription based on audio tokens, which scale with the duration of the input. Faster audio = fewer seconds = fewer tokens.

Here are some rounded numbers based on the 40-minute audio file breaking down the audio input and text output token costs:

Speed	Duration (seconds)	Audio Input Tokens	Input Token Cost	Output Token Cost
1x (original)	2,372	NA (too long)	NA	NA
2x	1,186	11,856	$0.07	$0.02
3x	791	7,904	$0.04	$0.02

That’s a solid 33% price reduction on input tokens at 3x! However the bulk of your costs for these transcription models are still going to be the output tokens. Those are priced at $10 per 1M tokens whereas audio input tokens are priced at $6 per 1M token as of the time of this writing.

Also interesting to note—my output tokens for the 2x and 3x versions were exactly the same: 2,048. This kind of makes sense, I think? To the extent the output tokens are a reflection of that models ability to understand and summarize the input, my takeaway is a “summarized” (i.e. reduced-token) version of the same audio yields the same amount of comprehensibility.

This is also probably a reflection of the 4,096 token ceiling on transcriptions generally when using the gpt-4o-transcription model. I suspect half the context window is reserved for the output tokens and this is basically reflecting our request using it up in its entirety. I suspect we might get diminishing results with longer transcriptions.

But back to money.

So the back-of-the-envelope calculator for a single transcription looks something like this:

6 * (audio_input_tokens / 1_000_000) + 10 * (text_output_tokens / 1_000_000);

That does not quite seem to jibe with the estimated cost of $0.006 per minute stated on the pricing page, at least for the 2x speed. That version (19-20 minutes) seemed to cost about $0.09 whereas the 3x version (13 minutes) cost about $0.07 (pretty accurate actually), if I’m adding up the tokens correctly.

# Pricing for 2x speed
6 * (11_856 / 1_000_000) + 10 * (2_048 / 1_000_000) = 0.09

# Pricing for 3x speed
6 * (7_904 / 1_000_000) + 10 * (2_048 / 1_000_000) = 0.07

It would seem that estimate isn’t just based on the length of the audio but also some assumptions around how many tokens per minute are going to be generated from a normal speaking cadence.

That’s… kind of fascinating! I wonder how John Moschitta’s feels about this.

Comparing these costs to whisper-1 is easy because the pricing table more confidently advertises the cost—not “estimated” cost—as a flat $0.006 per minute. I’m assuming that’s minute of audio processed, not minute of inference.

The gpt-4o-transcription model actually compares pretty favorably.

Speed	Duration	Cost
1x	2372	$0.24
2x	1186 seconds	$0.12
3x	791 seconds	$0.08

Does This Save Money?

In short, yes! It’s not particularly rigorous, but it seems like we reduced the cost of transcribing our 40-minute audio file by 23% from $0.09 to $0.07 simply by speeding up the audio.

If we could compare to a 1x version of the audio file trimmed to the 25-minute limit, I bet we could paint an even more impressive picture of cost reduction. We kind of can with the whisper-1 chart. You could make the case this technique reduced costs by 67%!

Is It Accurate?

I don’t know—I didn’t watch it, lol. That was the whole point. And if that answer makes you uncomfortable, buckle-up for this future we're hurtling toward. Boy, howdy.

More helpfully, I didn’t compare word-for-word, but spot checks on the 2x and 3x versions looked solid. 4x speed was too fast—the transcription started getting hilariously weird. So, 2x and 3x seem to be the sweet spot between efficiency and fidelity, though it will obviously depend on how fast the people are speaking in the first place.

Why Not 4x?

When I pushed it to 4x the results became comically unusable.

That sure didn't stop my call to summarize from trying though.

Hey, not the worst talk I've been to!

In Summary

Always, in short, to save time and money, consider doubling or tripling the speed of the audio you want to transcribe. The trade-off is, as always, fidelity, but it’s not an insignificant savings.

Simple, fast, and surprisingly effective.

TL;DR

OpenAI charges for transcriptions based on audio duration (whisper-1) or tokens (gpt-4o-transcribe).
You can speed up audio with ffmpeg before uploading to save time and money.
This reduces audio tokens (or duration), lowering your bill.
2x or 3x speed works well.
4x speed? Probably too much—but fun to try.

If you find problems with my math, have questions, found a more rigorous study qualitatively comparing different output speeds please get in touch! Or if you thought this was so cool you want to hire me for something fun...

Querying Random Blog Posts with Netlify Functions

George Mandis — Wed, 04 Dec 2019 00:00:00 +0000

Inspired by something Derek Sivers implemented on his site, I decided to add a URL to this site that automatically redirects to a random blog post. You can find the link via the /dev/random menu item on my website or simply go to george.mand.is/random.

I like it because it adds a quality that's tricky to capture on the web: "skimmability." It reminds me of being able to thumb through the pages of a book before committing.

With a Traditional Server Setup

Setting this up on a traditional server would've been fairly straightforward. If it was running on Apache or NGINX for example it probably would've been just a matter of adding a line to the configuration file to redirect requests to another script on the server that could pick a blog post at random and tell the browser to redirect. There would be other implementation details, but that's the gist of it.

With Netlify

This site, however, is hosted on Netlify. In all the ways Netlify eases the development and deployment experience for some types of sites, doing relatively simple backend things often requires finding interesting workarounds.

For this random URL redirection idea I was able to get this up and running without too much trouble using Netlify Functions.

Here are the steps to take:

Install the Netlify Command Line Tool.

This will allow you to setup and test your functions locally. You can find more information on the documentation site on how to configure your project locally and connect it to one of your Netlify sites.

Once you've successfully installed the command line tools and connected your local working folder to your site you can run npm run dev in the console and access your site at localhost:8888 in the browser. Functions, redirects and other Netlify-specific features will behave just as though they're in production on Netlify's servers and allow us to test this feature as we're building it.

Setup Netlify functions.

I suggest calling the folder functions and configuring it via a netlify.toml file instead of using the web interface. There is more informatoin about how to set that up on Netlify's documentation page about configuring functions.

Setup Your Redirect

Create a _redirects file in your Netlify site and add this line:

  /random /.netlify/functions/random 302

You can also set this up in your netlify.toml file, which is explained in this blog post. My site has a lot of simple redirects though and I find the separation to be more manageable.

Selecting a Random URL From Your Blog

We'll need a way to have all the URLs available in our function. This is the trickier part and will vary depending on how you built your site. There are many approaches, but this was my approach:

Create a special URL that returns a JSON feed that's nothing but URLs for all my blog posts
Use node-fetch in my function to pull in that data and pick one at random
Send information in the header response to tell the browser to perform a 302 redirect to the random selection

I debated adding some measuer of security to this special URL, but decided it didn't much matter. It's really no different than a sitemap and I've ensured that only blog post URLs are presented in this feed. You can see it here:

george.mand.is/_all.json.

You'll notice it's returning relative URLs. This is helpful for testing it locally.

I found creating this feed fairly straightforward with Eleventy but you could probably do this with whatever static generator you're using. If you're using Jekyll I'd taking a look at my Jekyll JSON feed templates on GitHub.

Creating the Function

Last but not least we need to create the actual function! I've written mine in Node.js, but you could write yours in Go as well.

It's worth noting that the directory structure influences the URL structure for your Netlify function. I've saved the file that contains my function at functions/random.js in my project folder. This function's endpoint is automatically created at /.netlify/functions/random both in production and locally.

Here is the code:

/**
 * Random Blog Post (/random)
 * ===
 * George Mandis (george.mand.is)
 */

require("dotenv").config();
const fetch = require("node-fetch");

exports.handler = function(event, context, callback) {
  fetch(`${process.env.URL}/_all.json`, { headers: { "Accept": "application/json" } })
    .then(res => res.json())
    .then(response => {
      const randomPost =
        response.posts[Math.round(Math.random() * response.posts.length - 1)];

      callback(null, {
        statusCode: 302,        
        body: `Location:${process.env.URL}${randomPost}`,
        headers: {
          "Location": `${process.env.URL}${randomPost}`          
        }
      });

    });
};

If you've completed all of these steps you should be able to test your redirection URL locally at localhost:8888/random and see a random blog post returned!

So far I really enjoy this feature. Anecdotally I'm noticing a few more hits on older posts than normal, but it's nice even for my own sake. It's fun to be able to flip back through the posts I've written over the years.

Introducing Bubo RSS: An Absurdly Minimalist RSS Feed Reader

George Mandis — Thu, 28 Nov 2019 00:00:00 +0000

Bubo Reader is a somewhat irrationally minimalist RSS and JSON feed reader you can deploy on Netlify in a few simple steps. I created this one weekend last summer after nostalgically lamenting the demise of Google Reader many years ago. It's named after the silly robot owl from the film Clash of the Titans (1981).

View the demo → bubo-rss-demo.netlify.com

View the source code → github.com/georgemandis/bubo-rss

You will find instructions on the project's GitHub page for how to make your own instance of Bubo Reader, update the list of feeds and deploy to Netlify. If you already have interconnected accounts on those two services it's really quite straightforward!

Read on for more information about the original impetus, design goals and thoughts surrounding this project.

What Does "Irrationally Minimalist" Mean?

Many RSS readers—including the former Google Reader—would pull the contents of a post into your feed so you could read everything in one place. Although I completely understand why someone would want to do that, I decided even that introduced too much complexity for my liking.

My goal with Bubo Reader was to be able to see a list of the most recent posts from websites I like in one place with links to read them if I want. That's it. If I want to read something, I'll click through and read it on the publisher's site. If I want to keep track of what I've clicked on and read I can reflect that using the a:visited pseudo selector in my CSS.

I think it's often overlooked how many problems the browser has already solved for us. Sometimes modern web development feels like fighting against the problems we've already solved as we try to build things that pretend they don't live in the browser.

Bubo Reader does not store posts in a database or keep track of what I've read. If an item is no longer available in the site's feed then it no longer appears in Bubo. If I miss something, that's just life. I can live with that.

Design Goals for This Project

Many RSS feed reader services have sprouted up since Google Reader left, but they all do more than I need. All I wanted was something that:

Had an absurdly simple interface, relying almost entirely on default HTML/browser behaviors and functionality. I'm using lesser-known HTML like the details and summary elements to hide and reveal content instead of recreating that wheel in JavaScript, for example.
Could be themed with CSS or mildly extended using JavaScript. For my personal copy of Bubo Reader I changed the font to use the system-ui font and bumped the font-size a little, but that's mostly it.
Didn't worry about pulling in the link's content into the reader interface. I'm happy to read most content on the site it originated from and many feeds only provide a short description of th content as it is. Mostly I wanted a single dashboard to know when new stuff is published and available.
Didn't rely on a database to see what I've read or keep an archive of content over time. Again, I found the browser has a way of taking care of this for me. The a:visited pseudo selector is enough indication for me to know whether or not I've already read something.

A Healthier Way to Read Online

I also think this is a healthier way to consume information and news. So much of social media is designed to reward things that hit the dopamine buttons in our brains, manipulate our common, human propensity for anxiety or distrubute outright propaganda.

Refreshing Content

The beauty of running Bubo on Netlify is you can setup a Build Hook to rebuild the site when you want to "refresh" the list of feeds. I'm using IFTTT to trigger rebuilds once an hour, which is a perfectly sane rate to consume information at. You could do the same, or use another service like Zapier, EasyCron, setup a cronjob on your server or even setup a cronjob to run locally on your machine and ping the hook as often as you wish.

What About Authentication?

There is no authenticaton required for Bubo Reader. Netlify does offer Basic Authentication under their Pro plan, which would probably be the easiest solution to implement. You could also utilize their Identity feature to add some authentication. I don't subscribe to any private or sensitive feeds, so at the moment that isn't much of a priority for this project.

Adding New Feeds

Find them in the site's source code and add them to the feeds.json file. This is the trickiest part of this whole setup I suppose, but I'm willing to bet the people who clone projects from GitHub and deploy them to Netlify are okay with editing a little JSON from time to time.

The first version of this project used Puppeteer to extract the feeds from a site. This was actually quite cool, but would hang or fail periodicially. Builds were slow and there was a lot of work making sure things didn't timeout or use too much memory on the tiny server I'd setup. Simply parsing a list of known RSS feeds was much simpler and faster.

It's on my list to look into converting this into a serverless version that could run using Netlify's Functions, but after using my own project for a month I realized it didn't make the thing feel much more usable to me.

In Summary

If you find Bubo Reader useful, interesting or it inspires a project of your own I'd love to hear about it! Again, you'll find the code on GitHub.

What's the Difference between link preload, preconnect and prefetch

George Mandis — Thu, 14 Nov 2019 00:00:00 +0000

Lately I've been running Lighthouse audits some of my client projects as well as my own. With my own projects I typically regard it as an opportunity to dive into some nitty-gritty optimizations that I might typically ignore for a client, only because the billable hours might be better spent elsewhere.

One of those areas of optimization is resource prioritization with links tags such as these:

<link rel="preload">
<link rel="preconnect">
<link rel="prefetch">

I was generally aware of these and had even used them, but I wasn't actually aware of the difference between most of these offhand. When the Lighthouse audit recent led me to the Google Developer documentation about resource prioritization I saw a chance to get better acquainted with the differences between them.

It'll probably serve you best (Pun!) to remember them in this order:

preload
preconnect
prefetch

Any time you use one of these <link rel="pre*"> tags you're telling the browser about a resource that you think is more important than others on the page and should be prioritized over them, in some fashion. The order that they're presented in above is basically in order from the "most" important of the important things to the least.

How exactly are these things prioritized? Well, rather than completely plagiarize some excellent documentation (which I started to realize was going to happen as I kept writing this blog post) you can read more about the details of each of these here:

https://developers.google.com/web/fundamentals/performance/resource-prioritization

Here's my short summary of when you might use these:

preload : Use for fonts and super-critical assets that you absolutely know you'll be using.
preconnect : Use for CDNs or any resource you know you'll be loading from another domain.
prefetch : Any content we thnk we'll need soon after some kind of user interaction. An interesting example is to prefetch the HTML content for another page that we think the user will be navigating to.

Detecting invalid dates in JavaScript

George Mandis — Thu, 27 Jun 2019 00:00:00 +0000

When you want to instantiate a new instance of a JavaScript date object you can pass along date information as a string like this:

new Date('June 27, 2019')

In fact, it's somewhat forgiving in accepting a variety of date formats. All of these in Chrome 75 as of this writing are valid ways to create a date object:

new Date('June 27, 2019')
new Date('2019, June 27')
new Date('2019/06/27')
new Date('6/27/19')
new Date('6-27-19')
new Date('6/27/2019')
new Date('6-27-19')
new Date('2019-06-27')
new Date('6/27/19 11:00')
new Date('2019-06-27')

For production I wouldn't suggest doing this. I'd suggest leaning on an established library like Moment.js or one of the many smaller alternatives suggested in this GitHub repository. But if you're just experimenting with something and need a quick-and-dirty solution to creating a date object, knowing you can do this is handy.

It's also handy to know if you've accidentally created an invalid date. Looking at the output in the console, this seemed like this should be easy:

new Date('My Birthday')
// Invalid Date

You might expect to be able to do something like this:

const birthday = new Date('My Birthday')

if (birthday === "Invalid Date") { ... }

But you would be mistaken! While it's generally considered a best practice to test for strict equality and use that triple equals sign, it's not helping you here. The value spit out to the console isn't actually a string, strange as that might seem.

Technically, this will work:

if (birthday == "Invalid Date") { ... }

But I don't fully trust it and am not sure about support in older browsers.

What's helpful to remember is that the date object is just a number, provided it's formatted right:

const day1 = new Date('June 27, 2019')
const day2 = new Date('My Birthday')

console.log(day1.valueOf())
// 1561618800000 

console.log(day2.valueOf())
// NaN

That means we can use the delightfully bizarre isNaN() function to figure out if our date is formatted correctly or not:

if (isNaN(birthday)) { ... }

Voilà.

If you're new to all of this JavaScript/Date/NaN chicanery, I'll leave you with this to copy-and-paste into your console:

typeof NaN

Edge Canary Supports Shape Detection API

George Mandis — Tue, 21 May 2019 00:00:00 +0000

The macOS version of Microsoft Edge Insider was released today at microsoftedgeinsider.com. Currently only the Canary Channel is available, which is updated daily. The more stable Beta and Dev channels will likely become available in the coming weeks as we run the gauntlet between Microsoft Build, Google I/O, WWDC and probably some other developer-centric events I'm forgetting about that happen this time of year.

The new version of Edge is built on Chromium, which is kind of a bittersweet victory for the web depending on how you look at it. On the bitter side, choice and differentation is one of the things that makes the open web great. No one company owns the web, nor should it. For all the things it does well, adopting Google's project to power their browser feels like Microsoft ceding a little too much control to Google's grip on the web, even if I think they've generally been decent stewards.

On the sweeter side, troubleshooting and debugging a Chromium-based browser is going to be much nicer than dealing with Edge! While I was at Microsoft Build the other week I asked a question about whether or not the new Edge would support the Shape Detection API. It's currently available in Chromium hidden beneath the experimental web features flag found at chrome://flags.

I asked about this while I was speaking at Microsoft Build the other week:

Does anyone know if the new MS Edge based on Chromium has an equivalent of the "Experiments" page (chrome://flags) to enable experimental web platform features?

You can enable the Shape Detection API on Chromium, which sort of surprised me. Wondering if Edge inherited this...

— George Mandis (@georgeMandis) May 3, 2019

Long-story short—looks like you can! Just go to edge://flags and you'll find an identical screen.

To answer my own question: YES! In Edge Canary on macOS you can find the flags at: edge://flags/

I also tested the Shape Detection API, and it works!!!

Long-term, I'm excited to think this means wide-support for a very cool feature:https://t.co/wj4CKixLGZ https://t.co/Dx4Pt1fZch

— George Mandis (@georgeMandis) May 21, 2019

Once you've enabled this you should be able to view this demo at my slightly neglected project Debugging Art :

debuggingart.com/sketch/shape-detection-dva-brata/

Though my feelings are still mixed on the state of browser homogeneity, I do think it's cool that features like this might become wide-spread more quickly.

Huff Post, Konami Code and Pet Photos Makes the News More Palatable

George Mandis — Wed, 10 Apr 2019 00:00:00 +0000

I've always kept tabs on my public profile out on the web. Sometimes it's surprising what you can find. You might have your own Google Scholar page because of a college paper you wrote when you were 18 or find out you were scheduled to speak at a conference in another country well before the organizers reached out to you.

Today I found out an old project of mine is being used on HuffPost—or should I say, FluffPost?

Go check it out! If you go to the HuffPost's homepage and enter the Konami Code all of the images turn into adorable photos of people's pets.

It has not been the best couple years for happy, uplifting news, but seeing some of these headlines accompanied by cute dogs and cats made it a lot more palatable. Cases in point:

Mnuchin definitely looks feisty. And that team Barr is assembling looks like serious business. I'm sure they'll get to the bottom of things.

How did I find this?

I accidentally stumbled across this not via a Google search but by doing a search for my name on GitHub in other people's code repositories. This might seem a little odd, but if you've created or contributed to a lot of open-source projects it's an interesting view into how people might actually be using what you've made.

It's also a good way to see if a private repository you handed off to another development agency accidentally found it's way into the public... but that's a different story!

In looking for my name I came across references to a project of mine in what looked like code scraped from the homepage of Huff Post. The code contains comments with information about licensing, the version and a byline with my name, which is what helped me find this.

I decided to go the Huff Post and try the code out. When I entered the Konami Code and saw the pets I laughed, and when I went to view the source code for the page I was tickled to see my name and code sitting there.

About the project

Konami-JS is an open-source easter-egg project I made back in 2009. It lets you add an Easter Egg to any website when a visitor enters the Konami Code. The differentiator, at the time, was my project worked on mobile devices.

Most of what I find are people putting Konami Code easter eggs on their GitHub pages, blogs and other personal projects. Occasionally it pops up in bigger places like Marvel.com or Newsweek. I recently discovered it was even being used on Tesla's online design tool back in 2012—I found remnants of it on archive.org here. I guess now I can add Huff Post to that list!

By modern JavaScript standards the script is kind of archaic, but it lives in a sort of gray area where I'm not sure it stands to gain much by modernizing it. The code footprint is compact but but understandable and it's easy to plop into any existing project with a quick copy-and-paste. Beginners can and do use my code, all the time.

As the barrier to entry into web development seems to grow a little steeper each year, I'm happy to have contributed a project that's being used by novices and high-traffic websites alike. I'm also happy that it's a joyful, frivolous contribution that's been mostly used to make the web a fun and sillier place.

Watch me give a talk about my experience maintaining this "frivolous but popular" project at OdessaJS in 2017:

https://www.youtube.com/watch?v=F3xI3ps7syI

Lastly, I do have open issues and discussions on GitHub surrounding what Konami-JS 2.0 could/should look like, a decade later. Your contributions are welcome.

Creating Trusted SSL Certificates for localhost on MacOS

George Mandis — Thu, 27 Sep 2018 07:00:00 +0000

Recently I was working with the Stripe Elements toolkit for a piece of custom billing software my web development company uses. The library is a collection of well-designed UI components for interfacing with Stripe’s services. Specifically I was working with their Payment Request Button which is designed to work with the W3C Payment Request API standard currently being discussed.

To implement the Payment Request Button you need to be using a secure (https) connection. This isn’t difficult to setup using OpenSSL, but the Payment Request API requires a little more than a basic SSL certificate in place — it has to be a trusted as well. Stripe’s suggestion to use a service like ngrok is a good one, but not necessarily always possible or desirable. Such was the case for my project.

Creating a trusted SSL certificate for your localhost server on macOS turned out to require a lot of steps and a fair amount of research. When I finally generated the certificates and had everything running smoothly I decided to package it up in a single command you could run in the terminal and made a GitHub project out of it:

github.com/snaptortoise/ssloca

Now, instead of copying-and-pasting cryptic OpenSSL commands into the terminal like I’m sure so many developers before me have done, you can generate and trust these certificates in two lines:

git clone git@github.com:snaptortoise/ssloca.git && cd ssloca./create-local-certificates.sh

You should end up with a folder called certs containing all the locally generate certificates including the root certificate and the certificate for your server. More information on what and how things are generated can be found in the code.

I called the project SSLoca — a portmanteau of SSL, local and loca, in Spanish. Because getting SSL to work locally made me feel a little crazy.

There’s plenty of room for improvement in my script, and I know there are lots of developers out there who have jumped through the same hoops to solve this problem. Please give it a look, let me know if you found it useful and by all means submit a pull request if you have thoughts on how to improve it.

A framework-agnostic explanation of web components

George Mandis — Tue, 31 Oct 2017 07:00:00 +0000

Last month I spoke at JSFoo and really enjoyed my time there. Besides the overall experience and amazing people there were some very good talks as well! One of them was by Rahat Khanna from Apple on web components.

Web components are one of those modern development tools that are hard to talk about in a way that’s framework agnostic. Rahat’s talk manages to do just that — discuss web components in a way that’s completely separate from frameworks like React, Angular and Vue. I often prefer these kind of talks that hone in on core ideas, concepts and APIs rather than the abstractions we build up around them. Frameworks come and go, but the underlying ideas end up sticking around… hopefully!

His talk inspired me to try a framework-agnostic approach to a client project using web components. It seemed like a good idea and turned out to be great idea! If you’re just getting started with web components or need a little inspiration you should watch his talk:

Resources and strategies for remote workers

George Mandis — Sun, 01 Oct 2017 07:00:00 +0000

A little over 10 years ago I threw myself into freelance web development without thinking it through too thoroughly. Since then I’ve thought on many occasions that my ignorance was probably to my benefit. If I’d known all the stuff I didn’t know I’m not so sure I would’ve done it!

There are plenty of things I would have done differently, better or perhaps not at all if given the chance to again. There are also some surprisingly good strategies and habits I managed to luck into over the past decade! One of those things was figuring out how to find work when I was just starting out.

Recently I was in India speaking at JSFoo about JavaScript, MIDI and Tiny Computers. In one of the introductory slides I mentioned my year spent traveling and working remotely.

After my talk, an earnest developer came up to me and asked about getting started as a freelancer and remote worker. That conversation inspired me to put together this resource on GitHub:

Remote Work List – github.com/georgemandis/remote-working-list

It’s a compilation of websites that post jobs that are remote-worker and freelance friendly. At the time of this writing there are over 60 sites listed. Additionally, I’ve indicated whether or not there’s an RSS feed available for each job board. For sites that provide a feed I’ve provide a link.

With the death of Google Reader in 2013 a lot of sites abandoned RSS, which is too bad. It was integral to my job search strategy as a budding freelancer. I’m happy to say that a little over half the sites on my remote work list have one:

This makes my original strategy still viable – though we’ll need a modern replacement for Google Reader – so I’ll go on to explain.

My Remote Worker / Freelance Strategy

Here are my steps and tips for anyone starting off as a remote-working/freelancer today and needs to build a client base:

Subscribe to all of the RSS feeds in this list using an RSS subscription service or dedicated reader. I’m partial to FeedBin and Reeder for Mac. You can find lots of candidates but I’d suggest finding one with the ability to star/bookmark or otherwise “save specific posts as you cycle through them. Keyboard shortcuts are a bonus too, but maybe that’s just because I was used to the ones Google Reader provided.
Every morning, while you’re drinking your coffee or tea or otherwise starting your day, cycle through all of the job postings that have accumulated. If you see something you feel could be a good match or if you find something you might be interested in learning how to do, save it in your reader of choice – give it a âï¸ or a bookmark or whatever the nomenclature is for your particular app/service. If it’s not something you’re interested in, mark it as read or otherwise archive it.
The most important part of that last step, which I’ve now turned into its own step: don’t overthink it! You can assess if the job is a good match or if you’re actually qualified in a later step. For now we’re just filtering out the obvious mismatches.
When you’re done going through all of the job listings, put it away and do something else. Make breakfast, go get exercise, or take a shower and start a proper work day. If you really don’t have anything else to do and feel eager to continue searching for new jobs and gigs you can go straight to the next step, but I’m a big proponent of breaks and resets.
In the afternoon, maybe after you’ve eaten lunch, or when you feel ready to take a midday break from whatever you’ve been working on all day, pull up the starred/bookmarked posts you separated from earlier. Read them a little more in-depth and decide if any of them now look like poor matches. If they are, go ahead and remove them.
Hopefully you should have a list of jobs you’re interested in and feel somewhat qualified for. Now it’s time to start applying! Coming up with a proper introduction letter that you can tailor to individual clients and companies is a topic for another day. Go through the starred/bookmarked posts one at a time, starting with the oldest listing you marked, and start applying. As you finish applying be sure to remove them from your saved list.
An important tip: It’s okay if you don’t get through all of them! Although the strategy I’m promoting really encourages searching and filtering these listings in bulk, take your time when applying. You want to make a good impression. As you get better at this you’ll be able to apply to jobs more quickly but still do so in a way the feels personable. If you have starred/bookmarked posts left over after an hour or two (or however much time you put aside for this activity) you can pick them up the next day. If you want you have a backlog after a few days and are getting swamped I suggest either being more judicious with your bookmarking and/or be willing to remove listings from your starred/bookmarked page if they’re more than, say, a week old.

That’s really it! I did this for months when I started out and acquired a lot of clients and worked on a variety of freelance gigs. Some of them were good and turned into client relationships I continue to have to this day. Others amounted to what I’ll call unanticipated learning experiences :)

It’s not rocket science, but I found this approach to be highly affective. This strategy also works well if you want to hit the “reset button at some point in your career and inject new clients and projects into your freelance life.

Do you have your own freelance/remote working tips? I’d love to hear about them! Send me an email, ping me on Twitter or post in the comments below.

And if you need a web developer for your project – even something a bit more outside the box – get in touch ðŸ˜Š

Tiny computers that run JavaScript natively

George Mandis — Fri, 22 Sep 2017 07:00:00 +0000

I’ve had johnny-five.io bookmarked for a long time as something to explore, and earlier today I took a break to do it. If you’re not familiar with the project, it allows you to program single-board computers and controllers like the Arduino, Rasperry Pi and many, many others in JavaScript.

For some of the platforms it runs directly on the devices, but for others it requires a host machine to run your JavaScript and communicate the hardware interactions with your tiny computer over a serial connection. Depending on what you’re trying to build that’s probably fine, but I’m more interested these days in hardware that allows you to run JavaScript directly.

Fortunately their hardware list is quite easy to filter! Essentially this list comprises all the SBCs that run some kind of Linux environment and allow you to install Node. Still, for posterity, here’s a list of all the tiny computers that you can run JavaScript on directly that I’m aware of:

Is this list missing something? In particular I’m curious about other projects like the Espruino that don’t run some flavor of Linux but instead allow you to run JavaScript natively on the board. All of these would make nice computers for some of my MIDI projects.

Did I miss any? Please let me know — send me an email or ping me on Twitter.