Testing messages with Elixir

If you're coming to Elixir from another language, you might wonder how to assert that a process sent a message to another process.

The key is to remember that each test itself is also an Erlang process (and has its own pid).

We can send a message to the test process's mailbox, and then use `assert_receive` to assert we got the message.

For example:

test "something" do
  IO.puts "I am test, my pid is #{inspect self}"
  send(self, "hello test")

  assert_receive "hello test"
end

When you want to assert that a process sends a message, you just need to make sure the process is sending the messages back to the test's pid.

We do this by creating a stub that forwards messages.

Example

Say you have GenServer process that handles Payroll. Each time an employee is registered with the process, it sends a notification using GenEvent.
You want to assert that the event is sent.

This is what your Payroll server looks like:

defmodule Payroll do
  use GenServer

  # convenience function for starting up server, requires an event manager
  def start_link(manager) do
    # start GenServer with current module, and pass manager as state
    GenServer.start_link(__MODULE__, [%{events: manager}])
  end

  # initialize state
  def init([state]) do
    {:ok, state}
  end

  def handle_call({:add, employee}, _from, state) do
    # send out event
    GenEvent.notify(state.events, {:added, employee})

    # reply :ok
    {:reply, :ok, state}
  end

  # public API for adding employee
  def add_employee(pid, employee) do
    GenServer.call(pid, {:add, employee})
  end
end

It can be used like this:

# start a gen event server
{:ok, events} = GenEvent.start

# start the payroll service and pass the event manager's pid
{:ok, payroll} = Payroll.start_link(events)

# spawn another process that will print out events
spawn fn ->
  GenEvent.stream(events)
    |> Stream.each(&IO.inspect/1)
    |> Enum.to_list
end

# add an employee to the payroll service, which will result in notification being sent to previously spawned process
Payroll.add_employee(payroll, %{name: "Josh", salary: 1_000_000})

To test it, we'll need to create a stub GenEvent handler to forward messages back to the test:

# inside payroll_test.exs

# define a stub GenEvent handler
defmodule Forwarder do
  use GenEvent

  # handle all events, first parameter is the event, second if the state
  def handle_event(event, test_pid) do
    # send the event to `test_pid`
    send(test_pid, event)

    # respond `:ok` and keep the same state (the test's pid)
    {:ok, test_pid}
  end
end

# create all the processes we need in the setup
# ExUnit automatically terminates child processes after each test completes
setup do
  # create a GenEvent process
  {:ok, events} = GenEvent.start

  # start the payroll process, passing the event process's pid
  {:ok, payroll} = Payroll.start_link(events)

  # add the Forwarder as a handler, pass the current pid (self) as the state
  GenEvent.add_handler(events, Forwarder, self)

  # return test state
  {:ok, %{events: events, payroll: payroll}}
end

test "adding employee, sends notification", state do
  Payroll.add_employee(state.payroll, %{name: "Josh", salary: 1_000_000})

  assert_receive {:added, %{name: "Josh", salary: 1_000_000}}
end

And that is all folks..

Happy Elixiring!

How to Start

"I bought a book about procrastination several years ago. Haven't read it yet. I will get to it eventually."

Just kidding, I actually did read it ;)

Turns out procrastination is directly correlated to perfectionism. When perfectionism increases, procrastination increases (and vice versa).

So when you find yourself avoiding some task, it's very likely you've built up the task into something so big, so gargantuan, that starting has become daunting.

Take for example, the relatively basic task of baking cookies (I'm kind of hungry).

There are two ways to do this:

The Easy Way

Buy a bunch of ingredients (flour, sugar, chocolate chips, eggs, etc..) mix 'em up, throw 'em in a baking tray. BOOM, done!

Becoming a Perfectionist

After doing that for a while, you've now graduated to the "cookie expert" level, so you up your game. Instead of buying chocolate chips, you now buy bars of chocolate and chop them yourself. Heck, maybe you drive out to a farm and get some farm fresh eggs, maybe even freshly grind some rock sugar.

The results are phenomenal, so you keep adding and complicating.

Until.........

The World's Most Difficult (and Expensive) Artisinal Hand-Crafted Small-batch Farm-to-table Cookie

Recipe:

• Get a hen-house with chickens in the backyard, for super fresh eggs.
• Buy a small farm to grow wheat and harvest it for flour.
• Buy a sugar plantation to grow and harvest your own sugar cane.
• Raise a cow for fresh milk.
• Harvest your own cacao beans and make your own chocolate.

Congratulations, baking cookies just became harder than climbing Mt. Kilimanjaro.

You can no longer complete this task in 10 minutes, you now need a metric crap-tonne (actual SI unit) of planning, pre-planning and organizing.

You've created something too big to start.

Breaking the Cycle

To break the cycle, you'll need to create an easier start condition. You can do this by SIMPLIFYING AND REDUCING the first (aka starter) task.

Recall that procrastination effects only the start condition, STARTING the task (not actually doing the task). Once you've started, tiny amounts of success and accomplishment will build up and melt away procrastination (because you're creating mini gratification cycles).

Examples

• Have trouble working 8 hours? work for one hour and see how that feels, odds are you'll have no trouble continuing because the start was the only real barrier.
• Want to paint the deck but never get around to it? Tell yourself you'll only paint the railing, chances are you'll be done in a jiffy.
• Wanna run a mile? put on your shoes and run for just 5 minutes, bet you wont stop there.
• Never get around to writing that blog post? Just write one paragraph, 30 minutes later you'll realize you finished an entire post (actually how I wrote this)

Conclusion

Starting is always the biggest barrier. When you feel stuck, simplify and reduce until you reach a starter task so small that your "engines" can turn on. With your engines rolling, you're well on your way.

8 Ways Software is Priced

Buying software is really hard.

When done right, it's a huge asset for your business. It becomes the backbone of your business and helps attract investment.

When done wrong, it can cost thousands in modifying and fixing problems and will result in hurting (and possibly losing) valuable customers.

In this blog post, I'm going to explain how software is priced. I will show you the the pros and cons of each option, and how to ask the right questions and avoid common pitfalls. If you follow these tips, your next software purchase should be a resounding success.

If you have any questions, feel free to contact me at joshnuss@gmail.com

So like, how much does software cost?

It depends :)

That's like asking "how much does a car cost?", "how much does property cost?".

It depends on the type of car, the location of the property, etc.

A better question to ask is "what kind of car would I need?", "what kind of property is right for me?". There is no one-price-fits-all.

Software is an investment

Some business people will measure things purely on cost. I call them the "bean counters".

Bean counters will hire someone because their hourly rate is 5% lower than the next guy. They always look for the cheapest option. Bean counters think "I can do it cheaper by hiring someone in Albania for $0.25/hour". They neglect to look at skill, experience or track record.

Don't be a bean counter!

Instead, ask yourself what value is this project going to bring my business.

For example, say you have two employees working full time creating spread sheets, say each employee costs your business $35K/year + $10K/benefits. That means it costs you $90K/year to create these spreadsheets. If you automated this process, you'd be saving your business ~$450K over the next 5 years. Plus you could move 2 excellent employees into a more productive position.

So now you know how much these spreadsheets are costing you, how much should you pay to automate it?

You should aim for at least a 5X to 10X return. That means you can pay between $45K to $90K to solve this problem.

You may still be tempted to pay a lot less. Avoid this temptation, it will end up costing you in the long term.

Be a Unicorn

Every business is made up of parts that are unique and other parts that are common.

Ideally, you should carefully invest in unique parts of your business and outsource the remaining common parts.

For example, E-Bay has a unique way of selling products, so they have custom software for selling products. But when it comes to payroll, taxes or other non-unique aspects, they'd do best to outsource these systems, since they aren't innovating in payroll or taxes.

Remember: Always maintain maximum control over your business's core competency!

Cost structure

Software purchases are commonly priced in 8 different ways: Free, One-Time, Subscription, Time & Material, Retainer, Fixed-Bid, Shares and Salary.

Here's a breakdown of each, with suggestions on when to use the particular option and when to avoid it.

Free

There is no such thing as a free lunch.

Sometimes, software is marketed as free to attract new customers who will later turn into paying customers (by buying customizations or add-ons).

There are 2 types of free:

Proprietary: A company owns the code you are using, should you ever decide to stop working with that company, you cant use the software any more. This can lead to "vendor lock-in" where it becomes costly to leave because you'd need to start from scratch.

Non-Proprietary: (aka Open Source) The software is free to use and modify. You are not beholden to anyone, but you most likely will still need someone skilful to maintain it - its not totally free.

Use: Open-Source software is a great, provided its for a non-core competency.
Avoid: Proprietary stuff is often a trap, you'll be locked in with that vendor and you'll always second-guess whether you should leave.

One-Time

A one-time price is common in many off-the-shelf commercial software packages. Think Microsoft Office, Quickbooks, etc. These softwarez are sold as is and provide little post-sale customization opportunities. So you get what you buy and that's it, that's all. If something doesn't work the way you'd like, there's little recourse - other than to buy a competing package.

These offerings tend to suffer from over-complexity, they sell based on features, and end up with so many features that you have more knobs to turn than a 747 cockpit. It will lead to difficulty setting up the system, in day-to-day usage, and will require lots of staff training.

Use: Great for low-cost non-core commercial software.
Avoid: When something customized will save more time. E.g. don't spend $1 million on SAP when you can build something much cheaper and more specific.

Subscription

The subscription model is used in many on-line service websites (Shopify, GoDaddy, etc..). They offer a very low initial commitment, but are almost always proprietary, so you're completely locked in. If you move to another service you will have to start from scratch. Many suffer from 747 cockpit syndrome (way too many knobs and dials to turn).

Use: Good option for starting out on a low budget, or when the service is not a core-competency of your business.
Avoid: When service provided is a core competency of your business.

Time & Material

Many consultants and freelancers will charge this way (by hour or week), but it has some drawbacks. It puts extra risk on the buyer, because projects can be open ended (no agreed upon finish line), the buyer assumes the risk if things take longer (often the case). It can also be hard to compare rates between different skill levels, a really good developer charging $150/hour could be more economical than a junior developer charging $20/hour, because the quality and productivity could be 10 times better than the junior developer. Also, there is nothing stopping a company from charging a hefty hourly rate and using junior developers.

Use: Good approach for support/maintenance or very short projects.
Avoid: Bad for bigger projects because you (buyer) assume all the risk.

Retainer

Sometimes the most valuable thing you can get is good advise. One minute of good advise can save thousands of dollars. So many companies opt to have technical talent on hand in an advisory role. These are generally paid by retainer. It differs from Time & Material because unused time is still billed.

Use: Great for paying for advise, every serious company should have advisers on retainer.
Avoid: Not good for paying for project work (will be too expensive). Agree to a fixed price instead.

Fixed Bid

The price is fixed to a set of features. Commonly used by freelances, consultants and agencies. Easier for the buyer to budget. It also reduces the risk to the buyer, because if something takes longer than expected the price stays the same.

The only danger to the buyer is when requirements change during the implementation. It's quite common to surface new ideas during the course of implementation. To mitigate this risk, it is recommended to split a large contract into multiple fixed bid contracts (phases). That way you can still pivot requirements before its too late and costly.

Use: Projects with clear expectations.
Avoid: When expectations aren't clear or will change drastically over the course of implementation.

Shares

Some developers accept shares or revenue sharing in place of payment. Common in startups. Often mixed with other payment method (i.e.. Hourly rate + Shares). Some developers avoid it because it adds to their risk. Companies use this to add a valuable partner and ensure the resource is invested in the success of the business (and not just the success of the project).

Use: Want to decrease initial spend and have a valuable partner.
Avoid: Want to control ownership of business.

Salary

When you have a large budget and in house talent (or the desire to build talent) your best and cheapest option is to build it in house. This will offer your business the most control. Just make sure you have the budget to do this. It can add up when you need many different skillsets to complete a project. If it's not enought work to require a full time developer, you're better off hiring a consultant, freelancer part time or outsourcing to an agency. Remember that employees cost more than just their salary, there's benefits, office space, etc..

Use: Large budget core-competency projects where skills and manpower are are available in house.
Avoid: Non core-competency or manpower not available in house.

Tip: Mix and Match

The best approach is to mix several of these options to get the best results. For example, you could do the initial work with several rounds of fixed-bid with an agency, and then hire a developer employee to maintain your system in-house.

Conclusion

My grandma had this saying "Too poor to be cheap". It means the best way to invest in one's self or business is to focus on quality. You can't afford to re-buy the same object constantly. Buy objects that last a long a time - don't shop at the dollar store. Dont skimp on yourself or your business. Forget ODesk, forget Fiverr, do it right and you'll thank yourself later!

Joshua Nussbaum is Technology Integration Consultant in Montreal, Canada. You can reach me at joshnuss@gmail.com


Next up: 6 types of software companies