Commit 28f92669 authored by pgicking's avatar pgicking
Browse files

Added next indicators

parent c4767536
......@@ -455,37 +455,29 @@
<aside class="notes">
OWNER: Peter
What we would’ve done differently
NEXT <br />
<p>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. The lack of search results outside of
their main website is something that should’ve sent up red flags in the start during our research.
Respect relational for example, required us to delve into their source code to figure out what was
going on and how to get it to do what we wanted it to do, even for tasks we thought would be simple,
like sending a raw SQL query to the database. The RESTler framework was better, had questions on
stack overflow and barebones documentation allowed us to get by without delving into the source code.</p>
The frameworks for PHP we were using didn’t have much support or documentation which made debugging difficult.
NEXT <br />
<p>Something both the front end and back end didn’t do was setting up a proper testing environment
before we started writing code. For most of the project the backend was testing all the api routes
by hand which caused some niche api routes to break when someone forgot to test every single
one with every commit. In a perfect world code reviews would catch these but some still managed
to slip through the cracks. It also made it hard to debug communication issues between front end
and back end. When frontend would try to call an api route and it would break, it was always initially
unclear if it was actually frontend’s or backend’s code at fault. Usually it was some combination
of both.</p>
before we started writing code. </p>
<br />
<p>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.</p>
<br />
<p>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. Because front end team members, like the rest of the team except josh, were all very
new working in a project like this, they had some issues figuring out what worked for them and how
to really get on their feet in terms of communication, goal setting and issue tracking. If they
could do it over again they would’ve used the same management strategies that backend was using.</p>
same page. </p>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment