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
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.
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?)
- 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!!!
