<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Guido.io</title>
    <link>https://guido.io/</link>
    <description>Recent content on Guido.io</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 15 Jun 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://guido.io/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Assumptions have an expiry date in software</title>
      <link>https://guido.io/posts/assumptions-have-an-expiry-date/</link>
      <pubDate>Thu, 15 Jun 2023 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/assumptions-have-an-expiry-date/</guid>
      <description>Assumptions seem to never hold Having a single e-mail per account may be fine for the first customers of your SaaS, but you will quickly learn that users want to invite their colleagues.
The assumption of “one e-mail address &amp;lt;&amp;gt; one account” is no longer good enough. The next step is to build a teams abstraction in your code, where one team consists of multiple users.
Should you have built this abstraction into your code from day one?</description>
    </item>
    
    <item>
      <title>What if Javascript had a synchronous async flavor?</title>
      <link>https://guido.io/posts/nasync-javascript/</link>
      <pubDate>Sun, 01 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/nasync-javascript/</guid>
      <description>When writing asynchronous javascript your code will contain a bunch of await and async, Promises and maybe callbacks.
Here&amp;rsquo;s an example where we fetch a page and count the amount of div elements:
As you write more and more code that is asynchronous, you will end up writing await quite a bit. In languages like Python and Go you write asynchronous code as if it&amp;rsquo;s synchronous. What if we could do the same in Javascript?</description>
    </item>
    
    <item>
      <title>Testing web-based notebooks</title>
      <link>https://guido.io/posts/testing-notebooks/</link>
      <pubDate>Sat, 31 Jul 2021 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/testing-notebooks/</guid>
      <description>Notebook systems for literate programming are increasingly popular. I&amp;rsquo;m talking about tools that allow you to mix code, text and rich content like Jupyter, Observable, and Starboard.
For Starboard I wanted to be able to make changes to Starboard itself and plugins while being confident everything still works end to end.
Testing in Jupyter The most serious tool I could find for Jupyter is testbook (part of the nteract ecosystem). This tool seems to follow a pattern that I saw used in other Jupyter testing setups: notebooks are treated a .</description>
    </item>
    
    <item>
      <title>Introducing Sunder - A framework for ServiceWorkers (like Cloudflare Workers)</title>
      <link>https://guido.io/posts/introducing-sunder/</link>
      <pubDate>Wed, 02 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/introducing-sunder/</guid>
      <description>Originally posted on the Sunder blog.
Sunder is a framework for Service Workers like those found in Cloudflare Workers. It allows you to create testable APIs and websites in a similar way as you would using Node.js&amp;rsquo;s Koa or Express framework.
Sunder is designed to be minimal, testable, and easy to understand. It&amp;rsquo;s only a few hundred lines of code.
A small example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 import {Sunder, Router} from &amp;#34;sunder&amp;#34;; const app = new Sunder(); const router = new Router(); // Example route with a named parameter router.</description>
    </item>
    
    <item>
      <title>Controlling variance in proof-of-work algorithms</title>
      <link>https://guido.io/posts/controlling-variance-in-proof-of-work-algorithms/</link>
      <pubDate>Fri, 17 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/controlling-variance-in-proof-of-work-algorithms/</guid>
      <description>Proof of work (PoW) algorithms generally have no notion of progress, instead they are more like playing the lottery millions of times until you win. Losing a million times doesn&amp;rsquo;t influence your chances of winning the next one.
That&amp;rsquo;s ok and probably even desirable for applications like a cryptocurrency mining, but undesirable for an application like hashcash in which the proof of work is used as a payment for say, signing up for a website.</description>
    </item>
    
    <item>
      <title>Going fully serverless with Cloudflare Workers</title>
      <link>https://guido.io/posts/going-fully-serverless-with-cloudflare-workers/</link>
      <pubDate>Thu, 16 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/going-fully-serverless-with-cloudflare-workers/</guid>
      <description>Over the past two months I&amp;rsquo;ve built FriendlyCaptcha, a privacy friendly alternative to Google reCAPTCHA. Normally if I were to start a new web application, I would write the server code in Golang, spin up a Postgres instance, and host a dockerized version of it on Google Cloud Run to get many of the serverless benefits.
For a CAPTCHA product the requirements were a bit different: it is critical that its API is fast, always available, has predictable costs, and can scale up and down instantly.</description>
    </item>
    
    <item>
      <title>Implementing a type-safe Stripe client for serverless using Typescript</title>
      <link>https://guido.io/posts/using-stripe-in-serverless-typescript/</link>
      <pubDate>Mon, 13 Jul 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/using-stripe-in-serverless-typescript/</guid>
      <description>In my current project I am trying to go full origin-less: everything runs in a CloudFlare worker script, there is no centralized server. These serverless Javascript environments often don&amp;rsquo;t run on Node, so there are a lot of libraries you can&amp;rsquo;t use.
This makes going fully serverless painful, so far I had to implement the client code for Mailgun, BigQuery and Stripe myself. Each of these has a great SDK for Node, but unfortunately we can&amp;rsquo;t use those.</description>
    </item>
    
    <item>
      <title>Sending e-mail from Cloudflare Workers</title>
      <link>https://guido.io/posts/sending-email-from-cloudflare-workers/</link>
      <pubDate>Wed, 24 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/sending-email-from-cloudflare-workers/</guid>
      <description>In most serverless environments, Cloudflare Workers included, you can not send e-mail through SMTP. Also, many client SDKs for providers such as Mailgun or Sendgrid assume you are on the Node platform and will not work in many serverless runtimes. Luckily most providers also provide a REST API to send e-mail.
I ended up going with Mailgun, below is some example Typescript code that works in Cloudflare Workers.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 declare const MAILGUN_API_BASE_URL: string; declare const MAILGUN_API_KEY: string; export interface EmailData { from: string; to: string; subject: string; text: string; html: string cc?</description>
    </item>
    
    <item>
      <title>Embedding WebAssembly in Javascript code using wasmwrap</title>
      <link>https://guido.io/posts/embedding-webassembly-in-javascript-without-a-bundler/</link>
      <pubDate>Sat, 20 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/embedding-webassembly-in-javascript-without-a-bundler/</guid>
      <description>As a followup to my previous post, I found that in practice embedding a WebAssembly binary in code as a base64 string using a bundler (such as Webpack or Rollup) is still not ideal. So I created a small tool, wasmwrap that generates a plain Javascript or Typescript file for you instead.
To install it:
npm install wasmwrap --save-dev Then you can use it as such:
wasmwrap --input my-file.wasm --output myFile.</description>
    </item>
    
    <item>
      <title>Embedding WebAssembly in Javascript code</title>
      <link>https://guido.io/posts/embedding-webassembly-in-javascript/</link>
      <pubDate>Sun, 14 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/embedding-webassembly-in-javascript/</guid>
      <description>Actually shipping compiled WebAssembly code can be tricky. Especially when you want the wasm module to be easy to install and use through NPM it gets complicated, users will have to use wasm plugins for their bundler of choice (such as Webpack or Rollup), or they will need to host the wasm file separately and pass it into your library.
If the developer of this project does not interact with WASM code otherwise, this may be a big ask.</description>
    </item>
    
    <item>
      <title>An introduction to AssemblyScript</title>
      <link>https://guido.io/posts/introduction-to-assemblyscript/</link>
      <pubDate>Wed, 10 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/posts/introduction-to-assemblyscript/</guid>
      <description>⚠️ This article is outdated by now, AssemblyScript has changed quite a bit - you will have to change some things.
AssemblyScript is a programming language that is almost the same as Typescript and compiles to WebAssembly.
WebAssembly allows near-native speed for programs that rely on heavy computation with smaller binaries. Any modern browser nowadays supports it as well as Deno and Node. It will not replace Javascript itself anytime soon, but for some problems it can be a good choice, especially those that involve extensive computation.</description>
    </item>
    
    <item>
      <title>Games</title>
      <link>https://guido.io/games/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/games/</guid>
      <description></description>
    </item>
    
    <item>
      <title>Projects</title>
      <link>https://guido.io/projects/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://guido.io/projects/</guid>
      <description></description>
    </item>
    
  </channel>
</rss>
