Sprint Retrospective 6

What seemed like a doomed end for us, eventually our team got great results in the end, even though we started out very rough. In the first few sprints we definitely bit off a lot more than we could chew and almost put the component in jeopardy because of this. But through our team’s efficient refocusing and discussion we had a component that worked. During our final sprint we spent most of the time trying to figure out a lot of the CSS work. One issue that we also ran into was that we had a lot of issue when we were trying to merge our component with others. Eventually we found out that this is mainly due to our node versions being different and our use of Ignite UI imports that were absent in other team’s components. The reason these were absent in other team’s components was because the base angular material design api already included certain components that the other groups needed, whereas our component needed this other library. We ran through the other merge conflicts on git hub and managed to resolve them all with relative ease.

With the various obstacles we overcame, and the points at which it seemed all hope was loss, these sprint taught me a lot. This whole project taught me a lot about team building and resource management. This class gave great insight to our team building skills and how satisfying it was to overcome obstacles as a team. Through collaboration with other teams it was great to finally get past a certain roadblock or figure out that one syntax error that you got stuck on. It was a fun experience working with classmates that I never had worked with before because we all now have a greater sense of what team building is all about. These sprints were a great way for me to really understand what it takes to work together to find a solution, or even by yourself to figure out how to incorporate findings into the team. Although we had a challenging start, we made it to the end. And although not everything is as complete as we would like it to be, it still a great accomplishment.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Sprint-6 Retrospective Blog

The time for the final sprint retrospective blog is here. It is time for Sprint-6 Retrospective Blog Post. As you are probably aware by now, during this semester I was working on a AMPATH project with a team I was assigned to by my Software Development Capstone professor. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of May 6th, 2019, we have completed Sprint-6. During this sixth and final sprint we were able to complete a minimal viable product to show case in our final presentation.  For this final sprint our task was different from the previous ones. For sprint-6 our task involved the following:

  1. Pulling all final changes from team members and integrating new updates.
  2. try to integrate the other teams work with our own.
  3. Divide the work needed to be done by our team for the final presentation of this project.

During this sprint my team and I focus mainly on trying to get the minimal viable product for the project. That way we can have something ready to show for our final presentation. At the beginning of this sprint we decided to use this sprint to focus on wrapping up our project, and working on getting our final presentation ready. We decided to do this approach by first finding out what we should discuss in our presentation and what each of us in the team should and will be talking about. For the final presentation, I will be talking about building the left navigation bar using Angular Material and how I got the buttons to work and on a new page when clicked by using an app routing module.

Beside working on the final presentation I also, spent a lot of time trying to integrate the other team tabs bar with our left navigation bar. I found this process pretty complicated because I ran into a lot of problems. It sadden me to say but trying to integrate the other team tabs with our left navigation bar was an epic fail. I tried many different approaches and nothing works. I also believe that I would have found a solution to this problem if I wasn’t working on a sensitive time frame.

During sprint-6, I’ve learned a little more about Angular Material, and a different approach we could have done in creating the left navigation bar. If there was time I would have tried the different approach and probably would have found a solution to our integration problem. For this sprint I also spent a lot of time working on the final presentation and trying to make sure that the project looks good and it looks like it contains the minimal viable product. From everything done in this sprint I have learned how we should set up and divide the work we have to cover in the final presentation. I can honestly say that everything done in this sprint has been an interesting and worth learning process from how to work with a team and applying everything we have learnt those far in our software development journey. In light of everything I learnt there are a few things that went on during the integration process that requires details explanations or strategies that would be required for handling the integration step differently for next time. For instance integration should have been done earlier on and the approach we were to use in this project should have been something covered earlier on or in either of the third or fourth sprint. That being said this project has proven to be, fun and interesting.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Sprint 5

Hello everyone and welcome back to another sprint blog post for CS 448. Today blog post is about what I did in Sprint 5. In sprint 5 I focus most of my time working on the presentation. I brain several ideas on what I was going to go over in the final presentation day. During this time, our team was working on a specific feature for the Ampath project. During the meetings we would discuss how we would improve the Application. We would help one another when needed and would advise each other on how to improve the in certain areas. During the project we came into a couple problems because in the beginning as I was creating the project I create it in Gitlab instead of GitHub so that a merging error which we eventually got the project to be converted, thanks to Tim who is a member of our group. I believe the merging and converting took a couple’s days, so we had to wait to push certain commits until the project conversion from Gitlab to GitHub. We are still working on merging our component to the group’s component because the problem that we came across was that the alignment wasn’t right. Also, during this sprint, we were looking into library type things in Angular. We also finished keeping an eye out for Zeplin shared folder – where designs will be. I would also like to say during this sprint we work well together as usual and everyone contribute equally. Mike was working on the drop-down box which he added many cool features. I also had many of the of the meetings on Tuesday and Friday done during this week’s sprint. All in all, I learned a lot from this week sprint 5 like that creating a project and GitLab and trying to paste it in GitHub creates major problems and time to fix. I also learned more about how Angular works by working on this Ampath project during this week. I am also improving on working as a group in scrum while working on this project during this week sprint 5. I think the plan for next week is to finish up on the presentation and have a working polished project to present. I believe that we will have those requirements by the end of the next sprint. To finish up this blog post I would like to go over the objectives for this week sprint 5. First, to get the presentation started and have a template of ideas. Second, we would also be close to finished with the application because we were approaching the end of the last sprint week. Finally, to learned more on Angular applications.

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.

Study the Classics

Before I became a Computer Science major and aspiring software craftsman, I was very much into reading what many people would consider “the classics”. Whether it was the Iliad and the Odyssey or A Brief History of Time, I have always been fascinated by works of literature that had such significant content or perspectives on the world that they were revered throughout centuries as “the classics”.

So when I came across this pattern, Study the Classics, I immediately resonated with the context they put forth and their motivation for including it in their book. The solution / action which they suggest to us budding apprentices is to collaborate with others and ask about a concept unfamiliar to us and to try and seek out the book which that concept was written about.

Immediately my mind drifted back to learning the Gang of Four’s software design pattern book, which I know for a fact to be highly revered and considered one of the “classic texts” in our craft. Even when I first read it for school assignments, I was enamored by how rich the concepts were and how articulately they were explained. My learning and overall understanding of software development as a whole is unquestionably markedly better than it ever would have been had I not been exposed to this book.

At the same time, I am aware that as good as this book is, and as valuable and timeless as the information in it is, it is definitely not a holy bible for software developers. There can not exist one text to rule them all, because there is no single entity capable of compiling everything we would possibly want or need to know into a single source. So in the future I will definitely seek out multiple individuals or groups of authors who are very well known and revered in our field, so I can add their works to the collection of books I need to read to be as knowledgeable and as prepared as possible for the uncertain road that lies ahead of me in my journey to competence in software development.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

After what feels to me as almost an eternity and an extremely short time all rolled up into one, we finally reached the end of our final sprint and are ready for our demonstration of our component and by extension work thus far. For me personally, this sprint was pretty chaotic, not because of the work itself but because of my personal situation. However, I have managed to overcome the adversity of my personal situation and am fully prepared to pull my weight at our final presentation. I am also confident with the plan of attack we formulated in the beginning of the sprint, and I have the utmost confidence in my team members as well. Even given my personal setbacks this last week, I would not proceed much differently as far as planning and preparation.

The first thing we did in the beginning of our sixth sprint was to begin preparations for our final presentation to the entire class. It took almost no time at all for Sam and I to decide on an approximate layout for how we are going to present our semesters’ worth of work, struggles, and achievements. Sam was adept at further refining our general topics until we were able to make rough estimations of how much time we should discuss all the topics we decided on.

After we had our foundation for the concepts we are going to cover, we had a full group discussion about who should and / or would prefer to discuss which sections. We divided the work among ourselves almost effortlessly, and then we began the process of fleshing out our skeleton presentation and decided which topics needed to be discussed with more attention to detail and time dedicated, and which topics we would not need the full standard allotted amount of time according to our original timetable. We did hit a bit of a snag trying to fill the criteria that every person in the group should discuss an even level of technical detail. This minor setback was just a consequence of the nature of presenting; somebody has to do the introduction and the wrap up. On top of that, we definitely didn’t want one person stuck with all the hard parts to discuss. Thankfully, we fleshed out a solid means of distributing the complicated parts of our project evenly among us. This part of the sprint I feel confidently that our group excelled at, as the plan came from a basic concept to an actual solid foundation in little time, expending little energy, and having no disagreements.

This point of the sprint however was when I became once more acquainted with Murphy’s law. Between having car troubles and blowing out a tire (twice in a 24 hour period), and having more personal issues to attend to with my family, I was not able to physically attend a few of our sessions. I made sure to let the group know about my absences, and they were of course very supportive. The silver lining was that we were done with the software developing at that point, so at least I could practice on my own and not leave any slack behind me.

Regardless of any personal or vehicular setbacks of mine this sprint, the work we did to prepare our presentation was spot on and efficient. I would definitely plan all future presentations in this way if possible, and I am excited to see tomorrow once and for all how our semester’s worth of planning, struggling, and ultimately our achievements have worked out.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

Since the last sprint retrospective, our group has been working to finalize everything that we have managed to get done so far. Most everything we do have to show for actually was created since the last sprint retrospective. Just about everything before then has been all about fixing errors, trying to understand Google’s material design and how to use it, setting up the development environment and fixing lots of errors. Another team had a working version of their component already, and our team was stuck on an error trying to get the styling to work correctly. The problem was that we were opening the component directly in the browser, just by opening the html file that has the component in it. There’s no connection between the styling code and the HTML code, so there’s no reason it would be properly formatted just from opening it directly, and that was the thing we were having a problem with. It turned out we had to use ng serve to start up the local amrs server, and then the component would show up correctly formatted after visiting localhost:4200. There were of course some more errors in the process of getting to this point, though, which I figured out through a series of Google searches and copying and pasting commands from stackoverflow answers from other people who had a similar problem. Since we got that working and were able to finally see our component correctly, we finished figuring out how to get Google’s material design template code integrated into the component, and then spent the last class officially adding our component to the main branch. The rest of the work we have been doing since then has been about preparing for the final presentation, recalling everything we have done so far and trying to allocate the material among all five of us to discuss when presenting. Most of the presentation is going to be talking about errors and the solutions to the errors and how the solutions to the errors were found. That is because most of this project has been about having errors, looking for the solution to the errors, having more errors with the solution, and then finding the right way to do things. Another portion of the presentation will be about setting up the development environment, which was a pretty big focus in this project. We spent the first couple of weeks setting up a development environment we never used, and then had to set up another development environment once we started working on the angular component. The rest of the presentation will be mostly about the actual programming of the component; what it is, what it is supposed to be for, and what further problems were had in developing it.

This class is very different from any other class I have had before, mainly because the whole time there was never a clear idea of what anyone is supposed to be doing or how anything is supposed to be done. It all seems to have worked out in the end, though.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Final Round

A reflection on what I learned from this week’s sprint is
that when proper systems have been setup and the team synergy has reached proficient
levels, the completion rate of tasks increase during the sprint and
communication within the group is significantly better.

On the topic of proper systems, this includes repository
management, branch management, issue tracking, and issue discussions. These
five systems are currently being utilized between the two groups assigned to
this project. It took several months of trial and error to effectively plan out
guidelines and familiarize ourselves with them. This effectively allowed the
groups to communicate clear intentions towards a certain issue, reduce
duplications of tasks, and complete significantly more tasks this sprint than
all previous sprints.

Furthermore, improvements towards team synergy allowed us to
communicate more frequently during our sprint planning. This resulted in less
confusing discussions as we can express our concerns towards specific tasks or directly
question certain decisions without fear.

Our main focus for this week’s sprint was to finish the remaining
tasks that would be carried over to this week’s sprint, clean up any mess made
during the development cycle and create an appropriate presentation detailing
our experience working on the project. Finishing up the remaining assigned tasks
will allow us to close up loose ends. This will also create an opportunity to remove
all active and past branches on git before another group takes on the project.

The remaining tasks consisted of several input fields for
the intake form. We chose to continue these tasks because they are relatively
simple to implement. Other tasks that were too large of a job were postponed
indefinitely and were not considered. An example of this would be designing a
database schema for the backend. The reason for abandoning this task for this
sprint is that there would not be enough time between discussing and creating
new iterations of the schema to clear up problems. Time invested towards
designing the database where the implementation will probably be done by a
future group would deem efforts wasted. The effort redistributed towards
working on the presentation was deemed more useful.

Our group contained five members, of which four worked on
the Food Pantry Web Application and one was dedicated to the FoodKeeper API. For
our presentation, we each contributed as much information about what was done throughout
this project’s development process. In the end, it is clearly divided into a
section for the Thea’s Food Pantry Web Application and FoodKeeper API.

What I worked on during this week’s sprint is providing
appropriate code snippets for the backend. This also includes providing any
missing content based on the requirements provided for the presentation.
Lastly, I made an effort to ensure a smooth delivery of the presentation by suggesting
a system for delivery. The system is quite simple as we marked down exactly
which slides, we would like to cover, exchange ideas on how the information
will be presented, and made sure that if changes needed to be made, the group
will be notified. As our chapter for this project comes to a close, the
experiences thus far was impactful and I enjoyed working with my team for the
past month on this project as a whole.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 6

The final stretch. As we wind down and tie up lose ends we look back on what we did during this Sprint. This Sprint was exactly that though the end of it all and the cleaning up of lose ends. We spent most of the time working on CSS items, and finalizing what we had… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hi everyone and welcome to another apprenticeship pattern blog post. Today apprenticeship blog post is going to about find mentors which I think is important because I’m doing the same thing in my new internship. I realize when you new to your craft or job it’s important because to always ask a question and help when needed and there should be someone you can count on. I agree with this pattern because when working and you come across a problem and have no idea how to fix it, you will need guidance and that will be your mentor. I think the best way to learn is to listen to those who have to be there before. I also agree that everyone will always find a mentor because I think there always someone that is willing to help anyone new that needs help. There might even be more than one mentors that will supervise an apprentice for example in the new job I have many people helping when I have trouble with a problem. I also agree that real-world apprentices have to scratch and claw their way into the lives of master craftsmen and are grateful for whatever attention they can get because I think that some mentors don’t if you want to learn or not so I think it always best to ask question and try to shadow the mentors as much as possible. I agree that when finding a mentor, you shouldn’t expect the mentor to know everything because no one does, and you are still walking the long road too. I like how the actions give a good tip on finding a mentor because it’s important to find the right one especially one the is patient with you. All in all, I think this apprenticeship pattern find a mentor is helpful and important. I know when I first started my job, I was looking for a mentor to help me when needed and I lucky to have a few that is patients with me. I feel like it was really important because I don’t think I can progress fast without taking the knowledge of others.

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 6

            The final sprint review of the semester was very successful with our component finally being completed. We ironed out some bugs before finally completing our form component. We worked on the dialogue box that needed to popup after the submit button was clicked. We imported a new module and created a new component for this solution. The module was called MatDialogBox and it was imported from the angular library, but we needed to create a new component to implement it correctly according to the documentation. We had multiple issues with formatting the popup box with buttons that said done and cancel because the default dialog box comes with a text field instead. Once finished, we pushed the changes and asked our instructor to finalize the merge. We realized that there were issues with multiple similar imports from various projects which lead to complications as I had mentioned in my previous sprint reviews. This stage was the stage that I worried about the most throughout the project and reflected on. The merging of our code with other teams’ components turned out to be much more complicated than I initially thought. We needed to remove any imports for angular modules that were repeated within every component that was made in the final project. We had to sift through various groups code to make sure there were the correct imports while also making sure it would compile correctly. We ran into issues very quickly when we ran the program since it wasn’t properly styled. The components that we made overlapped each other when we served it. This meant that the visual details in the html and css files needed to be further modified. We looked into moving the tab component around and the homepage to make sure our component was underneath which proved fruitful. However, formatting the entire project to be visually appealing turned into a nightmare. The branches that we initially pulled to piece the components together turned out to be a branch that held broken code. There was a different branch that held the compatible code with other components which led to confusion in the beginning when we tried to serv the project. We were suggested to leave this task to the integration team, but we still wanted to persevere and try to find some way to make things easier for them. Finally finishing the Q-Form component was a very interesting experience as was this entire project. We went from using real Ampath code to making our simple app that would run off pre-determined data that we would feed ourselves. It was a great learning experience as to how to communicate with a team and understanding a groups workflow to enhance communication between each other. This allowed us to debug together and solve issues much faster in person compared to over our communication channels. I realized that we really crunched through any questions or troubleshooting very efficiently when in person compared to online. This sprint really taught me to understand other people’s point of view when debugging. I learned to be patient and try to understand another mindset even if it takes me longer than necessary. The final presentation really showed me how patience and teamwork can prove to be useful in the grand scheme of things.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.