Links below for my work on Sprint 1 of the LibreFoodPantry project.
MongoDB spike:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
The goal of this task was to preview MongoDb and determine whether or not it will be useful for the project.

Production DB:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/8
The goal of this task was to create a working Database to match our schema and work with our Rest API.

My favorite part of the scrum framework was actually the integration of kanban. The mixture of the two frameworks really made the work environment productive, predictable, and understandable. My team members and I assigned roles respectively to the scrum framework guidelines, at least two members of the team would know how something is done so that only one member would not have sole knowledge of the task. This way it made it easy to spread the knowledge throughout the team without holding up productivity. If one team member was busy then often the other would be available, or would be in the near future. This team plan also made development quicker in a way that if you were stuck on a task, your fellow task member may have another way of figuring out the issue. Together you can overcome obstacles easier than on your own. A great example of this is when I was developing a Production Database that could be used with our Rest API. I was having trouble figuring out the java code for MongoDb queries. Setting up the connection wasn’t the main goal of the task but it was necessary to have an understanding of it to be sure that MongoDb was the database application we would use. The issue was querying dates and one team member and myself were using CalenderDate which worked, but it ended up being eight lines of code to set up. My other team member on the task figured out LocalDate can achieve the same success with only two lines of code. If I had been left to the task myself the code would be less clean and bulkier, but thanks to my team members different approach we have clean and concise code.

The only things that didn’t work so well was our activity on planning and taking notes on Gitlab. We did not plan in the best way that we could have for the sprint and were constantly editing our backlog and to do lists. We also scarcely posted notes and updates on Gitlab. We did complete our task frameworks in order to move them into the done board. However, we did not thoroughly record our progress on Gitlab. In this way it could be hard for a newcomer to understand the evolution of our issues and how we solved them. They would only see the beginning and end product which is not clear and understandable.

To improve as a team we need to break down our planning technique and make sure our issues are concise and weighted correctly. I think our only problem with this was that we planned last minute because we were unclear of what was expected. However, now that we know we should be able to plan better and make sure our to-do list is concise.

To improve as an individual I need to record my progress, mistakes and achievements on Gitlab more often. Frequent updates on Gitlab would allow a newcomer to see my process and avoid failures that I may have already attempted so that they don’t waste time on something that already is proven to not work. Perhaps they actually solve a failure that I had attempted but was not able to make functional. Without notes to address these topics then a newcomer would not be able to interact and understand our work.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Hello my readers. So as I mentioned in the very first blog for this semester, all the blog posts will be related to that class. This is a Capstone class and we are working in groups in a project that I am really looking forward to give my contribution.

But what is AMPATH? AMPATH stands for Academic Model Providing Access to Healthcare and is a healthcare partnership based in Kenya and created from different organizations. As far as I understood from my professor, there are multiple universities working on the AMPATH project. What we will be doing this semester is to help developers in Kenya as they are rebuilding the system. Excitingggg!!

Before the second sprint kicks in, here I am thinking about how did this last sprint go. Overall good I would say! My biggest disadvantage was that I had to be away for a week from the country and I kinda missed a few meetings but was able to recover in time without missing much information.

Starting working with AMPATH felt to me just like starting a new job. During sprint one we mostly got familiar with tools, the program we were going to use, our teammates, the systems we were going to use. We were assigned to different teams based on our availability. Fortunately I knew half of my team as I had worked with them in the past in other projects and was looking forward to work with the other developers as well.

In all this new process, I would like to point out one of the systems that i really liked and had not used before: Trello. It was very convenient to have all the stages of the First Sprint lined up in front of you (Product Backlog, Sprint Backlog, In Progress an Done). We started to organize our work and what needed to be done to increase our productivity.

Another step we took was pulling, cloning and getting familiar with the code of the project we were going to use. As a new MAC users (pointing this as I don’t know Mac too much) I had a few issues with running the code in my computer. Kristi though, was able to help me figure out the issue and solve it. .

Unfortunately our semester is a bit short for us to have big development getting done. However I am very excited for the new learning that I am and will be getting out of this project. I choose this project because I thought this way I could assist in an application that was real and had a good purpose.

I would consider this sprint as a research sprint where we researched and tried to learn ans study a lot about Karma ( a test runner for JavaScript), and JavaScript itself. Personally I hadn’t worked with it a lot and needed a few more blogs/chapters to read about it. I am really looking forward to the next sprints and to see what we will be achieving. I didn’t lie when I said it felt like starting a new job :).

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

For our project Software Development Capstone course, we got assign to working on food pantry. After we got to know our group members, we started to research about food pantry. We looked at how the data stored, what kind of software there are and what steps we need to take. At first, we meet our first problem, our project still in the early stage we didn’t know what customer are looking for. We took one by one step to set up our operation. We set up slack for our communication, we also have channel to communicate to other schools and food pantry owner. For planning and assign job to team members, we use Trello. We set up different stage of development “Product Backlog”, “Sprint Backlog”, “To Do”, “Doing”, “Review” and “Done”. We agreed on this setup is best for our operation, this way we know how doing what job and what been done and coming up. Next, we looked at what software and technique that require for this task. We know that we are using JSON file from USDA’s website as data base. We need to set up API able to read and get the information we need from JSON file. In order to get specific information as customer want such as what type of food, their expiration date and create report. We agreed using java for this project. Since most of us comfortable with it. That is most of back-end data that we are working with. ( https://catalog.data.gov/dataset/fsis-foodkeeper-data )

We need to host API where can be access online, there are a few options with paid and free. We chose Heroku since it is free, and we feel comfortable with it. To setup Heroku we need an account and set up app on our computer. They have good information on their Documentation Page. ( https://devcenter.heroku.com/ ) We are planning to set up mock-up test for JSON parsing and front end, where we can test and see how our project work. We figure since we still at early stage, we don’t know how other set up their front end. We can set up our own and make sure it would work.

Although at the beginning we didn’t know where we supposed to do, we weren’t used to project in early stage. I feel much better now that we got more ideas about what to do. This has been interesting, we learned about how the team set up in software development. We have good members that take on the job, I am still learning and trying to help. It is excited and fun to figure it out, next at the food pantry meeting with customers. We will have better idea of what they are looking for.

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.

For this week, I have finished up Sprint 1 and I would glad to be talking about it.

What I wish I could done throughout this sprint was to know what was figuring out my laptop

Link:

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.

Hello everyone and welcome to the first sprint retrospective blog posts. Today I’m going to go over what had happened during the first sprint. During the first sprint, we first got familiar with each other because we just had form groups. We then decided on a team name which was 3m2g which stands for 3 mud kips and 2 goats. This team name was combined with two of the most voted names that were considered. We made a list of what had to be done in the product backlog and discussed with each other on what can be done in a certain amount of time. Here were the objectives that we had to complete. First, as a team developing software for AMPATH, we need a GitHub group so we can fork the AMPATH/ng2-amrs repository. Second, as a developer working on AMPATH/ng2-amrs, I need to clone ng2-amrs to my computer (every team member). Third, as a developer working on ng2-amrs, I need to set up my development environment so I can build/run ng2-amrs. Fourth, as a developer working on ng2-amrs, I need to learn about testing in Angular so I can write tests for our new code. When setting up the environment, it was easy because most of the needed software so already installed from the previous CS course. I had the following software and applications was already installed like Insomnia, Gradle, and some sort of Typescript IDE which I had Visual Studio Code installed. Some of the members of my group didn’t have some the development environment installed so the members that finished help provide information when needed. We also had to learn more about these testing tools which are karma and protractor. During the process, the of cloning the AMPATH/ng2-amrs project, Me and my fellow’s group members didn’t come across an issue. The only problem we had to was attempting to run the project which was unsuccessful. I then decided to follow one of the apprentice patterns which had to advise me to ask the help when needed. So, I call my friend Khoa which I and he went over the error and then figure out the solution. I then posted the solution into slack and notify my group of my fix. I learn more about understand certain errors and how to fix them on the day. Some of the software and application that I had installed on my previous class work fine but just need to be updated. When working on the first sprint I became more familiar with SCRUM and really understanding the importance of it. Also, when looking for information about testing in angular I came across many informative sites when inputting angular test on google. I missed the last day of the sprint, but the members of my team were very helpful in informing me of the information that I missed during that day. All in all, this first sprint was simply because the product backlog was a familiar assignment that was accomplished before and I enjoy working with the members of my group.

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

Good day my fellow readers. Today I will be writing a retrospective on my first Sprint. For this Sprint, we were tasked with mainly setup tasks from our Product Manager. The first task we as a group decided to conquer was the simple task of reviewing the README for the AMPATH software we would be editing. It appears that, from the last time our Product Manager worked with AMPATH, there was a contributing section that was removed in the current iteration. The next task tackled was to create a Github organization, fork the ng2-amrs software to the organization, and clone the software our machines. We then needed to ensure that npm, Insomnia, and a Typescript compatible IDE were all installed on our machines. I believe that we will need to install Gradle as well for some of the testing packages but, due to the pains that come with installing Gradle, as a group we decided that we can put off installing Gradle until it is determined that Gradle is actually needed. With all that situated, we then installed and played around in OpenMRS, a demo of an EMR, or electronic medical record system. The point of this was to gain a feel for an EMR first hand and it was neat to play around with one. The next task was to actually get ng2-amrs running on our units. This was the troublesome part of this sprint. During this part of the Sprint, I got sick and regrettably, did little towards getting it running on my unit at first. During that time, however, others in both my group and the other AMPATH groups did solve many of the issues that would crop up. This created a wealth of troubleshooting resources and made it much easier for everyone to get their ng2-amrs software working. At the end of the Sprint, our group did have a couple tasks left that we did not accomplish and had to push to our next Sprint. These tasks were to install both Karma and Protractor and learn more about both of them. They are both testing software that we will eventually be used for testing our changes to the AMPATH ng2-amrs software. We also pushed having everyone up and running with ng2-amrs due to some members, including myself still having issues getting it running. Thankfully, two members of our group have the software fully up and running.

This Sprint has forced me to dive back into some work from a previous class to remember how to work with npm and Insomnia. While I did not need Insomnia, in particular, this sprint, it was collateral learning. I also got a chance to learn about electronic medicals records as well and get a, “peek behind the curtain” as it were. We not only had to mess around with the OpenMRS software, but we also had to listen to an article called, “Why Doctors hate Their Computers”. This article, in summary, told the story of doctors struggling with their new EMR software and investigating the cause of this hatred. In the end, I came to the conclusion that the cause of the pain of doctors was that the EMR software was directed to the patient as the customer, rather than the doctors who actually use the software. This did put a thought into my mind that while working on the AMPATH software I should not only keep the doctors in mind but keep the patients in mind as well.

That is what happened, and what I learned on my first of many sprints to come. See you next time readers!

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

Over the course of this sprint, I have started to understand more about various aspects of software development that don’t necessarily include coding. Between getting to know the other members of my team and troubleshooting the errors upon errors that I encountered while setting up my development environment, there was plenty to learn about and work on each day. These skills are definitely applicable to countless other scenarios – for example, troubleshooting is necessary on a daily, if not hourly, basis. If I had a chance to go back and redo this sprint, I would probably have distributed my time more evenly for the task that took the longest to complete (troubleshooting the provided Angular project so that it built and ran successfully), rather than working on it somewhat irregularly, which was during working class sessions and occasionally outside of class.

For the past couple of weeks that made up the sprint, we have been spending time completing various set-up tasks related to the user stories given during our sprint planning session. Our team is collaborating with AMPATH (more information about their organization here), working with their medical record software. The tasks completed this week included cloning their “ng2-amrs” project repository onto our own local machines, successfully running the project, and downloading any additional programs to prepare for writing and testing code. Using a Trello board, we organized these tasks (and will continue to do so throughout the semester) into “Doing” and “Done” columns, with the user stories either staying in the overall Product Backlog or the latest Sprint Backlog if we wanted to get those completed during this sprint.

In order to clone the project, we first created a GitHub organization, adding each team member to the group. Then, one of us forked the project from the AMPATH repository to our organization repository. Finally, each team member cloned the project to our computers. None of us had any issues with this task. When we were downloading other programs that may come in handy later (like a TypeScript IDE, as well as Insomnia for work with REST APIs), there didn’t seem to be any issue with this either.

The vast majority of problems arose when it was time to build and run the ng2-amrs Angular project. When I initially ran the build command (“ng build –prod”), a bunch of errors popped up, preventing compilation and building of the project. Fortunately, several classmates have been posting discussions and solutions to many of these errors on our Slack channel, and these were so helpful when I was trying to troubleshoot my project. These discussions combined with frantic Google searches got me through this process of fixing my project.

One of the errors had to do with inadequate memory allocation when running the build. This was solved using the commands presented in Reference #1, which adjusted the memory used to extend its limit. Another error had to do with a package (“ngx-openmrs-formentry”) used in some of the many TypeScript files not being imported or recognized properly in the program. I spent a lot of time trying to fix this issue, even going so far as to re-clone the project twice to no avail. Finally, once I realized that the error messages were coming from the same reappearing package present in the files, I simply reinstalled that package (with the installation command in Reference #2), and that fixed the problem. A third error that I encountered involved the Angular Dev-Kit not being recognized when attempting to run the build. Using the command from Reference #3, this issue was easily resolved.

As of yesterday, using the command “npm start,” I FINALLY got the project to run! This was great timing, as it is now the end of the first sprint and the beginning of the second. I’m looking forward to the upcoming sprint, especially once our team is all up and running!

References

1. https://stackoverflow.com/questions/50621043/fatal-error-call-and-retry-last-allocation-failed-javascript-heap-out-of-memo – used to fix the memory allocation error
2. https://npm.taobao.org/package/ngx-openmrs-formentry – installed to ensure that the specified “ngx-openmrs-formentry” package is being imported properly
3. https://www.npmjs.com/package/@angular-devkit/build-angular – installed to have the Angular Dev-Kit on my local computer to build the project

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law 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-1 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, February 20th, 2019, we have completed Sprint-1. This first sprint was a pretty good sprint where we got a lot of work we needed to do done. However,  there were a few bumps on the road where we didn’t get to do everything we intended to get done during this first sprint cycle. For sprint-1 we had a total of 8 task we were hoping to get done. These task were:

1. Come up with a name for our team.
2. Set-up a sprint-kanban board to keep track of our “Product Backlog”, “Sprint Backlog(stories)”, “Sprint Backlog(task)”, “Doing” and “Done”.
3. Set-up our development environment by installing insomnia, gradle, and a typescript IDE.
4. Create an organization for our team on github
5. Fork ng2-amrs and etl-rest-server repository to our organization and then clone the ng2-amrs and etl-rest-server repository from our organization into our computers.
6. We had to read the readme.md section for instructions.
7. build and run ng2-amrs.
8. Learn about testing in Angular to be able to write tests for our new code.

From the list above I was able to complete all the task except for the last 2. When it came down to trying to build and running ng2-amrs I ran right into a wall. Trying to build or run it feels nearly impossible. I have been trying to do everything possible, and just when I feel I got it going I have more errors appear. Trying to get this going is pretty important since, the purpose of doing this is to make sure the system is running correctly and have it ready for you to modify and update it with your code. For the next sprint I am hoping I am able to build/run the system.

From this sprint and activities I have learned that if I am stuck on something to make sure that I do not wait until last minute to ask for help. I have also learned that if your stuck on something try working on the next task and come back to it when your done with that new task. With that in mind going forward I will make sure that I ask for help after struggling for 3-4 days or less. Going forward I will also make sure that if I am stuck. I will take a break from that, move on to the next task, and return the old task after completing the new task. That way I am not wasting too much time on something I am stuck on for too long. Come to think about it these are actually good idea that can be applied in other situations.

For this sprint I did not find any useful information or help. I did manage to go on the slack channel where my team mate kat was successful  and she gave me a few good suggestions I will work on the next sprint to try and get the system build/running. I am certain that for the next sprint I will have better luck!

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.