Brains under DDoS

Software Development grows more complex day by day; Especially web apps. Just think of all the things in the stack you must now know:

And if you are doing this solo as a full stack dev you have to know at least 1 item in each of those categories. This is crazy town. I mean, let’s be clear, it’s not like you can’t know all of these things, but you certainly aren’t going to get them all right. In order to be a full stack web dev today it seems like you have to go for extreme breadth instead of depth.

I’d love to hear comments.

Granular Software Estimation is a Myth

Software estimation has got to be one of the best examples of humanity as a whole not learning from its mistakes. Time and time again we attempt to estimate how long our software is going to take and it’s always always wrong; And usually it’s wrong by a lot. But we keep doing it.

Why Estimate at All? Can you?

icebergWhen time and money are finite it’s important to weigh alternatives. Usually the way this happens is we try weigh software X vs software Y in terms of what will have the highest impact per time input. But complexity determines time input. And you can’t understand the complexities of software and the variables involved because they do not become clear until you are in the middle of developing the software and uncover that complexity. At the start of a project our level of understanding about the software is the lowest it will ever be, which makes it the worst possible time to estimate.

So what do you do? How do we estimate then?

Software estimation is a lot like estimating nature:

  • You can’t accurately estimate whether a volcano is going to explode unless you are estimating within a matter of weeks.
  • You can’t accurately estimate the weather unless the estimate is within a matter of weeks.
  • You can’t accurately estimate where a hurricane is going to landfall unless you are estimating within a week.

What’s the common theme? Complexity. Nature is a very complex thing and as such the only way to estimate is to reduce complexity. The only way to reduce complexity is to reduce the amount of time that complexity can take place. Software is like that. Software is complex. If anyone tells you that anything in software development is simple they either haven’t been bit by this or don’t understand the complexity involved.

The only way to estimate accurately is by doing one of the following:

  1. Provide very low confidence very coarse-grained estimates.
  2. Provide estimates for things with low complexity.
  3. Provide estimates for things that are going to happen in the next week or two.

Items 2 and 3 are really just the same thing, stated in different terms. If you attempt to granularly estimate anything farther than a couple weeks out you are lying to yourself and everyone involved in your project. Item 1 is only valuable when it helps you make a significant decision about finite resources like time and money.

It’s been my experience that item 1 estimates are too tempting and can be abused, leaving item 2 and 3 as more attractive options. Don’t plan and estimate big software. Plan and estimate small incremental software.

Wat?

I just ran into something that’s probably common knowledge among rubyists but it caught me off guard:

byte$ irb
1.9.3-p374 :001 > nil == false
 => false 
1.9.3-p374 :002 > !nil
 => true 
1.9.3-p374 :003 >

Wat?

mother-god-meme

This was boggling my mind so I did a quick google search and came up with a post from Alan Skorkin‘s blog: True, False And Nil Objects In Ruby.

The reason is nil is really a singleton NilClass instance and true/false are singleton TrueClass/FalseClass instances. Thus the comparison of whether they are the same object fails, but nil does evaluate to boolean false in a conditional.

Ruby In-Memory Database

One of the things that Uncle Bob talks about a lot is architectures that allow you to defer decisions about frameworks and other dependencies as long as possible. The logic being that if you follow that principle your architecture will be decoupled from the dependency and therefor allow you to change it at will depending on changing needs. Probably the most common application of this thinking is in the decision around database technology (sql, nosql, filesystem, etc etc). The way the deference is accomplished is typically by developing your application against a uniform data store abstraction that can have any concrete persistence wired up to it and use an in-memory implementation with it as long as possible. I’ve stolen an image articulating this idea from @mikeebert‘s blog:

deference

In-Memory DB for Ruby

I’m doing a lot of Ruby lately, so I wanted to create a good in-memory data store that would be general enough to use for a variety of data entities without creating a specific type of data store for each entity type. The logical thing to do seemed to be to start from a plain old hash:

  
  class MemoryDataStore
    def initialize
      @storage = {}
    end
  end

Since I want to store many different types of entities in this data store, it seems logical to have the hash structure end up like so:

  
  @storage = {
    'foo-entity' => {
      '123' => foo-entity-123
      '456' => foo-entity-456
    },
    'bar-entity' => {
      '123' => bar-entity-123
      '456' => bar-entity-456
    }
  }

The idea here is that the keys in the top-level hash are the entity type names, with a sub-hash for those entities. In the entity hash you’ve got an ‘id’ => ‘entity’ map to allow for quick-lookup by id. I also wanted to set this up such that the data store was responsible for dishing out that ‘id’ for each entity. Here’s what the code implementation looks like:

  
  class MemoryDataStore

    def initialize
      @storage = {}
    end

    def save(entity_name, entity)
      @storage[entity_name] ||= {}
      entity.id ||= SecureRandom.uuid
      @storage[entity_name][entity.id] = entity
    end

    def get_by_id(entity_name, id)
      entities = @storage[entity_name] || {}
      entities[id]
    end

  end

Alright so that works. But what if I want to look up an entity by some arbitrary attribute? For example, what if I want to look up a user by his name instead of just some database identifier? I decided to construct a query method that would locate an entity based on an attribute hash of options passed in:

  
  def get(entity_name, options) do
    ...
  end

  entity = get(:user, { :name => "Ben" })

The implementation would only return a user if all of the options passed in were found on an entity in the data store. Since the options passed in is an arbitrary hash of attribute names to values we need to check if the entity has an attribute with the name of each option key and that the value returned by that attribute matches up with what’s desired. Here’s what it ended up looking like:

    
    def get(entity_name, options)
      entities = @storage[entity_name] || {}
      entities.values.find do |entity|
        options.all? do |op_key, op_val|
          entity.respond_to?(op_key) && 
              entity.send(op_key) == op_val
        end
      end
    end

I’d love to hear your thoughts on this, or if you’ve got a better solution.

Ruby 101: Classes

I’ve been doing a lot of learning about Ruby lately. All the cool kids are doing it these days so I figured I ought to dive in and teach myself. I’ll probably be doing a series of blog posts like this one on Ruby 101 type of stuff. So if you already know Ruby… well, sorry.

Some Background

RubySo Ruby was created in 1995 by this guy “Matz”. The language itself is sort of a mixture of Smalltalk and Lisp, wherein it’s infix based messages and receivers and everything is an object (‘everything’ as in everything; not ‘everything’ as in everything in Java is an object). The general theme in Ruby’s ecosystem is to be as clean and readable as possible by enabling the creation of DSLs appropriate to whatever task you’re facing.

Classes

Ruby is an OO language so let’s dive right in and see what a class looks like.

class Person
  def initialize(name)
    @name = name
  end
  def name
    @name
  end
  def name=(name)
    @name = name
  end
end

some_person = Person.new('Ben')
puts some_person.name # prints 'Ben'
some_person.name = 'Joe'
puts some_person.name # prints 'Joe'

Methods in ruby are defined by the ‘def’ keyword. If there are no arguments to the method the parenthesis can be omitted. Methods can be suffixed with characters like ‘?’, ‘!’, ‘=’, etc, and each conventionally carries some meaning. In the case above the ‘name=’ method will allow us to use assignment. The ‘initialize’ method is the constructor and is called when you call ‘Person.new’. The ‘@’ prefix on a variable indicates it’s a member variable (member variables are always private). When calling methods, the parenthesis are optional, which is why our usage of the assignment method above doesn’t need parenthesis. We could have just as easily called it like so:

some_person.name=('Joe')

But that’s not very asthetically pleasing.

Generators

One of the key things you’ll discover about Ruby is that it aims to increase developer happiness by removing unnecessary cruft. As it turns out, the above example can be simplified like so:

class Person
  attr_accessor :name
  def initialize(name)
    @name = name
  end
end

The ‘attr_accessor’ generates some code given the ‘:name’ label (more on that in a minute). The code it generates is essentially what we saw in the first example. Also available is a ‘attr_reader’ generator that will only generate the ‘getter’ and a ‘attr_writer’ that will only generate the ‘setter’.

Symbols

So what’s that weird ‘:name’ thing? It’s a symbol, which can be thought of as a global constant string object with an underlying numeric representation for the compiler. That’s a mouthful, but the general idea is that if the same string is going to appear in various places in your code then you can use a label to save on memory. Symbol use in Ruby is extensive, so you’ll see them everywhere.

Inheritance

Traditional inheritance in Ruby is accomplished like so:

class Student < Person
end

If you're familiar with OO inheritance in other languages you won't be surprised by much about the implementation in Ruby (except a few corner cases). So why did I say 'traditional' inheritance above? Well, it's because in Ruby you also have the concept of a mix-in.

Mix-ins

I won't cover it in depth here (but probably will in a future blog post), but here's what a mixin looks like:

module Knightable
  def knight!
    @name = "Sir #{@name}"
  end
end

class Person
  include Knightable
  attr_accessor :name
  def initialize(name)
    @name = name
  end
end

some_person = Person.new('Ben')
puts some_person #prints 'Ben'
some_person.knight!
puts some_person #prints 'Sir Ben'

Here we mixed in a module method which expects a member variable '@name' to exist and operate on. The 'knight!' method implies it changes the receiver object by having the suffix '!'.

Well thats all for this blog post. You may see more Ruby 101 posts soon!

Squawking Hens

“Why are programmers so violently opposed to these (intellectual property) laws? If I were a legislator, I’d be interested in this mystery—for the same reason that, if I were a farmer and suddenly heard a lot of squawking coming from my hen house one night, I’d want to go out and investigate. Hackers are not stupid, and unanimity is very rare in this world. So if they’re all squawking, perhaps there is something amiss.”

Source: Paul Graham – The Word Hacker