There’s a clear problem with the current implementation of the tokenizer library: it only covers the happy code path. We’ve skirted the possibility of an error with all the calls to unwrap(). This is perfectly fine in unit tests, where failing fast is appropriate, but product code must handle errors gracefully — the subject of this post.
In some ways implementing Trie requires less proficiency with Rust than even singly-linked stack. A few auxiliary ideas are also discussed, like lazy instantiation and the difference between const and static.
Let’s organize some of the exercises into a library with the goal of learning how to build one. Although all the problems in Rust Dust would be candidates for a library distribution, it’s more straightforward to develop them as simple binaries. Except for those problems which I want to reuse elsewhere in the Rust Dust project — these are the ones included in Rust Dust Lib.
A safe, instructive, but rather impractical implementation of a doubly-linked list.
Rust Dust is my notes as I am learning Rust by implementing various common data structures. We start with a singly linked list, which supports pushing onto the head and popping off the head — a stack. It is significantly easier than a doubly linked list because each list node is pointed to by exactly one owner.
In their influential 2017 paper Aleksander Fabijan et al postulate the three paramount requirements for any experimentation service. I consider these in detail and see how Variant stacks up and even challenges some of the assumptions that seem inherent in these principles.
The experiment’s configuration, lifecycle, and runtime should be handled externally of the host application, leaving it completely unconcerned with those details. Moving experimentation-related details out of the host application’s domain achieves the complete separation of experience implementation (handled by the host application) and experiment instrumentation (handled by the experimentation server)—the holy grail of any successful experimentation framework.
The fundamental flaw of all existing commercial A/B tools is that they all started out as SaaS, which was a reasonable approach to the shallow experiments—their beachhead market,—but that architecture proved untenable when they attempted to extend down the host application’s stack. Without cogent support for full-stack experiments enterprise customers by enlarge opted to roll their own.
Although many tech-capable enterprises have been able to develop custom experimentation platforms, many tech-second companies have had to spend sweat and treasure on what are essentially stop-gap solutions. Here are the three principal reasons why implementing an A/B testing practice is a particularly gnarly problem to solve in the wild.
Scala programmers are in an advantageous position to learn Java quickly: they are likely to know a lot about the JVM and to have used Java’s standard library. This article is intended to help experienced Scala programmers to grasp Java’s key concepts quickly, by introducing them by analogy with the familiar Scala idioms.