Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group.
Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want.
Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.”
I failed to make a successful working prototype that did everything I wanted. It seems that I have less knowledge of how all these work together than I thought. This brings to mind the apprenticeship pattern mentioned earlier, “breakable patterns” — I leaned through failing.
I will return to the Angular “Tour of Heroes” the next day or two to fill in the gaps in my knowledge. I don’t think there’s very much that I’m missing, but what I am is important to making it work. I would like to do this as soon as possible to be as much of a useful contributing member of the group as I can be.
Last retrospective, I was optimistic about how much we would be able to do this sprint. In truth, I am a little disappointed that we were not able to complete as much as I hoped. I am still optimistic about what we can accomplish coming up, but I have to bear in mind there are only two sprints left.
I am hopeful we will get a lot accomplished, but I have to be realistic that it might not be as much as I would like. This is the time where I should be thinking about buckling down and dedicating several more hours per week on top of what I already dedicate to this class.
I do have to keep in mind the learning curve we are experiencing when working on a team project like this. It took us a long time to just get the program to build and run on our computers. We didn’t hear what we wanted the final product would look like from AMPATH until relatively recently.
However, I think we are approaching the end of the end of that learning curve. Once our scrum team gets one component finished, I am confident the second will come a lot easier. It is reasonable to hope we are able to do a third, and maybe a fourth if we we split up into smaller scrum teams. Anything beyond that might not be wishful thinking, but I learned my lesson for setting my expectations too high.

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

Sprint Review Blog # 4

          Our fourth sprint laid the first real groundwork for the project design and coding. The AMPATH developers have given us more information as to how they want the simple app to look like. It should have a simplistic design within the flow and written code of the app to make sure it works properly. We created a new repository from a more updated version of the original files given to us. The original files were lacking in certain angular development modules so importing certain components and data became an issue quite quickly. The updated files now have those development modules which we have just cloned onto our computers and created a QForm component for the questionnaire form. We had to delete our previous branch known as questionnaire-form because it wasn’t up to date with the new files. We decided it would be easier to create a new branch from the new files and start over in this manner. We created the new QForm component and have laid the groundwork skeleton for how the design should look within our CSS and HTML files. The CSS is giving us issues however, because the form that we imported was vertical in format while the one that shows up when we ng serve is horizontal and slightly unformatted. We will continue to work on these issues to make sure they are ironed out and looking as proper as possible. We debug any issues we come across separately on our own and then bring it to the team if we can’t seem to figure it out. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic. I personally enjoy group debugging because it makes the learning experience much more enjoyable. I still think that the hardest part for the future will be to connect each component together and bind them into one final app with the other groups. We’ve already started collaborating with other teams on what information we all will be needing from a mock server. It will be necessary for the future so I think we should discuss how this server will be setup and which development tools will be used. We should also understand how data types will be formatted within this database so as to hold only meaningful information. It would be interesting to see how patient data types are handled at AMPATH but we’ll just have to make our own version based on guessing. I’m now more worried about connecting the CSS and HTML for the final application to make sure everything looks nice and simplistic since we had issues with our own CSS. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. The most important aspect of this design that we decided on seems to be simplicity with functionality. We want to incorporate that using the imported modules while also gaining knowledge on how they designed their app.

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

Individual Apprenticeship Patterns – Concrete Skills

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

This pattern works with the situation that an upcoming software engineer has some knowledge, but not much experience applying that to practical situations. This is also under the assumption that the learning engineer is seeking out work with a suitable team of coworkers, or applying to a new job.

Following this, the pattern advises becoming proficient at skills that every team needs. This typically means executing simple manual tasks, allowing the apprentice to contribute before moving to a more direct role in the group. It is important to get to the point where work can be done without supervision or help from the rest of the team, so they can focus their time on other work. This type of work includes “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.”

On the other side of the coin, hiring managers are taking a risk by hiring a student or apprentice since they might require more help early on. To help combat this, concrete skills are an immediate and significant answer. Being prepared before getting hired allows instant benefit and payoff to the group that decided to take that chance, proving the worth and capability of the applicant.

This also helps when constructing a resume beforehand. Highlighting the areas that offer those quick benefits will help make the resume stand out, resulting in a higher chance to be contacted. Following this point, it makes sense to do extra research on the position first in order to train for the concrete skills that will be necessary once hired.

Although I feel that this can be challenging, they are very good practices. It can be frustrating if things don’t turn out perfectly, and an application is denied, but especially in cases where a dream job is on the line, the extra effort is very worth it. Even if the applicant is not hired, they likely can use or relate the concrete skills they’ve learned in at a different company.

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

sweep the floor

Hello everyone and welcome back to another apprenticeship pattern blog post. Today blog post is “sweep the floor” which Is basically about what happens usually you’re a newcomer. The task will be simpler than you expect but as the more you learn the more skill you become and eventually you will start to have more complex tasks. I learned that when you are in a team and you don’t know your place on the team and the team is unsure of you, you should try to find some way to contribute so you can earn some trust from the new team. I agree with this completely because when I start with a new team I always try to contribute as much as possible, so I don’t feel like I’m not contributing. I learned from experience that it’s best to contribute early as possible because you don’t want to give a wrong impression even if you don’t mean it. The more you put in to the project the more people will respect you because if you don’t put in any effort, they will all think that you shouldn’t be on the team and you don’t know what you are doing. I learned that its’s really important to volunteer for any task even if the task is not unglamorous but necessary tasks. I agree that it show you can do any job and gives you a chance to display your work. I learned that I should tackle the grungiest task that everyone is putting off because it will show people that you know what you are doing and it’s a way to exceeds people’s expectations. Always try to make the task more creative so that it can be more fun to work on. All in all, I think this individual apprenticeship pattern sweep the floor is really important pattern to learn because it teaches you how to function when working within a new group. I took a lot from this pattern and agree with every information that it gives. I have implemented most these tips in my daily life and benefit from them.

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

Why doctors hates their computers?

Imagine you are a pilot, the world’s best pilot, and you are told “we are updating your control panel to make it more universal so that everyone can use it”. You show up to work one day and the entire control panel has now been reversed and is in Chinese. Chinese was never part of … Continue reading Why doctors hates their computers? →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 4 Retrospective

Over the course of this past sprint, our team has continued to make more progress in providing a functional side navigation bar for the AMPATH mobile application. In fact, at the very end of this sprint, we found that we now have a minimum viable product for this component! Every member of the team had a part to play in this development.

For this sprint, we divided each section of the side navigation bar component into parts, such that each of us would have a smaller contribution to complete. Each of the roles were as follows: creating skeleton code for the side navigation bar so that it could provide a template for adding styling and further functionality, fixing the toggle button for opening and closing the navigation bar, adding styling and design based on the uniform style for the rest of the app, determining the type of content that will be displayed and navigated to with this bar, and adjusting the scaling of the navigation bar depending on the type of device used to access the application.

Most of these tasks were able to be completed by the end of the sprint! One of the team members created a blank Angular project on GitLab and provided code for a functioning dropdown navigation menu, which was a great template for our next step to creating the navigation bar.

The next step was figuring out the styling and design for the application overall (which would reflect in the navigation bar). This ended up being Angular Material (powered by Google), which is an implementation of Google Material Design that is compatible with Angular applications. Because the wireframes that were provided from the AMPATH team utilized Google Material Design, it made sense to work with this sort of design. So, using the Angular Material Getting Started guide (found here), I followed the 5 steps to change the skeleton Angular project into an Angular Material project. This first involved using the following command to install required packages: npm install –save @angular/material @angular/cdk @angular/animations. Next, the BrowserAnimationsModule was imported into the Angular project such that animations that come with Angular Material would be supported. Then, the NgModules for each of the desired components of the project were also imported. A prebuilt theme was also added, so that all core and theme styles could be incorporated into the application. This required the following statement in the styling sheet: @import ~@angular/material/prebuilt-themes/indigo-pink.css;. Finally, in order to allow for gesture support in the application, the HammerJS library was installed using the following command: npm install –save hammerjs. With all of these steps in place, we had a project with Angular Material! One of my teammates found a useful video tutorial about Angular Material (found here), and this resulted in even further developments on our navigation bar, in terms of better aesthetic, as well as functional pages to navigate to, and a working toggle button!

This upcoming sprint will be devoted more towards adding more features to this working navigation bar, and these will all be discussed in more detail in the next sprint retrospective.

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.

Let’s Sprint, Into This Retrospective

Good day my fellow readers! Welcome back to another sprint retrospective. This is the fourth sprint in the AMPATH project. With things kicking off last week, we are into the thick of things working on the project.

With the new sprint, and a new goal in mind, the group decided to tackle the side navigation bar in pieces. As a group, we all sat down and discussed what are the components of a navigational side bar and, what components we should prioritize. As a group, we decided to prioritize the skeleton, button tasks, design, scaling, content, and web view. This, of course, lead to more learning about Angular. The sprint continued on with the group working off of a dummy app that one of the members had made. This is a concept where one makes a dummy or a toy of sorts. This dummy or toy serves no purpose to the project but, acts an environment to learn and mess around in. This way, one can learn in depth about say, for example, an Angular app, without impacting the real and important app in a negative way. You can make mistakes on the dummy or toy, and learn what not to do when working with the real thing. This was quite helpful to everyone on the team. Thanks to the dummy, by the end of the sprint, we had a working side navigation bar with working buttons. We had even worked out a nice design for the side navigation bar. While I was researching scaling, a fellow team member brought up that scaling might not be an issue that we need to tackle at the current moment. Taking time to look at his opinion I came around and began to agree with them. At the stage we were in development, we were developing for one kind of screen, our computer screen. However, we did not realize this until the end of the sprint. During the sprint review in class, we decided to look at the side navigation bar in the current state that we had it. Looking at the side navigation bar, the group started discussing on what devices the app would be used. Doing some quick changes to the side navigation bar, we quickly found that if we wanted to have the side navigation bar used on multiple varied devices, we would need to have the side navigation bar adapt to the screen size of the device. I will admit that after discussing how needless scaling was earlier in the sprint, now finding out made me a little embarrassed. For about half of the sprint I was doing a little less work than I should have been, thinking that my assignment was not useful and I would not need to learn this. This has left me with egg on my face and a bit of catch up work to do.

At the end of the sprint I have come out learning two important things. The first is that while it may not contribute to the project directly, making a dummy to learn about a component is a great learning method. The second is that even if something seems, useless in the current sprint, it is best to continue working on it, as it may be useful later on in the sprint.

That brings us to the end of another sprint review. 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.

Sprint 4 Retrospective

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

What I wish I could done throughout this sprint was to finding

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.

Sprint 4 Retrospective

Sprint four lasted from March 27th to April 8th. I was sick for the first class, but it wasnt hard to catch up on what the rest of the team was planning for the rest of the sprint. By the end of it, we’ve made a lot of progress, our group currently has a working prototype for our final presentation. After this sprint, or the next, we should be able to focus more on putting our presentation together since our project will likely be working and polished by then.

Recently we’ve brainstormed a list of improvement ideas to work on, polishing the project while we still have time. Some of the improvements include changing the header colors around, making the words bigger and easier to read, adding more buttons, and doing more with the title on the page. Many of these features are quick fixes, typically each one will take less than an hour. This sprint is likely going to change dynamically as we think of good ideas or quick changes.

We decided not to implement a login feature, or rather, it has a low priority and we will do it last if we have extra time on our hands. Additionally, the way we divide up work will be different than described in my last retrospective. Each button in the navbar is more of a placeholder, not exactly designed to perform a specific task other than change the text in the middle of the screen. Instead, each member will be given minor to moderate tasks to complete like the ones we planned out in our last class.

First we made sure to download the required angular material, our group member quoc took the liberty of creating a skeleton project and pushing it to gitlab. We all downloaded the skeleton, and have since made improvements on the style and layout of our navigation bar. Of the features we brainstormed, in class we quickly completed centering the text, which makes it much easier to read. Currently, we are also quickly working on changing the color values, which will also be completed soon.

My role in the group is to figure out how to have a nested button within one or multiple side bar buttons. The idea is that we could have a category named button that also works as a drop down bar, offering a few different buttons based on the category. My assignment seems not difficult, but also not as easy as changing color values, which is why some group members have multiple low effort tasks while I only have one moderate effort task.

Completing this by the end of the next sprint, along with everybody else’s contributions, results in a very usable product for our final presentation. To accomplish this, two tutorial videos were posted to the team backlog on github which each group member is assigned to complete as homework, though ideally the videos will help shorten the amount of time our contributions will take. I’ve linked both tutorial videos below:

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

Apprenticeship Patterns – Breakable Toys

This week on apprenticeship patterns, i read on breakable toys. From the readings i learned, experience is built upon failure as much as (if not more than ) success. From the readings, i got some importance of failure and the reasons why we should allow ourselves to fail. And also, at the same time what if you are working on a real job. And the real world job, you are not allowed to fail. But yet you will eventually will fail one way or the other. So in this case, you will need a special space to practice on your work. That will be playing with your toys. For examples, you are working on computer tools or you are on a real job working on how to fix computers. Since you will always want to put up with good production without no mistakes. I will be advisable to get computer devices either good or spoil device and be practicing on it. with much practice and also with a lot of failure, you will get all the tricks of fixing on the device. Also be very good at it. I also learned apart from all these, you must love your toys. That is to say, you should love what you do. In that case through your many failures, you just don’t give up easy. All because you love what you do. In the other way, if you do not love it. You will just give up on your toy(what you are working on).  With the pattern solution with the breakable toys, give us some ways on how to use our breakable toys in order for a team to grow or as individual growth.  from the readings, i got the understanding of the important lesson gained from failure is experience.What happens when we fail? When we go through something and can walk away with firsthand experience, it helps us to develop a deeper understanding for life. The experience of failing at something is truly invaluable. It completely changes our frame of mind through the induction of pain. It makes us reflect on the real nature of things and their importance in our lives, transforming and improving our future selves.

 

 

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