DEV Community: Filip Defar

My love-hate relationship with side-projects

Filip Defar — Sat, 10 Aug 2019 07:06:48 +0000

I've got a folder on my laptop that's quite a sad sight. You can find a bit of everything in it: an unfinished Haxe game, few browser plugins, a bitcoin trading bot, an attempt of writing a Go web application, and much more. It's a graveyard for all of my abandoned side-projects.

These abandoned projects are a result of what I call a 'side-project fever'. I first noticed this pattern during my stay at a co-working space that was mostly used by local startups. Compulsive starting of projects, being obsessive about them for a short while - just to completely abandon them afterward is all too familiar to me. At one point it got so far out of hand that a strict "no side-projects" rule had to be introduced in our co-working office - we were just wasting too much time on this dead-end work. I ended up breaking that rule a lot.

I've been aware that this behaviour is futile, and I was doing it anyway. It's not surprising that I started to wonder: am I sane? Why do I spend hours upon hours working on projects most of which never see the light of day? How many hours have I wasted on these projects that in the end didn't accomplish anything?

You might argue that I have learned a lot while working on them - and you would be right. But aren't there better ways to learn advanced programming techniques? For example: getting involved in a popular open-source project. Not only would I get an opportunity to learn from more experienced developers, but it would also look better on my CV and I would make valuable contacts. My main drive in starting these projects is not an urge to learn.

I love stories. I sometimes get inspired by a story of someone turning their side-project into a profitable business. They make it look fun. And like a child that just watched a movie, I want to emulate my hero - I want to go through all the troubles and end up victorious on the other side.

These stories can also make me question my self-worth and build a lingering feeling that normal career is not enough. That I must run my own business to be fulfilled.

Other times it's the pressure and stress of the day job that pushes me into starting a side-project. I use a side-project as an escape from the problem I'm currently supposed to be solving. It's a bit more productive variant of procrastination, so instead of wasting time on social media, I delay one programming problem by solving another one.

There's irresistible ease of starting a greenfield project, especially in an exciting, cutting-edge technology. It's easy to imagine that the project you are building on your own terms is going to be perfect, and the development process will be easy and stress-free.

And this is the reason why it's a lot easier to start a side-project than to get involved in an open-source project. The initial effort to start your own side-project is a lot lower than to break into open-source.

But soon this ease fades as reality kicks in. The beautiful greenfield project starts to get complex. I add a quick hack or two just to get that new feature done. Technical debt starts to accumulate and soon the project is not that fun to work on anymore.

I effectively created a second day-job for myself. Except that for this one I'm not getting paid. I start wondering how much money I could make if I spent all that time on client work?

This builds pressure to make the project profitable. It turns out that this is extremely hard, and it requires skills that have nothing to do with programming. The combination of endless hours working on a side-project combined with the day-job becomes stressful, and that's when it stops being fun.

So the side-project becomes a giant waste of time, money and a great source of stress, so why keep bothering with it? And that's how another project dies.

But what if everything goes right and a side-project becomes profitable?

By some wonder, I managed to make this happen with one of my projects. First payments started to roll in, and now I'm officially running a profitable business. Slightly profitable - but profitable.

It turns out that even when the project is profitable, it's not as fun as I have imagined. It's extremely exciting when things go right, and extremely stressful when thing are going bad.

But my main problem was having wrong expectations of what running your own business is like.

I thought that being my own boss means spending all day solving fun programming problems in an amazing technology that I love. Instead, I spend most of the time thinking about how to sell stuff to people. And I do not like selling stuff to people.

I foolishly believed that running my own business would create a stress-free job. Ironically, by doing this, I've made my life more stressful.

Instead of spending my free time with my friends and family, and reducing stress, I've been chasing a carrot-on-a-stick promise of stress-free life in the future.

So after tremendous effort and years of work, dozens of abandoned project I finally managed to create a profitable business - that I hate.

This made me realize that every job involves solving problems, and solving problems is always to some degree stressful. No career is stress-free and the only thing we can choose is the kind of problems we solve.

I love software development. I've been doing it for over a decade before I started earning any money off it. This is the kind of problems that I want to solve and I'm incredibly lucky that it happens to be well paid.

I believe it's time for me to take a side-project sabbatical. And if you recognize yourself in this post - I hope you will consider joining me.

Running your own business is not a requirement for having a fulfilling career, in fact, it might be blocking you from reaching your full potential.

The only question left is - what the hell do I do with my slightly profitable side-project?

Cover photo by Aarón Blanco Tejedor on Unsplash

Exploring Ruby: Splat, splat and double splat!

Filip Defar — Mon, 06 May 2019 10:37:59 +0000

Ruby has a quite flexible way of defining methods that accept arbitrary number of arguments.
We run into splat operators often, so I wanted to take some time and explore them in a bit more depth.

Let's start with a question that might intrigue you into exploring this topic.
If we have the following method call:

my_method('Go', 'Now', name: 'John Goblikon')

What will be assigned as arguments when the method is defined in following ways?

def my_method(*args)

def my_method(**args)

def my_method(*args1, **args2)

Let's find out!

Splat operator (*)

Splat operator allows us to convert an Array to a list of arguments and vica versa.

Let's look at an example function that takes arbitrary number of arguments.

def things_i_like(*things)
  things.each { |thing| puts "I like #{thing}" }
end

We can call this method like this:

things_i_like('pie', 'doggos', 'grog')
# => I like pie
# => I like doggos
# => I like grog

All passed arguments will be collected into an Array and passed as a single argument named things.

things # => ["pie", "doggos", "grog"]
things.class # => Array

Mixing it up

We can also define regular positional parameters in combination with a splat parameter.

def likes(main_interest, *others)
  puts "I like #{main_interest} the most!"
  others.each do |other|
    puts "I also like #{other}"
  end
end

likes('pokemon', 'cats', 'chairs')
# => I like pokemon the most!
# => I also like cats
# => I also like chairs

This type of parameters is called "positional parameters" for a reason - the order of arguments decides how they will be assigned.

In this case, the first argument is separated from the rest. However, the splat argument does not have to be the last argument. Doing something like this is completely acceptable:

def likes(main_interest, *others, last_one)

However, there is a limit to how crazy we can get. It is not allowed to have more than one splat parameter in the same method.

def likes(main_interest, *others, last_one, *and_some_more)
# => syntax error, unexpected *

Putting it in reverse

The splat operator also works the other way around.
It can convert an Array into a list of arguments!

def three_things_i_like(a, b, c)
  puts "I like #{a}, #{b} and #{c}."
end

We can now call this method with three arguments as usual.

three_things_i_like('pie', 'doggos', 'grog')

However, we can use the splat operator to pass in an Array instead.

array_of_likes = %w(pie doggos grog)
three_things_i_like(*array_of_likes)

This can be quite useful. but we should be cautious! If the array does not have exactly three elements we will get an ArgumentError.

array_of_likes = %w(pie doggos)
three_things_i_like(*array_of_likes)
# =>  wrong number of arguments (2 for 3) (ArgumentError)

Named parameters

Ruby 2.0 introduced keyword arguments, and splat argument works with them. Splat argument always creates an Array, and all unmatched keyword arguments will be collected in a Hash that will be the last element of that array.

def splat_test(*args)
  args
end

splat_test('positional')
# => ['positional']

splat_test('positional', foo: 'bar')
# => ['positional', {:foo=>"bar"}]

splat_test(foo: 'bar')
# => [{:foo=>"bar"}]

The single splat operator works in reverse even for named parameters. We just need to add a Hash as the last element of the array.

def introduction(title, name:, surname:)
  puts "Hello #{title} #{name} #{surname}"
end

args = ['Mr.', { name: 'John', surname: 'Goblikon' }]
introduction(*args)

Double splat operator (**)

Double splat operator works similar to the splat operator, but it only collects keyword arguments. For this reason, it always generates a Hash, not an Array.

def do_something(**options)
  options.each { |k, v| puts "Options #{k}: #{v}" }
end

do_something(color: 'green', weight: 'bold')
# => Options color: green
# => Options weight: bold

things # => {:color=>"green", :weight=>"bold"}
things.class # => Hash

Double splat operator will collect only named arguments that were not matched to regular parameters. This behavior is similar to the single splat operator, but instead of relying on the position of arguments it relies on their names.

def do_something(action:, **options)
  puts "Action: #{action}"
  options.each { |k, v| puts "Options #{k}: #{v}" }
end

do_something(action: 'print', color: 'green', weight: 'bold')
# => Action: print
# => Options color: green
# => Options weight: bold

Double splat operator also works in reverse. You can convert a Hash into named parameters.

def print_multiple(value:, count:)
  count.times { puts value }
end

hash_params = { value: 'Hello', count: 3 }
print_multiple(**hash_params)
# => Hello
# => Hello
# => Hello

It's important to notice that keys of that hash must be symbols. They can't even be strings.

hash_params = { 'value' => 'Hello', 'count' => 3 }
print_multiple(**hash_params)
# => wrong argument type String (expected Symbol) (TypeError)

Using both splat operators

You can mix both splat and double splat parameters within the same method.

If both are present at the same time, the single splat operator will collect only positional arguments while the double splat operatr will behave as usual. It will collect all unmatched named arguments.

def can_you_do_this?(*positional, **named)
  puts positional
  puts named
end

can_you_do_this?('first', 'second', name: 'john', surname: 'doe')
# => first
# => second
# => {:name=>"john", :surname=>"doe"}

You can define positional, splat, keyword and double splat parameters inside the same method. However, the order is important here. Keyword arguments need to go after positional arguments, and the double splat operator must be at the very end.

def can_you_do_this?(first, *positional, second, name:, **named)
# This is perfectly ok!

Conclusion

Even though it might look a bit intimidating at first, the splat operator logic is actually quite straightforward.

Just keep in mind that:

Regular arguments have precedence and will be assigned first.
Double splat always works only on named arguments.
Single splat collects both positional and named arguments unless there's also a double splat parameter defined in the same method.

Solution

So to answer the question from the beginning. What will happen with this method call?

my_method('Go', 'Now', name: 'John Goblikon')

Example 1

The first method is ok and it will collect all arguments into an Array, with named arguments stored as a Hash.

def my_method(*args)
# args => ['Go', 'Now', {name: 'John Goblikon'}]

Example 2

The second example is invalid, we are only collecting named arguments while two positional arguments are passed to the method. We will get an ArgumentError.

def my_method(**args)
# wrong number of arguments (2 for 0) (ArgumentError)

Example 3

The third example is again valid. This time the single splat argument will collect only positional arguments, while the double splat will collect the named arguments.

def my_method(*args1, **args2)
# args1 => ['Go', 'Now']
# args2 => {name: 'John Goblikon'}

Exploring Ruby: What the hash?

Filip Defar — Tue, 19 Mar 2019 15:10:48 +0000

A while ago I came across a piece of ruby code that got me a bit puzzled.

Let's say we need a hash that has an array for each value. It would be reasonable to create a hash that has an empty array as the default value instead of nil, right?

Ok let's try with this:

hash = Hash.new([])
hash[:foo].push "Bar"
hash # => {}

Hmm ok. That does not seem to work very well. So did we store anything in that key?

hash[:foo] # => ["Bar"]

Wait, so it is there?

hash # => {}

Aaaaand it's gone. What the cabbage?

Let's check the documentation for Hash.new.

Returns a new, empty hash. If this hash is subsequently accessed by a key that doesn't correspond to a hash entry, the value returned depends on the style of new used to create the hash. In the first form, the access returns nil. If obj is specified, this single object will be used for all default values.

So if we specify an object as a default value, that single instance will always be returned for unknown keys. If we modify that instance, then modified version will be returned.

So when we did this:

hash[:foo].push "Bar"

We accessed that default object and modified it. But we have never set a value for the :foo key. Reading a value from a hash does not modify the hash itself, even when the default value is set. And that's why we get back an empty hash.

However, if we access the :foo key, we get our array with "Bar" string in it, because that's the new default value. Actually if we access any other key that does not exist, we will get that same array.

hash[:fiz] # => ["Bar"]

So for this specific use case, we should use the third option when creating a new hash, and that's using a block. According to Ruby documentation, this should work properly.

If a block is specified, it will be called with the hash object and the key, and should return the default value. It is the block's responsibility to store the value in the hash if required.

hash = Hash.new { |hash, key| hash[key] = [] }
hash[:foo].push "Bar"
puts hash # => { :foo => ["Bar"] }

In this case, we assign a new value for the default key by merely accessing it, and this works as expected.

However, this might not be a very wise idea, modifying a hash when someone tries to read a value seem like a pretty unexpected behaviour and might confuse your fellow developers, or future you.

Building a memoization module in Ruby

Filip Defar — Mon, 18 Mar 2019 09:47:00 +0000

A while ago during a job interview, I got asked to develop a generic memoization method in Ruby.
The goal is to be able to memoize a method by simply calling:

memoize :my_awesome_method

This is not as hard as it might sound at first, but there's a lot of depth to this task and requires a decent Ruby metaprogramming knowledge.
This is why I decided to revisit this task in this blog post.

But, first of all, what is memoization anyway? Wikipedia says something like this:

Memoization is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

Whenever a memoized method is called we take note of the parameters it was called with and the result it produced. If the same method is called again with the same parameters in the future, we skip the calculation and return the results that were produced last time.

Lets write an expensive method we can then try to optimize.

class Snail
  def serve_tea(kind)
    sleep(2)
    "Here's a #{kind} tea for you!"
  end
end

We have a Snail class with a single method serve_tea that after 2 seconds of sleeping returns a string.

The non-generic solution

First, let's implement memoization directly as a part of serve_tea method.

We can use a Hash as the cache store.
We will use the parameter that method was called with as a key and the result that is to be returned as a value.

class Snail
  # Step 0: Initialize the cache store
  @@cache = {}

  def serve_tea(kind)
    # Step 1: Check if a return value for this parameter is already stored
    return @@cache[kind] if @@cache.key?(kind)

    # Step 2: Do whatever you used to do
    sleep(2)
    @@cache[kind] = "Here's a #{kind} tea for you!" # Step 3: Cache the result
  end
end

Intuitively we use a class variable for the cache store, this means all instances of snail will use the same cache. We will discuss this approach later in the text, but first, let's try to extract the memoization logic to a generic solution.

Generic memoization method

When memoize method is called it needs to wrap the given method with memoization logic. The solution we are exploring here works in two steps. First, we store the to-be-memoized method in a variable, then we overwrite the original method with the memoized version. The memoized version of the method will call the original method that we stored in a variable.

We can do the first step by calling instance_method which returns an UnboundMethod object. This way we created an object out of a method, we can store it in a variable and call it later via the call method.

The good thing is that subsequent changes to the underlying class do not affect the unbound method, which means that we are free to overwrite the original method and then call the unchanged variant from a variable. We can overwrite the original method simply by defining a new method with the same name as the old one.

This gives us all the tools necessary to create the generic memoize method.

class Snail
  @@cache = {}

  def self.memoize(method_name)
    # Step 1: Objectify the method
    inner_method = instance_method(method_name)

    # Step 2: Overwrite the old method with the memoized version
    define_method method_name do |arg|
      return @@cache[arg] if @@cache.key?(arg)
      @@cache[arg] = inner_method.bind(self).call(arg)
    end
  end

  def serve_tea(kind)
    sleep(2)
    "Here's a #{kind} tea for you!"
  end
  memoize :serve_tea
end

Extracting memoization method to a module

We defined memoize method as a class method directly on Snail class. If we want to use it in different classes we need to extract it to a module.

We will add this module to the Snail class using the extend keyword, not the include keyword because we want memoize to be a class method, not an instance method.

module Memoize
  @@cache = {}
  def memoize(method_name)
    inner_method = instance_method(method_name)
    define_method method_name do |arg|
      return @@cache[arg] if @@cache.key?(arg)
      @@cache[arg] = inner_method.bind(self).call(arg)
    end
  end
end

class Snail
  extend Memoize
  def serve_tea(kind)
    sleep(2)
    "Here's a #{kind} tea for you!"
  end
  memoize :serve_tea
end

snail_one = Snail.new
snail_two = Snail.new

puts snail_one.serve_tea('green') # Takes two seconds to calculate
puts snail_two.serve_tea('green') # Returns instantly, using the cached value

Fixing the cache key

While the previous implementation seems to work properly, there are two significant issues with it.

First, we can only memoize methods that take a single parameter. If we try to expand our method like this

def serve_tea(kind, sugar)
  sleep(2)
  "Here's a #{kind} tea #{sugar ? 'with' : 'without'} sugar for you!"
end
memoize :serve_tea

We won't be able to run the code.

`serve_tea': wrong number of arguments (given 1, expected 2) (ArgumentError)

We can fix this easily by using the splat operator. Splat operator will collect all arguments passed to this method and convert them to an array and then convert them back to the list of arguments when calling the inner method.

You will notice that now we are using an Array object as a Hash key for our cache object. This is perfectly fine because in Ruby, Hash allows you to use any object type as a key.

module Memoize
  @@cache = {}
  def memoize(method_name)
    inner_method = instance_method(method_name)

    # *args will collect all arguments into an array
    define_method method_name do |*args|
      return @@cache[args] if @@cache.key?(args)

      # *args will convert the args Array object back into a list of arguments
      @@cache[args] = inner_method.bind(self).call(*args)
    end
  end
end

However, there is another issue with this implementation. We did not take into account the method name when caching the method result.
If we memoize two different methods that receive the same parameters we will cache and return incorrect results. Here's an example of that scenario.

class Snail
  extend Memoize
  def serve_tea(kind)
    sleep(2)
    "Here's a #{kind} tea for you!"
  end
  memoize :serve_tea

  def serve_coffee(kind)
    sleep(2)
    "Here's a #{kind} coffee for you!"
  end
  memoize :serve_coffee
end

snail_one = Snail.new
snail_two = Snail.new

puts snail_one.serve_tea('black') # => Here's a black tea for you!
puts snail_two.serve_coffee('black') # => Here's a black tea for you.

Even though the second call was to the serve_coffee method, our memoization module returned the results from the serve_tea method.

To fix this, we can build the cache key as an array where the first element is the method name and the second elements is an array of arguments.
While this key is quite complex, because Hash keys can be any object type, we are still fine.

module Memoize
  @@cache = {}
  def memoize(method_name)
    inner_method = instance_method(method_name)
    define_method method_name do |*args|
      # Use both arguments and the method name as caching key
      key = [method_name, args]
      return @@cache[key] if @@cache.key?(key)
      @@cache[key] = inner_method.bind(self).call(*args)
    end
  end
end

Inheritance woes

Our Memoization module uses a class variable as a cache store. Intuitively this seems like a good solution, however, we can easily run into issues.

class Snail
  extend Memoize

  def serve_tea(kind)
    sleep(2)
    "Here's a #{kind} tea for you!"
  end
  memoize :serve_tea
end

class EvilSnail
  extend Memoize

  def serve_tea(kind)
    sleep(2)
    "Here's a POISONED #{kind} tea for you!"
  end
  memoize :serve_tea
end

evil_snail = EvilSnail.new
snail = Snail.new
puts evil_snail.serve_tea('green') # => Here's a POISONED green tea for you!
puts snail.serve_tea('green') # => Here's a POISONED green tea for you!

Oh no, we served a poisoned tea to the wrong person!
The issue here is that the cache class variable belongs to the Memoize module and is shared across classes that use that module. We can avoid that problem by replacing the class variable with a class instance variable, which is considered a good practice for this exact reason.

module Memoize
  def memoize_cache
    @memoize_cache ||= {}
  end

  def memoize(method_name)
    inner_method = instance_method(method_name)
    define_method method_name do |*args|
      key = [method_name, args]
      cache = self.class.memoize_cache
      return cache[key] if cache.key?(key)
      cache[key] = inner_method.bind(self).call(*args)
    end
  end
end

Now each class that uses Memoization module will have its own instance variable that contains the cache. This will prevent cache mixup between sibling classes and will make tea safe to drink again.

Conslusion

As with every other programming problem, the devil seems to be in the details. While we covered some edge cases in this blog post I would still not recommend using this soulution in a real world application as more issues are sure to be lurking behind the corner.

For a more complete solution, you can check out the memoist gem.