Things I’ve learned, Places I’ve gone, Food I’ve eaten

about me

I’m a product of the late ’80s and early ’90s. After studying Marketing and Spanish at the University of Florida, I deceided to move across the pond to Deutschland where I discovered the joys of programming. Now I work at 6Wunderkinder in Berlin. Besides the obvious (long walks on the beach, sunsets, etc.) I like to code, cook, and travel.

recent public projects

Status updating…

find me

contact me



- -

Working in a startup is a perfect opportunity for learning. There is never a lack of opportunity to learn about software engineering, marketing, finance, and more. But even in such an environment, it’s easy to get trapped in a bubble leaving you blind to how else things can be done. Luckily working in Europe I’ve had the opportunity to visit startups in many countries.

Soon I’ll be making a trip to the unofficial Mecca of startups, Sillicon Valley, for the first time. The things (both positive and negative) I’ve heard about the valley are enough to make me very interested in what I’m about to see. The following are just a few of things I’m looking forward to learning more about while in the Valley.

  • Engineering at Scale: The scale we’ve reached at Wunderlist is nothing to laugh at, but we don’t even come close to the likes of companies like Twitter and Whatsapp. What are some of the issues companies with hundreds of millions of users face?

  • Rust: I’ve also become very interested in new programming languages such as Mozilla’s Rust programming language. I hope to meet some others in the area that are actively working on the language.

  • Daily Operations: I would also like to see how Silicon Valley companies operate on a daily basis. Seeing pictures of certain offices in the Valley makes some stories of excess very easy to picture. How does this manifest itself in the day-to-day? What are the opinions on those that work in these offices with regard to elaborate offices and lavish amenities?

  • Different Software Domains: Finally I hope to branch a bit out of niche of tech I normally find myself in. While many Silicon Valley companies work on consumer apps for mobile and desktop built around RESTful web APIs just like we do, I hope to meet others working on different problems using different technologies. I hope to meet those working on such things as software for NGOs, difficult machine learning problems, software for different hardware such as wearables and more!

If you’d like to hear about the problems we’re solving at Wunderlist or what it’s like working in Europe, feel free to message me on Twitter!

What’s All This Fuss About Monads?

- - posted in fp, functional, monads, programming

Despite Functional Programming’s (FP) growing popularity, for many “normal programmers” the language family seems to be merely an academic exercise that they are neither capable of or willing to engage in. Despite there being many FP languages that are arguably much more accessible than some “normal” programming languages like C++ (e.g. Elixir), FP does at times have some concepts that remain fuzzy even to those who have programmed before in the functional style.

Perhaps no concept breads more fear in the hearts of aspiring functional programmers than that of the monad. In this series of posts, I’ll try my best to explain what a monads are and more importantly, why they’re awesome.

This won’t be a formal attempt at defining monads but rather a practical look at the expressive power they give the programmer using them. In other words, if you’re looking for some category theory, look elsewhere.

No PhD Required

In order to get the most out of this article you should be somewhat comfortable with the basic tenants of functional programming (especially first class functions), and you should feel comfortable with static typing. Don’t worry though. Even if you’ve never touched a FP before, you should still be able to get something out of this too.

Our Journey

On our road to understand what the heck a monad is we’ll also be getting to know other concepts with seemingly scary names like functors, applicative functors, and monoids.

Accompanying us on our journey will be the Haskell programming language. Don’t worry if you’ve never programmed in Haskell, I’ll try to explain everything you need to know along the way. Also, this will not be an academic explanation of what a monad is. If you’re looking for your answers based in Category Theory, you’ll have to search elsewhere.

Yo Dawg. I Heard You Like Values…

Before we get started, it’s best to look ahead to where we are going. Haskell is very statically and strongly typed. "hello" is a String and 1.0 is a Double. When we declare functions we will specify exactly the kinds of types that we will alow to be passed into and returned from our functions. The compiler will make sure we keep this in mind the entire time we program.

Haskell’s type system is in fact more pervasive than perhaps you’re used to in other languages like Java. Even actions which have side effects (e.g. printing something to the screen or making a network call) have special types.

Let’s start with a simple value:

ghci> let myString = "Hello, World!"
"Hello, World!"

If we ask Haskell the type of the value myString:

ghci> :t myString
myString :: String

We see that it is indeed a String. By now you should be saying, “Wow this Haskell thing is easy!”. Haskell’s type system let’s you do more than just have types like Strings, Chars, and Integers. In Haskell you can also have types that are part of the Monad type class. Monads let you have values that are wrapped in a context. This context tells you more about the plain value inside.

Let’s take a look at an example to clarify.

Haskell has a type called Maybe which is part of the type class Monad. Maybe wraps another type (like a String or Integer) and gives it a context (or more information) about that plain type inside. What context does Maybe give?

Maybe tells us that a value is either there or it is not. In other words, we maybe have a value.

Here are three instances of the Maybe type:

Just 5
Just ["Hello", "World"]

The first two values tell us we do indeed have values, the Integer 5 in the first case and the list of Strings “Hello” and “World” in the second case. The third value says we have nothing at all.

Scala (another FP style language) has a similar type called option that looks like this:

Some 5
Some ["Hello", "World"]

We either have some of something or none. The Maybe/Option monad gives us the ability to say we have some sort of value or we do not.

Get Func-y

Of course, these values in isolation don’t do us much good. Of course, if we manually write out the value Just 5, we know that we have the Integer 5. Things become much more interesting when we have functions.

So let’s say we have a function (which we’ll call myFunction) with the following type signature:

myFunction :: Integer -> Maybe Integer

This says that the function myFunction takes in an Integer as its only argument and returns a Maybe Integer.

So we, and the compiler, know that when we pass in an Integer to myFunction we “maybe” will get an Integer back. Depending on our input we can get back out something like Just 5, or Just 49283 or even Nothing (which, of course, is different than Just 0).

The Maybe monad is often used where in other languages we would use the value nil (or null). However, for reasons that we will explore later, the Maybe monad allows us to do the same sort of things we would do with nils without having to always do nasty if nil checks. The compiler guarantees that you’ll never have any undefined method 'foo' for nil type errors again.

Not only can we avoid nil checking, but the compiler will catch any mistakes we make at compile time.

Other Monads

So we now have a monad that gives a wrapped value with the context of either being there or not. Just "Hello" or Nothing. What other “contexts” can we wrap values in?

  • IO – IO wraps a value in a context where side effects (the bane of functional programming) can take place.
  • Writer – Writer Wraps a value in the context of having another value that acts as a “log”. This is often used to log the intermediate steps of a function.
  • List – Yes, List, the data structure backbone of almost all functional programming, is a monad with the context of having many values or having none at all.
  • And many more!

What’s Next

Now that we know where we’re headed, we’ll start next time looking at two concepts central to monads, functors and applicative functors. All monads are both functors and applicative functors so understanding both will get us much closer to understanding monads.

Disciplined Yak Shaving

- - posted in learning, tips, yak-shaving

Being productive is more popular than ever. Everyone wants to get more and more done in less and less time. And no wonder. Getting things done feels really good.

Yet, “getting things done” is not always the best way to spend our time. yak shaving, done in the right way, can also be a good way to spend time.

Here are some reasons why I find disciplined yak shaving to be a good thing and some things I’ve learned along the way about how to do it well.

Edifying Yak Shaving

When I was learning how to program, I often felt overwhelmed by the amount of information that was available about programming and computer science. Instead of picking one area to stick to and focus on (e.g. rails development), I started down a path of yak shaving.

I learned a little about Rails, which led me to learn more about Ruby, which then led me to look into C (on which Ruby is built). Before I knew it, I was looking a bit into programming language interpreters.

Of course, one doesn’t need to know anything about the Ruby interpreter to be an expert Rails developer. And many would even argue that learning such things only serves as a distraction. However, when I then went back to Rails I found things easier to understand. I was not only able to achieve this because my time in Ruby land had taught me what a “@” really means, but also because the edges around what I was learning became clearer.

Through my deliberate yak shaving distraction, the distracting “great unknown” at the boundaries of what I learned faded away.

While the uneasy feeling that comes with “just not knowing” would come back, the peace that deliberate yak shaving had afforded me allowed me to learn more effectively.

Self Improvement Yak Shaving

We tend to stick to what we know. Now that I’m beyond being a beginner, I’ve noticed that if I wanted to, I could get by just fine on what I already know. However, anyone who enjoys what they do (as I do programming) knows that this just won’t cut it.

Reading books and listening to podcasts are some ways to further yourself, but often times the best way to learn new things is to go on a good ol’ fashion yak shave. Put yourself in the middle of an area where you “shouldn’t be” and force yourself to learn your way out.

Careful Yak Shaving

Yak shaving can get dangerous. Obviously, it’s important to know when not to start yak shaving. Don’t, for example, go on a great yak shave while the servers you’re in charge of at work are on fire.

However, it’s equally, if not more, important to know when to stop yak shaving. In order to reap the benefits of an edifying yak shaving you need to return to the original task at hand. Stay too far away and you may never get back.

Also, knowing the limits of where you think the yak shaving should take you is very important. You don’t want yak shaving to become an extremely tedious or frustrating activity. If you feel overly frustrated, you’ve gone too far, and you’ll kill the motivating experience that yak shaving can be.

So I suggest giving a yak shave a go. See how long you stick to each part of the yak shave. Do you spend too much time on one thing so that you’ve forgotten how and why you got there? Do you spend too little time and fail to appreciate what you can learn at each step?

Happy Yak Shaving!

Erlang Is the Most Object Oriented Language

- - posted in erlang, functional, object-oriented, oo, paradigms

Here’s an idea: Erlang is the only true object oriented language in use today.

You might be thinking “WATTTT, that doesn’t make any sense”. But bear with me. Let’s examine this idea a bit and see where it takes us.

Functional Programming and Object Orientation

Often when you ask programmers what the opposite of functional programming is, they simply reply “well, object oriented programming, of course!”.

Unfortunately, this isn’t true. Object orientation and functional programming are orthogonal to one another, meaning, in more layman’s terms, that you can have your cake and eat it too. A language can be both object oriented and functional. While most functional languages do not implement an object system, Scala and F# are both popular languages that attempt to combine the two paradigms.

Functional programming at its core cares about concepts such as immutability and first class functions which are not incompatible with object orientation.

So Erlang is not excluded from the realm of object orientated languages simply due to its functional nature. In order to see how Erlang fits into the world of object orientation we need to examine what exactly OO is.

What is Object Orientation?

Wikipedia’s explanation of object orientation uses terms such as “object”, “instance”, “attributes” and “methods” to describe object orientation. Such terms feel very familiar to Java and Ruby programmers. However, to truly understand what OO is, we’ll go the source, the man that coined the term, Alan Kay, one of the inventors of the Smalltalk language.

According to Kay, OO is only about message passing and isolation and protection of state.

Concepts such as classes and objects are only an attempt to implement the ideas above. The over emphasis on classes and objects at the expense of message passing has led many “OO” languages to stray from the core concepts of object orientation stated above.

As Kay puts it, the spirit of OO dies when people stop thinking about objects and the messages they send between each other and start thinking merely about “remote procedure calls”.

Where does Erlang fit in?

If we take Alan Kay’s definition of object orientation as canonical, then Erlang fits almost perfectly. Instead of “objects” per say, Erlang uses “processes” that are fully isolated constructs that can only communicate with each through message passing.

Unlike objects in Java, Ruby or other so-called “object oriented” languages, Erlang processes are fully isolated from one another, so much so that catastrophic failure in one process does not spell disaster for all the others.

Since these processes are fully isolated, they cannot share state and are forced to explicitly send messages between themselves to get things done.

Erlang is perhaps the only language that truly embraces the ideas that Kay puts forth as essential to object orientation: message passing and isolation.


Whether you think the argument above is convincing or a big pile of crap, I hope you take away the idea that perhaps what we all think of as object orientation perhaps isn’t OO at all at least not how it was originally conceived.

The next time you’re writing Java, Ruby or whatever OO language you use, stop to think about how you can mold your code to be more like what Alan Kay originally envisioned.

To see how this can have a real, practical impact on the code you write, I recommend Sandi Metz’s book Practical Object-Oriented Design in Ruby which is amazing even if you’ve never written a line of Ruby in your life.

ActiveRecord Connections: A High Level Overview

- - posted in activerecord, code-walkthrough, rails-4.0

So, you feel pretty comfortable writing Ruby on Rails applications. Connecting to one (or more) databases and doing complex queries on complex relations doesn’t faze you one bit. But it bothers you that you don’t know more about how it works “behind the scenes”.

Today I’ll be starting the first in a series of posts on the internals of ActiveRecord, the part of Rails that allows us to connect to relational databases. This post will focus on the basics of how ActiveRecord establishes a connection.

When getting to know the internals of ActiveRecord, there’s no substitute for reading the source code, but sometimes having some direction can certainly help. After reading and following along, I encourage you to read through the comments left by the Rails developers. They’re quite clear and answer a lot of questions.

Where to Begin?

When poking around ActiveRecord, a good place to start is in our old friend ActiveRecord::Base located in the base.rb file. ActiveRecord::Base has a nice overview of ActiveRecord features in the comments. The actual code is just a long list of modules included and extended into the class. We see familiar faces such as “scoping”, “Validations”, “Callbacks” and a whole lot more.

Our next step will be into the ConnectionHandling module where, you guessed it, database connections are handled. ActiveRecord::ConnectionHandling is what gives our model classes such handy methods as .establish_connection, .connection_pool and .connection_config.

General Concepts

Before we get into more details, it’s important to know generally how ActiveRecord connects to databases. ActiveRecord uses either a hash or url describing how it should connect. By default Rails applications will specify this information in the config/database.yml file, which gets read during Rails initialization and passed to .establish_connection.

ActiveRecord uses the idea of a connection pool that coordinates threads’ access to a limited number of database connections. The connection pool is smart and will allow only one thread per database connection. Once a thread is done with a connection it will free it up for other threads to check out the connection.

ActiveRecord also offers a connection reaper that acts to garbage collect old connections. Since this is turned off be default, we won’t cover it here.

Basics of .establish_connection

For those not following along, .establish_connection looks like this:

def establish_connection(spec = ENV["DATABASE_URL"])
  resolver = ConnectionAdapters::ConnectionSpecification::Resolver.new spec, configurations
  spec = resolver.spec

  unless respond_to?(spec.adapter_method)
    raise AdapterNotFound, "database configuration specifies nonexistent #{spec.config[:adapter]} adapter"

  connection_handler.establish_connection self, spec

First, the method gets a connection specification resolver that simply is able to parse the various forms of database configs you can throw at it (e.g. hash, url, etc.). Then a specification object is returned that embodies the spec of how ActiveRecord will connect to the database. This object gets passed around a lot so ActiveRecord knows what to do.

Many terrible spellers (myself included) will notice the check for the response to #adapter_method, which raises if a non-valid database adapter such as “postgrsql” is given.

Next ActiveRecord removes any connection the model has to a database, before then connecting to the specified database.

Wrap Up

This concludes our first look at ActiveRecord interals with a very high level look at how ActiveRecord connects to databases. Next time, we’ll dive a little deeper into database connections with a look at database adapters and more on connection pools.


- -

Fear is something that we all experience. Generally when we think of fear, we conjure up stereotypical images of snakes or serial killers in our minds. And it makes sense that this would be our go-to definition of fear. We tend to remember things that are out of the ordinary, and the truth is that the fear the some homicidal manic invokes in us is much more unique than the fear that we experience on the daily basis.

But it is not this fear that poses the greatest danger. Rather it is the fear that creeps into your mind when you’re at work or on the bus ride home – the fear of the unknown, of what will come tomorrow, next week, next year.

Having spent the last year and a half in an industry of which I knew little about when I started, I’ve experienced these feelings often. It’s not to say that these feelings weren’t juxtaposed with feelings of elation or self discovery, because they most certainly were. However, the one thing that has held me back and prevented me from reaching my full potential has been the little feeling of fear in the back of my mind.

When I sit at my desk wanting to work on a new project using some technology I’ve never used before or when I think of who I can be in 5 years, fear begins to creep up on me. “I don’t know what I’m doing”, “what if I can’t finish?”, “am I even good enough?”. All these questions begin to form in my head.

However, over the past year and a half, I’ve made a conscious effort to fight these feelings. I’ve learned you must ignore such thoughts, or they will consume and paralyze you. When you’re contemplating whether you can finish a project or even make a career change, make absolutely sure that any reasons you have for doubting whether you can or should pursue your goal are founded in fact and outweigh the potential rewards you stand to reap. Don’t stop yourself just because you fear the unknown or just because you doubt yourself.

Go for it.