Unisys12's Blog

My adventures, trials & tribulations of learning web development as a hobby! I mean... who does that?


Employee Log Project Part I

Phillip Jackson - 2015-02-21 15:31:08
Project Rewrite using Laravel 5 and Host of Others

This is a project that I wrote and deployed, at this time, 2 years ago. The project originally started further back than that, as individual overly complicated PHP files. One performed action to capture mileage data and the other acted as a time-sheet. Both were written during a time when I was just beginning to learn PHP and just horrible. The later, deployed project, was written using Codeigniter v2.3 and works. I still using it to this very day, but as with most projects, it is time for an over-haul. On that note, I felt that it would be best to cover the users flow, as well as what the app does and does not do well and use those notes as a starting point before starting this new project.

Current Working Infrastructure

As mentioned, the current version of the app is up and running right now on a shared host, purchased by the company I work for (has nothing to do with web development), over at Network Solutions. It is using a MySQL instance for data storage and running some version of PHP v5. Which version? Who knows! I don't really feel like put a file on my current site that spits out phpinfo(), because I really don't care. I am out of there and that is all that matters to me right now. Since this is on a shared host, I am currently using FTP for changes and updates.

On the front-end, I used Zurb Foundation 4 and compiled all the Sass files together using Compass. I am leveraging a custom built Modernizer package and a HTMLShiv to get the date pickers to work on older version of Firefox and IE, but... that is irrelevant now. You can take a look at the project over on my Github account.

What I Will Be Changing

Suffice it to say, everything. On the back-end, the new app will be hosted on Heroku, running PHP v5.6 with, of course, Laravel 5 as the project framework. I will leverage Heroku's 'Auto Deploy' feature with Github. Instead of MySQL, which I have no problem with, I am going to use MongoDB. Why? Well, just for the sack of experience. This is not typically a good practice, using something in a production app that you have no experience with, but this is my app, so... I will break that rule. As for my data-store of choice, there may be better solutions, but I feel like Mongo is well documented and has a good user community and install base, so... why not? Anytime you can "safely" gain experience with a new or different technology, in this case - a NoSQL data-store, I think you should. Even if you fail! Since this app is going to be very database intensive, I will leverage caching... a lot. For that, I am going to play around with Redis as well, which is another service I have never played with. Caching in Laravel, yes. Redis... No.

On the front-end, again, everything is changing. I will not use a CSS framework. Not that I don't like any of the currently available options (that's a post for another day), I need the experience of writing and better understanding grids, layouts and working through the design and code implications of the decisions I make. On that note, as far as the grid goes, I am going to try and use Flexbox, because it's so nice. Only issue I may run into will be the Android browser that most of our techs use. Rewriting a project is one thing, but changing someone's mind can be a monumental task. I will be leveraging Sass, which I do have plenty of experience with, but this time leveraging the SCSS syntax of the language. Also, I will include Autoprefixer, which will allow me to worry myself only with the core element syntax and save myself with research on vendor-prefixes. To wrap things up into a cute little package, I will be using Elixir, which comes bundled with Laravel 5 and leverage Gulp as it's core. Elixir acts as a asset pipeline for your projects and I am looking forward to getting up to speed with it's workflow.

"But what about JavaScript?" Well, there really isn't going to be any right now. I have some thoughts rattling around in my head, at the moment. But until then, there is nothing that I need to do with JavaScript that I cannot do with CSS, so... Yeah, it's a thing. And another post for another time.

Mileage Tracking User Flow

login screen

User logs in and is greeted with a fairly bland list of links.

home_screen

The user clicks the mileage link.

mileage form

If it's the start of a new work day, the view looks like the image above. The user clicks the Date field, the users native calendar is displayed and they chose the date. Basically, click "Ok". They then enter the odometer reading from their vehicle into the "Starting Odometer" field and click the "Submit" button.

If it's the end of a work day, they select the date, and enter the ending odometer reading, from their vehicle. Followed by any notes pertaining to the day (vehicle maintenance performed or troubles, etc) and press the "Submit" button. This updates the previously made row for that day with the new information.

Note the file upload area, "Add Receipt to Today's Report"? That never really worked they way I expected and will cover that more later.

mileage summary form

To generate a mileage summary report, the user will click the mileage summary link, from the mileage form. This leads them to a form with only two fields. A starting date and an ending date is required. Upon submission, the above view is displayed, showing the date range, which can be updated, and all the dates and info available for that user during that time span.

printable mileage summary report

To generate a printable format from the info gathered, the user will click the "Print" button. This generates the clean table above. To print, from my phone, I can use Google Cloud Print or from an iOS device you can use AirPrint or one of the many other services out there. But we still ran into problems and mainly performed this action, at the shop, where we could easily print the report. Most of the time, when not able to get to the office, we could save the page as a PDF, then email this file to the office.

Time Tracking User Flow

home_screen

User clicks the link for Timesheet

timesheet form

The name field is auto filled based on the authenticated user. The user chooses the date for the entry. Selects holiday, if it is a holiday. Since it is given that we all work 8 hour shifts, a value of 8 is the default value for time worked. If the user used sick or vacation time on this day, they edit the hours worked field and any other necessary fields. Then click "Submit". Upon submission, the user is taken to a Timesheet Summary form, where the user can select a date range to generate a time sheet.

timesheet summary

Pretty much the same workflow as the mileage summary report from above.

printable time sheet summary report

Represents printable time sheet summary

What Doesn't Work and How I Proposal to Fix It

Problem - About the receipt upload issue in the mileage form? I found it not worth the trouble to navigate through Androids folders to find the image I took earlier that day. Actually, at the time I wrote this app, I was using a Blackberry so... I have everything in place to validate the MIME, move the file to a new location and store the path to that file in the database. Honestly, I just never used it because of this.

Proposal - Use the HTML Media Capture method to streamline the process. By using this API, I can simply click a button and the phones camera will automatically launch. I take the picture and the path to the image is saved in the form input. Handle it as normal from there.


Problem - Printing summaries turned out to be a real pain point. Entering the info works ok, but at the end of the day, the apps usefulness is judged by how well you can work with the data you put into it. Given this very important pain point, the app is basically a failure in my eyes.

Proposal - Incorporate an email option that will allow the employee/user to simply email a auto-generated PDF of the page. Since we have to sign these documents, I will scan images of each employee's signature, convert these into SVG's and incorporate this into the generated file.


Problem - Time sheet summary reports are generally entered at or close to the end of a time period. Since the workflow currently in place was designed more for daily entry, this becomes a fairly tedious task and not something that I did not for-see.

Proposal - Automate the entry of days worked. This could be done by monitoring the submission of mileage data. If that event is found, then automatically perform an entry for that same day. Upon generating the summary report, give the user the ability to edit the summary report to better reflect the hours worked.


Problem - The app does not currently track vacation or sick hours remaining to an employee.

Proposal - Add employee's hire date to their profile. Based on their hire date, we can figure how many days of vacation or sick time the employee has. This can then be reported on the employee's profile page, once logged in.


Problem - In the code base for generating the summary reports, I am utilizing MySQL Views, which is probably not the best solution from a performance stand point. Then again, it may be the simpliest. We will see...

    public function monthlyViewCreation(){

    /* Creates a view, if one does not exist, or Replace the data if the view
     * does currently exist, and populates it with the date, starting odometer,
     * ending odometer. I use the SUM() aggregrite function to subtracte the
     * ending odometer from the starting odometer, which gives me the total
     * miles driven for the day.
     */

        $q = "CREATE OR REPLACE VIEW daily_summary AS
            SELECT `date`, `start`, `end`,
            SUM(end-start) as `total`
            FROM `mileage`
            WHERE `date`
            BETWEEN ? AND ?
            GROUP BY `date`";

        $starting_range = $this->input->post('starting_range', TRUE);
        $ending_range = $this->input->post('ending_range', TRUE);

        $this->db->query($q, array($starting_range, $ending_range));

    }

Proposal - Currently no proposal for this, but since I have no experience with MongoDB, we will cross that bridge when we come to it. Honestly, if I had to gander a guess at this right now, it would be that I will not be using the database at all for this, in the new app. I will simple return a Laravel Collection object, which will allow me to tweak and twist it when outputting to the view.

LARAVEL 5, LARAVEL, MONGODB, REDIS, TIMESHEET, LEARNING, PHP, CSS3, SASS, SCSS
comments powered by Disqus