Sprint-5

There was a lot that was done in this sprint. After we had moved the code that Dan had been working on, onto the Tabs branch we decided to add more code. For our project the main component of course is the tabs component. This tabs component consist of a certain number of pages for a certain form that patient may need to fill out. For example, if a form is about four pages, then that form may need 4 tabs. While in class we as a group first made sure that the new updated code with the simple tab component was on all of our computers. Since Dan had pushed it up, Ryan, Sam and I all had to pull it. Since we all had different amounts of code that was not usable, we decided to start all over again.
The first command we had to do was a git clone https://github.com/cs-worcester-cs-448-sp-2019/amrs-simple-app.git
After that we had to get into the project. So then we did a cd amrs-simple-app and a
cd ampath-simple-app. After we got into the application, we had to do a git checkout Tabs to get into the Tabs branch. After we got into the branch we did a git pull origin Tabs. Since we were starting again, some of us needed to update some of the dependencies we were using. To help fix this on my end I did a ng update –all. After we finally got it running on all of our computers, we decided to start working on the forms component.
Towards the end of that class, we were able to implement a simple forms field with just three fields into our application. We were able to do this with this link: https://material.angular.io/components/form-field/overview. After we were able to get that working we decided to push up our changes again on my computer. To do this I first did a git checkout master to get into the master branch. From there I did a git pull origin master to grab anything that had been added in the master branch. After that I did a git checkout Tabs to get back into the Tabs branch. From there I did a git add . –This added everything that we had added to our code. After I did a git commit -m “Added forms” and committed the changes. From there I did a git push origin Tabs and pushed up our changes into the Tabs branch.
After getting both a simple tabs and form field working we decided to start adding extra things that would better our application.The first component we thought we would add was an add and delete tabs button so the AMPATH developers could add as many tabs as they wanted for each card. This took us a little longer than we expected but Dan was also able to get this working on his end. While we may have gotten in working we did and are facing some issues now. After I had pushed up the changes for the new Form field component, Dan did not pull those changes that were made and immediately started working on the new component. This in hand has messed up where the git is and how up to date it really is. What my team and I are working on now is to just get that working again and for all of us to be on the same page. We are taking the steps to get it on a new clean branch so we can get everything working properly.

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

AMPATH-WSU Sprint 1 Retrospective

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.

Who Doesn’t Hate Their Computer?!

Hi dear readers. Welcome to my next blog post. In this blog post I am going to write about an article that I read with title “Why Doctors Hate Their Computers” written by Atul Gawande.

Gawande starts the article writing about this new system that the hospital he was working was upgrading to. The new system’s name was Epic. Epic is a leading provider company of software for healthcare industry. Gawande shortly explains all the process of training and using this new software, as well as the consequences that it brought with it.

I found the article pretty interesting as it is always good to know, especially as a developer on where do the other industries stand with technology and how are they liking it. I am personally in a Fleet/GPS industry and an internal developer. In my opinion doesn’t really matter which industry you love or hate, technology lies in the same path (most of the time).

Just like Gawande, also a lot other healthcare doctors/employees were not happy enough or at all with the new system upgrade. It is unfortunate how in some things this system had a bad effect when it was supposed to improve all the process. But while reading the story I find so many truths in this article that even I, a software developer can relate to my place of work. To be honest I would say you are ling if you come up to me and say that the system your work/school is using is amazing and you got no issues with it. It is not that the technology is not perfect but it’s people behind those written lines of code. People well trained or not, people with good knowledge or not, people with good skills or not. Having these people combined leads to problems with software.

I would like to point out one part of the article when Gawande’s collage Dr. Sadoughi was explaining how she felt about the new software and how slow it made her work. In a moment she mentions how she logging was very bad as all other doctors could access the documents of a patients, which in my opinion is amazing as, myself as a patient have to explain to each doctor over and over again on what my current health condition is. As far as the other doctors not putting the exact notes for patients, I would say that is a professional matter. At this point the doctor is not playing by the rules but slacking by just using enough words for the billing system to care but not to help in the overall functionality process of this software. In the same time this doctor is hurting the patient as well as the other doctor has no clue of the real health problem the patient has. Let’s be fair at this point!

I have experienced a lot of issues with systems at work too. Once my boss said: “Think how good a software is, if even a developer is confused”. Its true that systems have problems and maybe this particular system had more issues but technology is the future and it has improved our lifestyle in so many ways and we can’t deny that. When creating a system the PMs should always consider the most important factors but also work with a group of users from different departments who represent the interest of them all .

I strongly believe that systems and technology can be improved even more if the correct specifications are set and met, but just like other things in this world, nothing is perfect. Technology doesn’t make an exception.

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

Unleash Your Enthusiasm

Hello dear readers. Welcome back to my next blog post. This time will be talking about enthusiasm in your new/current work place.

This chapter of the book  talks about how to feel and what to do about your enthusiasm at your work place, being that a new or current environment. I believe these advises would mostly apply to a new work environment as in an old environment you already know your coworkers and your boss. The author gives credits to people with enthusiasm and strongly supports them to unleash and keep the spirit up.

Getting into a new work environment it is indeed a bit hard, especially when that is your first job. When it comes to choosing a job, unfortunately you can’t really know what kind of team and people you are going to work on unless you have been recommended for that job. So being nervous is FINE. And I was crazy nervous in my interview and first week of my job.

I have heard a lot of stories about teams with employees who don’t accept suggestions or new ideas and especially when those are coming from a new employee and a recent graduated student. If you were to read their face, it would say only one thing: YOU DON’T KNOW. At that point it is time to move up and get to your manager and if you are still not heard I truly think is time to move on. But always keep your spirit and enthusiasm up because just because those people don’t accept new ideas doesn’t mean you are wrong.

Never hold back on ideas and always express them. A good team will listen to your idea and will take it in consideration and will explain why that might or not be a good idea. Nobody was experienced on their first jobs! Its true that these new team you are in might know more than you but you might know something they don’t and that’s a plus to the team productivity.

Keep in mind that nobody knows everything. Try to find the person who you think would listen and welcome your ideas. Also accept critics, its very important for your development.

 

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

Sprint Retrospective – 5

On sprint 5, our team was still working on the search bar project. I was having a little problem figuring things out. But come to understand how and what i should have done. First there were a lot of error while compiling. The errors were not there before but when i tried run the app, it did not work. It took me some days to figure out what the problem was. Not knowing one of the file was missing (main.ts). So when i realized that i probably thought i might have touched some of the files or anything. So i rather clone another one. Started that whole process from scratch.

Another day as we meet as usually, one of out team member was finding little difficulty merging or pushing his project to github. So he talked about it to the professor also as the manager of the team. Our manager was to help him or let me say us through the merging or pushing our project to github. I guess we were the first team in the class working on the “amrs-simple-app” to push our project to the github. So as things were going through. i decided to pull the things or any update made in our project from github. I tried several times but to no avail. I asked a member of the team and he notice was not added to the github or did not receive the invite. Knowing that, i decided to clone again and see if what he said was true. With time going by, i decided to it the next meeting. We tried fixing it, and we found out that our manager did invite me but i did not accept the invite all along. We finally fixed it and i was able to get things to work.

On another day doing out spring, we decided to changed the project because the search bar was too simple and we need something very challenging.   And also we found out that if we will have to emerge out search bar project to others, we needed them to push their project to the github. But seems things were going slow. So we asked the manager if we can integrate all other team members and also add our search bar to it. So we kind of being the team that joins other part of an application together making it a whole.

While on the change of project, we are still waiting for all the team members to finish their project, push it to the github and from there will be doing the putting together parts. As we wait, i am seeking help on how we will be doing the integration and how we will be testing of all the code.  I have been doing a lot of research on our change of project. We are also dividing an additional task on who will be doing this or that part of the project. For now i will say we are getting closer to the end. Kind of wrapping everything up and also preparing for our presentation.

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

Sprint Retrospective 5

From the last sprint, our team was entering this new sprint with a lot of questions as to whether or not we could complete the server. After a lot of team discussion as to what we think is best, we ultimately decided to drop the server (for now) and start working on an actual component. We were all really frustrated that we had come to that standstill with this server and it seemed as though no light would come of day. But with the internal discussion we had and rethinking processes, we decided that it would be best to just start for production on the bottom navigation bar component. To start, we talked to other teams as they were essentially done with creating an intractable framework for their components. After talking with them for a bit, we understood that a lot of the work was actually already handled by the angular material design. A lot of the components that were needed were built into the API and could easily be implemented…except for ours. Figures right? However, it wasn’t all doom and gloom. When scouring through the angular material design api, we saw components for forms, side navigation bars, tabs, and much more. However, what we didn’t see any documentation for was for a bottom navigation bar. A static module that was always overlayed on top of almost every other component and was responsible for switching to different pages or fields when needed. Fortunately for us, we found was was called “Ignute UI”. This was a lifesaver and a time saver. Like the base angular material, it had all the other components such as forms, tabs, etc. But it also included the bottom navigation bar and much, much more!

Our team was relieved and immediately started implementation of this within the component. The API was very clear and had java-doc like documentation with greatly explained what was included in each package and component. This was exactly what we were looking for. We finally got the navigation bar implemented and working successfully! This was a great step ahead and major improvement after the essential devastation that was our last few sprints. Our team came together and persevered to find something that worked, and this Ignite UI could potentially be even more useful than the base material design to consider using in the future. But for now our focus was to test this component and start to match the CSS as it looks on the Zeppelin layout.  It’s feels great to finally be able to move past a barrier that we have been stuck at for so long now and to finally see something that we can actually interact with. A component that we had initially thought to do but put it to the side. It seemed like we had to restart several times but finally we have something that we can show and something that can finally start being merge with other groups in hopes to create one large working component to finally interact and share data through.

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

Sprint RetroSpective 5

This sprint was much more productive since last in my opinion. First throughout the sprint we kept running into simple errors. One error I had several times was my angular not being recognized for some reason but then a clean reinstallation fixed this. This happened to Harry just a few days ago which has been resolved. After the angular problems we had some connection issues to see the component on the local host site. James was the first one to run into this while me and Gulshan where on the other component branch fine. We were using another groups component “Tabs” for reference to see if our repositories were set. After a day or two issues were resolved. Just yesterday we ran into yet more problems on this issue, this time on our own Q-Form branch component. Firstly, Harry couldn’t see the Q-From branch or rather the deletion of the Questionnaire Form branch to the new formed Q-Form branch. Then James was having an error that I don’t even know what he did wrong. After that was resolved we finally got our component branch working. Now all we have to do is just add our stuff in and structure it how we want and we should be good. After this component we should have time to do more components if we do not run into similar errors.

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

Sprint 5 Retrospective

Since the last sprint retrospective blog post, our team has struggled to get the component we have been working on to show up correctly. It has been determined that the formatting code will not be applied to the component if it is just opened by itself in a browser. It is necessary for the amrs server to be running first, and then the component will show up at localhost:4200. We made progress once another group had us make a copy of their component and try to get theirs working for us, since they already had it working for them. I ran the commands cd amrs-simple-app, cd ampath-simple-app, git, checkout Tabs, git pull origin Tabs to make a copy of their component. Then I tried ng serve, and that errored, so I googled the error and found the solution and entered the command npm install –save-dev @angular-devkit/build-angular, npm audit fix, ng serve –prod, and then it worked. I waited for it to say “Compiled successfully” and opened localhost:4200 and the component showed up, correctly formatted.

Since that is out of the way now, we should be able to actually finish the one component we have been trying to get working for the last month. We should probably be able to do a second component, too, since the thing that has been holding us back the whole time has been solved. Now we can go back to our component, apply the solution that worked to display the other team’s component, and finish getting it to work and move on with the project.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective (Capstone)

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.

Sprint 5 Retrospective

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.