Embedded Files
This website is still under development and is the stepping stone to the actual one. So please mind the dust!
This was a school group project where we created and fixed features of the school's tutoring website to assist with the transition to the IT department taking and managing it. We used skills learned from previous classes like SCRUM and AGILE development and applying those skills while learning a new programming language called Ruby on Rails that used a Model View Controller pattern which was new to all of us.
This was a school group project where we created and fixed features of the school's tutoring website to assist with the transition to the IT department taking and managing it. We used skills learned from previous classes like SCRUM and AGILE development and applying those skills while learning a new programming language called Ruby on Rails that used a Model View Controller pattern which was new to all of us.
Things We Did
Things We Did
When we started this project at the beginning of the school year, we needed to learn Ruby on Rails including how it works and it's syntax. From there, we worked and fixed bugs like autofill and created features like the bulk import of classes (to assist with the semester transition). Once we had the site fixed and updated, we redeployed and made a new AWS EC2 instance. From there, we were at the end of the school year and we officially signed the project as the last team to work on it.
When we started this project at the beginning of the school year, we needed to learn Ruby on Rails including how it works and it's syntax. From there, we worked and fixed bugs like autofill and created features like the bulk import of classes (to assist with the semester transition). Once we had the site fixed and updated, we redeployed and made a new AWS EC2 instance. From there, we were at the end of the school year and we officially signed the project as the last team to work on it.
My Role
My Role
During the development of the project, my role in the team was the Product Owner Proxy (POP). In which I spent about a third of my time communicating with our Product Owners to ensure that we were creating and fixing problems they deemed important, as well as ensuring we are aware of any issues or concerns that they had.
From here I spent most of my time during developing on the Front End adjusting the site to be more user friendly to everyone, as well as creating new JavaScript features like sorting and autodeletion of courses.
During the development of the project, my role in the team was the Product Owner Proxy (POP). In which I spent about a third of my time communicating with our Product Owners to ensure that we were creating and fixing problems they deemed important, as well as ensuring we are aware of any issues or concerns that they had.
From here I spent most of my time during developing on the Front End adjusting the site to be more user friendly to everyone, as well as creating new JavaScript features like sorting and autodeletion of courses.
How We Got Here
How We Got Here
There were a whole lot of meetings and communication to ensure that we understood what the RCAS team wanted. From there, it was then ensuring that these new features would be secure and up to date in order to meet what IT wanted. Lastly, we mocked up new designs for some pages or how some features worked in order to make things easier to navigate.
Things We Learned
Things We Learned
Throughout the project we would run into issues with team confusion on goals or issues with the tech stack we were working with. We overcame these goals through teamwork and communication, where at the start of each sprint we would ensure that each team member had a strong understanding of the current goals. Once we learned how to manage those issues, we were able to create and update scripts with instructions on installing the docker image we were using as well as automating it further so less manual steps were needed to install all of our necessary tech.
Another skill that we were able to refine was our development of proper tests so that as code was being updated and features were being changed, we were able to stay above 80% code coverage to ensure proper functionality. Aside from just refining skills, we learned how to work in MVC models due to the nature of Ruby on Rails. We learned the importance of keeping functionality separated in this manner. It allowed for us to easily integrate features across the board as well as ensure proper security and data control since only certain views which could access certain models through their controller. This allowed for easier troubleshooting as well since anything for a user would only be in a couple of locations.
Page updated
Google Sites
Report abuse