It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint.

My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close.

I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort.

I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few venues of communication, using the most appropriate for what we need. Most days, we have been back and forth in a group chat. Whenever we find resources, we add it to a Google Drive document.

The days of our classes have been incredibly productive for the most part. I am surprised what we can get done in a little over an hour. When I play around with parts of it on my own, I find I hit walls more easily. It is great to have the shared pool of resources to help each other out.

We have largely been working from the official Angular guide to how to work with tab components. We found this very early on, but it has been our primary guide to everything we have done so far. The great thing about is that we have a few different ideas of what we want the final product to look like, and there are examples with all the code we need to do what we pick.

I think the most important thing we do when we plan this last sprint is to finalize what we want the end product to look like. There is an idea of having a button to add a new tab, but we don’t have a clear idea what the content of that tab will be if we decide to go that route. It is key to plan it out fully before diving in so we don’t waste any of the little time we have left.

A part of me wishes we could have two more sprints after this, because once we finish this component, I would like to continue to try to create another after this. Perhaps, in a way I can. Even if I do not continue working for this project in particular, I can use all the skillsets that I have picked up to continue to work on project just like this independently.

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

This sprint posed a few challenges which I am not confident we will be able to solve by the end of the semester. While I am and I am willing to bet my team members would agree with me that we all have made good progress through the semester, however two major snags hit our project that will be difficult to solve given the time we had left.

At the beginning of the sprint, we were collaborating with the team who was working on the server, and they hit a significant issue when we found out that they weren’t able to make calls to the main server. For some reason, when they tried to access the server URL’s, they weren’t getting any data back from the server, but just a never ending stream of URL text return values. Without an ability to connect to their server, we won’t be able to integrate our component with the rest of the class.

While this snag would not directly impede our group in the progress of developing our component, we also hit another wall which I don’t have the faintest idea about the cause. When myself and my other teammates have our project forked onto our computers, and we run the application, we see exactly the component the way that we made it. However, when we tried to have a different team clone our component and run it, the output they saw was completely different. At the moment, I am not sure if that is an issue with dependencies on our end, or if the other team had a problem with forking our repository. This hindrance is by far the more significant problem because it affects the integrity of our component.

By the end of the sprint, our team decided that the best course of action was to improve as best as we can the usability errors, and to create a minimum viable product which we can use for our presentation. Given the multiple unexpected set backs, I will be happy creating a prototype component that is clear enough to understand so that we can pass it off to future students working on our component who will be able to focus solely on the integration with other teams’ components.

Although this sprint was definitely an exercise in patience and a refresher course in Murphy’s law, we definitely are continuing our march of progress regardless. As far as our component goes, we only have to throw on a few more bells and whistles to have a product which I can say for myself and with some degree of confidence for the rest of my team that we are happy with. I definitely expect set backs like this to be a common part of the job description. After all, nothing happens in a vacuum, and for every perfect plan there is a perfect failure.

At this point we are preparing for our final sprint, and getting ready for our final presentation. I’m sure that during our next sprint planning meeting tomorrow we will be beginning the process of wrapping up.

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

            Our fifth sprint really allowed us to sink our teeth into the project and build our first component. We continued to have bugs and issues with git and node modules that we had debugged earlier in our third and fourth sprint. These bugs have come and gone randomly among our team members which made working in synchronization much harder because not everyone had a stable version running at all times. We debugged the issue through various methods using multiple pulls from other branches in git to solve the issue. The first error started with the CSS formatting that had been troubling us for a long time. We had originally solved the issue, but it came back once again when we pulled a fresh copy of the project from our branch repository. We decided to pull another version of the project from another groups branch and debug their files to see if the problem was with our local machines. It seems that the issue was with our file structure for our git branch because the other groups branch was running just fine. We decided to look further into the file structure of our project and reorganize the node modules to see if we could solve the issue. After further reinstallation of the node modules through the npm install command, we were able to get an interface up again. The CSS now works fine with the HTML and other application files. The integration of the Q-Form component with the app files within the code is our next real goal. We want to easily connect the component to the app files so that we can finally see if the function is up to our visual standards. We also have to decide if we want to select subgroups to finish this component while another set of people begin working on the next component. We will have to discuss this as a group during our next sprint, but I believe we are on the right track for this development cycle. We have solved many issues and are almost done making our first component. There has been talk about communication with an integration team that will be handling the total integration of various components into a demo file for the application. It could be possible that we have to mock some information as well for data instead of a server. It would be easier for time constraints to make random data rather than set up a server so that is definitely an option. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic as well. I personally enjoy group debugging because it makes the learning experience much more enjoyable. This sprint really taught me to understand other people’s point of view when debugging. I learned to be patient and try to understand another mindset even if it takes me longer than necessary. This proved to be vital when communicating with team members and allows a feeling of inclusion as well as mutual understanding.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

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.

Once again, this week marks the end of another sprint, with even more progress taking place for our team’s component of the AMPATH mobile app, the left navigation bar. As I described during the previous sprint retrospective, our team was able to complete a minimum viable product (MVP), meaning that any consumers utilizing this app would have a minimally functioning navigation bar! This sprint was focused mostly on adding and polishing new features that could make this navigation bar better.

During our preparation for the upcoming sprint, we came up with a list of additions that would benefit our navigation bar component, not only in terms of aesthetic but also in terms of functionality. For styling changes, we decided that we wanted to make edits which promoted easier readability. Other changes that we wanted to make included adding a home button on the navigation bar so that users could redirect back to the main home page, creating a dropdown menu for some of our buttons in case a sub-menu was required, and fixing the navigation bar such that once a button was clicked, the menu would collapse, rather than staying open when switching to a new page.

My overarching task for this sprint was to focus on the styling changes that we wished to make to the navigation bar. This included making the text size for the navigation buttons larger, increasing the spacing between each button to make navigation between each tab easier, center-aligning the button text (rather than left-justified text) because our whole team preferred the center alignment, and changing the color of the whole app to a darker mode so that it makes it even easier for users to look at the app. Adjusting the font size of the button text required a quick edit in the CSS file, app.component.css, where the font-size attribute related to the container with our navigation bar buttons was increased. I used the following site to make this change. Likewise, switching the alignment of the button text was specified in this CSS file, in the same section which described the formatting of the same aforementioned container. I used the following site to verify which attribute to change and how to modify it properly.

In order to increase the spacing between the buttons, I simply added 2 line breaks between each button, modified in the HTML code for the app (saved in the app.component.html file provided by the Angular framework). Finally, to change the color scheme of the app, I used the following site in the Angular Material documentation to learn more about the different themes that are pre-built into Angular Material, as well as how to go about creating my own custom theme. I initially considered creating a custom theme, but I wanted to check out each of the pre-built themes beforehand in case I liked any of those instead. As part of the Angular Material Themes, each theme has a primary palette (which are colors most often used on the app), an accent palette (for interactive elements on the app or any floating screens or dialogs), and a warning palette (for any error messages or notifications). I did a trial and error of each of these 3 palettes, for each pre-built theme provided by Angular Material, listed on the Angular Material site, and I found that I, and the rest of the team, preferred the accent palette of the pink-bluegrey.css theme, which resulted in a “dark mode” of the app. In order to incorporate this theme into our app, I navigated to our global stylesheet, styles.css in the top level of our src folder, and added the following line: “@import ‘@angular/material/prebuilt-themes/pink-bluegrey.css’;” Then, in our HTML code, whenever a color attribute in our button tag came up, I specified that the accent palette would be used, which looked like: “color = accent”.

This was a very productive sprint, and I’m very glad that our team has the flexibility to add more features without having to be concerned about the basic functionality of the navigation bar being affected. For our final sprint, we are going to be focused on finishing most, if not all, of the rest of our additional features. We will also be wrapping everything up for the semester (holy moly it’s the end of the semester already?). Stay tuned for my last sprint retrospective, and thanks for reading!

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.