Sprint Retrospective 1

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.

Sprint Retrospective

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.

Sprint 1 Retrospective – Getting Started

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.

Sprint 1 Retrospective

This was our first sprint as a team and was anything but normal.  I would like to say that I believe that having a sprint where the main objective to set up our personal and team environments was a great starting point.  It allowed everyone on the team to help each other get ready for the project and not feel like we had to rush.  It also gave us to sit together as a team and go through the same steps that we will in future sprints.  There was definitely a lot of experience to gain with very little risk if we did not complete the sprint the correct way.  That’s not to say there was no risk, because if we did not set up our environment or study Angular we will be in trouble next sprint.  We did not start contributing to the project though so it was less stressful than a trial by fire and risk falling behind at the beginning of the project and put the team in a bad mood and kill morale for the rest of the semester.  The other side of this sprint though was that most of the activities were personal and did not contribute to a group whole at the end of the sprint so for times in the middle of the sprint it was hard to be able to talk during the working classes to the rest of the team about our progress and work as a team.  I am fully aware though that that will not be the case moving forward though and even though we will be working individually I think since they will be pieces of a whole it will be easier to collaborate during class and reach out when we run into roadblocks.

This made the rating difficult for the first sprint as well.  It quickly became hard to rate the rest of the team on their contributions to the team during the sprint when there was not much of a team effort needed, with the main exception being if someone needed assistance setting up the environment or asked a specific question on one of the user stories.

I feel like this sprint got our team ready to go though and I look forward to helping improve this application throughout the semester and working with my team.  We are set up in a good place and we have a solid foundation to start working on our portion of this project.  I also like that we will be working on a real world application that we can put on our resume, but also one that is doing good throughout the world and be able to point to it in the future and say “I helped make that better.”  I’ve talked to a few people about it, but I think that as a whole everyone is excited to start working on this application and feel that even though we are on separate teams we are all willing to help other teams.  This really has the feeling of a project that is bigger than us and no one is competing against anyone else the way that some may feel if we were all completing the same assignment or taking tests.  We are all taking on this task together and ready to do it to the best of our ability.

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

Sprint Retrospective Blog – First Sprint

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.

Sprint 1 Retrospective

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.

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

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.

Sprint 1 Retrospective: Getting up and Running

We’ve just completed our first sprint in the Software Development Capstone course. I will be posting similar blogs biweekly for the next few months. The purpose is to periodically check in and reflect upon the overall progress of our team.

Many of us, such as myself, learned for the first time what a sprint refers to in the context of software development. The whole concept of “sprints” and scrum is brand new to me. In very simple terms, scrum is a framework where teams produce material in small “bursts” (i.e. sprints) where the intention is to increase overall productivity. I must say that I am enjoying the team based environment, especially because it seems to closely emulate what we should expect when we graduate and transition to our soon-to-be careers.

This first sprint was designed to help us become more familiar with working in development teams, setting up our environment for future sprints, and the whole concept of sprints in general. We are working with AMPATH this semester, contributing to a healthcare consortium software project that is primarily used in the Kenya area. We hope to provide the AMPATH application with feasible offline accessibility, where data can be submitted online once an internet connection is reestablished. Offline access would be a great asset to those using the software, as Kenya internet access is reportedly unreliable at best.

It is our team’s personal goal to contribute as much as possible, assisting our class in accomplishing everything the AMPATH team expects from us. So we spent this sprint getting everything up and running that will be required of us to contribute to the AMPATH project:

  • Slack – Our team has been (and will continue to be) using this platform for communication among ourselves and other teams. Personally I think Slack has certainly contributed to our team’s productivity. While our in-person collaboration is great, I feel it is equally important to have a means of communicating asynchronously; Slack provides this capability for us. We also use Slack to complete our stand-ups, which help periodically determine what each of us currently working on.
  • Trello – We are currently using Trello as a scrum board to manage tasks during each sprint. We’ve spent this first sprint becoming familiar with Trello, such as how to create and assign one or more of us to a “task card.”  For this sprint, we’ve typically either told each other personally or via slack if we completed a Trello card. I feel managing tasks could have been easier if we used Trello more productively; this is something we should work on in future sprints.
  • JIRA – This is a project management web app (similar to Trello) that the AMPATH development team uses. We’ve spent some time reading tutorials regarding the JIRA framework, because we will likely be using this soon.
  • Angular, etc – It was imperative to ensure we all had the required Angular stuff up and running. We’ve also read tutorials to familiarize ourselves with the framework, and how tests work for it. The AMPATH app is written in angular, so in turn we needed the node package manager installed in order to run the angular framework. For more experienced users looking for flexibility, I would recommend Node installation via the Node Version Manager (nvm) app. This is a great tool that allows the on-the-fly switching to different versions of node, something that is much less feasible with the proprietary version from the node.js website.
  • WebStorm – This IDE provides the TypeScript and Angular support we need when working on the AMPATH project. I recommend this to anyone who is a student looking for a good Angular/TypeScript IDE (it’s free for students, otherwise the price is a bit too pricey in my opinion).
  • GitHub – We ensured all of us as a team had GitHub accounts because this is the version control system that AMPATH uses. We then created and forked the project repository to our personal team’s organization. From here we all helped each other successfully clone and install the application to our personal computers.

I feel we collaborated well as a team; overall I would say we’ve had a successful first sprint. My only concern is that we had to change some code in the module files to get the application to run properly. We are not sure if this is a problem in our end, or an issue that AMPATH is experiencing as well. We are in the process of communicating with the AMPATH development team to figure out the best resolution.

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

Post #19 – Ampath Application Development – Sprint 1 Retrospective

Our first sprint was an introductory one where our team officially organized on GitHub and Slack, created local working copies of Ampath’s application, and began looking at Angular resources.

Our team worked well throughout this sprint, despite not having all members present for 1/2 of our in-person meetings.  The required tasks included in this sprint’s back-log were fairly easy to complete, but I did run in to some trouble during the installation of the application’s dependencies.   I was absent for the first meeting following our sprint-planning-meeting, but all of my teammates were extremely helpful in getting my application compiled and running at the following meeting; they each gave me a different piece of advice and the combination of those pieces of advice was instrumental in the completion of this task.  I also received some help from Shane R. who is on one of the other development teams.

We began the sprint by organizing on GitHub so that we could create a working copy of Ampath’s application that would be at our team’s disposal, that we could then clone into local working copies on our individual machines.  We then organized on Slack so that we had a direct means of communication between the members of our team and with our professor.  Finally, we organized on Trello so that we could set up product and sprint back-logs to keep track of what has been and needs to be done.

The next task we had to complete for the sprint was to install the application and its dependencies on each of our machines.  Everybody had a little trouble at first but my troubles persisted right up until the last day of the sprint.  After quite a bit of trial and error, I realized a couple mistakes I was making in the installation process.  Apparently, the package-lock.json file in the application’s main directory was having some effect on the success of its compilation, so I had to delete it.  The second mistake I made, was that I was doing all of the installation in Git Bash instead of WebStorm’s built-in terminal.  I had attempted installing the application’s dependencies using Git Bash for the first 4 or 5 attempts and got the same compilation error at the end of each attempt.  Finally, by using WebCharm’s built-in terminal to install the application’s dependencies, I was able to successfully compile the application and run it, thus completing all the tasks required of me on the sprint back-log.

My installation process summed up:
Clone application to PC
Delete the package-lock.json file
Open application in WebCharm
Using WebCharm’s terminal, follow directions to install dependencies and update software (found in README file)
Get Google Chrome extension for ability to log into the app (also mentioned in README file)

So, it was a fairly simple and straight-forward sprint, this time.  I think the main piece of knowledge that I took away was, kind of, how developers are able to contribute to open-source applications using GitHub and, overall, how a development team organizes to contribute to such a project of this size and magnitude.  I can now apply this knowledge if I am ever offered an opportunity to work on an open-source application that I am interested in, or if I ever want to form a development team that utilizes an Agile/DevOps style of development.

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