Conference & User Group Presentations

Redis is best known as a high-performance, in-memory, key-value database used for distributed caching. However, data structure databases like Redis, Valkey, and Dragonfly can do so much more than just operate on string values! With over a dozen different data types like hashes, lists, sets, sorted sets, bloom filters, and streams, these databases provide a number of tools that can help solve common problems.

We'll explore these basic data structures in Redis OSS Compatible databases, with real-world examples of using them to solve problems like rate limiting, distributed resource locking, and efficiently checking membership in massive sets of data.

We'll also discuss some of the newer functionality designed for AI and LLM applications, like vector similarity searches and vector sets.

It's easy to tell when peer code review fails: a trivial change is blocked with a dozen comments; a massive pull request gets approved with just "LGTM"; a production-breaking bug slips through; a comment is taken personally and affects the team dynamic. Reviewing code written by someone else is a skill that needs to be developed with practice and effort. The increasing adoption of AI as assistant, author, and reviewer has introduced new challenges and complications to the code review process.

We will cover practical, real-world strategies for successfully reviewing code, regardless of whether it was fully handwritten or generated by AI, including:

• Reviewing changesets deliberately instead of just reading them
• Approving/blocking pull requests systematically
• Writing constructive comments about the code and not the developer
• Leveraging pair peer code reviews for reduced turnaround time
• Making the review process beneficial to both the author and reviewer
• Safely outsourcing parts of the code review process to AI and other tooling
• Reviewing code written in an unfamiliar programming language pragmatically

Running open-weight AI models locally as a hobby often begins innocently enough. You download a small model, ask it a few questions, and think, “That was neat.” A few weeks later, you are comparing quantization formats, benchmarking tokens per second, explaining to your family why the house is warmer than usual, and trying to convince your boss that the super-high-end gaming GPU is a critical business expense.

Local model inference is more than another hobby for nerds. It has a real place as part of a developer's toolkit, in addition to frontier cloud models from Anthropic and OpenAI. Frontier models remain the best choice when a task is urgent, difficult, or critical, but not every workload needs to be sent to a remote service. Open-weight models running locally can handle the low, slow, and long work: background agents, code analysis, document processing, experimentation, embeddings, reranking, and tasks that benefit from privacy, predictable costs, or simply being allowed to run for a very long time. Additionally, working with AI models locally helps to build a next-generation skill set that will matter increasingly across the software industry.

In this talk, we'll explore how to get started without spending a fortune, how to choose models and runtimes, and how to balance quality, speed, memory, context length, and concurrency. We'll also look beyond the model itself to the surrounding infrastructure: OpenAI-compatible APIs, routing, observability, and specialized models. We'll also consider the relationship between open source and open weights. If developers care about understanding, modifying, and controlling the software they depend on, then the same questions increasingly apply to the models powering their toolchains.

You do not need a data center, a research budget, or permission to expense a suspiciously large GPU. You can start small, learn the fundamentals, and gradually build local inference into a useful complement to cloud AI. Come for the practical guidance. Stay because you, too, may soon have strong opinions about four-bit quantization.

Dead and outdated code is a stumbling block to upgrading, refactoring, and maintaining any software project, and at worse could become a security vulnerability. As a rule, we want to remove code and dependencies that just don't belong in the code base anymore; however, it's not always clear if and when dead code is really dead. Removing "zombie" code can be disastrous if it is still being used in production.

We'll cover common ways to statically identify dead code, and the accompanying pitfalls. We'll then cover creating and using code tombstones in our project to definitively identify the living dead. Finally, we'll discuss some best practices to avoid having zombies in your code in the first place!

Thanks to the ubiquity of Composer, a PHP application may depend on dozens of third-party packages, each of which will have their own recursive dependency requirements. The aggregated version constraints of all these packages restricts your ability to add or upgrade any other dependency, including PHP itself. The more dependencies we have, the more likely we are to encounter version conflicts because of packages becoming abandoned, adding or dropping constraints, or requiring incompatible dependencies. It can be especially problematic when a critical package does not have a release that supports both your current and target PHP versions.

Luckily for us, Composer is more than just "install", "require", and "update", and we can use some of the lesser known functionality and behavior to untangle the web of conflicts and create a forward-friendly migration path.

In January 2020, I delivered a conference talk titled "Enums: The Missing Data Type", which ended on a sour note: PHP probably would not have a native type for handling enumerations any time soon. To my surprise and delight, PHP 8.1 would release with a new "Enum" type less than two years later.

We'll cover how representing things like statuses with enums improves immutability, readability, and type safety; the different types of enums available to us; and the most common questions about PHP enums.

If you work in a codebase where you can tell who wrote a particular block of code just by looking at it, this talk is for you.

Whether your team consists of one developer or many, establishing and maintaining coding standards is essential for creating code that is easy to read, understand, and maintain. A truly effective coding standard encompasses much more than enforcing "tabs versus spaces" rules.

We will discuss practical methods for identifying, formalizing, and enforcing these standards, including how tools like PHPStan can automate enforcing more complex conventions.

Are you stuck with a legacy monolithic codebase and wish you could be working on microservices backed by a modern PHP framework? Learn how to use your existing code, conventions, and experience as fertilizer for greenfield projects, providing a path to pay down technical debt.

This talk explores how you can leverage the PHP ecosystem to build a lightweight, custom framework tailored to your team's conventions and needs. By extracting reusable, tested functionality into Composer packages, you get an immediate foothold for creating new projects.

In an ideal world, every PHP class would rely exclusively on interface-defined dependencies injected at runtime through a service container. However, we have to work with existing codebases burdened by hard-coded, tightly coupled dependencies.

This talk dives into practical strategies for leveraging dependency injection to incrementally refactor legacy PHP applications, including the Builder, Wrapper (Proxy), and Adapter patterns.