My first sprint experience was interesting. The experience was more of a sprint-lite, a streamlined version of the process. The tasks we had to accomplish did not have to be split up between team members and there was no real roadblocks that had to be overcome except minor issues which were solved with out too much hair pulling.

This weeks sprint was a learning experience in that it was my first time with sprinting on a software project. It allowed me to get some of the basics down and get used to the experience. Not much would change with the knowledge I have now, other than issues would be fixed sooner. Though they were fixed quite quickly to begin with.

I feel like most of our progress was made during the in class meetings, as we could share a large amount of our findings with each other and have long discussions on them. In the future, I feel as if more discussion should be had remotely, to increase productivity overall. Though this time it did not really matter. Helpful links and tips were still posted to slack. The Trello board was set up quite quickly, and the stand ups were finished by everyone pretty consistently. Barring two very minor misses. Overall, the team worked really well together. Everyone was helpful and made contributions to aid others. I brought up a fix for an issue I will describe in a few moments, and was helped in resolving an error by a fellow team member.

During the week everyone had to setup their teams repositories which had forked versions of the n2-amrs app. They then had to get the application working on their machines. The steps to take were basic, but they did not end up being as simple as they should have. Npm install should have installed all dependencies and npm run should started the application running. However, many people, including me, received errors when trying to install dependencies. The errors mention files that do not exist in the application. I searched the issue and online and was able to come upon a page on git about the specific issue with many suggestions for fixing it. Here’s a link to the page in question:

https://github.com/npm/npm/issues/17444

The method that ended up working for me was to delete package-lock.json, which would be reinstalled along with the other dependencies after running npm install.

Running the application came with an issue in the styles guide file, where it could not find another file called ladda.min.css . There were suggested fixes on the general slack channel, and suggestions made by my team mates. I ultimately fixed it by moving the ladd.min.css file and then rewriting the path in the styles guide file to its new location.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

During the first sprint of my software development capstone, it mainly consisted of setup tasks which would aid into the upcoming sprints that are later to come. What I’ve learned was how to adapt to the team that I’ve been set up with, using Angular through the webstorm IDE, accessing the AMPATH server, briefly using trello, using git commands, communicating on the Slack channel, managing the Team’s git repository, and experiencing of what it’s like to work in a software development environment. Looking back on how I’ve learned all of these things, what I would’ve done differently is that I would communicate to my teammates a little bit more through the slack channel because there would be times where my teammates would often lose sight on what I was doing. They could only know through the standups that we do every Monday, Wednesday and Friday during the sprints. That would be one of the main areas that I could’ve improved on and would’ve done differently.

Out of these things that I’ve learned through this first sprint, they could all be applied in upcoming situations. Communication will always be an ongoing action to take especially working in a team since everyone needs to be up to date on each others work. Angular will probably be in constant use as well as the Slack channel and possibly trello. Acessing the AMPATH server will probably be a must in all sprints as well because the team and I will be submitting code to the server.

On a scale of one to ten, where ten is the highest, the team’s effectiveness throughout this sprint would be an eight and a half. There were some instances where my team members Rick, Jason, Jeremiah, and myself all had trouble getting access to the AMPATH server. Some of us had to install some dependencies, whereas some of us had to update the webstorm IDE. There was a case where Rick had inputted the wrong command into the terminal in the webstorm IDE to connect to the AMPATH server. At first we thought there could be something wrong with his code, which led to spending an entire class on figuring out what went wrong. That’s when we knew at the end that he had entered the wrong command. After all of the team members had successfully accessed the server’s login menu, it was smooth sailing from there.

As an individual throughout working in this team, I felt I was competent enough to do the work that was assigned to me. Besides going through some trouble with accessing the server, the process of trial and error helped me learn new things, which led me to teach my teammates things that I encountered along the way. Besides delivering quality work, I tried to be the individual within the group that made the atmosphere more enjoyable, especially in group discussions about our current tasks. What we will be doing differently moving forward is that we would organize our tasks a lot better through the concepts of the trello board by organizing and assigning tasks to each individual team member. That way, it allows everyone to keep track on who is doing what.

What was done during the week was we established a connection to the AMPATH server, created a trello board for the team, practiced some angular tutorials, and managed a github repository. As said earlier we tried many things to fix and gain access to the AMPATH server login screen through using different commands, updating webstorm and installing dependencies. We tried the command “npm run server” or “npm start” in the terminal in webstorm, and that worked. The command that failed back in Rick’s situation was “ng serve”. There were also some instances where Jeremiah and I had to uninstall node.js and install it again, which was one of the course of actions we took when nothing else worked.

Overall, the first sprint was a learning experience for myself and the others. Currently, we are trying to figure out a better way to manage our github repository that allows an easier way to do pull requests. My teammates and will come up with something later on.

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

The focus of the first sprint was cloning and building AMPATH’s existing code on our own systems in order to get us in a position to begin adding the desired functionality. Additionally, we set up our team’s Trello scrum board and our team GitHub organization, and we began learning about both Angular testing and the JIRA project tracker. We ran into problems most significantly when we couldn’t build ng2-amrs due to compiler errors, but by the end of the sprint we were all in a position to successfully build it.

I downloaded Visual Studio Code and an add-on for TypeScript to use as my editor for this project, since WebStorm so slowly it’s impossible to use on my laptop. This is the first editor listed in the recommendations in AMPATH’s readme file, and so far it runs smoothly for me.

To start off the sprint, I created our GitHub organization and invited all team members and Professor Wurst. George forked the repository from AMPATH. Everyone cloned the repository, and we began going through the readme file. We installed the required dependencies and began attempting to build ng2-amrs, at which point we began encountering errors. Matt figured out that some references to ladda.min.css and ladda.directive.js were producing the errors and implemented a fix that resolved the errors. He created a list of instructions for fixing the errors and shared it. Members of other teams (Oren and Rick) made corrections to these instructions. I and others on my team made the outlined changes, after which we were able to successfully build ng2-amrs.

After this, we learned about doing scrum on JIRA, and some of us went on to learn how tests work in Angular. Matt and George were able to connect ng2-amrs to the server.

For JIRA, I consulted Atlassian: https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software. To learn about Angular testing, I began reading the official Angular testing guide: https://angular.io/guide/testing.

Our team worked closely in the beginning, but then began to work more independently when installing the required dependencies took varying amounts of time for all of us. We shared Matt’s fix to the ladda compilation errors and aided each other in implementing the changes as team members became ready. Our team had difficulty showing up in full to the stand-ups. We haven’t yet decided as a team any specifics as to how we will proceed differently, but I hope to get from everybody a reliable way of contacting them so we can increase our team’s communication and so I can provide reminders if that’s something other team members would appreciate. I think our team will do better if we can close the gaps in the progress we’re making as individuals.

As this sprint consisted mostly of set-up tasks, I didn’t learn much that could be applied to future situations apart from the way our team functions. In light of this, I would strive to keep us on the same page and updating each other on our progress.

To do the same work we did, someone could fork and clone ng2-amrs and follow the most recent set of instructions to fix the ladda errors. Better yet, they might be able to proceed without having to fix anything, as the pull request containing the necessary changes was approved and merged into the course repository’s master branch.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

This sprint session was really an exciting one and it start with individual student taking the CATME survey which enables the professor to place students in the appropriate group based on the students’ availability. Teams of five were formed initially and we named ours the gung of five. One of our team members could not make with us and our team ended up with four members. We again deliberated on changing the name from the Gung of Five and we settled on the Abstract Class. The team decided Rick Phillips should be our leader and since then Rick have been leading the team in all our discussions. Rick created a repository and cloned the class repository to it and the rest of the team members fork our own copy to our repository.

At the beginning, we tasked ourselves to have the environment setup for everyone. As we are all using web storm, I had it install on my laptop from the previous semester and the only thing I was to do hen was just to upload the ng2-amrs cloned to the desktop.  I had so many challenges as I tried to compile to project. Almost everybody in the team faces similar problems. We had errors coming from many difference angles including ladda.min.css file and styles.scss file. With the help of Rick Phillips and Jason, I was able to resolve all the compilation issues. After this stage of our setup task, I was at the login screen where almost all the team members were. Just before our next meeting, I encounter another problem that we spent the entire class time trying to resolve it. Among the step taken to resolve it was to delete the entire work and clone it again from the repository to the desktop.  At some point in trying to fix it, Rick Phillips also had the same problem then we tried to check our step and command because that seems unusual. We checked our step and realized we were using a wrong command for compiling the app; we were using ng serve to start the server instead of npm start.  We figure this out when Rick Phillips faces the same problem. I have learnt a lesson and I don’t think we will repeat that anytime.

Besides the setup task, we also tasked ourselves to do the things in the trello board.  By then we already have our github accounts setup and as directed by the team, I went through the tasks in the trello board one after the other.

One last thing I did was to watch that video posted on ampath slack channel which explains the instructions of connecting to the server built for this project. The steps in the instruction video were pretty much simple and straight forward so I did not have any difficulties in getting connected to the server.

So many things were leant including how we have to go into the app module and change some line to have the app working and how our own negligence causes us a whole meeting trying to figure out how to resolve issues. In the future, I will be paying attention to instructions done just trying to fix problems as they come.

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

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

My team’s name for this project is “Everyone Else”. Everyone Else consists of myself (Shane Rookey), Caleb Pruitt, Ben Lagasse, Fuverion Ymeri, and Connor Virzi. The first sprint went pretty smoothly and we learned that we were capable of working through errors and fixing them to get our application running.  We all had issues getting the app running. Most of those issues came from missing dependencies that were supposed to be installed but weren’t (for whatever reason).  After trying “npm install” a couple of times I figured that something happened to get installed wrong because I was getting different errors that no one else was getting.

Specifically, when trying to run npm install  in the ng2-amrs directory i was getting an error that said something along the lines of “Missing package Dezalgo” which was supposed to be installed when I installed all of the dependencies. What I did to fix this problem was erase the entire repository on my computer. I then cloned the repository from GitHub again and installed all of the dependencies AGAIN. Before running npm install, I deleted the package-lock.json file in ng2-amrs directory. Once deleted, I ran npm install and it worked like a charm. After npm install, I was able to run npm start and get the test server up and running.

One other thing I needed to get the test server working was a Google Chrome extension called “Allow-Control-Allow-Origin”. This was required by AMPath to connect to the test server.

You can find instructions for the extension here:

https://www.useloom.com/share/97cab1199df843d4b04b41ec8cbd7582

This entire process so far has been an excellent learning (and refreshing) opportunity. I have been familiar with GitHub before, but I have never been a part of a project that is a REAL thing (if you know what I mean). These people we are working with have a REAL business and we are trying to help people make their programs better. It is truly encouraging and fun. Working remotely with GitHub will be good experience for the working world because almost everyone uses version control of some kind.

I have also never worked with 4 other people at once on a single computer science project where we are all trying to work towards the same goal. Its inspiring to have a team and also motivational because you don’t want to let them down. Two people on my team missed a standup for the first sprint but I don’t hold it against them, It is difficult to remember that you need to do something every single day to reach your goal, even if that is just some planning and communicating. I think my team will truly step up and begin to shine once we delve into the more technical work.

Besides getting the test server up and running, we looked over the user stories to see what we were going to be dealing with. For each one we quickly brainstormed what each story might entail regardless of what task we ended up with. I am excitted to continue on with this process and get planning for the next sprint on Thursday.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

I have just finished the first sprint and there are a lot of things that I’ve learned from this experience so far. Before I talk about the experience I’ve had, I’d like to share my opinions about the task we will be performing down the line. I think that the work that we will be doing for Ampath is both really interesting and pretty important, it’s pretty nice to know that if this functionality can be completed it will be used to make a difference in other people’s lives. That being said, this week I’ve learned a bit about node, and javascript and some of the other components that Ampath uses, most of this knowledge so far on only top level but I am looking forward to diving deeper in the coming weeks. The components weren’t perfectly set up for us, there were a few bugs which members of the team took care of fairly quickly and this reminded me of how valuable teamwork is. If there is a lesson that I will take with me going forward from this week, (and this applies in most professions) is truly how valuable teamwork is.

On the topic of teamwork, my team worked very well together internally but even better still, we worked well as a class. I think that this ability to reach out to other groups will be extremely helpful down the line since we most likely be working on different components/modules.  I thought my participation was fair, but It could’ve been better. Moving forward I will try to spend more time trying to understand the code and most importantly improving my communication with the team. As a team we also are striving to improve our communication with each other.

During this week we mostly spent the entire time setting up. We had to set up all of the accounts that we needed including Jira, Trello, Git, Slack, Catme, etc. The setting up of the accounts was fairly straight forward, then we had to work on setting up the repositories at the class level, team level, and developer level. While setting up the repos we were also setting up our dev environments, this involved installing the NPM (Node Package Manager) and getting the Ampath application installed and successfully built. Successfully building the Ampath app required some extra work due to a bug that was quickly discovered. This bug was caused by a missing reference to a style resource, this bug was quickly fixed by (I believe) Oran Shoemaker and he shared it with the team to unblock the rest of us. The only other sizeable hiccup that we encountered was in connecting with the server, but the ampath team provided us with the instructions on how to do it correctly. During this time we were going through the Trello board and participating in scrum to share with the team our current status.

As a team, we were able to get through almost all of the Trello tasks for this sprint. There were a few that remained, but those tasks were either completed and not marked so or nearly finished. Personally I will make an effort to keep Trello up to date as much as possible. In conclusion, this sprint has done a great job giving me a general idea of what is to come and showed me that we as a team must work well to get it all accomplished.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

In this sprint I learned how to set up a development environment for a fairly unfamiliar IDE and language, and I learned how to work with other people to work through issues in building a local copy of the AMPATH app.  I struggled most in the latter with actually understanding the error messages and how to resolve them.  I can take the difficulty I experienced with this process and use as a reminder in the future to more carefully pick through the error messages and try to resolve the conflicts myself.  I was concerned about making changes to files or folders, even though the worst outcome would just be reverting back a version.

I think the team worked pretty well together on this sprint, although it’s a little early to tell.  We were all working on the same thing (environment/app setup) which didn’t offer a lot of room for collaboration other than helping each other resolve problems.  I think that we’ll get a better feel for our team dynamic in this upcoming sprint when we have more “real” work to do.

This sprint was primarily focused on getting the AMPATH app up and running on my local systems.  I started by forking the repository from the group repo, then cloning it to my system.  I then looked through the README and tried to follow the instructions.  I must have done something incorrectly or in the wrong order, because I ran into missing dependencies (which should have been downloaded by npm).  I then tried a variety of solutions to resolve the problems.  I attempted to directly install the dependencies (didn’t work, due to a file/folder creation error).  I deleted and checked out the project again (didn’t work either, same issues as before).  I tried rolling back to older versions of Angular and npm, which was suggested by a couple of StackOverflow pages I found relating to similar errors  (did not work, bricked my Angular install, had to reinstall).  On the second or third try of just installing the dependencies (with a clean Angular install and project version), I managed to resolve the issue  but then ran into a problem with the ladda module — it wasn’t in the right place for Angular to find it.  I was stuck on that until Matt Foley found and posted a solution.

Once I had the solution to the ladda error, I reinstalled Angular again (just to be sure), worked in order through the steps outlined in the README, worked through Matt Foley’s fix, and wrote up the procedure I took as I went so that other people in my group and in the class could use it.

The prodecure boiled down to the following:

Run npm install, then install global dependencies, then npm install again to catch anything that might have been missed.  Create copies of one of the ladda files in the directory Angular wanted to look for it in, and modify one of the ladda files to point to the proper directory.

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