Programming

Data-Driven Code Generation of Unit Tests Part 3: Java, Maven, StringTemplate, JUnit

Data-Driven Code Generation of Unit Tests Part 3: Java, Maven, StringTemplate, JUnit

This post is part 3 of my series about data-driven code generation of unit tests. This blog post explains how I used Java, Apache Maven, StringTemplate, and JUnit to perform data-driven code generation of unit tests for a financial performance analytics library. If you haven’t read it already, I recommend starting with Part 1: Background. As mentioned in Part 2: C++, CMake, Jinja2, Boost, all performance analytics metadata is stored in a single file called metadata.
Data-Driven Code Generation of Unit Tests Part 2: C++, CMake, Jinja2, Boost

Data-Driven Code Generation of Unit Tests Part 2: C++, CMake, Jinja2, Boost

This post is part 2 of my series about data-driven code generation of unit tests. This blog post explains how I used CMake, Jinja2, and the Boost Unit Test framework to perform data-driven code generation of unit tests for a financial performance analytics library. If you haven’t read it already, I recommend starting with Part 1: Background. All performance analytics metadata is stored in a single metadata file called metadata.csv. This file contains the complete list of calculations, and for each calculation, its settings (i.
Data-Driven Code Generation of Unit Tests Part 1: Background

Data-Driven Code Generation of Unit Tests Part 1: Background

This post is part 1 of my series about data-driven code generation of unit tests. At Morningstar, I created a multi-language, cross-platform performance analytics library which implements both online and offline implementations of a number of common financial analytics such as Alpha, Beta, R-Squared, Sharpe Ratio, Sortino Ratio, and Treynor Ratio (more on this library later). The library relies almost exclusively on a comprehensive suite of automated unit tests to validate its correctness.
Future (circa 2010) Parallel Programming Models

Future (circa 2010) Parallel Programming Models

Joe Duffy regularly posts amazing material which is well ahead of our time, such as his current blog post series about Midori. I’d like to call out this particular assertion made by him way back in 2010: [D]evelopers must move towards single-threaded programming models connected through message passing, optionally with provably race-free fine-grained parallelism inside of those single-threaded worlds. Add “async/await everywhere” and you can sign me up!
Threading is a Poor Concurrency Programming Model

Threading is a Poor Concurrency Programming Model

Here’s why I try to avoid thread-based programming models for expressing concurrency: The opponents of thread-based systems line up several drawbacks. For Ousterhout, who probably published the most well-known rant against threads [Ous96], the extreme difficulty of developing correct concurrent code–even for programming experts–is the most harmful trait of threads. As soon as a multi-threaded system shares a single state between multiple threads, coordination and synchronization becomes an imperative. Coordination and synchronization requires locking primitives, which in turn brings along additional issues.
Exploring the .NET CoreFX

Exploring the .NET CoreFX

This is my exploring the .NET CoreFX post series Annotate Pure Methods With PureAttribute Cache ThreadLocal Variables in Locals Making Methods Debugger-Friendly The Requires Convenience Class Keep Indexers Trivial to Allow JIT Optimization Use IEquatable for Higher-Performance Equals() Reference Versus Structural Equality NullReferenceException Performance Tricks Immutable Collections and the Builder Pattern Performance Tuning Enumeration Code Contracts Aggressive Inlining ImmutableList is an AVL Tree Inside Immutable Collections Using Non-Generic Factory Classes to Enable Type Inference Platform-Specific Builds Using Compile-Time Polymorphism Videotaped API Review
Exploring the .NET CoreFX Part 16: Platform-Specific Builds Using Compile-Time Polymorphism

Exploring the .NET CoreFX Part 16: Platform-Specific Builds Using Compile-Time Polymorphism

This is part 16 of my Exploring the .NET CoreFX Series. While .NET has historically been limited to Windows machines, Mono notwithstanding, the introduction of the cross-platform .NET Core runtime has introduced the possibility of running .NET Core applications on Unix machines. With this possibility, developers may have the need of writing platform-specific code. One way to write platform-specific code is: Define a conceptual base class which will have an identical name and methods across all platforms.
Exploring the .NET CoreFX Part 15: Using Non-Generic Factory Classes to Enable Type Inference

Exploring the .NET CoreFX Part 15: Using Non-Generic Factory Classes to Enable Type Inference

This is part 15 of my Exploring the .NET CoreFX Series. While C# supports type inference for generic methods, it does not support type inference for constructors. In other words, while this code works: public class FooFactory { public static Foo<T> Create<T>(T value) { return new Foo<T>(value); } } var myObj = FooFactory.Create(212); This code does not: public class Foo<T> { private readonly T field; public Foo(T value) { field = value; } } var obj = new Foo(212); // DOES NOT WORK For more background on why this is, see this StackOverflow post.