Sprint 4 Retrospective

This blog is about our third Sprint. This sprint is a bit better than the last one. I finally think that we are making some progress towards the Food Pantry project.  During this sprint, we did a lot of organization and more planning. We have decided to put our board into Github.

We created a project board and created issues on github as sprint backlogs or product backlog. This process was not easy since I do not have much experience with creating issues on github. I also find it weird how we create issues and use them as a story, but it is actually pretty efficient when you got a couple groups working on a project. During this sprint, it was a little tough how to separate what is an epic, a story, or a task. We were deciding in the group what is considered a story or a task. Most of the story we made had to be broken into a task so that it is more descriptive.

Another thing that kind of made it hard is that we need to create issues in two github repositories. There is the internal repository for the cs-448 students only which are the two group and there is the LibreFoodPantry which is more for the more serious issues and is available to others. I was not sure what difference is written in the LibreFoodPantry and the cs-448 repository. For now, I think it is mostly tasks that are put on the groups repository and the major stuff like one card scanning are placed into the public repository.

Lastly, we got ourselves a magnetic card reader. We are gonna be using it to get the student or customer’s ID from their OneCard and use it to find their information from the database. It will be stored along with their information. If an ID does not exist in the database, we would prompt them to fill out the intake form. Then we store these attributes into a database. I think we should try to design the database along with the food pantry’s front end. Since it feels like there is not enough task for everybody to do, I would probably try to make a rough draft of database design.

In this sprint, I learned more about agile development. This time we are doing it in github by creating issues. I also learned that I should always try to break down stories that are very vague and making tasks from it. I also learned that the process into creating a project is not as straight forward as it seems, there is a lot of things that have to be considered like which programs to use, what server, and other little things that make up the project. This time, we actually got our hands to a magnetic card reader where we could swipe the OneCard to. We figured out that it takes the ID number that needs to be formatted before it enters the database. Hopefully, we can manage to get it working during the next sprint.

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

Sprint-4 Retrospective Blog

It’s time for Sprint-4 Retrospective Blog Post. As you are probably aware by now, during this semester I will be working on a AMPATH project with a team I was assigned on 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 Today, April 9th, 2019, we have completed Sprint-4. During this fourth sprint we were able to get everything we intended to get done during this fourth sprint cycle.  For sprint-4 our task involved the following:

  1. Learn about Angular Material
  2. Start working on the left navigation bar for the ampath mobile app
  3. As a team we had to divide the work to start working on the left navigation bar for the ampath app project. The work to be divided: setting up the project in GitHub, working on the left navigation bar skeleton, scaling, design, its content and button.

During this sprint the reason we had to learn about angular material is because it provides a Google’s Material Design Specification. Angular material is a UI component library that is well-tested and reusable for functional web pages and web applications. Since, in our project we are working with angular with the goal to contribute to the ampath mobile app.  Learning about angular material was considered an important steps to getting the left navigation bar started. After I had done the tutorial on angular material I started on our left navigation bar. Where I worked on the design, and minor button function. I generated a routing module, a few sub module and sub component that can be used for button function. During this sprint we was able to make the left navigation bar; however, it still require some tweaks and extra work to it. We decided that for the next spring we would focus more on improving the features in order to have a side bar with custom design and add some function it as well. For this sprint we only had to get the left navigation bar started to have some visual progress. Where next sprint the goal is to have a little more details.

I can say that during sprint-4, I’ve learned a little more about mobile angular doc, and about angular material. While reading and doing tutorial on angular material I learned the benefits and the different type of possibilities that can be done working with angular material. For example, you can use angular material for working on standers app layout, stander design, creating stander navigational tool and etc. Which I found pretty interested and will keep doing further research about it. In light of everything I learnt there is nothing very special that went on that requires details explanations or strategies that would be required for handling things differently next time. That being said this project is proving to be fun and interesting. So far this project is going without a hitch, and it’s not making anything more complicated than it has to be.

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 4 Retrospective

This sprint seems to be the last of nearly entirely research sprints. Now we have the tools we need to get down to business and make some meaningful changes to the code. We have access to the replica of the current, existing system, we’ve gained insight into whether or not we can use AccuTrack, and we learned how we will have to integrate OneCard Scanning. We’ve also organized our story boards to a reasonable state but there is always room for improvement and there are definitely pieces that we are forgetting to add that we’ll come up with on the go. Now it’s time to build stuff.

The first thing we did the sprint was something that actually happened at the very tail end of the last sprint, we gained access to a working replica of the existing system with help from Michelle, Beaulieu, the graduate assistant for the food pantry project. This let us see what flaws there are in the existing system as well as an idea of the complexity that the food pantry workers are familiar with. From obtaining access to this system, we learned about several new stories/epics that we’ll need to add to the growing list of things to do. This included additional fields/questions for the intake form as well as an entirely non-existent report system that we thought was somewhat integrated already. There are other small examples of things that we caught but those are the highlights.

I also met with Bridget Joiner from the student affairs office and discussed theproject. She was the liaison between Joanne and Laura Caswell, the person in IT who was setting up the system within AccuTrack for the food pantry. From this meeting, I learned that it was unlikely that we would be able to integrate with AccuTrack at all but that it was also a good idea to meet with Laura Catwell to get confirmation and possibly hands-on experience with the AccuTrack system. Following this meeting I met with Laura and confirmed that it was not possible to use the AccuTrack system and I also learned that the food pantry workers never bothered to learn the AccuTrack system so the lack of utilization won’t make a difference. I also learned that the level of communication between all parties was poor to say the least but this was a lesson to develop better communication in the future with all parties involved. Laura also confirmed that we could use a scanner and how to access the ID numbers on the card.

Next was the big move from Trello to GitHub issues. While everything has been moved from Trello to GitHub this is an ongoing process and we’re continuing to improve our system as we go along. We’ve decided that anything more than a task belongs on the LibreFoodPantry repository and all tasks should be on the one specific to our sections. We’re continuing to make organizational decisions regarding specific wording, tagging, and branches.

We’ve also obtained the scanner and confirmed the pattern that occurs when scanning OneCards for future integration of the device.

I also spent some time trying to correct some version mismatch problems with my local system and the current code that was on GitHub as of yesterday. There seems to be a new push from the other group that will hopefully resolve these issues, as the old version they had pushed used older versions of software.

This sprint was productive but not in ways that we expected. We expected to have more done regarding the actual software but instead we learned much more about the future and the long term goals of this project. We would have needed to have these conversations at some point so getting them out of the way now is not a bad thing. Hopefully by the end of the next sprint we’ll have some more developed, working software to discuss.

GitHub links to both repositories mentioned:

https://github.com/LibreFoodPantry/Theas-Pantry

https://github.com/cs-worcester-cs-448-sp-2019/Theas-Pantry

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Sprint-4

For this weeks retrospective, I really felt as though my group and I got a lot done. A majority of what we had decided to do was to look up some more skeleton code. Our plan for this Sprint was to finally get started on some code and getting things running. While talking with Professor Wurst we realized as whole for this project that each group with each of their components will make a separate branch for that component and work separately in that branch. From there we would make a pull request to the AMPTH repository where they can other members from other group can view our code and see if it compatible with the rest of the code.
To go in more detail on our specific branch, for Team Rocket I created a branch named ‘Tabs’. I did this by going into the project through the terminal. Then by running ‘git checkout -b Tabs’. From there I needed to create an empty commit – ‘git commit –allow-empty -m”Create a Tabs branch’. This just shows that we created a branch and committed it right away with nothing in it. After the branch was created Professor wurst told us that we will need to install some angular app materials that would be useful in creating our component. Everything that we will be using in our project comes right from angular, so it would be smart to download these tools. We got this information from https://auth0.com/blog/creating-beautiful-apps-with-angular-material/.
The main things i ran in the terminal inside the project was ‘npm install @angular/material @angular/cdk’ and ‘npm install hammerjs’. The second one was from the angular/material tutorial.
After installing these tools, the plan for the weekend was for all four of us to use some of the skeleton code that we had found and implement it into our code to make sure everything was running smoothly. This just ensured that we had the right libraries and dependencies while running the final project. The skeleton code that we decided to use was from https://material.angular.io/components/tabs/overview. After this weekend, Daniel Ryder from our group had created a simple tabs component from the website listed above. The problem that we had with this was just that Daniel had created this inside of a simple angular project that was not connected to the project that we were working on. Ryan also found some useful form skeleton code that we would need for the forms of each tab in the future. We found out that we still do not know what is needed inside of each of the forms, like what the patient needs to fill out but we could include the overall code of a simple form into the code. Samuel Bryan, the other person in the group had worked with James on the website Zeplin which thoroughly explains what Greg Schmidt would like from us and each of the components. It very easy to understand and much more detailed than the videos. That website can be found https://app.zeplin.io/project/5c7fe3c5826def62505ec3b8. Since Daniel needed to put the code into the branch, and the blank angular project I had was from the project, I decided to generate the folders that would be needed for the tabs function. From there Daniel cloned the project from the repository and then started to move the code he had started to working on, into the new cloned project while in the Tabs branch.

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

WSU x AMPATH || Sprint 4 Retrospective

Sams Ships (12)For this sprint wrap-up, we discussed how we are trying to move on based on our team planning meeting. One of my teammates, Kristi, along with Professor Wurst, tried to check out an idea they had and continued to bounce ideas back and forth with one another until they came to a conclusion.

Overall, I’d say we are continuing to plan out our next steps and work on something new. A new development was a suggestion by one of my teammates based on what we already have to work with. The suggestion was that we should wait for the other group to push what they need and then we can seamlessly build upon it. If the other group (who are working on the sidebar and navigation bar) add their work, it would help us have a better base.

We have to carefully analyze how the components are going to go together and get through to make sure that they are not just getting thrown in. If we plan things out more, it will make the process more efficient. I think taking a step back to look through angular was helpful because it allowed us to learn something new at our own pace. It’s nice to not have to rush on what we are doing; especially when the concepts are newer. This will help us deliver something even greater for our client, who is Greg from AMPATH.

There is also the approaching team presentation that we are going to be focusing on to explain our work and what is happening. I think it will mainly be focused on the search bar and our experience with learning angular or the concepts that introduced us to it.

On top of what we have been doing, I have been continuing looking up resources to learn more for our project. I think Codecademy is a good reference for learning AngularJS, https://www.codecademy.com/learn/learn-angularjs. It is actually one of my preferred sites for reviewing programming languages to sharpen up on things I may have forgotten or for learning new ones in general.

It has been a great experience being able to work with a solid team so far this semester. I wonder how much we will accomplish by the end of it! I think learning about communicating within a team is so important, especially since we will all be graduating very soon and entering roles that require consistent communication.

Overall, the only thing I would say I would have proceeded to do differently is come up with another way to “work smarter not harder” when it came to figuring out the process for the search bar. There were not necessarily any fails because our continued work dealt more with the planning behind the work instead of testing to see what worked for us. I am very excited to continue moving forward with this project in the few weeks we have left!

Some advice for others who are going to work on things includes:

  • Having an open mind on what they would like to do because things are always changing
  • Understanding what the client wants is important because at the end of the day, they will be the ones who need to use this software
  • Try to make sure teammates are on the same page with you on what is happening that week

 

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

The IncreEdibles Sprint 4 Retrospective

This is Sprint 4 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our plan to Theas Food Pantry; we also moved our stories from Trello to Github. We also got the OneCard swipe to work it our program.

On Trello, we have Product Backlog, Sprint Backlog, Doing, Review and Done. We placed all stories into these categories. By doing this we can assign and to keep track with our work. Product backlog is where the bigger features, big stories. Sprint Backlog is where we place all of the stories, we plan to do during the sprint. The last categories are for the progress and review. But by this way, it is difficult to know which story is task or epic stories. We are also work with other team; we don’t know which stories they are doing because we are not on the same storyboard. So we moved into planning on Github, because we are the first to try out this system. We are tester to set the rules of how the classes operate later. We came across a few problems while set this up. The tag feature in Github is good but we didn’t know where to place our stories. There are two repositories, we got confused to where to place stories on CS-448-Theas-Pantry or LibreFoodPantry/Theas-Pantry. After we test and try it, we think that LibreFoodPantry/Theas-Pantry is for big stories such as Epic and Story. And tanks are what we are working on individual, small tasks to make one story/feature. Other problem is branches, we are not used to work together on one project with many people. There are few people including me still confused about branch, but we will figure it out after using it.

Github have many positive features we need to work on this project. We now can create tasks and share between two groups. We can pick and working issue on our storyboard, also we can view other team board. We able to work on your own branch, without change master branch and review each other work. There is still confusion about the way we setup, but we are moving along. Hopefully we have the set of rules, work system so the future classes have better start. For next sprint, I hope to contribute more to this project. This is really way to understand how software development, we will meet roadblock as team communication , product owner … not just the technical side.

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

Sprint Retrospective #4

Sprint #4 was a very productive sprint for my team. We were able to get a lot of research and planning done in regards to the tab component that we will be creating for the AMPATH project. We also narrowed down the exact functionality that this component will have and discussed how it will interact with the rest of the app. During this sprint, each member of my team began coding an Angular component to get a better understanding of how we can implement the tab functionality. I was able to create a test component with tab functionality that displays patient information.

My plan for writing the test component was to follow the beginning of the Angular Tour of Heroes tutorial then build off of it. This was a useful way to do it because I was able to start with a base application that I could modify into something else. My team decided that we should each create a component just to see how it worked, so it didn’t necessarily have to be related to the tab functionality. However, I decided to build a tab functionality for my component because I felt that it would give me a better understanding of what we would have to do to to get our project built. What my code does is display patient names on tabs at the top of the screen. When you click on one of the tabs, it brings up information about the patient including the name, id number, age, and gender. It also allows you to edit the patient’s name, which reflects instantly on the tab itself. For our actual project we will need to connect to some sort of database for patient information, but for this test I just created a Patient class with the attributes that each patient will have. I then have a mock-patients.ts file with an array of predetermined patient information. The patients.component.html file is where the tab functionality resides. I used the Angular Material Design tab component to build the tabs. This link was very helpful for showing how to implement that: https://material.angular.io/components/tabs/examples

The biggest challenge I had was making the correct set of patient information display when clicking on a tab. I originally had something similar to the Tour of Heroes tutorial, where clicking on something brings you to a separate section of html. However, this didn’t work great with the tab functionality, as it required waiting a few seconds before clicking on a tab would bring up the correct information. I was able to fix this by putting the part that displays patient information in the mat-tab-group and using *ngFor.

Overall I feel that this we made a lot of progress during this sprint. It felt good to finally code something with a tangible result. By creating the test project my memory of Angular and html was refreshed and I learned how to implement Angular Material Design. This will be a big help throughout the next few sprints as we develop the tab component for the AMPATH project.

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 – 4

During this sprint there was a lot of confusion on how we should move forward with certain things. In the last sprint we were able to determine which components each team was going to be working with but we have yet to set up our branches on GitHub. We sat down as a class to recreate the whole Git system/directories/branches. We decided to pull fork the original, clone it, and moving forward we would add any changes we make to our code to our forked repo and create an upstream to the original to be able to merge as a class.

There were some problems we encountered; the biggest was not being able to correctly style our component given the angular material code. We hope to be able to solve this issue by the end of the next sprint. Other than this, we had some minor issues when actually running ng serve but we later found out that some of our angular versions were not up to date. A simple update fixed this.

That was pretty much all for this sprint. Our goal for the next sprint is to finish our component!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Studying the Classics

For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.

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

Reading Railroad

Read Constantly is a brief section, but it is an important apprenticeship pattern. Read Constantly is what it says. You need to constantly by reading and introducing yourself to new information in order to learn new ideas and improve. Most of the learning you do is from reading, whether its from sources on the internet or chapters of a good programming book. The more often you read and the better reading skills you develop, the better off you will be.

There is a book out there for every different programming language, every concept, every challenge you will come across in your professional career. I am currently reading a book that discusses the whiteboard problems brought up during many coding interviews. The book is long, and the content inside is dense, so it is important to read it carefully, take notes, and read it again to be sure of the information. That is my usual strategy for reading information that I need to learn.

My biggest challenge with reading constantly is feeling like I’m not absorbing all the information because I’m just trying to get through it. That’s why it is always good to do exercises in the book, if any are provided. That way you can do practical work alongside the reading that helps break up the monotony of reading and also gives you a different way to learn the content.

Another good strategy I use when reading is to take notes. There are often ways to boil down a text to its essential parts and the things you need to focus on and remember. Keeping notes, highlighting key lines, and keeping track of answers to exercises is a good way to maintain a reference if you ever want to brush up on what you just read.

Read Constantly is an important pattern when you want to learn something new or build a new skill. Good reading habits can open the way to learning lots of new things in a short period of time. It is absolutely the best way to learn quickly, especially if you are an independent person.

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.