Krane — Simplifying Daily Reports
Drawing inspiration from my previous life in the construction industry, I set out to improve a process that desperately needed help across the board, Daily Site Reports. Used to track daily construction progress on a given project, they are also essential documents to rely on when things go south in the legal department. Not to mention they are a mundane daily task that no project field staff enjoys, and the processes for them have been typically very time consuming and inconsistent, any help to make this a painless and quick process would be beneficial.
The Gameplan:
My general approach to this project was to build up the functionality layer by layer. I began conceptually with sketches of my database structure, webpage layout, what models to include, etc. This then gave me a guide to follow to create the file structure, where I then created all my folders, config.ru, environment.rb, migrations, readme, gemfile, etc. along with the blank template ruby files within the /app folders.
After creating the base file structure I completed the configuration files and set up the database. Outlined my routes in each controller file, created each model, flushed out each route within the controllers. After the routes were all roughed out, I added each view with basic HTML in order to get everything functional and data processing correctly.
Once the basic website was working correctly, I weaved in more functionality, including the data validation (using both HTML form validation and ActiveRecord ‘validate’ methods), user logins, sessions, and password encryption (via bCrypt), and finally CSS to make everything pretty.
Greatest Takeaways:
Implementing CSS and dynamically generating HTML from database elements
The most enjoyable part of the project was the front-end development. Once it was time to develop views, CSS, and optimize the controllers, things started to move right along. Following my layered approach, I initially created each view without any CSS styling, using only basic HTML headings and line breaks.
I worked out how to utilize embedded ruby to iterate through multiple database items to not only generate simple checkbox or radio button lists, but to create ‘summary’ items that would show a select amount of data for each daily report, project, or user on their respective index pages.
Once I had these pages functional (however, ugly html) I then went back through and adapted each view page to the CSS styling to clean things up, separate out into classes and divisions, and make easier to read.
Custom Rake command
As I was constantly filling up my database with dummy test data and broken, incomplete entries during development, I decided to create a custom rake command to ‘reseed’ my database periodically. The $rake db:reseed command calls the db:drop, db:create, db:migrate, and db:seed commands to clear everything out, recreate the database and fill it back up with my valid seed data, all from one single command.
Challenges:
Setting up the database and relationships
My largest hurdle was at the start of the project, setting up the file structure, active record, and database. For me, this area was the least intuitive, and found myself referencing previous labs extensively. I did not want to use any templates or generators for the MVC file structure to force myself to understand the requirements and best practices.
I struggled to get the development environment functioning properly with ActiveRecord and getting any connection to my database file. (turns out my problem was some settings in my database.yml file not defaulting to the development environment.)
Handling the params[] hash and complex forms
Early in the development of my HTML forms, I struggled to get the data organized correctly into the params hash. To create a new User or Daily Report for example, I had to create a new instance of the object, iterate over the params hash and assign each param attribute separately to the object attributes, and then save the object. This was a case where the code worked, but was not efficient or scalable to changing data, therefore I kept working at it to refactor and abstract it.
I discovered that if the param keys submitted from the html form matched the database column names for that attribute, I could simply pass in the whole params hash into the Active Record ‘create’ method. Turning 5–10 lines of code into one or two. (eliminating an entire explicit ‘.each’ iteration loop.)
Lessons Learned:
In the end, I feel my weakest area was the CSS and HMTL formatting. After working through issues and bugs with Sinatra, ActiveRecord, and Embedded Ruby files, the implementation of CSS still felt rough. This was likely a cause of simple inexperience, and time constraints as it was the last phase of the project coupled with a lower weight on the final outcome than the other areas.
Even though this was a class project, I tried to keep my head in a mindset that this was for a real client, to create models, routes, forms that could be scalable as a company grows and adds more data to track. If this project was to continue, the next couple features I would like to add are filtering and sorting functionality to index pages, making these more dynamic, as well as a way do download reports to a file. (such as .pdf for example)
Conclusion:
Overall I enjoyed this project tremendously. Many of the separate pieces we have been learning finally had a chance to come together and work as a complete app. Many elements started clicking in my head and the time I spent ‘per-error’ reduced drastically by the end of the project as I understood more and more what caused each one.
I am looking forward to the next lessons and how to make these applications more dynamic!