Loading…
Browse by type
Explainer reads
Explainer posts on Yomu, summarised newest first.
- 1,318 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.
Explainer posts
Charting a path to AI accountability
Anthropic’s response to the NTIA’s Request for Comment on AI Accountability proposes processes and infrastructure for evaluating highly capable and general-purpose AI models. It recommends funding rigorous evaluations, requiring near-term disclosure of evaluation methods and results, and developing longer-term industry standards with agencies such as NIST. The framework would use capability-based risk thresholds, pre-registration of large training runs, confidential registries, technically literate and security-conscious third-party auditors, and external red teaming before advanced model release. It also calls for more interpretability research, acknowledges that regulations requiring interpretable models are currently infeasible, and seeks antitrust guidance for industry safety collaboration. Anthropic says these measures require collaboration among researchers, AI labs, regulators, auditors, and other stakeholders to build accountability and auditing mechanisms that support safe development and deployment.
Prompt design
The post argues that “prompt design” better describes prompt construction than “prompt engineering,” comparing it with web design. It frames prompts as clear communication with dynamic inputs that must adapt to changing content and context-window limits, then identifies shared practices such as inspecting rendered output, using composable declarative components, and pursuing precise formatting. For LLM agents, the analogy extends to interactive websites whose prompts re-render after function calls, although text-only output and caching constraints differ. This perspective motivates Priompt, a React-like, JSX-based library used internally at Cursor, with a preview site that renders prompts using real request data and serialized props; the author considers JSX more ergonomic than string templates while noting that model capabilities and platform abstractions may weaken the analogy over time.
The JavaScript Ecosystem is Delightfully Weird
The post explains why the JavaScript ecosystem is “delightfully weird,” arguing that its defining feature is not JavaScript’s oddness but the layers of transformation surrounding it. Bundlers first changed source boundaries by minimizing, tree-shaking, code-splitting, and producing executable files different from those developers wrote; CoffeeScript, Babel, TypeScript, JSX, Svelte, and esbuild extended that pattern. Frameworks and tools also make the ecosystem a “Big Tent,” allowing imports of CSS or PNG files and adding semantics outside ECMAScript, such as Svelte’s reactive labels and TypeScript annotations. React Server Components push this further: “use server” and “use client” are valid no-op statements whose placement changes code meaning, while RSC compiles into a stream of tagged JSON and depends on bundlers. The post presents this cooperation among languages, frameworks, routers, and bundlers—including the server/client interaction demonstrated in Dan Abramov’s React talk—as profound and beneficial, especially for geographically distributed application styles.
Next steps for Postgres pluggable storage
PostgreSQL pluggable storage would let different tables in one database use storage engines optimized for transactional, analytical, or archival workloads, while allowing developers to build engines in an extensions-like model. PostgreSQL 12 added basic support through refactoring and expanding table access method APIs, initially to enable ZHeap, whose undo log showed promising results and addressed long-term table bloat, but work on ZHeap and TAM appears stalled. The current API has important gaps, including limited index flexibility, all-or-nothing index updates, and row-version identifiers tied to block and offset numbers; available options such as Citus Columnar Storage remain constrained by these limits. OrioleDB's upstreaming has reduced its fork's patchset from about 5,000 lines in PostgreSQL 14 to about 2,000 for PostgreSQL 16, raising the possibility that required changes could land in PostgreSQL 17.
Identifying vulnerabilities in GitHub Actions & AWS OIDC Configurations
In 2021, GitHub released OpenID Connect support for GitHub Actions to let workflows retrieve short-lived cloud session tokens instead of storing static secrets. Tinder Security Labs discovered widespread IAM role misconfigurations that allow external repositories to assume target roles and access AWS resources. The primary issue stems from IAM trust policies that authenticate the GitHub identity provider but omit strict validation on the subject claim. Researchers located exposed role identifiers via public workflow searches and confirmed that arbitrary external GitHub Actions workflows could assume them, including roles within AWS official repositories. Remediation requires configuring trust policies to restrict the audience and validate repository namespaces, while unauthorized assumptions can be detected in CloudTrail logs.
Trusted Language Extensions for Postgres
Cloud Postgres providers often restrict extension installation until extensions are vetted, leaving some useful functionality unavailable on hosted databases. A Trusted Language Extension (TLE) is a Postgres extension written in a trusted language, allowing installation through pg_tle without placing code on the server filesystem. The source explains that conventional extensions may include SQL and functions implemented in languages such as C, while trusted languages follow PostgreSQL's security rules and cannot access raw process memory or system functions. AWS developed pg_tle, and collaboration with Supabase makes it available on Supabase and Amazon RDS for PostgreSQL 14.5 and higher; the dbdev registry can install packages such as langchain-embedding_search through SQL migrations. TLEs are presented as a way to distribute and iterate on trusted extensions without waiting for each cloud provider to preinstall them.
Creating a Flexible Order Routing System with Shopify Functions
Shopify’s smart order routing replaces a one-size-fits-all approach to choosing which inventory location fulfills an order with configurable routing rules. Rules can rank eligible locations by proximity to the destination, staying within the destination market, or merchant-defined location priorities, and merchants can arrange them in an order in the admin. Each rule is a Shopify Function written in Rust, receives data shaped through a GraphQL query, and returns location rankings; a reducer resolves ties by applying later rules to locations tied at rank 0. The rebuilt process uses the pipeline pattern to separate input preparation, rule execution, reduction, and final location selection, improving readability and debugging compared with the earlier tightly coupled implementation. This first stage dogfooded Shopify Functions on its own merchant stores, with a later stage planned to let developers add more complex rules.
Designing with AI: Generating unique artwork for every user
Supabase Launch Week 7 needed distinctive, shareable tickets that could improve on earlier Launch Week designs while keeping overlaid text readable. The team experimented with Midjourney prompts and blends, then chose minimalist purple swirls and a gold overlay approach after finding generated visuals too chaotic and direct gold prompting unreliable. For each ticket, a Supabase Edge Function retrieves a cached PNG from Supabase Storage or renders HTML and CSS into an SVG with Vercel’s Satori, layering backgrounds, a GitHub profile picture, and text before uploading the result with long cache control. A Postgres view selectively exposes ticket fields, calculates referral counts and marks a ticket golden when both Twitter and LinkedIn sharing have been detected, while row-level security protects the underlying email-containing table. Supabase Realtime then sends client-side updates so users can see progress and stop listening once golden.
How Migrating from Vanilla Redux to Redux Toolkit Improved State Management in Shopify POS
Shopify’s React Native Point of Sale team migrated its production state management from Vanilla Redux to Redux Toolkit (RTK) after developers found boilerplate and debugging difficult. They rejected a full rewrite in favor of incremental reducer-by-reducer conversion, allowing Vanilla reducers and RTK slices to coexist and limiting rollback and destabilization risk. Most reducers adopted RTK’s mutable syntax and generated action creators, while asynchronous logic retained a hybrid thunk approach because RTK Query did not support GraphQL and wholesale use of pending and fulfilled actions would split logic between thunks and reducers. The roughly three-month migration deleted 3,500 lines of boilerplate and was released gradually to production. The team also identified explicit TypeScript typing for dispatch, selector, and store hooks, plus dispatch().unwrap() for awaited calls, as important details, while atypical reducers were deferred to separate projects.
What Being a Staff Developer Means at Shopify
The post defines a staff developer at Shopify as an individual contributor whose scope and seniority can match a manager’s, while emphasizing that the role is a form of leadership rather than simply a more senior senior developer. Technical excellence comes from varied, challenging project experience, including large-scale systems, refactors, technology shifts, mistakes, and learning to choose appropriate solutions under constraints. The role also pairs with a team manager, translating product and business objectives into technical proposals, judging scope and infrastructure needs, finding recurring product problems, and saying no when effort does not match return. Its impact is measured partly through enabling others via reviews, mentorship, sponsorship, and support, leading to an adaptable leader comfortable with ambiguity whose responsibilities evolve with company needs.
Supporting Passkeys in Shop's Authentication Flows
Shop Pay and the Shop app began deploying passkeys in December 2022 across web and native app authentication, initially as an additional method for existing users and as a replacement for email and SMS verification. Passkeys use public-key cryptography: the private key remains on the device, while the service stores a public key, with platform or roaming authenticators providing options such as biometrics or hardware keys. Built on Ruby on Rails, Shop used webauthn-ruby to store a server challenge during registration, verify the allowed domain and challenge, and save the credential identifier; login looks up that identifier and verifies authentication while updating the sign count. The team also integrated passkeys into an iframe-capable login component for use across Shopify interactions, including merchant storefronts. Domain scoping, authenticator settings, challenge handling, Conditional UI, and cross-device interoperability are identified as important implementation considerations.
Unlocking Real-time Predictions with Shopify's Machine Learning Platform
Shopify’s Merlin machine learning platform was expanded to support online inference, allowing trained models to return predictions as input arrives rather than through periodic batch jobs. The design targets varied Shopify use cases and requirements, including support for TensorFlow, PyTorch and XGBoost, low latency, autoscaling, rolling deployments, observability and model updates. Each use case runs as a dedicated service on Google Kubernetes Engine, with a Python serving layer that loads models and artifacts, exposes an inference endpoint, and can use the Comet ML model registry and Pano feature store. Separate staging and production configurations let teams tune resources and test model versions before release; Shopify reports that online inference is providing the intended low latency, scalability and faster iteration, while ensemble inference, platform-based monitoring and continuous training remain planned areas.
Responsibly mid-size: What Matters, Suffers
Moving into a mid-size company requires adopting processes and attitudes piecemeal rather than suddenly operating like a large enterprise, while preserving the ability to deliver customer value. The post challenges “clean code” as a universal standard, arguing from Sandi Metz’s discussion of churn and semantic complexity that important, frequently changed files are often large and complicated, making “bad code” an emergent feature of successful systems. It also uses Joel Spolsky’s case against rewrites to explain that ugly code may contain accumulated fixes for real bugs and operating conditions. The resulting advice is to distinguish code that manages responsibilities from code that does not, develop engineering judgment, and avoid letting aesthetic reactions damage collaboration, team cohesion, or delivery.
Improving the Developer Experience with the Ruby LSP
The Ruby LSP is a language server intended to improve Ruby’s developer experience by providing editor features through the Language Server Protocol, without typechecking code or requiring type annotations. It targets performance and stability in Shopify’s Core monolith, where it must analyze thousands of files that may themselves contain thousands of lines, and is opinionated toward Ruby on Rails. The article explains LSP’s client-server model, in which editors exchange JSON requests and responses over STDIN and STDOUT, then focuses on nonpositional features such as Folding Range, including document synchronization and parsing. It also outlines future work on parallel request processing, codebase indexing, caching, and a plugin system for framework-specific capabilities such as Rails navigation and model information.
The Case Against Monkey Patching, From a Rails Core Team Member
The post argues that Ruby monkey patches—global changes to existing objects or libraries—should be used sparingly because they are brittle, dangerous, and often unnecessary. They can make Rails and Ruby upgrades harder by depending on private APIs, leave applications exposed to vulnerabilities if security fixes are not mirrored, and accumulate poorly documented technical debt. One Shopify example, activerecord-pedant-adapter, changes Active Record’s MySQL2Adapter so database connections report MySQL query warnings; upstreaming that behavior into Rails allowed the gem to be archived and the patch removed. The recommended alternative is to investigate whether an upgrade or documentation resolves the issue, fix genuine defects upstream, and, when patching is unavoidable, document and test it while maintaining a removal plan.
The 25 Percent Rule for Tackling Technical Debt
Technical debt is framed as four categories that need different responses: yearly debt may involve rewrites or gradual replacement, monthly debt requires team-sized planning, weekly debt can become a sprint card, and daily debt is code tidying during ordinary work. The article cautions that some apparent yearly debt reflects growth or changing markets rather than a past mistake, while smaller debt can be deferred only if it is recorded and scheduled. The proposed 25-percent allocation gives 10% to daily improvements, 10% to weekly work, and 5% to planning monthly and yearly debt, with the latter focused on prioritization rather than implementation. Its conclusion is that sustainable remediation depends on team culture: engineers need permission and encouragement to refactor, teams need space to schedule broader work, and leaders need to weigh costs and tradeoffs.
The Complex Data Models Behind Shopify's Tax Insights Feature
Shopify Tax’s Tax Insights feature provides merchants with state-level information about sales-tax liability and approaching liability, amid U.S. rules that vary by jurisdiction, product, threshold, and evaluation period. The implementation modified existing data models, added four new ones, and represented changing tax rules with lookup data containing valid_from and valid_to dates, including thresholds, date ranges, inclusions, exclusions, and inclusive or exclusive comparisons. Teams prototyped models in BigQuery SQL, implemented them in PySpark and Spark jobs, and combined merchant monthly taxable-sales aggregates with the rule model to evaluate economic nexus; the architecture moved source data through GCS and a warehouse into a final model. Each run publishes merchant-keyed insights to Google Cloud Bigtable, where the core application retrieves them for the frontend, while warehouse data supports analytics and other processes.
Carving The Scheduler Out Of Our Orchestrator
Fly.io describes why it is carving scheduling out of its existing Nomad-based orchestrator and replacing it with a simpler system centered on flyd and AppsV2. It first reduces orchestration to a client-server supervisor, then explains centralized scheduling: workers register resources, while a server filters candidates by constraints and ranks them. The proposed design avoids jobs sitting pending or being placed in nearby but incorrect regions; requesting VMs in MAD yields MAD capacity or nothing. Policy-heavy behavior such as deployment spares, crash recovery across workers, and regional decisions moves into flyctl and other platform components rather than the scheduler. Fly Machines already exposes APIs to reserve, start, and stop individual VMs, with Nomad still used in January 2023 and flyd expected for deployments in December 2023.
From Farmer to Security Engineer: How Dev Degree Helped Me Find My Dream Job
Cailyn Edwards recounts how she moved from leaving high school and running an organic farm to a career in infrastructure security through Shopify’s Dev Degree program. Before entering the program, she completed a horticulture co-diploma, finished high school and the required math courses, and pursued computer science while needing to pay her mortgage and maintain work-life balance. Dev Degree’s training path and rotating placements exposed her to computer science fundamentals, pair programming, Ruby on Rails on the orders team, infrastructure security, and network foundations, leading her to discover a strong interest in cyber security and cloud infrastructure. After graduating in September 2021, she joined Infrastructure Security full-time and later reports projects, internal security talks, a promotion to Senior Infrastructure Engineer, and Kubernetes contributions including a contributor award.
How Good Documentation Can Improve Productivity
Internal documentation is presented as a productivity and scaling tool for engineering organizations, especially as people move between teams, projects, or companies and remote work makes writing a default channel for knowledge sharing. Shopify’s approach combines standardized writing practices with three primary locations: Markdown microsites built with Docusaurus, internal GitHub for issues, READMEs, setup guidance, and searchable code, and the Vault, a GitHub- and Markdown-powered source of contextual information. The article argues that documentation should be treated as a product: it should be searchable, user-friendly, kept fresh, integrated into CI/CD, and hosted where engineers already work. It also recommends making writing routine through small contributions, paired writing, peer review, and audience-aware context, concluding that accessible documentation speeds onboarding, reduces duplicated problem-solving, supports asynchronous and cross-team collaboration, and improves developer literacy.
Top topics
- Architecture830
- Performance812
- LLMs648
- Machine Learning617
- Open Source561
- AI Agents542
- AI454
- Developer Experience446
Weekly digest
The best engineering reads, once a week.