Category Archives: Sprint-3

LibreFoodPantry Sprint 3 Retrospective: All Things Come to an End

Here is what I worked on during Sprint 3:

Sprint reflection:

In my personal opinion, this sprint was truly when my team and I started to get into the flow of collaboration. For this sprint, rather than each working on a separate service, such as the API or front-end we all collaborated on a single front-end. What I noticed with this was we had a lot more discussion and it really felt that we were working together towards the goal of getting all of our issues we started the sprint with done. Unfortunately, this was the last sprint of the semester, but it was good to feel that we were all working collaboratively and using discord and GitLab to communicate any issues and roadblocks that were stopping us from achieving. As I talked about in my last retrospective blog, the transition to fully remote was a pretty tough one since we are a relatively new team and haven’t really had the time to form the communicative skills that a seasoned team would have. It felt at times like the fully remote nature felt made it more difficult than it was previously to reach out for help while working. Maybe it was the quickly approaching deadline that made the difference, but I think we all worked really well together on this last sprint. All members of the team used discord messaging extensively and we had our fair share of discord calls to talk about implementation and problems. As for things that could be improved, as there always will be, I felt like work wasn’t being pushed to GitLab as frequently as it should have been. This made helping with implementation a pretty slow process. There is really nothing that we can do to help collaborate if we don’t have that code up on GitLab. I also feel like we still had the issue of keeping way too many things in the needs review column of our Kanban board. This also slowed down implementation greatly because there were many times where I couldn’t start working on another component until a feature was merged and sometimes it would take days for that to happen. In the end, we implemented a lot more than I originally thought we would have and we did it as a team. We even got to working with Docker on the Dawn of the final day and while it was a scramble I learned a lot about containerization and Docker implementation.

Going Forward:

It did take my team a fair amount of time to gel together and feel comfortable collaborating, but I feel like we pulled through in the end. This project has been a huge learning experience. Not only did I learn a ton about how developing on an Agile team feels, but I also got a feel for being a Scrum master. I know that this experience is one that I will look back to throughout my software engineering career. There were failures and frustration, but it was extremely informative to be part of this project from the idea phase all the way through to the implementation, albeit not a finished implementation. Having the experience of transitioning to working fully remote is an experience that has already helped me in my professional career. If any of my team members read this, thank you guys for sticking it out with me and I know you will all succeed in life.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Capstone Sprint 3 Retrospective

The third sprint in my capstone was a race to presenting a working project. This sprint brought new difficulties in coordinating the team and getting work done in a logical order. The issue wasn’t our team work, but rather trying to work around the pressure of getting the work done. Many issues took longer to resolve than expected, meaning we had to put a pause on some issues to help each other get prerequisite issues done.

My contributions

Set up CI for Angular to automate testing and prevent failed pipeline merges

Create Angular Service to update backend

Create Docker container for Spring Boot

Create Docker container for Angular

Establish communication between all 3 docker containers (MongoDB included)

Retrospective

I was really happy this sprint with how our team dropped what they were doing for a team meeting. We all had snags with almost ALL of our issues, and the order in which we had planned to do things was not possible. For example, while setting up the CI, I decided to explore Docker a bit more in detail so we could potentially use the same Docker image for the CI as we used in our project. This meant that we as a team had to focus on Docker sooner than expected.

At the same time, there were some problems while working on different issues synchronously. The biggest problem came from a couple incidents of copying and pasting code from other branches to get it to work in their code, instead of waiting for the code to be merged. If someone else’s issue is blocking you from working, the team should try to resolve the issue as soon as possible first, then get the updated master branch. While copy+paste might seem easier in the short term, it has a potential to cause issues as people try to merge their own requests. For example, code was copied from one of my branches because a feature was required for another issue. These changes were then merged from a different feature branch. My merge request was never approved because the changes were already on master. When it came time to merge one of my requests, it looked like I had made no changes compared to master, because my changes had erroneously already been committed in another branch. It was especially confusing, since change had been made to my original code since then.

This could have been solved if I had blocked other issues from being merged before my issue was merged, which is a feature of GitLab. However, there were also a couple cases where certain features stopped working because code was merged to master without consulting other team members while resolving conflicts. This led to some of the work from my issues being completely erased. Luckily it was easy to add back in thanks to version control, but the extra effort could have easily been prevented. Checking the git diff more carefully while merging would help in this effort.

Branch names were also confusing in a couple cases. “Working_branch” followed by initials is not a useful name, although I understand wanting to signal to your teammates that it is your branch. Appending initials to a name describing the feature would be more useful for everyone. Even better, GitLab has options to prevent modification to a certain branch except for merge requests. You can name the branch after a feature, anyone can help you, and then you can accept changes only if you want. This makes it easier to find a branch when helping your team members with issues.

These problems did teach us about features in GitLab we were missing out on. Our team could improve by following the GitLab workflow and maintaining consistent software development processes. Deviating from this workflow hurts productivity because other members have a certain expectation on how things are being done, and for example, shouldn’t have to check to make sure a past bug fix is still on the master branch.

Despite these issues we got a lot of work done, even though it came down to finishing the night before because of all of our snags. I had a great time with this team and although we’ll no longer be working on this project on a sprint team, I’d like to continue working with any of them who will continue to contribute to this project. We’ve all learned a lot about GitLab and the technologies we’ve used and have adapted well to the new workflow.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

AMPATH-WSU Sprint 3 Retrospective

Hello dear readers. Welcome again to my blog. This blog won’t be for the patterns I have been writing about, but for the progress of me and my team in our Capstone Class. It is exciting to see that things are progressing and we are moving forward with this project.

As I mentioned at the end of the last blog, (AMPATH-WSU Sprint 2 Retrospective) we received videos and actual output samples of how the new application should look like. I think that this is a very important step and want to say that I think it should have been sent earlier to us, as for a long time we kept researching about the tools we were gonna use and to be honest it got a little bit boring as I was really was looking forward to this part of the process. It’s true that in order for you to start working on a project you should know the tools and systems but I also believe in the theory where you also learn while working on it.

So during this sprint we took our time to watch the videos and after we made sure we all had seen and understood the videos and the requirements, we created Zeplin accounts. For all of you who don’t know Zeplin, Zeplin is a collaboration tool for UI designers and front end developers. It goes beyond the design workflow and helps teams with the design. I had never used Zeplin before but I found very useful in sorting the project and handling off designs. Recommended if you ever do front end development!

A Github section was created for all WSU participating in this project and each of the teams created their own branch. We discussed if each of us should have their own branch but we ended up in the conclusion that it would be very messed up for each of us to have their own branch pulled from master, so a branch per team was the final decision. However, each one of us could create its own branch from the team branch and that would be great in case any of us wanted to experiment. we left the option available  to whoever wanted to do so.

After we created our branch we choose our task to do, which is a search bar.  Something I really would like to point out is the team environment we have. We all are very communicative and express ourselves and our opinions. For us it was easy to agree on the search bar as a start up to do task for this project.As a lot of steps on this process don’t depend on us I would say that everything is going fine and I wouldn’t change anything if I was back in the same situation.

While working on the search bar we keep checking with our teammates and how is the progress going. I am really glad we haven’t really been facing any major issues and our team is working strongly together. I am really looking forward to getting the search bar done and move on to the next task. Stay tuned for my next blog post to see what happens. Until then..Have a good time ?

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

Sprint 3

Hello everybody and welcome to another sprint retrospective blog post. Today sprint retrospective blog post about what I have done during sprint 3. Some of the things we had on our sprint backlog is if we have login information – examine screen code for some examples of screens on AMPATH site. Figure out if we’re getting information to access AMPATH site. If we have time – read more about Angular unit testing – mocking. If we have time – read more about Angular unit testing – mocking. Read mobile angular docs http://mobileangularui.com/docs/. I also sign up for Zeplin and send my information to Greg so he can verify my email. I also kept an eye out for Zeplin shared folder – where designs will be. I also to work on the navigation bar tool for the Ampath project. I created a skeleton for the Ampath project and discuss roles for stories that will about the project. After the second sprint I realize that I was getting more comfortable with scrum. I can now easily now login on to Trello and understand what’s going on and what I can do and what other did and are in the progress of doing. When I finished the skeleton, I posted on Gitlab instead of Github because there wasn’t a repository for at the moment and I was more comfortable with Gitlab. I also lookup more sample of a navigation bar so I can see what features other navigation contains. One of the problems that I have so far was to get the toggle button to drop down when click because the code actually to drop down when hover. I think the scaling of the project is not going to be a problem because I tested the component and it look fine in a iPhone simulator. There were others stuff I think has to be done like adding information and hyper link to the navigation tabs so that when clicked it would navigate to a different view controller. I think design is also important later to make the component more presentable. I also ran the project on a web browser, and it was fine too. During the standup, I got more comfortable with the time schedule. I haven’t missed a stand up. I realize the importance of the standup so that we can keep track on our progress. All in all, I think this sprint all went very well, we got a lot done, I think. I also found many ideas on how to show that link actually works by inserting hyperlinks and navigate to that site. I think it is a good way to show how the component performs. I didn’t have much problem during this sprint and expecting the same going forward. The only problem is that we don’t have access to the service right, but I don’t think its issue because we don’t really need it to have the component to work. This sprint was fun, and everyone was on the same page, until the next sprint retrospective blog

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 Reflection 3

In our third sprint, we ended up having to revisit some of our previous work and recreate it, but better. After having a lot of difficulty with the previous way of doing it, using some old code from an old project, I decided to go with a more structured approach and read the guide on making template driven forms on angular.io. This guide was incredibly helpful in creating the form, as it has step-by-step instructions, example code and is very descriptive in the how’s and why’s of doing things.

Using the guide and their code as a template, I began to customize the intake form to the necessary specifications. I pretty much tried to recreate the “Thea’s Food Pantry Intake Form” given to us by the food pantry representative. I had to make different types of input for the text and the button input, and this time I was able to get some error-handling working, such as required certain fields before submission. Instead of using WebStorm as my IDE this time, I developed everything on Stack Blitz, a free online IDE and Angular editor that displays your application in real time. It was really useful to use, and hopefully once our group figures out its intricacies and how we can use it to collaborate within it, we can use it more in the future.

I was able to use some of the lessons learned in my Software Process Management class to make sure I maintained the clearness and readability of my code as well. I tried to use good spacing and white-space in the form so that it is clear where one module of the code ends and another begins. I also tried to keep my names both clear and consistent, so that variables containing the same information are named the same throughout the program. This is an issue that caused me much confusion last semester when I was developing a different web based form.

A unique issue I ran into while making the form was the compiler getting confused about the format Student IDs at Worcester State University have. Because my ID number is “0662077” the compiler kept thinking I was trying to use an octal, which would be something like 0x662077, and would not compile. I had to accept the Student ID as a string instead of text to fix this issue. Another issue with accepting Student IDs is that the program tries to get rid of unnecessary 0’s, which ends up making my ID Number different from what is desired. It took me a while to solve this issue, as I had no idea what was going on at first, but it was interesting to see how it could misinterpret my input data because of a preceding 0.

Overall, this Sprint was relatively productive for me, and I hope to continue going forwards. I have to find out what my next goals and challenges are and figure out what I’m doing next. Hopefully it will be something I’m familiar with.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Since the last sprint retrospective, we have all finally begun to get an idea of the actual work that we are going to be doing. From the videos that were sent to us that we watched, it seems to be the case that we are going to be implementing some front end components like HTML forms and buttons using angular and javascript or typescript. Even with this in mind, though, we still have not begun writing any actual code yet. We are still in the stage of figuring out how to start on this project. Part of what was described in the videos included what appears to be an already functioning template of buttons and components that interact with the page but have no backend functionality, so my assumption is that we are expected to take this design and program the buttons to read the forms and pass the information to some function that sends it to a database. I am anticipating that we are going to need to read some of the existing ng2-amrs code so that we can have the frontend invoke the right functions written on the backend. This is all in my imagination, though; we are still not certain enough to know that that is what we are going to be doing. After trying to access the wireframe designs from the videos, they do not seem to exist in HTML – they are possibly just a graphical simulation of how they should interact. If this is the case then our work will begin first with building the pages and placing all of the components on them how they appear in the wireframe.

I think things would be moving more quickly if all of the groups were communicating more about what everyone plans on doing, since everything is going to need to be divided among the groups, and then within our group we will need to divide tasks further among ourselves. Firstly, though, we need to understand the goals better in order to be able to come up with smaller tasks to break them into so that we can work on separate pieces of it individually, then bring it together as a group, and then bring each group’s contributions together to complete the project. Progress in this regard seems to be happening very slowly. We have a vague idea of what needs to be done and we do not know what comes next, so until a lot more detail is figured out, there is only one thing to do, and that is to clarify what needs to be done and come up with some more things to do so that the work can be performed in parallel by multiple teammates.

At this point it seems like the groups have decided on one particular thing to focus on, and our group is focusing on one particular component of one page of a wireframe made in Zepplin that was demonstrated in the first video. We do not know what we are doing, but we are making progress.

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 – Round Three

A reflection on what I learned from
this week’s activities is that sometimes it’s best to restart. Our initial two
sprints brought us up to a point where the current delivery is usable but could
not be built upon. We had trouble trying to incorporate features from each of
our own work loads that was divided in Trello. The main issue from the scrapped
delivery is that it is written in Java and missing fundamental components that
would make it difficult to create a webpage with. As such, the problem resolved
after deciding to focus our efforts on Angular and using it’s features to make
our lives easier.

Another lesson learned from this week’s
activities is that having more than one repository between two GitHub and GitLab
is a nightmare. It was a mix between each of the members uploading to our own
repositories to share mockups of things we have created during the sprint. This
choice is backed by us not feeling up to upload mockups directly to the repository
made by the professor since we weren’t “feeling ready” yet.  Then there is the issue with having two different
food pantry repositories which further confused everyone. However, this issue was
eventually resolved when the professor and some students came up with another idea
for handling the repositories. The new system creates a fork from the main
project to the class repository. There are a couple other things mentioned
about incorporating “stories” using this setup that I have yet to fully
understand.

The third lesson learned from this
week’s activities, is that it is very easy to get lost and sidetrack from the
main goal. This lesson is mainly for myself as I was working on the database
but took me an entire sprint to realize that I was working on the wrong portion
of the project that was unneeded at the moment. Focusing unnecessary resources towards
a feature that should be left for later. The other members were focused on the
intake form and had created the front-end of it but needed a place to store the
information later on. This is the area I should have tackled, in which our
members would have been working in unison.

During this sprint, I focused my efforts on mainly establishing a connection to the SQLite database created from the previous sprint with the current project. Using JAVA and the available JDBC library found on the web, I was able to successfully connect to the database. However, when it came to transfer what I learned into the main project we were working on gave plenty of errors. There were missing libraries and many unused and preplanned files that needed deletion. Although this was a problem, the next problem is mentioned earlier in the blog. We needed a clean slate to work with since the project was in an unworkable state. After we got back to the point where we were in JAVA, now in Angular, I had to find a new way to get the SQLite database to work in Angular. Now that we are back on track, I can see where the project is likely headed!

References:

http://www.sqlitetutorial.net/sqlite-java/sqlite-jdbc-driver/

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 #3

During our third sprint we finally got an idea of what we will be coding for this project. Greg Shmidt from AMPATH sent us videos that showcased wireframes of the electronic medical record system that they are requesting. The main thing that I did during this sprint was watch these videos and start planning with my team what we will be working on and how we will go about coding it.

After watching all of Greg’s videos, my team decided that we wanted to work on the tab functionality. The tab is one of Google’s standard material design elements, and Greg showed a few examples of apps such as Google Music and Twitter that incorporate tabs similar to the way that we will be for this project. Each tab will contain a form that displays patient information. The tab bar must also be able to scroll to show additional tabs.

During this sprint my team began planning how we are going to go about designing and implementing the tab system. A link was posted on the Slack channel to documentation about coding mobile Angular user interfaces. This was helpful to read through as it gave me a better idea of what we will actually have to do to code the tab system. I also found a page on tabs on the Angular site that was useful to read through: https://material.angular.io/components/tabs/overview

One challenge in implementing the tab system will be making it so that it functions with the systems that the other groups are developing. To do this we will have to figure out which services we will need to use. Luckily, a member of another group found where all the services are located in the ng2-amrs project. During this sprint I began looking at these services to figure out what they do so that we will know which ones we will have to implement when creating the tab functionality.

After this sprint I believe that my team is ready to actually start coding. We now have clear instructions on what to do and have done preparation work that let us get a better understanding of how we are going to proceed. During this sprint I learned what is expected from us for this project and gained a conceptual understanding of how to implement a tab system in Angular. It is exciting to finally know what we are working on and I’m glad that we can now begin to make progress on this project.

Overall, I would say that this was a successful sprint and I would not proceed differently in light of anything that was learned throughout the sprint. I am satisfied with the way my team is working together and I believe we will begin to make a lot of tangible progress during the next sprint. I think that the tab component we are working on will be a lot of fun and am glad that we chose it. This project is definitely going well and I’m excited to continue working with my team.

 

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

At the beginning of this Sprint, we all watched the videos that AMPATH shared with us for ideas for projects they would like to incorporate into their app. It was really encouraging to make contact with them. I was wondering how much they would ask of us, but I was glad that they seem to value what we’re going to do. I like that it looks like we will be able to do some interesting projects. I hope we are able to get through as many stories as possible because I want to do a good job on this.

After watching the videos they provided, and we all decided that we wanted to start by trying to implement the story which was to creating tabs in the app so more than one form for multiple patents could be open at once.

After a quick google search, I found some good resources from the official Angular site. It provided with some examples of different ways to implement it. It also showed the code behind it in an interactive app that showed how all the components work together. Within the app, I was able to modify the code and see in real time the changes I made to the example.

I shared what I found with the team. It is very exciting because this was exactly what we wanted, and it was laid out in a way that was really intuitive and makes it straightforward to  see what we need to do next.

I think what may be our next biggest hurdle is getting something concrete started. After we have done that, I think it will be pretty straightforward assigning roles and dividing up tasks. When we have finished the first story, I think I will have enough of a feel of how things are done to branch out and form a sub-group so we are able to cover more ground.

Andrew was a huge help to our group. He pointed us in the direction of a lot of resources, especially how to interpret the code we have been provided.

I think a good goal for this upcoming sprint is to finish this one story that we have chosen. I think it is something that we can realistically do, and I don’t foresee that it will be all that challenging. It’s still early to say for the sprint after, but I would like to at that point do what I mentioned earlier and split up into smaller groups and between the four of us, tackle two more stories with two of us working on each.

Of course, I have coded enough to know that there will be unforeseen obstacles that we will have to overcome. There is a chance that one or several might cause quite a bit of delays, so I should not get too ambitious right out of the gate. After all, we have not done any real work of substance yet.

However, I believe it is important to set our goalposts high. If we don’t achieve all of our goals, we can just append it to the next sprint. I think we will achieve more of our goals if we are more ambitious setting them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

For the third sprint, I was assigned to create a REST API for the USDA’s Food Safety Inspection Service’s FoodKeeper Data (located here:
https://catalog.data.gov/dataset/fsis-foodkeeper-data). Prior to starting this assignment, I felt I had a poor understanding of what a REST API was, let alone how to go about making one. Fortunately, the resources that Professor Wurst sent me were a very helpful step in understanding what one looks like. I also read several other resources and followed many other tutorials while making it. By the end I had over complicated things by storing the data into a MongoDB database and ended up switching to data stored in memory, but despite this I think it was still very useful to work with MongoDB as well integrating it with the REST API. I had also considered trying to use a relational database such as PostgreSQL, as the data seemed to lend itself well to it given that each data type already contained keys relating to the other data, however it was a bit harder to set up when compared to a document database.

This sprint began before spring break, and during that time I felt that the project was at a much earlier point than was initially assumed, so I spent a good chunk of my break working on it. As I said I started with a poor understanding of REST APIs so I felt that there was some catching up that needed to be done. By the end of the break I had something that was mostly working but was a bit complicated to set up since it required installing MongoDB locally at the time. I imagine we may have run into similar issues when trying to host it in Heroku, but fortunately it’s since been simplified. I don’t think that it would necessarily be a bad thing to store the data in a separate database, however, given the relatively small set of data as well as the fact that changes aren’t made very often, it didn’t really make much sense to go that route. Changing the code that I had already written to no longer use MongoDB was pretty trivial, as not many changes needed to be made. At this point, the REST API Order System example (located here: https://gitlab.com/worcester/cs/kwurst/rest-api-order-system) that was sent to me was particularly useful, as the was it was set up was almost one to one, with a few changes here and there.

Currently the project is almost at a point where it’s ready to be used, as far as I’m aware at least. I feel that it was much simpler than I had originally thought it would be, but since I hadn’t had any experience with doing something like this before it took longer than it should have. I think one of the most important things that I’ve learned from this is how to start working on a task in which I’m unfamiliar with. It was definitely useful to learn how to make a simple REST API, but I’d say being able to work on something you’re uncomfortable with is a skill that will help me greatly in the future.

Links:
https://github.com/LibreFoodPantry/FoodKeeper-API
https://github.com/cs-worcester-cs-448-sp-2019/FoodKeeper-API

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.