FitnessJiffy (Java / Spring Framework version)
- Intro and Background
- Technologies Used
- Previous Technologies Used Along the Way
- Application Features and Screenshots
Intro and Background
FitnessJiffy is an application for tracking diet and exercise, and generating charts and reports for health information over time. Under the surface though, it's really a self-learning and teaching tool. I've written numerous versions of this application over the years, every time I want some deeper experience in learning a new programming language or framework.
This version is based on Java and the Spring Framework. Although these have long been the primary tools in my professional career, I wrote this version of the app as an excuse to explore Spring Boot. I used the code and build process here as the basis for a lengthy blog post on Spring Boot (http://steveperkins.com/use-spring-boot-next-project), which was linked from the Spring website and drew a bit of attention in that community.
If you're looking for a robust sample application to get started with Spring Boot, then you've come to right place.
In addition to Spring Boot, this application makes use of technologies including:
- Java 8
- Spring Boot
- Spring Data JPA
- Spring Security
- MySQL (with H2 for unit testing)
- JSR-305 annotations
- Thymeleaf templates
- Twitter Bootstrap
Previous Technologies Used Along the Way
If you go splunking through the commit history, you'll find the following:
- Google Guava
- No longer necessary after the move from Java 7 to Java 8
- Likewise replaced by the Java 8 standard library
- I know PostgreSQL is more feature-rich than MySQL, and is trendy among developers right now. However, I needed to improve my hands-on familiarity with MySQL due to some professional work (dev features or not, MySQL blows PostgreSQL away when it comes to ops support for replication and scalability). Since this is a small open source application, the wide availability of cheap MySQL hosting doesn't hurt either.
- Apache Maven
Application Features and Screenshots
(click on a screenshot thumbnail to see its full size)
Login and logout is built around Spring Security, with some custom event-handling hooks. In the future, I might add OpenID or OAuth support, to let users authenticate through an existing account with some provider (e.g. Google, Yahoo, etc).
More importantly, there is not yet a "Create User" function in the web application. Users must be created in the database manually. This is not so much due to the complexity of adding a "Create User" page, but rather due to not yet being ready to open it up a hosted version of the application for public use.
However, the Flyway database scripts do create an initial test user for you, with username
firstname.lastname@example.org and password
Users can track their weight on a daily basis, and their profile will show their current body-mass index (BMI) and the estimated number of daily calories needed to maintain their current weight:
Tracking and editing of foods eaten each day:
The database includes a built-in set of "global" foods, which are visible to all users but cannot be modified. When a user modifies a "global" food, or simply creates a new food from scratch, then a food is created in that user's "private" set of foods. This is all transparent to the user.
The database includes comprehensive data on over 800 exercises, taken from the 2011 Compendium of Physical Activities. By using the user's weight on the date when an exercise was performed, FitnessJiffy can calculate how many calories were burned by that particular user.
Users have quick access to recently-performed exercises (i.e. within the previous two weeks), can search for exercises by full or partial name, and can browse exercises by category.
FitnessJiffy stores for each day a summary of each user's stats (e.g. weight, calories burned, etc), for quick retrieval as JSON so that charts can be rendered and report data summarized on the client-side. Whenever any data pertaining to a user changes, FitnessJiffy schedules a background thread to update that user's report data for the affected data range. This thread is scheduled to run after a five-minute delay, to avoid unnecessary duplication when the user makes multiple changes within a short period of time.