Making the weight CRUD work per user

In the previous two posts I created a full CRUD, using scaffolding, for weights and a way to get the current user. The weight CRUD, as it was, allowed you to edit data for any user (check out the screenshots). Moving from there to editing data only for yourself was trivial.

In the views I just removed the user_id field, no big deal. In the controller it gets interesting, there you have lines like the following:

@weights = Weight.all
@weight = Weight.find(params[:id])
@weight = Weight.new
@weight = Weight.new(params[:weight])

Those four lines get all the weights, find a specific weight, create a new weight object and create a new weight object with the goal of saving it to the database with the data from the web form; respectively. Of course those lines are not all together, but all over the controller.

I replaced those lines with the following:

@weights = user.weights.all
@weight = user.weight.find(params[:id])
@weight = user.weight.new
@weight = user!.weight.new(params[:weight])

And that’s it! Line 1 gets all the weight for the given user. If user is a not-in-the-database user, then that’s an empty list. The same for line 2. Line 3 could still be Weight.new, because that object is only used for displaying the form, but I like being consistent. Line 4 gets interesting. Shortly after line 4 I do a @weight.save, so the user must exists on the database to save the weight, that’s why I user user!

The whole patch can be seen in the screenshot:

sano-009

That program is GitX in case you are wondering. A MacOSX GUI for Git, which I really love.

I tried it by opening two browsers (Firefox and Safari) and putting some data in. I left the user id in the listing just to be sure:

sano-010

sano-011

Getting the current user

I’m not using any authentication gem or plug in, I’m rolling my own. I’m actually using OpenID, so rolling my own is not hard: no passwords to encrypt, resend and send, no email address to verify. I think this is the future. But I’m also doing something that I call ghost users.

When you use one of my web apps you can start using most of it right away. At first you are a totally anonymous user but as soon as you do something that requires you to have an account on the database I create one for you. In the case of Sano, the moment you add a weight you’ll have an account.

At that moment your account is accessible thanks to the session of your browser. The moment you close the browser that account is no longer accessible. If you use the app and like it and decide to stick around, all you have to do is log in with your OpenID. For using the web app there’s no barrier of entry.

From the programming point of view this creates some challenges:

  • Maintenance of the users and related data. Over time the user database will have users that are no longer accessible with weights and other related data. That needs cleaning up. For the moment I’m going to ignore that problem because it has no impact on the system and it’s not likely to present a problem any time soon.
  • Getting a user object is no longer a query to the database. Any piece of code should be able to get a user object no matter what’s the status of the session. Sometimes the user object is only needed in memory and sometime it’s needed in the database. For example: if you create a new weight, I need a user object that’s been saved on the database; to list your weights, I need a user, I don’t care if it’s in the database or not (if it’s not, it’s not going to have any weights, which is where you start).
  • Merging users happens regularly. Look at this scenario: you go to the app, you log in, you enter your weight, you leave; you go back to the app, you don’t log in, you enter a new weight. Now you have one account with one weight and another session only account with another weight. You realize you need to log in and you do it. At that moment I have to merge the two users.

To make it as simple as possible I’ve created a method called user in my application controller that is also declared as a helper method so it’s available for all controllers and all views. This method is guaranteed to return a user, and if you call with options[:create]=true then it’s guaranteed to return a user that is also on the database. What is not guaranteed is that the user object represents a permanent account. It may be what I call a ghost user.

This is the method:

class ApplicationController < ActionController::Base
  helper_method :user
  helper_method :user!

  protected

  # Helper method to get the current user. It will always return a user but the
  # user may not be in the database. If options[:create] is true, then the user
  # will be in the database (although it may be a ghost user).
  def user(options = {:create => false})
    # If we already have a user object, return that.
    return @user if @user != nil

    # Try to find the user in the database if session[:user_id] is defined.
    @user = User.find(session[:user_id]) if session[:user_id] != nil
    return @user if @user != nil

    # Create a new user object.
    @user = User.new()
    if options[:create]
      # Save the user in the database and set the session user_id for latter.
      @user.save
      session[:user_id] = @user.id
    end
    return @user
  end

  # Helper method to get a user that for sure exists on the database.
  def user!
    return user(:create => true)
  end
end

Creating the weight model and scaffolding

With one command line I’ve created the weight model and the scaffolding, a fully functional CRUD little app without my Rails app. I know all Rails developer are rolling eyes now; but I still think this is awesome. It gets you up and running so fast:

 ./script/generate scaffold weight user_id:integer weight:float timestamp:datetime
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/weights
      create  app/views/layouts/
      create  test/functional/
      exists  test/unit/
      create  test/unit/helpers/
      create  public/stylesheets/
      create  app/views/weights/index.html.erb
      create  app/views/weights/show.html.erb
      create  app/views/weights/new.html.erb
      create  app/views/weights/edit.html.erb
      create  app/views/layouts/weights.html.erb
      create  public/stylesheets/scaffold.css
      create  app/controllers/weights_controller.rb
      create  test/functional/weights_controller_test.rb
      create  app/helpers/weights_helper.rb
      create  test/unit/helpers/weights_helper_test.rb
       route  map.resources :weights
  dependency  model
      exists    app/models/
      exists    test/unit/
      exists    test/fixtures/
      create    app/models/weight.rb
      create    test/unit/weight_test.rb
      create    test/fixtures/weights.yml
      exists    db/migrate
      create    db/migrate/20091121135320_create_weights.rb

And this is what I’ve got:

sano-003

sano-004

sano-005

sano-006

sano-007

sano-008

Profile models

The profiles in Sano are built out of two models:

  • User
  • OpenId

The reason to have an OpenId model and not just one field in the User model is that I like giving users the possibility of defining more than one OpenId provider. StackOverflow does that and since I use my own OpenId server, the day it was down, I was really grateful I could still use my myOpenId account to log in.

So I created the two models:

./script/generate model user name:string email:string height:float gender:boolean birthday:date
./script/generate model open_id user_id:integer identifier:string display_identifier:string

and then I used Matthew Higgins’s foreigner to define the foreign keys. The end result follows.

Migration for users:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name
      t.string :email
      t.float :height
      t.boolean :gender
      t.date :birthday
      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

Migration for OpenIds:

class CreateOpenIds < ActiveRecord::Migration
  def self.up
    create_table :open_ids do |t|
      t.integer :user_id, :null => false
      t.string :identifier, :null => false
      t.string :display_identifier
      t.timestamps
      t.foreign_key :users
    end

    add_index :open_ids, :identifier, :unique => true
  end

  def self.down
    drop_table :open_ids
  end
end

Both models:

class User < ActiveRecord::Base
  has_many :open_ids
end

class OpenId < ActiveRecord::Base
  belongs_to :user
end

A thousand more words:

sano-002

I'm going to do an experiment today

I’ve started learning C# and ASP.NET MVC about 5 or 6 months ago. While learning I’ve developed a clone of Reddit that had a very clear differentiator: you could see the messages and the web page at the same time. When I was close to completion Reddit released exactly that feature. I scrapped that project.

Then I had the idea of making Is it Science Fiction?. I started coding and since the day of the idea to the day of deployment I had one full day of work and four days of part time work. I was really surprised by my productivity, and quite satisfied.

When I started to write some complex features for Is it Science Fiction? I hit a roadblock on writing tests for it. What sometimes is called functional tests are not trivial in ASP.NET MVC. I mean tests that hit controllers properly initialized and the database with some fixtures (but not touching HTTP). I spent three days developing a framework for those kind of tests when I realized I was wasting my time, Rails could do this out of the box.

I’ve decided to re-write Is it Science Fiction? on Ruby on Rails while I was reading Agile Web Development with Rails. Unfortunately, it took me more than a month to do it. I’ve moved to Rails because I thought it was more mature and had many more libraries and utilities that would make me more productive. I was extremely disappointed. But, my first ASP.NET MVC project also took a long time, while I was reading the book; so it’s not fair to compare my time at re-writing Is it Science Fiction? because I was reading a book while doing it and not skipping any part of the book even when it had no application to my current project.

I want to find out how productive I’m in Rails. So I’ve decided to try to do a simple project in a weekend. That day is, starting today. Today I will run the rails command and create the project and if everything goes well, today or tomorrow you’ll be able to use the app. It’s not going to be a very complex app; after all it’s only one weekend and I do aim to having tests and clean code. I’ll try to post as I go along so my blog is going to be quite noisy.

The project code name is Sano, it means health in Esperanto. It’s a health tracker. Both my wife and me want to be more healthy and the first step of course is for me to code an app for it. Let’s start with a spec for Sano.

Sano

Sano is a health tracker that can track many different health parameters of a person. The goal is for that person to have a clear view of how healthy they are and their health trends (am I getting better or worse?). It should also be a good tool to convey clear scientific non-biased information to a medic when the users needs that.

Countries that doesnt use SI
Countries that doesn't use SI

All units of measurement will be SI. My apologies to those three countries in the world that have not adopted these units and are using weird obsolete old units. Grow up!

Authentication

A user should be able to use the site without doing absolutely any authentication. The user should be able to enter data, see tables, see charts and all that information is stored in reference to a “ghost user”, that is session only. If the user closes the browser all that data will become inaccessible. The user will be warned several times about the potential losing of data if they are trying the application in this fashion. The warnings would be as notices on the page itself and if possible a pop up when closing the page.

For logging in, Sano will use OpenID and only OpenID with the usual friendly login pages. No other information will be asked and no registration page will exist. Users already in the system will log in to see their previous records, the rest will register on the fly silently. If a user has session data before logging in (previous paragraph), that data is going to be merged with their authenticated user.

The site won’t have any publicly viewable section. Even the sections that you can see without logging in are shown differently user by user. In a sense it’s like Facebook.

Profile

The profile of a user will be a set of meta-data associated with that user. It will contain the following fields:

  • name: the real name of a person (not broken into last name and first name, because that doesn’t make any sense; how would Madonna use my system?)
  • email
  • height (consideration: what about varying height? like in children, for version 2 or 3 or 23)
  • gender
  • birth date (important to know the age, maybe).

all fields are going to be optional.

Trackers

Sano will start with two trackers:

  • weight
  • blood pressure (systolic, diastolic and pulse)

Each of the trackers will have its own CRUD to add data and will be implemented as standalone controllers (that meaning no meta-tracker that can track anything astronaut-architect-style).

Each of the data points will be stored with time and date (most weight trackers only track date; this will allow for time variation compensation) and the form should allow the user to enter a data point as happened now (or just now) but also with a specific date and time (don’t ask for any more precision than the hour of the day, but store up to the seconds, just in case).

Every tracker should have a table for updating, deleting and exporting (it should export to CSV) but also a graphic view that is tracker dependant.

Weight tracker

The weight tracker asks only for one number: the weight. The first iteration will work only with kilograms.

The weight tracker will ask you to complete your profile to include your height to be able to calculate the range of acceptable weight.

In the table view three colors will be used, red, yellow and green to show under or over weights according to your height, gender and maybe age.

The chart should be a simple line chart at the beginning. In a second version it should have a weighted average according to the Hacker’s Diet rules.

Blood pressure tracker

Three pieces of information will be asked in this tracker:

  • systolic
  • diastolic
  • pulse

The table view again will use the red, green and yellow colors to show dangerous values.

The chart should be a bar chart showing sets of three bars (one for each measurement). Each of the three vars will be in a different tone of green to be able to distinguish them and when they reach dangerous levels they will turn yellow and red with different tones accordingly.

Dashboard

The dashboard is a chart of all or most of the data you have in the system. A one place to look at your current health.

Third party access

All the data in the system is private and sensitive so it’ll be kept private. But, a very important aspect of the system is to give other selected people access to your data.  There will be two ways to grant a third party person access to the system: permanent or temporary (both are revokable at any time).

The permanent access would mean giving access to another registered user in the system. That’s most likely your main medic or a medic that’s treating you. Consideration: what about write access to a trusted third party that helps keep track, what about allowing your medic to add information or annotations that require your approval?

It would be nice to be able to keep that kind of close relationship with a medic, but it’s not very realistic. So there’s a temporary access system. You will log in to your account and generate a token for half an hour access to your profile. The person that gets the token will be able to see your profile for half an hour. The use case is that you go to the doctor, you pick your phone (potentially while you are at the weighting room), log in to Sano, generate the token and the URL would be displayed big on the screen. You can then show your phone to your medic and he/she would have half an hour access to your data.

Let’s code!

It’s not a huge app, but it’s not a hello-world either. I don’t plan to be able to do all of it on one weekend and there are some parts, like charts, which I desgined without knowing the capabilities of available charting libraries. It may not be possible to do some of the things I mentioned without writing some custom charting which is out of the question.

Since my goal is to have something deployed, as soon as it is barely usable I will deploy it, and then I’ll keep adding features until the end of the weekend (or whenever I have to stop).

Sano is the code name for the app, I’m not sure about the public name. If you have any suggestion with an available domain name, please let me know (note: I won’t buy domain names unless you are doing it out of good faith and selling it for no more than 200% of its cost).

That’s all, let’s code!!!