Loading…
Browse by type
Tutorial reads
Tutorial posts on Yomu, summarised newest first.
- 630 posts
- 20 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Tutorial posts
Leveraging Pre-trained Language Model Checkpoints for Encoder-Decoder Models
Pre-training sequence-to-sequence transformer models incurs massive computational costs, limiting development primarily to large institutions. To mitigate these expenses, encoder-decoder architectures can be warm-started using existing pre-trained checkpoints from encoder-only or decoder-only models like BERT and GPT-2. This walkthrough details the methodology and implementation of warm-starting sequence-to-sequence architectures using Hugging Face Transformers. By utilizing the EncoderDecoderModel framework alongside Seq2SeqTrainer, practitioners can construct and fine-tune models such as BERT2BERT on datasets like CNN/DailyMail. The resulting fully trained BERT2BERT model achieves a ROUGE-2 score of 18.22 on the full evaluation set, matching competitive sequence generation baselines at a fraction of standard pre-training costs.
Porting fairseq wmt19 translation system to transformers
The fairseq WMT19 news translation system was ported to the Hugging Face transformers library under the FSMT architecture. Development began with an initial proxy notebook emulating the transformers API before implementing native configuration, modeling, tokenization, and checkpoint conversion scripts. The author first targeted English-Russian models to handle complex dual-vocabulary requirements and directly evaluate output quality during testing, later extending the implementation to merged-vocabulary language pairs. Although model ensembling was omitted due to library limitations, removing fairseq optimizer states reduced the final model download footprint from 13GB to 1.1GB. The implementation was validated locally against converted fairseq checkpoints and merged into the main codebase after two weeks of iterative review.
Hyperparameter Search with Transformers and Ray Tune
Hugging Face Transformers models often require hyperparameter tuning to achieve high performance, but practitioners frequently rely on basic grid search or bypass tuning entirely. The Transformers 3.1 release integrates Ray Tune into the Hugging Face Trainer to provide advanced hyperparameter optimization without losing framework customizability. By invoking hyperparameter_search with the Ray backend, users can configure trial budgets, parallelize runs across multiple GPUs, and plug in search algorithms like HyperOptSearch alongside schedulers like ASHAScheduler. Experimental benchmarks on a BERT model using the RTE dataset show that Population-based Training reached 70.5% test accuracy in 48 GPU minutes, outperforming Grid Search at 65.4% test accuracy. The integration also supports experiment tracking tools like Weights and Biases out of the box.
How to Introduce Composite Primary Keys in Rails
Shopify addressed inefficient data access in its multi-tenant Rails application, where auto-incrementing primary keys interleaved records from many shops even though queries usually targeted one shop. InnoDB stores rows in B+ trees and loads pages into a buffer pool, so the team changed orders and other suitable tables to composite primary keys such as [shop_id, order_id] while keeping an auto-incrementing id secondary key and configuring Active Record to use id. Supporting Ghostferry, migration tooling, and data extraction systems also had to accommodate the schema change, with unique secondary constraints avoided in some cases because LHM migrations could deadlock. On the most queried table, common queries improved 5–6x, median buffer pool reads fell from 1.8 to 1.2, and elapsed database time dropped roughly one hour per day per shard, while inserts became about 10x slower.
How to Do an In-depth Liquid Render Analysis with Theme Inspector
Shopify theme code can create server-side rendering bottlenecks that leave customers waiting on a blank screen, so the article explains how to analyze Liquid performance with Shopify Theme Inspector. It describes flame graphs as representations of code paths and execution time, then compares clean Liquid with heavy loops, nested loops, and mixed global Liquid scopes. Accessing product attributes raised a 10-item example from 13 ms to 162 ms, while 50 products took 800 ms; two- and three-level nested examples rendered in 55 ms and 72 ms. The guidance recommends examining total iteration time, sawtooth or hair-comb patterns, unnecessary attributes, pagination size, and AJAX alternatives. It proposes aiming for 200 ms and keeping total page rendering under 500 ms, while noting that this alone does not guarantee a good LCP score.
How to Build an Experiment Pipeline from Scratch
The post describes building an email experimentation pipeline at Shopify after an existing framework for web properties and Shopify admin experiences could not support tests in external channels. The motivating case was a personalized blog-post recommendation algorithm whose incremental benefit needed comparison with generic blog emails, while local randomization and text-file storage created risks around unsubscribed users, shop-email relationships, and overlapping audiences. After requirements gathering, system mapping, mock-table queries, stakeholder review, and technical design review, the author implemented three pipeline phases in PySpark: experiment definitions, consolidation, and filtering with deduplication and exclusion rules. Production output supported ongoing randomization, backfills, category tags, sample limits, and integration with Shopify’s existing analysis framework; the tool was subsequently used across multiple data teams for email experiments.
Stuff Your Pi-Hole From Anywhere
Pi-Hole blocks advertising and tracking domains by acting as a DNS server that returns a dummy address for listed hosts, but a home deployment is difficult to use while traveling and can incur latency. The post presents “Fli-Hole,” a globally reachable Pi-Hole application deployed on Fly’s edge network, using the official Docker image without modifying Pi-Hole itself. Its configuration sets INTERFACE and DNSMASQ_LISTENING, exposes UDP port 53 through fly.toml, stores the web password as a Fly secret, and deploys with fly deploy. Additional Fly regions, such as Frankfurt, can be added so nearby traffic is routed through them. Each regional instance has independent settings and no persistence or sharing, while Dockerfile changes and redeployment provide a way to distribute configuration updates.
Maps, Apps, and Tracks
Maps, Apps, and Tracks describes how to build an online map that tracks a marathon runner from a mobile device and deploys it with Fly. The route is drawn and exported as GPX, imported into Google My Maps, enriched with mile markers, and exported as KML for display through Leaflet.js and the leaflet-kml plugin. An Express server accepts OwnTracks HTTP POSTs at /log/, filters location messages by a hard-coded topic, stores latitude and longitude in memory, and exposes them through /where/. Browser code places or moves a marker by polling that endpoint every 30 seconds, while static files are served from the mappages directory. Local testing uses a shell script with mock OwnTracks JSON, and Fly deployment uses flyctl, fly init, and fly deploy; the post notes authentication, Redis persistence, and multiple runners as possible additions.
Using Heroku Postgres From A Fly App
A Fly application can use Heroku Postgres without migrating the application itself, with Heroku hosting an add-on-only app that provides the database. The setup provisions a Hobby Dev Heroku Postgres database, retrieves its URI credentials, and passes DATABASE_URL to the Fly deployment as a secret. A Node REST API using Sequelize parses that URI with pg-connection-string, then supplies the database, user, password, and host while enabling SSL and setting rejectUnauthorized to false for Heroku’s certificate-chain issue. After fly deploy, the app connects externally to Postgres, but the Hobby plan limits it to 20 connections unless upgraded. The article presents Heroku’s US and Europe data-center choices as a way to keep the database relatively close while Fly places the application near users, and warns that credentials rotate periodically without notification.
Migrating Heroku Database Apps To Fly
Migrating a Heroku application to Fly requires attention to database connectivity because Heroku Postgres must be accessed over SSL from outside Heroku. The post uses the DATABASE_URL environment variable, parses it with pg-connection-string, and passes a configured connector to Massive.js, setting sslmode to require and rejectUnauthorized to false to accommodate self-signed certificates in Heroku Postgres’s certificate chain. It also shows a local-development fallback that uses a non-SSL localhost Postgres connection when DATABASE_URL is undefined. With these changes, Turboku can migrate the app and convert DATABASE_URL into a Fly secret, while the application retains its database connection and can use Fly’s region and scaling controls. Database latency still depends on proximity to Heroku’s US or European database regions, so caching within Fly regions may matter for mission-critical performance.
Always Be Connecting (with HTTPS)
The post explains how to ensure users reach an HTTPS version of an application running behind Fly’s edge proxies, particularly when a custom domain and certificate are attached. Fly’s default fly.dev behavior redirects HTTP automatically, but custom certificates do not activate that upgrade because connection behavior remains under the application owner’s control. The recommended method checks the X-Forwarded-Proto header, which records whether the original client connection used http or https, and returns a 301 redirect to the same URL with an https scheme when needed. Examples implement the check in Go middleware, Express middleware for Node, and Nginx configuration; the post also notes that non-Fly deployments can inspect the request and URL scheme instead, while Fly was considering future automation.
Tophatting in React Native
Shopify’s tophatting process manually verifies coworkers’ changes before pull requests are approved, but React Native reviews previously required saving work, switching branches, rebuilding, and loading the app. The new tool stores compressed JavaScript bundles and their assets in cloud storage when Shopify Build’s CI pipeline processes a React Native pull request. A backend service records metadata such as the app ID, commit SHA, and branch, generates signed URLs, and posts a pull-request comment with a QR code, bundle ID, and download link. A React Native component library handles deep links through a separate Tophat screen, confirms bundle metadata, downloads and decompresses the selected bundle, saves metadata locally, and restarts the app with it. The first iteration lets developers load peer changes within seconds, and almost all Shopify React Native projects now use the tool.
5 Ways to Improve Your React Native Styling Workflow
Shop's React Native app began as Arrive's codebase, and its visual overhaul prompted a broader rethink of styling practices. The resulting open-source Restyle library organizes styling around a design system covering spacing, semantic colors, and typography, represented by a theme object that components receive through React's Context API. Reusable Box and Text components map props such as spacing, background color, and text variants to theme values, while responsive properties target predefined screen-size breakpoints and TypeScript restricts props to valid theme options with editor autocomplete. The stated result is a more enjoyable and efficient workflow: Restyle supported the transition from Arrive to Shop, enabled theme switching, helped tailor screens to device sizes, and made dark mode easy to add.
How to Track State with Type 2 Dimensional Models
Application databases often retain only current values in Type 1 dimensions, limiting analysis of historical settings such as feature adoption, retention, and switching behavior. The post explains Type 2 dimensional models through Shopify’s need to track users’ admin languages over time, contrasting application-model changes, scheduled database snapshots, and event logging. Its selected implementation uses Rails after_commit callbacks to send created or updated records to Kafka, then transforms that event history into records with valid_from, valid_to, and is_current fields using ETL recipes involving PySpark and dbt. The approach provides the required granularity but can miss changes or events, requires delete handling and data-quality checks, and is presented as an iterative solution; MySQL binlogs are described as a more reliable future source.
Let’s Debug a Node.js Application
Node.js applications can be difficult to debug because asynchronous workflows complicate stack traces, while crashes may require core-dump analysis through complex command-line tools. The article presents a layered toolkit: production-oriented logging with Pino or Winston, interactive inspection through Node Inspect and Chrome DevTools, IDE integrations, and the standalone ndb debugger. Running node --inspect-brk launches an application for inspection at chrome://inspect, where breakpoints, stepping, call stacks, heap snapshots, and memory profiling are available; ndb additionally supports edit-in-place changes. For catastrophic crashes, llnode maps JavaScript frames and objects to C/C++ representations from a core dump generated with process.abort, while debug filters namespaced logs and trace and clarify improve asynchronous traces and remove Node.js internals, respectively, for local debugging.
Continuous PostgreSQL Backups using WAL-G
Continuous PostgreSQL backups require coordinating physical base snapshots with ongoing write-ahead log archiving to support point-in-time recovery. The open-source WAL-G utility simplifies this workflow by managing backup pushes and fetches to cloud storage services such as Amazon S3. In a typical setup on Ubuntu with PostgreSQL 12, envdir supplies AWS credentials and storage prefixes to WAL-G commands embedded directly in the PostgreSQL archive configuration. Regular base backups can be automated via cron jobs, which minimizes the volume of WAL archives that must be replayed during a restore. When recovering to a new instance, administrators fetch the latest base backup, define a restore command with targeted recovery timestamps in the configuration, and initiate replay using a recovery signal file.
Migrating Large TypeScript Codebases To Project References
Shopify’s merchant admin UI grew from a Ruby on Rails ERB-based front-end into a TypeScript, React, and GraphQL codebase, and its size eventually made VSCode’s TypeScript language tooling take roughly two to three minutes to initialize. The team investigated the bottleneck with TypeScript’s performance diagnostics, VSCode TSServer logs, and support from the TypeScript team, which recommended splitting the monolithic configuration with project references. They built the TypeTrack VSCode plugin to measure initialization time, then migrated dependency-graph leaf nodes such as packages and tests, creating project-level tsconfig.json files and references incrementally. The migration reduced initialization times for sampled files from about 155 seconds to 8–13 seconds. The post explains how to resolve missing module errors, respect project-reference restrictions, and continue upward through the dependency graph while distributing migration work across teams.
Serve small with Fly.io and GoStatic
The post shows how to deploy a tiny static signpost site on Fly.io using GoStatic, with the aim of keeping the application’s footprint and running cost low. GoStatic is a self-contained web server that can run in a bare Docker image; the described image is 6MB, while the completed deployment reports 7.7MB. The setup uses fly init examplegostatic -p 8043, a two-line Dockerfile based on pierrezemb/gostatic, and an index.html copied to /srv/http/index.html; Fly routes ports 80 and 443 to GoStatic’s port 8043 and provides HTTPS. After deployment reaches one healthy instance, the post reduces the default micro-2x VM from 512MB RAM to micro-1x, which provides 128MB. This matches the small workload and is presented as a way to reduce running costs.
Hugo's There - Flying with Hugo and Caddy
A new community venture’s website is built with Hugo, served by Caddy, and deployed on Fly, with a custom makeroni.cc domain added after the initial deployment. The process initializes a Fly app on port 80, uses Hugo’s Quickstart and Ananke theme, and employs a multi-stage Docker build based on klakegg/hugo:0.74.0-onbuild, copying generated files into caddy:2.1.1. Caddy serves the static files with file_server while auto_https is disabled because Fly handles certificate management; separate rules serve makeroni.cc and redirect the old fly.dev hostname. DNS A and AAAA records connect the domain to Fly, and flyctl certs create requests a Let’s Encrypt certificate through DNS validation, leaving the site ready to serve securely after redeployment.
Run Apollo Server Close to Your Users
Run Apollo Server Close to Your Users presents an edge deployment pattern for GraphQL APIs. The post argues that, much like serving JavaScript and markup from a CDN, placing API servers and an application cache near users can improve application speed. Its approach combines Fly.io’s platform for running API servers close to users with a global Redis cache service, then uses Apollo Server’s cache capabilities and first-class Redis support. A demo GraphQL API built from the Open Library REST API accompanies the guide, with both a guide and source code available. The author frames the design through a newly adopted GraphQL perspective, emphasizing static typing and describing the resulting setup as CDN-like infrastructure for an API.
Top topics
- Architecture834
- Performance817
- LLMs673
- Machine Learning622
- Open Source568
- AI Agents564
- AI483
- Developer Experience448
Weekly digest
The best engineering reads, once a week.