For this week, I have finished up Sprint 2 and I would glad to be talking about it.
What I wish I could done throughout this sprint was to finding
Links:
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
Welcome back everyone to another CS 448 blog post. Today topic is going to be about the second sprint retrospective. This second blog post is going to about the recent actions that I been learning in the class, the work and work products that I am producing during the second sprint. The second sprint was very informative we worked on researching many topics that can potentially relate to our projected plan like Angular testing, Ampath, etc. During this sprint, I already had the Ampath to run on the personal computer but there were a few group members that were having minor issues when building the Ampath project, so I prioritize some so my time towards having Ampath running on every member in the group personal computer. I research many of Unit testing for Angulars like Karma and Protractor and found it important to learn for a solid foundation when testing in Angular. There was really much work again during this sprint as we were waiting for more information about objective for the Ampath project but meeting on this sprint we finally got some clarity in the project. We added more task in our sprint backlog like figuring if we will get access to Ampath on our computers, keeping an eye out for Zeplin shared folder and finding out more about mocking the database. There were also some videos from Gregory Schmidt that we had to watch which I finish which gives the main idea on which we should create during this semester. I found these videos easy to understand and after I feel more anxious and clearer on what must be done. I saw that Gregory Schmidt was developing an android application and now curious if we can create the Ampath application in another platform like IOS. My thoughts on the project are that the project will be a simple application that records and stores data. I will be continuing to do more research on this project during the break and found out more about the developing environment and programming language that we will be using. I researched briefly on how to save data into a database and I found that in IOS developing you can use SQL to create a database and then import the database into the swift project. I believe that you can probably apply the same concept with another other environment and programming language. Other than this information, I really haven’t done any significant towards the Ampath project. Also, if anyone is still having trouble getting the Ampath project to run on their personal computer just follow the lists of steps that I and the members of my group posted on slack. During the sprint, our group work well and perform great together as a team. I learned a lot of important information about testing and application development during this step. I am planning on applying some the stuff that learning in application developing in Swift towards the Ampath project. All in all, this is what happen and the things I learned during this sprint.
From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.
For this week’s blog, I will be talking about our second sprint working on the open source food pantry project. This sprint was a bit unique as to the first one since it is mostly about communicating with the customer.
In this sprint, I learned a lot about the communication between us, the developers, and the customer. I learned that it is not a simple process. At first, I thought that it would just be a simple interaction, they give us what they want or how it should look like, and then we try to create it and meet their demands. But that is not how it goes at all. There was a lot of interaction that we needed to do since the customer does not know what they really wanted. There is also the issue of communication. Most of the time, it is hard to get hold of the customer and we have to wait for them to respond to us before we could even move on with what we are doing. I also learned that starting a new project is like an open-ended question. while planning on this project and asking the customer questions as to what they want, it just seems like they do not really know what they want.
During this sprint, we have decided to change our focus from making the foodsaver REST API onto making the food pantry software since the other team has already made it. This sprint was mostly about communicating with our customers. The first meeting with the customer is with Serena. Serena works on Thea’s food pantry and knows how the pantry operates. During the interview, we asked how the pantry operates. They have a google form that is filled out once by every student that goes there. It asks about the number of people in their household, their income level( whether they qualify or not), and what kind of help or services they are already receiving. If they already filled out the form, they only need to swipe their card preferably but for now, they just take note of the student’s ID number. Then they weigh the items that are being taken by the student and record it. They only keep track of how much weight is taken and how much weight is left on the pantry.
The second meeting that we had was with Joanne, she has been helping guide the student-led-food-pantry initiative. Before our meeting with her, we tried to come up with questions to ask. Most of the questions we came up with was just a clarification on the information we got on the first meeting. In our meeting with Joanne, we asked her again about the forms and what kind of information they are storing. Since they cannot give us private information, we asked if she could just blur out the pieces of information and leave the column headers. This meeting was mostly trying to learn what the food pantry does and how they get food in and out. This meeting also opened the topic with the one card system and how they want it to show information about the student once they swipe.
From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.
This week’s Sprint was relatively uneventful due to a combination of reasons. First, due to the weather, we had snow days which interrupted our meeting. Second, we had issues communicating with the Ampath people, and we had classes cancelled for a week, so there were no concrete assignments for us to add to the product backlog to create our definition of done to deliver value. Finally, and this is a more personal reason, I caught a stomach bug so I was unfortunately not able to show up to the few classes we met up in.
Even though we weren’t able to produce any solid units of work, we still kept our team on track for our Scrum related tasks such as our stand-ups and kept our overall plan pretty solid. We are still in the process of completing the tour of heroes tutorial for angular, as well as installing and finishing the tutorials for the two testing frameworks Karma and Protractor.
After we began that, we took a look further at the tutorial for Karma, and installed the code into our computers. The Karma tutorial is relatively short, although we are expecting to have to allocate some extra time to researching about the Jasmine framework and syntax that both Karma and Protractor use in their testing commands. One thing we noted while looking through the tutorial is the fact that Karma tends to look similar to junit unit tests, so we are hopeful that Karma will feel somewhat intuitive when designing our unit tests.
The first major decision our group made based on the tutorials was that we are going to go with the tour of heroes for brushing up on our angular skills. We are allocating the most amount of practice time to completing the tour of heroes because we all believe that brushing up on our angular skills will be the primary force behind our whole project, while we can learn the testing frameworks slightly easier, is what we are hopeful for.
In light of the fact that our group was not able to produce any direct value this sprint, I still believe that we will be an efficient team. Even though we had no tasks, a few of our team members kept us on track for due dates of stand-ups, CATME surveys, and blog posts. The rest of us kept on track for preparing for when we had work to do so everyone in our group would be ready to hit the ground running.
So what I learned is that even though we did not contribute anything to the project during this sprint, I do not believe that we need to change anything about how we proceed or group organization or splitting of tasks. I am happy to have learned that team roles are naturally starting to develop due to the personalities of our team members, as one of us is adept at time management and keeping the group on track, while some of us can help out more with technical skills and troubleshooting skills. That is great because we will have less difficulties.
From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.
During our second sprint we were still focused on learning about the tools we will be using as we have not yet received actual work to do for AMPATH. There were two things that I focused on: testing with Karma and Protractor and the Angular Tour of Heroes tutorial.
Karma and Protractor are the two testing tools that we will be using for this project. Karma is used to write unit tests while Protractor is used for end-to-end testing. My teammate Ryan put together a very useful Google Doc that includes all of the basic information about these two tools including how they work, how to use them, and helpful links to learn more. This is the main resource I used because it includes pretty much everything I wanted to know about Karma and Protractor.
The following link provides a good overview of what Karma is and how it works: http://karma-runner.github.io/3.0/intro/how-it-works.html
Karma works by creating a web server that executes source code against test code. The test results are examined and displayed through the command line so the developer can see which tests and browsers passed or failed. Karma looks like it will be an incredibly useful tool for unit testing our code.
Protractor also uses a web server to run browsers that will test the code. It simulates user interaction with Angular applications in order to test system dependencies. The following link is a good tutorial that helped me get familiarized with Protractor and learn the basics of how it works:
http://www.protractortest.org/#/tutorial
Other than learning about these two testing tools, I also started doing the Angular Tour of Heroes tutorial in order to re-familiarize myself with Angular. I have previously done this tutorial in Software Construction, Design, and Architecture. However, I wanted to go through it again to make sure that I remembered the specifics of Angular and Typescript. Even though I haven’t gotten incredibly far in the tutorial, much of the information is coming back to me. I think the Tour of Heroes is one of the best coding tutorials I’ve ever used. Everything is explained clearly, there are links for more complex topics that come up, and all of the code you should have is displayed at the end. There are also summaries at the end of each section that review everything that was learned. I’m glad that I started doing this tutorial because I now feel more prepared and also eager to start actually coding.
Overall our second sprint was still all about preparation. While I do wish we could have started working on something during this sprint, it’s good that we have had plenty of time to learn about the tools we will be using so we aren’t caught off guard when we have to actually produce code. During this sprint I learned a lot about testing with Karma and Protractor and relearned information about Angular. I’m excited for the next sprint as it looks like AMPATH has finally sent us information on the work that we will be doing.
From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.
On our second sprint, Team FIG definitely got more of the ball rolling with our progress on the project. Following a meeting with a representative from the food pantry, we were able to discuss some of our stories and tasks and what each member was going to work on, and were able to begin in earnest. I felt a lot better going into this sprint as it seems our goals were becoming more clear and it felt like I knew what I could do to make progress.
My tasks was to begin work on a front-end system that the food pantry could use to keep track of the weight they are giving out and automate some of the process of filling out an intake form and determining the proper amount of food in weight. I referred a lot to my final project from CS-443 last semester, developing a sort of “back-end” that enabled me to test the functionality of my front-end. After that was squared away, I began developing the front end. Since exactly what the customer wants still doesn’t seem crystal clear to me, I thought it would make the most sense to take the provided intake form and try to implement it in an online application.
After I wrote all the functions to allow adding/changing of data in the back end, I developed the HTML part of the front-end, adding the input boxes and buttons for submission and making sure they used the right commands. Things I still need to add to the front-end are error messages for incorrect submissions (missing data, wrong input type, etc). It might also be prudent to add some way for authorized users to change customer information that has already been entered, in case of a mistake or changing information. I have also not began working with the CSS, as it has been low priority for me, and I have questions to ask about what sort of style we should be going for. I also have not done anything with keeping a running weight total or adding/removing from that total.
The current issue I am dealing with is a ‘fatal’ error preventing me from committing to GitHub that says the line endings need to be replaced with LF from CRLF, which seems to be an issue with the way Windows handles line endings. I decided this was a good place to stop anyways, as I was having trouble fixing the issue and had done a lot of work without being able to review it with my group. It is unfortunate that we have had three classes cancelled, as it definitely hurt my groups ability to meet up and their motivation to do so.
The biggest task our group has to work on now is creating a functional back-end that will be able to store the information. We have not determined exactly how this will be done yet, but it is something we will definitely discuss so we can begin work on it in Sprint 3.
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.
This semester for my Software Development Capstone course we are working on a AMPATH project working on a point of system by Ampaths Clinic. For this semester I will be working on this with a team. This blog is actually Sprint-2 Retrospective blog post. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, March 7th, 2019, we have completed Sprint-2. During this second sprint we were able to get everything we intended to get done during this second sprint cycle. For sprint-2 everyone in the team had the same task except they where more individual kind of task. These task were:
From the list of task above I was able to complete both task listed. Although, there is more to learn about testing in angular I was able to at least learn the basic of it. I learned about testing in angular by following the karma and protractor tutorial. These tutorial were very informative and straight forward. In my opinion, from the task of this week… learning about karma and protractor was not as complicated as trying to build/run ng2-amrs. Trying to build/run ng2-arms on my PC took a lot of researching and configuring in order to be able to successfully build/run ng2-arms. During this sprint I had better luck… where I was able to get the ng2-arms project to successfully build/run on my PC.
During sprint-2 I learned about testing in angular using karma and protractor. Karma taught me how to unit test on angular, and protractor taught me about end-to-end testing and its basics. These are testing tools that are going to help me test the code develop by my team and I. During this sprint I also, learnt a lot of different ways to handle problems when trying to build the ng2-amrs and the different ways to fix a problem when trying to build/run ng2-arms. I also realized that not everyone might run into the same problem when trying to build/run ng2-arms. What worked for me was opening Git bash in the ng2-amrs file typing “npm install”, I then “ng build”. When I did that came across a problem that stated I did not have “@angular-devkit/build-angular” so, I had to type “npm i @angular-devkit/build-angular” on the git bash command prompt. I then was able to “ng build” and “ng serve” successfully. I had a few error I did had to fix and things I needed to install. However, I don’t remember all the error and problems I came across. For this sprint I found a lot of useful information and help on the ampath slack channel, and on stackOverflow with the help of Google.
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.
For my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on Stack Overflow. Through the process of not being able to install angular-cli on my mac, it led me to installing nvm, where there was another series of instructions to follow through Github.
It is very relieving whenever we get stuck on something and are able to find similar scenarios from people around the world who have run into the same roadblock and they share advice on how to work around it. Thanks to their input, I was able to resolve my terminal errors and/or warnings that resulted from trying to build something. It also helped me try and see if I could assist any of my other teammates who were running into errors as well even on Windows. I would definitely continue using the internet as a resource when I get stuck on mac-specific issues. The same thing happens when an installation that is only available in .exe files is required, I must find a mac-appropriate version.
However, if I were to proceed any differently; I would have double-or-triple-checked what is necessary to move forward. If someone else were to follow these steps; I would highly recommend checking out the links I provided above when I was unable to install angular-cli on my mac.
So far, we have been hit with some New England weather
which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.
A big update is we got some more information on the AMPATH x WSU collab right around the end of this sprint so I am looking forward to exploring that with my team. It will allow us to analyze what has been given to us and decide where to move forward with the project.
Overall this past sprint included a lot more learning and collaborating with my team. I’m excited to begin watching the walk-through videos that Greg uploaded of the wire-frames. They look like they are broken down well and all of them are combined into a playlist so I would say we are going to be learning a lot more. Stay tuned for the Sprint 3 retrospective!
From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.
This reflection is based on the work done from 2/20 to now, 3/5. In this time, our team has only met two times and I missed one of those meetings, so not a whole lot actually got done together during sprint two. We met in class and made progress on 2/20, I was absent from the meeting on 2/25. On 2/27, class was expectedly canceled with the optional choice to meet in class anyway, which we decided against. We figured we could wrap up anything that we needed to work on in the upcoming Monday’s class. Yesterday, on 3/4, Worcester State canceled all classes and events due to inclement weather, and the end of the sprint is next class at 3/5.
Our workload was fairly light anyway, we only had two sprint backlog tasks; make sure every team member could build and run the project, and learn more about angular testing. We could independently conduct research into testing, and we are encouraged to branch out to find potentially helpful content, so the snow day didn’t slow us down significantly.
To study angular testing, our group particularly focused on the two programs karma and protractor. Using the trello project management board we set up in the last sprint, two links were shared for the group to look over. For karma, I used the following link:
https://karma-runner.github.io/3.0/intro/how-it-works.html
This website explains in general terms how karma works. It loads multiple browsers and tests given code on each one, displaying the results conveniently to the developer. We will have to practice hands on with karma once we get some code and tests. For protractor, we used the following link:
http://www.protractortest.org/#/tutorial
All the information on protractors site is very hands on and literal. It explains steps and shows exact commands and lines for example, it should be easily set up and modified to our project. Since we downloaded the latest version of node.js in the last sprint, and have experience using npm, protractor will be a useful resource.
Our more major goal for sprint two was to have every member a working build of the AMPATH project in an IDE of choice. Right now, everybody besides me has a running project since I missed the last meeting. I will need to communicate with them for help troubleshooting and follow the same steps they took the next time we are all in class together.
At the same time, during our next meeting we will be planning for sprint three. We don’t have much on our plate currently since we’ve been making pretty good progress so far, so I’m not sure what to expect for sprint three. I think Professor Wurst will be giving us more concrete things to do, which we can add to our trello board.
We’ve also been keeping up to date on slack, every group member answers automatic check-ins two times a week. This keeps us all updated on what we’ve done since the last check in, what we are planning to do before the next check in, and state any obstacles blocking our progress.
From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.
With now two full sprints under my belt, I think I’m beginning to grasp not only the aspects of team dynamics with which I have comfort, but also those aspects with which I have discomfort. I am glad to be encountering obstacles and pitfalls in an academic setting rather than in a much higher-stakes workplace environment.
Where last sprint was primarily concerned with setup tasks, this sprint was more geared toward design – be it the design of the user interface, the program structure, or the module as a whole. We determined as a team during our first meeting that we would take responsibility for developing the Offline Data Storage service. Much of the remaining class period was spent looking over user stories, and looking into the suggested service for offline storage: PouchDB. Over the next several meetings, we worked toward three goals in particular. Firstly, we wanted to figure out the best way to transition from the online state of the application to the offline state of the application. To this end, we drew up a few of our ideas, and posted a number of them to Balsamiq. In addition, we sought a better understanding of PouchDB, so many of us spent ample amounts of time doing online exercises from the PouchDB website and making small, basic offline applications for practice. Perhaps least importantly – but certainly still relevant – is that we spent time during each meeting reading through the code that Ampath has already written. We focused on their data storage service that is already in use for their online storage, and are looking to see if we can translate ideas from those sections of code to the ones we develop.
As far as my contributions to the team this week, I would say that the largest part I played was in the dissection of Ampath’s code, and in the assistance with PouchDB growing pains with the exercises. I would have liked to have spent more time working out a foundation of a plan for our service’s implementation. In the sprints to come, I hope to dedicate more resources toward the actual building of the service, so that we can get the ball rolling with the code.
The biggest takeaway I came to from this week is that self-management is a critical skill in the field of software development. Although we are not yet at the stage of writing the actual classes for the project, it is clear that each of us is not used to having a large task with no overseer. While Ampath is technically available via Slack, we haven’t had much success in getting additional information from them, such as a UML diagram for the existing project (which we were told does not exist). As a result, we have had to maintain a degree of discipline on our own without the extrinsically motivational forces we have grown used to. Going forward, I hope to develop a more productive and attentive attitude, and believe that such a change will greatly benefit the project.
From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.