Conceptual

Basic Overview of Routelandia

• Android app presents travel times on highways near Portland
• Historical data
• What do traffic cycles look like?
• Lets you know best time to hit highway

Data Into Information

• Transportation data collection through Various applications and technologies
  • Traffic Detectors
  • Data Base Management System
  • 3 TB of Traffic Data
• Intelligent Transportation Systems & Portal
  • A powerful feature of information is performance-based trend representation.
  • Collection
  • Prediction and diagnostics by statistical inference
  • Visualization and analysis on parameters of interest
  • Performance trend
  • Optimization and evolutionary adaptation of daily performance

Demo

Development

Who did what?

We split up into teams!

• Front end
  • Nasim: UI/UX of front-end, visual statistics plot, marker and map interaction, date and time picker, splash screen.
  • Loc uses data from the backend draw highway in the map and sets up CI
  • John did QA
• Back end
  • Josh is leader and bearded wizard
  • Peter is tall wizard. Wrote PHP and coordinated API structure with front-end
  • Jesse is test wizard. Wrote the testing enviornment

So, who did what? I split the teams up into three separate groups initially: Front-end, Back-end and UI design. UI design was a temporary team composed of Nasim and Jesse. They were responsible with coming up with the look of the front-end app. Once that was finished, I re-assigned Nasim to the front-end and Jesse to the back-end.

NEXT FRAGMENT - PRESS DOWN!!!

The front-end was composed of Loc, John and later Nasim. Loc was put in charge of the sub-group and responsible for putting down the groundwork for the application. Nasim implemented several of the graphical features such as the splash screen, date and time picker, and statistics plot. John worked on testing and doing QA work.

NEXT FRAGMENT - PRESS DOWN!!!

The back-end had Josh, Peter and then Jesse. Josh was the lead, bearded Wizard (their choice of title) and laid the foundation for the server application as well as writing the Postgres queries. Peter wrote lots of PHP code and took the lead with working with the Front-end and decided how the API structure would be implemented. When Jesse came on board, because of his experience writing test code at work, he took over the role of writing the entire test suite.

Method and Process

• "Full time Student" agile
  • No daily stand ups
  • Weekly meetings and goal setting
• Schedule changes
• Handoff process

Each of our schedules varied greatly. John has a full-time work schedule, Nasim is a student at two universities, Jesse has a job and a family. With this situation, we had to adopt a "modified" agile development method. It was not possible to hold daily standups, but we did have weekly meetings where we tracked our progress and set goals for the following week.

Since our last presentation, we've had a few changes to the schedule we laid out for ourselves. For example, we were unable to implement highway chaining, but refined our monthly milestones such as successfully drawing lines over the freeways where there was data and writing queries for route statistics.

Our handoff is pretty simple. Since our software is free, Portal will only need to deploy a build on their servers which the app on the Playstore will reference. No signing over rights or IP is necessary for this project.

Tools Used

• Postgres
• Java
  • Android
  • PolyUtil
  • AChartEngine
• PHP
  • Restler
  • respect/relational
  • behat
• Github
  • Source Code Management
  • Issue Tracking
  • Code Reviews

Retrospective

Challenges

• Clicking near the line?
• Limited only to highway data
  • This was a deliberate choice
• Currently cannot generate statistics across multiple highways

What we would've done differently

• Backend would use different frameworks
  • Different language if possible
  • The frameworks we used had little support
• Setting up a testing environment immediately
• Using android hardware instead android emulation
  • Android emulation was incredibly slow
  • Made programming a very slow and frustrating process
• Different strategies for front end communication and issue tracking
  • Backend and frontend teams used different management strategies

First off in the backend, we would’ve wanted to choose different frameowrks The frameworks for PHP we were using didn’t have much support or documentation which made debugging difficult.

Something both the front end and back end didn’t do was setting up a proper testing environment before we started writing code.

Front end initially assumed that android studios native android emulator would be sufficient enough to work on. However the emulator ran incredibly slow on our machines, to the point of making programming an incredibly frustrating process spending lots of time waiting instead of being productive. By the end front end had a couple of old android phones being shared between them which turned out to be better.

Backend had the advantage of having someone with previous technical leadership experience, so we were able to set up a schedule we could all work in from the get-go that kept us on the same page.

If we had more time

• IOS App
  • Backend would not have to change
  • Whole team could work on it
• Multi-freeway routing
  • Originally planned to be in product
  • Became stretch goal after major design change
  • Would require pg_routing and design change to Portal database
• Error reporting
  • Ask the user if our prediction was close
  • Serve as a tool to help Portal highlight missing or incorrect data

If we were where we are at now a month ago, we would’ve started working on an iOS app. Most of the team could work on it since the API wouldn’t change, and we could use the lessons we learned from building the android app and apply them.

However before we started the iOS app we’d want to work on multi-highway routing first because this was initially supposed to be in the app but had to be made a stretch goal after we did a major design change in terms of how the app communicated with the server. We discussed a lot of kind’ve hacky ways to go about it but would want to avoid because they relied on PHP doing the number crunching instead of keeping all that heavy computation inside the database. After some research we discovered pg_routing would best tool to suit our needs but it would require some non-trivial design changes in the PORTAL database which would take time than we had to implement.

Finally we wanted to add some kind of error reporting as a tool for us and Portal to highlight missing or incorrect data in the Portal database. This would let us know how far off the mark our predictions were for travel time.

What we learned

• Backend Lessons:
  • How to code in PHP
  • About model/view controller coding
  • How to work with behavior driven development testing tools
• Frontend Lessons:
  • How to code an android app
  • The importance of Google API keys
  • How to setup a continuous integration service
• Group Lessons:
  • Working on a group coding project for the first time
  • About rest-ful api construction
  • How to use GitHub and merge requests and the importance of code reviews