Feross Aboukhadijeh wormhole.app

Wormhole – Simple, fast, private file sharing ✨

Wormhole lets you share files with end-to-end encryption and a link that automatically expires. So you can keep what you share private and make sure your stuff doesn’t stay online forever.


Our #1 goal is speed – you should be able to get a share link in less than 2 seconds with the absolute minimum number of clicks.

That’s why Wormhole supports instant file streaming. There’s no need to wait for your files to finish uploading before you can copy the link and send it to your recipient. The recipient can start downloading even before the files have finished uploading.

Wormhole uses super fast peer-to-peer transfer to send files directly to the recipient when possible. This improves speed and security – especially when transferring files over a local network, like when you just want to get a file from your phone onto your computer.

In addition, Wormhole stores your encrypted files on cloud servers for 24 hours so the share link will keep working for your recipient even after you close the Wormhole site.

CloudZero Icon CloudZero – Sponsored

11 DevOps metrics to monitor for organizational success

logged by @logbot permalink

When evaluating the effectiveness of your DevOps model, it is critical to use metrics relevant to your organization. The best approach for measuring success is to identify the key outcomes you want to achieve, and then find the right DevOps metrics to monitor those outcomes.

This post from CloudZero shares eleven performance metrics you can track to gauge the success of your DevOps approach.

Practical AI Practical AI #133

25 years of speech technology innovation

To say that Jeff Adams is a trailblazer when it comes to speech technology is an understatement. Along with many other notable accomplishments, his team at Amazon developed the Echo, Dash, and Fire TV changing our perception of how we could interact with devices in our home. Jeff now leads Cobalt Speech and Language, and he was kind enough to join us for a discussion about human computer interaction, multimodal AI tasks, the history of language modeling, and AI for social good.

Hidde de Vries hiddedevries.nl

Criticism pushes the web forward

Hidde de Vries takes a strong, reasoned stance to online criticism of others’ work:

This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.

This is a tough subject because we identify so closely with the things we create (our code), but Hidde is right: if we want to progress as an industry (and individually) we need to be able to criticize (constructively) and receive criticism. It’s part of the process.

We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.

Jerod Santo changelog.com/posts

You might as well timestamp it

In my 15+ years of web development, there are very few things I can say are unequivocally a good idea. It almost always does depend.

Storing timestamps instead of booleans, however, is one of those things I can go out on a limb and say it doesn’t really depend all that much. You might as well timestamp it. There are plenty of times in my career when I’ve stored a boolean and later wished I’d had a timestamp. There are zero times when I’ve stored a timestamp and regretted that decision.

Nat Bennett simplermachines.com

What happens when you pair all day, most days, for years?

There are obvious upsides to pair programming. This post from Nat Bennett shares both the ups and the downs of pairing all day for years…

So I paired all day, most days, for about five years. This had a lot of upsides, far more than I can list here. There’s a standard list of benefits and drawbacks to pairing that you might be familiar with, but the impact of pairing, especially pairing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.

Nat goes on to share when pairing took more than it gave for them.

Pairing requires being vulnerable, to another human being, for hours at a time. Intimacy, both physical and mental. I had to share space, decisions, thought processes, and often feelings with this person. … This never stopped being draining.

Over time, over years, pairing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.

LaunchDarkly Icon LaunchDarkly – Sponsored

Building better software with the scientific method

logged by @logbot permalink

As humans, we are constantly faced with problems. We build software to solve problems. The features we create sometimes have problems when we deploy. We encounter an obstacle and need to figure out how to overcome it. We don’t necessarily know how to solve the problem at the outset, but how we think about the problem and the solution will impact whether we are successful or not.

I remember learning about the scientific method many years ago. Watching the Neil DeGrasse Tyson Masterclass, I started thinking about how the scientific method applies to delivering and supporting software. One quote jumped out at me: “The most important moments of your life are not decided by what you know, but how you think.” It’s not about what we know about delivering and deploying software, but how we think about the processes we use to do so.

How do you approach a software problem? Imagine you’re trying to compile newly written code and encounter an error. You don’t immediately know what is wrong; we need to investigate the issue. How do you approach the problem?

Start your 14-Day trial today

Gerhard Lazu changelog.com/posts

🚀 KubeCon + CloudNativeCon Europe 2021

I really appreciate how well this event came together. The virtual platform and diversity played a big part in this world-class experience. This was the perfect one to Ship It!, a brand new Changelog show that honours the makers, the shippers, & the visionaries that see it through. Tune in mid-May to find out more about the behind-the-scenes of this event.

Stripe Icon Stripe

Guide to managing founder stress

Stripe Atlas has a wide array of guides to running an internet business that are totally open and free for everyone. This guide, written by Dr. Sherry Walling (a clinical psychologist), on “managing founder stress” covers everything from running smart (not just hard), coping with chronic stress, mastering the ups and downs, and a reminder that as a founder you are not alone.

If you like this guide, then you’ll probably be a fan of my podcast Founders Talk too.

Mark Eriksen fly.io

Building a distributed turn-based game system in Elixir

Mark Eriksen:

Many great Phoenix LiveView examples exist. They often show the ease and power of LiveView but stop at multiple browsers talking to a single web server. I wanted to go further and create a fully clustered, globally distributed, privately networked, secure application. What’s more, I wanted to have fun doing it.

So I set out to see if I could create a fully distributed, clustered, privately networked, global game server system. Spoiler Alert: I did.

I like the way he frames his experience. He says the most remarkable thing about it is not what he built, it’s what he didn’t need to build in order to accomplish his goal.

Node.js github.com

google/zx – a tool for writing better scripts

Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice, but standard Node.js library requires additional hassle before using. zx package provides useful wrappers around child_process, escapes arguments and gives sensible defaults.

I wouldn’t say JavaScript is a perfect choice for this kind of scripting, but it’s definitely a suitable one (especially if it’s the language you already know well). Here’s what scripting looks like with zx:

#!/usr/bin/env zx

await $`cat package.json | grep name`

let branch = await $`git branch --show-current`
await $`dep deploy --branch=${branch}`

await Promise.all([
  $`sleep 1; echo 1`,
  $`sleep 2; echo 2`,
  $`sleep 3; echo 3`,
])

let name = 'foo bar'
await $`mkdir /tmp/${name}`

Top-level await sure makes things nicer. (Deno supports this out of the box, btw.)

The Changelog The Changelog #439

Elixir meets machine learning

This week Elixir creator José Valim joins Jerod and Practical AI’s Daniel Whitenack to discuss Numerical Elixir, his new project that’s bringing Elixir into the world of machine learning. We discuss why José chose this as his next direction, the team’s layered approach, influences and collaborators on this effort, and their awesome collaborative notebook project that’s built on Phoenix LiveView.

SQLite unixsheikh.com

SQLite is the only database you will ever need in most cases

SQLite is so hot right now.

Even if you start out small and later need to upscale, as long as your web application can run on the same machine as the database, which it can in 99% of the time, you can just upgrade the hardware to a beefier machine and keep business as usual.

The only time you need to consider a client-server setup is…

SQLite phiresky.github.io

Hosting SQLite databases on GitHub Pages

The benefits of such a setup are numerous, especially for small sites and side projects:

Hosting a static website is much easier than a “real” server - there’s many free and reliable options (like GitHub, GitLab Pages, Netlify, etc), and it scales to basically infinity without any effort.

The how is also super interesting:

So how do you use a database on a static file hoster? Firstly, SQLite (written in C) is compiled to WebAssembly. SQLite can be compiled with emscripten without any modifications, and the sql.js library is a thin JS wrapper around the wasm code.

There’s more to the story, and the resulting solution is also open source.

Paul Graham paulgraham.com

Crazy new ideas

Paul Graham on preposterous sounding ideas and how easy they are to dismiss:

Most implausible-sounding ideas are in fact bad and could be safely dismissed. But not when they’re proposed by reasonable domain experts. If the person proposing the idea is reasonable, then they know how implausible it sounds. And yet they’re proposing it anyway. That suggests they know something you don’t. And if they have deep domain expertise, that’s probably the source of it.

Such ideas are not merely unsafe to dismiss, but disproportionately likely to be interesting. When the average person proposes an implausible-sounding idea, its implausibility is evidence of their incompetence. But when a reasonable domain expert does it, the situation is reversed. There’s something like an efficient market here: on average the ideas that seem craziest will, if correct, have the biggest effect.

I’m not a big ideas guy. Never have been. Adam is, though. And I freely admit that many of his ideas sound preposterous to me at first. But I’ve learned over the years to hear him out, because he’s usually on to something, even if it’s not fully-formed yet. And it turns out I’m pretty good at taking partially-formed ideas and helping firm them up. This is one of the reasons why we make a good team.

Having new ideas is a lonely business. Only those who’ve tried it know how lonely. These people need your help. And if you help them, you’ll probably learn something in the process.

0:00 / 0:00