Dex is a productivity application inspired by Trello. Dex enables users to organize projects by dividing the project into phases and assigning tasks to each phase.
Users can invite other users to contribute to their projects. All of a project's team members can create phases of a task, create tasks for each phase, assign tasks to other users, and move tasks through the phases of their project. [#Gif here]
Every member of our team is a full stack engineer and worked on every part of the application. Each member also has primary authorship of at least one part of the application.
was the project manager. He built the Edit Card modal and the New Card modal and connected them to the back end using an http service.
connected the front end and back end. On the front end, he built the http service and authentication service. On the back end, he built routes and database models for cards, decks, and tables. He also wrote custom authorization middleware, a try/catch utility, and this ReadMe.
oversaw UI/UX, together with Laine Doud-Eisenbart. She made tough design decisions, mocked our site with wireframes #link, and wrote much of our CSS. On the back end, she contributed to the route handlers for cards.
wrote authentication middleware for registering a new user and for authenticating a logged in user using JSON web tokens and cookies. Together with Laine Doud-Eisenbart, he created an invitation feature that sends an html-styled email inviting a user to join a project and, if applicable, to join Dex. DJ deployed our application with AWS and Docker.
wrote the Users route handlers, and associated database models, debugged authentication middleware, and deployed our database with AWS. She styled the card thumbnail component, table controls, and nav bar with React Bootstrap and CSS flexbox.
created the table view that shows all the tasks for a particular project. The table view includes several React components: Table, Deck, Card Thumbnail, Controls, and Table Settings. Michael also wrote the front end search and filter logic.
designed and implemented our relational database, which includes eight tables and three join tables. He also wrote the most complex queries1 and implemented a trigger system for broadcasting live updates on the database. He prototyped a WebSocket connection for consuming these live updates and plans to implement it on a forthcoming version of Dex. Zona also optimized our production build.
was part of the UI/UX team. Together with Brooke, Laine designed the UI, prototyped it with wireframes #link, and contributed much to the CSS. Laine also built the dashboard view, which displays a user's projects and tasks. Together with DJ Park, Laine created an invitation feature that sends an html-styled email inviting a user to join a project and, if applicable, to join Dex.
built the nav bar and the view for creating a new table. He also created our logo and favicon.
We employed the Agile methodology and managed tasks with a ticketing system. We worked on feature git branches of a development branch, which was finally merged to a master branch. Every pull request was associated with a ticket and reviewed by another team member before being merged. We also pair programmed when appropriate.
We synced our github repo to TravisCI, with the goal of maintaining at least 80% test coverage on all submitted code, but extreme time pressure (a delivery time of eight days) limited our ability to write tests. As a result, bugs frequently crept into our code base. In order to address this problem within our time constraints, we increased scrutiny of submitted code and pulled approved code into a development branch, pulling into the master only when confident the development branch was bug free. Going forward, we would prefer to have complete test coverage and continuous integration.
In early days of the project, we experienced frequent merge conflicts. To address this difficulty we developed a strict git workflow whereby every feature branch must be up to date with the dev branch before pulling into the dev branch.
Most of our technical difficulties were due to the complexity of our data: we have eight related SQL tables and 26 api endpoints. A significant portion of our time was spent designing the database, implementing the database models, and writing route handlers. Production of the front end was slow until we had a live back end. We think SQL is the correct choice for highly relational data, but using MongoDB would have streamlined production significantly and left more time to develop the front end.
1One of Zona's queries:
select
c.id,
c.title,
c.description,
c.due_date,
c.weight,
c.impact,
c.table_id,
c.deck_id,
array_agg(
json_build_object(
'member_id', cast(u.id as varchar),
'member_name', u.name
)
) as cards_members,
array_agg(
json_build_object(
'id', l.id,
'label_name', l.label_name,
'color', l.color
)
) as card_labels
from
cards c
left outer join cards_members cm on c.id = cm.card_id
left join users u on cm.user_id = u.id
left outer join cards_labels cl on c.id = cl.card_id
left join labels l on cl.label_id = l.id
where c.id = $1
group by c.id;