When test-driving your code, you shift between red (write a failing test), green (write the code needed to make the test pass) & refactor (clean up). But how do you kickstart this loop? What heuristics can you use to guide selection of the next test you write? This article summarizes the most common heuristics and highlights the one I use predominantly:
Continue readingPick the test that forces you to add one (and only one) new facet.
Jupyter notebooks have been a thing for a while now in data science communities. Recently I wanted to take a look at how to set these up with support for the F# programming language. While there is some documentation out there, I quickly got lost in a plethora of alternative tools and out-of-date documentation. This walkthrough will get you up and running with F# Jupyter notebooks online and in your vscode editor in no time!
Continue readingThis weekend I had the opportunity to visit my favorite work event of the year: a socrates unconference. This is a quick brain dump of the things I learned in sessions, hallway discussions or over a drink. My goal is not to give a full overview of the topics covered during the sessions, but rather showcase what a typical day at a Socrates unconference could look like in case you are on the fence about attending one in the future.
Socrates unconferences use the open space format, this means that there is no predefined schedule. People just show up & share their own ideas for sessions in the morning. After some self-organization we end up with the schedule for the day. The next day this pattern repeats. It’s amazing to see how sessions and discussions during the first day often result in totally fresh session proposals the second day.
Continue reading
We need to talk about refactoring. Or rather, about the frequent misuse of the word, the dangers this encompasses and what we can do about it. Time to reclaim what is an intrinsic part of software development!
As with many words in the English language, people use the word refactoring for different concepts. It’s a human thing to do, but it keeps surprising me how open for interpretation most terms are in a “scientific” field like computer science. Just try to Google an exact definition for the concept of a unit test: you’ll find about as many interpretations as there are people writing about it.
This post highlights an F# feature called type providers that makes my life as a software developer easier. Ever had to parse some JSON? Explore a shiny new REST API? Maybe you’ve had to quickly try out an undocumented SOAP service?
Imagine you could talk to any kind of service or interact with any kind of data in your regular IDE, using the full capabilities of a static type system with minimal fuss. No need to generate proxy client code from .wsdl files, no need to reference any Nuget package. With some help from F#’s type providers, It just works™!
I’ve been looking to introduce F# in my daily workflow. As a consultant, I often don’t get to pick the programming language I work in. As a result, my experiences with F# are limited to side-projects or throwaway code that doesn’t get committed to version control. One area where F# and its ecosystem are really practical and even outperform alternatives is in exploring data and services, both in the broad sense of the term. Say you have to integrate with a third party REST API that provides little-to-no documentation. F# provides a magical feature called type providers that allows you to explore this API with static types, minimal fuss, and all the features you’ve come to rely on of your trusty IDE. It’s the perfect way to get started with functional programming in a .NET environment.
jvaneyck 