For fitness reasons, I have been logging my diet and weight for most of the last 1.5 years. At first, I started with just paper and pen but quickly found it cumbersome to carry a notebook with me whenever I wanted to log.

I quickly moved on to using Google Sheets to keep track of everything. This solved the issue of portability and even cross platform accessibility. However, as I continue to log every single day I have noticed these problems:

  1. Annoying to have to scroll through previous data to get to enter today's entry
  2. Can't keep a history of meals to avoid retyping
  3. Have to manually calculate 7 day average of weight
  4. Mobile app for sheets is buggy (sometimes doesn't load data past the first 1000 rows)
  5. Limited graphing option and graph layout isn't ideal for viewing

Given that logging is now an important part of my life, I have decided to build a web app called DashFit to handle all the fitness related data input/storage/display.

Choosing a development stack

The first order of business is to choose a development stack. At the time of writing, there are more than a dozen popular development stacks.

From previous project experience, I believe it is important to start off with good code architecture to make maintenance and updates easy. Part of this comes from choosing the right stack.

In the UI department, one library that stands out is React. Treating your UI as reusable modules will aid in clarity and long term maintainability. A downside from using React is that it requires building/pre-processing.

I want to keep the build tools as simple as possible, since many of the fancier tools go out of date fairly quickly and have a steep learning curve. My build tool of choice is WebPack, which is simple to use and not hard to learn. The idea behind WebPack is elegant: imagine your dependencies as a tree where each node is a module and edges are requires, you basically provide it the root (react file where you do all the requires) and it traverses the tree until it loads all the dependencies and their respective dependencies.

In terms of the back end, I see no reason to move away from Express and mongoDB. So all in all, I am using the MERN stack (mongo, express, react, node).

Thinking in React

Using React is like learning web development all over again. The thinking in React is very different from any UI work I have done before and one such aspect is styling.

React seems to advocate(they have since taken down the article as of March 2017) inline styling, something that I do not agree with - so I will instead use LESS and style elements like I have always done. However, I also see value in React's way of thinking - which is to keep components their own respective, independent unit including its own styling.

As such, I will use LESS as a preprocessor and organize my file structure such that each component has its own stylesheet in development that gets bundled together for production.



Notice that the react code also lives in its own folder. WebPack will bundle these as well for production.


  1. User authorization system
    • Use Passport.js to support email login
  2. Weight logging
    • Table view of weight for the week
    • Ability to view and edit week data
    • Undo redo
    • Accept kg. and lb. input
  3. Diet logging
    • Table view of daily caloric intake for the day and week
    • Ability to store custom recipes and their calories/protein
    • Auto complete input based on previous recipes
  4. Data visualization
    • Graph weekly average of weight

Update 1 (10/21/17):

It's been a while but I have been implementing the aforementioned feature throughout the summer. The code can be found on github.

The original feature list now looks like:

  1. User authorization system
    • Use Passport.js to support email login
  2. Weight logging
    • Table view of weight for the week
    • Ability to view and edit week data
    • Undo redo
    • Accept kg. and lb. input
  3. Diet logging
    • Table view of daily caloric intake for the day and week
    • Ability to store custom recipes and their calories/protein
    • Auto complete input based on previous recipes
  4. Data visualization
    • Graph weekly average of weight

So I would say that the core features are implemented but the bells and whistles should still be added on at some point.

Here is what the webpages look like as of now:

This is the first page that I ended up implementing. I wanted the UI to have a modern, lightweight feel so lots of whitespace and simplicity is what I ended up going with.

For styling, I used skeleton as a starting point and LESS as my preprocessor. React is amazingly fast thanks to their virtual DOM diffing process. Lastly, for layout I went for a standard dashboard theme. This design was highly inspired by the dashboard template for Bootstrap but I ended up building the website from grounds up. This is the initial layout I was going with:

You could probably see the similatiry between that and the current design, except I stripped away the color scheme in favor of a flatter tone.

React's modular nature also made it easy to organize components. For each tab on the left (log weight, visualize, log meals), I have defined "widget" that acts as a kind of scaffolding that calls all the components in the page and brings them all to a functional "sub-app".

For this part, I used the react plotting library Recharts. This library had some issues that I ended up actually helping identify but for personal project plotting I think it works well enough but I would be hesistant using it in a production environment.

Pictured above is my weight trend for the last ~2 years. The purple line is the daily weight and the green line is the weekly average.

At this point, I was fed up with the way states were kept. Specifically, they have to "bubble" up to a parent component.

Thankfully, React has a solution for this: Flux! I implemented the meal log using this and I must say: its design philosophy is simply elegant and makes building large UIs much more manageable.

Additionally, it makes code more readable and less likely to fail from improper handling of data.

Right now, I am thinking about refactoring the first two parts of the code using Flux so will likely implement the missing features when I find time for that.

CrossPack Tutorial

Programming Mictrocontroller Without Arduino

Programming with the Arduino IDE and utilizing its included libraries is nice, but oftentimes Arduino abstracts away crucial details that have to be accounted for in more complicated projects. I thought it would be a good opportunity to move closer to the hardware level and to program the AVR microcontroller in C for my upcoming project, using command line utilities neatly packaged by CrossPack.

As a test, I wrote a simple script targeted for an ATTiny85 to output a 50 Hz square wave on one of its pins using the template from running avr-project Demo:

#include <avr/io.h>
#include <util/delay.h>

int main(void)  
    DDRB = 0x01;    //Set PB0 as output
        PORTB ^= 0x01;  //Toggle PB0 
    return 0;   /* never reached */

The makefile configuration that came with CrossPack's demo template worked extremely well in simplifying the compile and flashing process, the changes I had to make were the following lines (note that your programmer may appear differently in your file system than mine, but it should be along the lines of /dev/tty.* for OSX):

DEVICE     = attiny85  
CLOCK      = 8000000  
PROGRAMMER = -c stk500v1 -b 19200 -P /dev/tty.usbmodem1411 #Settings for ArduinoISP  
OBJECTS    = main.o  
FUSES      = -U hfuse:w:0xdf:m -U lfuse:w:0xe2:m    #default fuses for ATtiny85 without clock division  


  • use avrdude -p ? to list the supported AVR devices.
  • find the Arduino ISP using ls /dev/tty.*
  • you MUST use -c stk500v1 and provide the baud rate of 19200 if using Arduino as programmer
  • fuse calcululator

To program an AVR chip, you must have a programmer. A popular choice is something like the AVR pocket programmer, but if you're like me and don't want to wait the shipping, an Arduino Uno can actually be programmed to be a programmer that you likely have around the shop! So, the first order of business is to flash the Arduino with the ArduinoISP (ISP stands for in-system programmer) sketch from File->Examples. Then, we connect the Uno like so to the Tiny:

The command make flash produced the following:

avrdude -c stk500v1 -b 19200 -P /dev/tty.usbmodem1411 -p attiny85 -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e930b  
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed  
         To disable this feature, specify the -D option.
avrdude: erasing chip  
avrdude: reading input file "main.hex"  
avrdude: writing flash (78 bytes):

Writing | ################################################## | 100% 0.18s

avrdude: 78 bytes of flash written  
avrdude: verifying flash memory against main.hex:  
avrdude: load data flash data from input file main.hex:  
avrdude: input file main.hex contains 78 bytes  
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.09s

avrdude: verifying ...  
avrdude: 78 bytes of flash verified

avrdude: safemode: Fuses OK (H:FF, E:DF, L:E2)

avrdude done.  Thank you.  

Upon checking the fuse, it turns out that the version of avrdude that came in CrossPack is the version that had a label typo when displaying the fuse values at the end, so it should really read: Fuses OK (E:FF, H:DF, L:E2).

The code above used up a total of 164 bytes of flash, whereas the same code (functionally) written using Arduino API:

void setup() {  

void loop() {  

resulted in a 932 bytes of flash usage. That's a substantial difference especially when we're working with devices equipped with only tens of Kbytes of flash.

So be brave, go out there and program your AVRs with the command line utilities and free yourself from the chains of Arduino.