Things I’ve learned, Places I’ve gone, Food I’ve eaten
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.
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
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.
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
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
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!"
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
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 ["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
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.
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
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.
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
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
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
And many more!
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.
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.
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
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?
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
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
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
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
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
which is amazing even if you’ve never written a line of Ruby in your life.
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.
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
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:
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.
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