A very typical test of programming skills is doing a short one-liner for something that is not easily a one-liner.

Today I did the FizzBuzz test. The task is simple; For a range of numbers 1..100 print “Fizz” if the number is divisible by 3 and “Buzz” if the number is divisible by 5, otherwise just print the number.

Python is my weapon of choice.

print(*map(lambda n:"Fizz"*(n%3==0)+"Buzz"*(n%5==0) or n, range(1,101)))

Don’t do this for production code 🙄

I quite often find myself in need of a REST API which does this or that. Yet if enough time pass between me making an REST API in Django I feel I have to start over and learn the process again. Here I’ve outlined a very basic calculator API which can add, subtract and multiply floating numbers.

I assume that you have python and virtualenv installed and you are working on a system with a proper commandline interface.

The Environment

Setting up the environment is just a few steps. First make a virtual environment for us to work in and start the django project.

$ pipenv install django django-settings-cmd
$ pipenv shell
(calc)$ django-admin startproject calc_api
(calc)$ cd calc_api/
(calc)$ django-admin startapp calc
(calc)$ django-settings-enable-app calc

Add the calc app urls to the global list of urls in calc_api/urls.py

from django.conf.urls import url, include
from django.contrib import admin

urlpatterns = [
url(r'^calc/', include('calc.urls')),
url(r'^admin/', admin.site.urls),
]

Create the list of endpoints in the calc app (calc/urls.py)

from django.conf.urls import url

from . import views

urlpatterns = [
url(r'^add$', views.add, name='add'),
url(r'^sub$', views.add, name='sub'),
url(r'^mul$', views.add, name='mul'),
]

Create the calc app endpoints in the calc/views.py

from django.shortcuts import render
from django.http import HttpResponse, JsonResponse, Http404

def getFloatParam( name, request ):
  try:
    val = request.GET[name]
  except:
    raise Http404( "Missing parameter %s"%name )
  try:
    fval = float( val )
  except:
    raise Http404( "Parameter %s is not a float value"%name )
  return fval

def add(request):
  left = getFloatParam( "left", request )
  right = getFloatParam( "right", request )
  return JsonResponse( {"result":left + right} )

def sub(request):
  left = getFloatParam( "left", request )
  right = getFloatParam( "right", request )
  return JsonResponse( {"result":left - right} )

def mul(request):
  left = getFloatParam( "left", request )
  right = getFloatParam( "right", request )
  return JsonResponse( {"result":left * right} )

Now lets get things running

(calc)$ ./manage.py migrate
(calc)$ ./manage.py runserver
(calc)$ open "http://127.0.0.1:8000/calc/add?left=1.5e2&right=2"

Most bug and issue tracking systems use a prioritisation model where you can set a severity, criticality or priority on each bug or issue.

Most systems fail miserably at this one feature. Here’s why.

In one such system a typical default view of a bug would look like this

The problem here is that “Low”,”Medium”,”High” and “Critical” or even worse 4-1 means different things to everyone, because everyone only relate it to their own little world.

Enter the critical bug

A typical everyday example is that in the morning someone enters a “Critical” bug. “Critical” to my team means; drop whatever else you are doing, cause something very bad have happened to one of our critical systems and nobody leaves work until this is resolved. Naturally this is what happens, we take it very seriously.

I then start to inspect the bug report to see what it is really is about (while my team is trying to fix the bug) and then find out that it’s a bug report for something that does work wrong, but only for a not yet launched product in a currently running project. The net effect for our customer base is currently NIL and the risk of a financial loss for the company is NIL. I call in the project manager who explains to me that it’s critical to him and his deadline that this bug gets resolved.

I truly understand his situation, but I also understand that this is not comparable to say if our serverroom was on fire. Our worlds are not the same, therefore we cannot prioritise using the same relative definitions of severity.

In the above situation after the project manager have explained his situation, I usually ask him how many people will die if I do not fix this bug today. I’ve not yet encountered a bug where I got a number higher than 0, despite the fact that there exists many software based products where a bug easily could kill many people in day. (We’re just not in that type of business)

We need absolute terms of severity

Critical simply means different things to different people. While “This will kill 1 person / day” means the same to everyone and is easily transferred between different projects and organisations.

I therefore propose that we state severity in absolute terms such as:

1. 5+ people might die
2. 1-5 people might die
3. People might get physically or mentally hurt
4. Our company might lose $100 mio+
5. Our company might lose $1 mio+
6. Our company might lose $10k+
7. This bug is annoying, please fix it

Now I think we would get more accurately prioritised bugs.