Another Sprint, Another Retrospective

Good day to you again, my fellow readers! Well, the time has marched on and I have once again found myself at the end of another sprint and you know what that means; time for another sprint retrospective.

This sprint has been a bit slower than the previous sprint was. With the trials and tribulations of relearning or learning angular (in the case of some of our group members) behind us, many members of the group were able to excel and start knocking items off the backlog. With each item off the backlog, my teammates were even able to add on extra features and improvements. Content for the left navigational bar was established and each was given an appropriate button. We then added submenu buttons, for items that belong under a certain category and not on their own. A home button was added to take the user back to the main screen, return from the left navigational bar and close it. Many aesthetic changes were made as well. Buttons were moved, spaced out more, colors were changed to make it more aesthetically appealing and less harsh on the eyes, the font size was increased for better readability, and the text that confirmed a button press was moved to be centered on the page. The latter was simply for testing purposes so that button presses could be confirmed that a button press would actually register and change to the appropriate page.

On the last day of the sprint, our manager/professor informed us that another team working on the search bar function for the AMPATH application wanted to push their work to the Github repository and we needed to push our work as well because we had made a base application in addition to making the left navigational bar.  As one could expect, there was a problem. The issue was that our group had made a repository and were not working off of the branch we had created. Now, this may not seem like a problem however, the repository we made was not on Github, but in Gitlab! Remembering the Git lessons I had just had earlier in the day, I suggested simply setting a remote upstream to the branch in the main Github repository from our Gitlab repository. We could then simply push from out Gitlab repository to the Github repository and all would be well. With approval from the professor, I made sure to pull all changes from my team members, set the remote and attempted the push. Error. Of course, things can’t be easy. The error was a permissions error that would not allow the push if I remember correctly. After conferring with the professor again, he determined that the best course forward would be to simply copy over the needed files and make changes where needed to other files and push those changes to the branch. Then request a merge with the master branch to make the changes available to the teams that needed them. This was not terribly fun as while some files could be copy-pasted in, there were many files that I had to manually edit and add in lines that we had added. Before attempting a push, I made sure that the application actually ran, which it did after installing npm. After pulling all changes and completing the manual edits, I attempted to push the changes. Error.  I was missing files from the master branch. I pulled from master and tried again; same error. I wasn’t sure what was going on as I had just pulled and there were no updates. I pulled again to receive a no changes message. This had stumped me. This left me with only one option, sleep on it. After waking up, I came back to the issue and had a random thought to pull from the branch, and it worked. When I went and attempted the push, I had one more error, but that was because I forgot to check the master for updates. One final pull from master and I had done it. I was able to successfully push to the branch. To end this saga, I made a pull request to merge our branch into the master branch. That saga was great practice with Git and solving its many errors.

That’s it, readers. Another sprint comes to a close. We have only about one or two more sprints left so the time we have left is quickly coming to a close.  Until next time readers!


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!

Stuff Is Happening!

Hello, again my dear fellow readers!

In this blog post, I will be reflecting on the events of these past two weeks or the third sprint and I have some good news to share will all of you; things are happening!

Over the past couple of sprints, or four weeks in real time, things were slow and consisted primarily of simple set up tasks, npm errors, and learning about testing frameworks. At last, we have received communications from our AMPATH representative and we have been given both direction and a task.

The new direction we are headed in is admittedly different than where we thought we would go but that is just fine by me. We will be working with the other AMPATH groups to collectively make a mobile app version of the AMPATH software. From our AMPATH representative, we received a group of 6 different videos. Each detailed a part of the app that he wanted to create and gave an overview of the idea for what they would look and operate like. It was decided that, due to a large number of groups working on the AMPATH project this semester, the work would be divided up into individual screen components. This resulted in our group picking the sidebar or the “burger bar” as the AMPATH representative so colorfully put it (I have honestly never heard that term before). The representative had helpfully set up a Zepplin board with mock-ups of each element that he had portrayed in the videos. However, no one was able to view them due to Zepplin policies. This issue was resolved however it did take a couple of days as the AMPATH representative had to invite each of us one by one. Once, we were in, each of us was able to get a good idea of what was wanted.

This has led our group onto the next step, to learn Angular for mobile development! Now Angular for web page design I have done. Although it was only one semester, it was still experience and thankfully it helped create a base I could jump off of when searching for mobile Angular tutorials. One of our group members found two excellent websites to help visualize and learn mobile Angular. The first was a very helpful demo website called Mobile Angular UI. It is a demo site that aims to demo every aspect of what mobile Angular can do such as scrolling, tabs, touch, swipe, and most importantly, sidebars. While this aspect is not immediately available, all it takes is resizing your browser to see it in action. The useful tutorials and information for how to actually implement sidebars came again from Mobile Angular UI.

From there, our group ended the sprint, discussing how the sidebar would work on each individual page and where it would have to pull the necessary info from to operate properly. Since we just started this part, it will regrettably have to go into my next sprint retrospective. For now, this sprint has left me with more knowledge on overall Angular programming as it is going mobile!

That’s all for now readers. See you at the end of the next sprint!




Another Sprint, Another Retrospective

Hello, again my dear readers! Another sprint has passed and as such, it is time for another sprint retrospective. These couple sprint weeks has left my group and me with a slightly lower than average workload. From the first two sprint weeks, not much has been added to the Trello sprint work board. The bulk of this sprint’s work was funneled into two major setup tasks.

The first of these major setup tasks was ensuring that each member of the team had the ng2-amrs software on our individual development environment. We also had to ensure that each person had it set up so that ng2-amrs could be built and run on each individual development environment. This proved to be a task that would throw more unexpected errors our way than I think any of us could have expected. Of the few in class meetings we did have, many were spent debugging and troubleshooting many of the varied npm errors that rose up to bother each and every one of us. My personal experience with installing ng2-amrs and getting it running was not the worst of all the ones in our group but it was not without its issues. I myself encountered three separate errors that stopped me in my tracks. However, thanks to the knowledge of my fellow peers both in and out of my group, they were solved. The rest of my fellow peers had similar troubles with the same bugs that I experienced and in addition, some new ones as well.

The second of the major setup tasks for ng2-amrs was for each team member to study and get familiar with Protractor and Karma. Protractor and Karma are both testing frameworks for Angular. Thankfully, there were easily accessible, available, and easily understood tutorials that were available right from the web sites of the two respective home pages of Karma and Protractor.

While not much happened these two sprint weeks, I can not say that it was spent lazing around or that it was quite unproductive or fruitless. Setting up the ng2-amrs was a good introduction back in to working with npm and was more than just learn the two basic commands of ng build and ng serve. In addition, I can now say that I am much more in tune when it comes to solving errors that might pop up when building an npm server. I have also learned what to search for on Google when a specific problem does crop up and wherein the error code to look to actually find the error that has actually occurred. Learning both Protractor and Karma was a nice change of pace as well. I remember learning how to test in my 443 class last semester and I remember that it was an interesting and enjoyable experience. Thus, this week two sprint retrospective comes to a close. Hopefully, in the next sprint, we will receive more messages from the project representative and be able to dive into something a little more relevant than just setup.

Until next time readers!


My First Sprint: A Retrospective

Good day my fellow readers. Today I will be writing a retrospective on my first Sprint. For this Sprint, we were tasked with mainly setup tasks from our Product Manager. The first task we as a group decided to conquer was the simple task of reviewing the README for the AMPATH software we would be editing. It appears that, from the last time our Product Manager worked with AMPATH, there was a contributing section that was removed in the current iteration. The next task tackled was to create a Github organization, fork the ng2-amrs software to the organization, and clone the software our machines. We then needed to ensure that npm, Insomnia, and a Typescript compatible IDE were all installed on our machines. I believe that we will need to install Gradle as well for some of the testing packages but, due to the pains that come with installing Gradle, as a group we decided that we can put off installing Gradle until it is determined that Gradle is actually needed. With all that situated, we then installed and played around in OpenMRS, a demo of an EMR, or electronic medical record system. The point of this was to gain a feel for an EMR first hand and it was neat to play around with one. The next task was to actually get ng2-amrs running on our units. This was the troublesome part of this sprint. During this part of the Sprint, I got sick and regrettably, did little towards getting it running on my unit at first. During that time, however, others in both my group and the other AMPATH groups did solve many of the issues that would crop up. This created a wealth of troubleshooting resources and made it much easier for everyone to get their ng2-amrs software working. At the end of the Sprint, our group did have a couple tasks left that we did not accomplish and had to push to our next Sprint. These tasks were to install both Karma and Protractor and learn more about both of them. They are both testing software that we will eventually be used for testing our changes to the AMPATH ng2-amrs software. We also pushed having everyone up and running with ng2-amrs due to some members, including myself still having issues getting it running. Thankfully, two members of our group have the software fully up and running.

This Sprint has forced me to dive back into some work from a previous class to remember how to work with npm and Insomnia. While I did not need Insomnia, in particular, this sprint, it was collateral learning. I also got a chance to learn about electronic medicals records as well and get a, “peek behind the curtain” as it were. We not only had to mess around with the OpenMRS software, but we also had to listen to an article called, “Why Doctors hate Their Computers”. This article, in summary, told the story of doctors struggling with their new EMR software and investigating the cause of this hatred. In the end, I came to the conclusion that the cause of the pain of doctors was that the EMR software was directed to the patient as the customer, rather than the doctors who actually use the software. This did put a thought into my mind that while working on the AMPATH software I should not only keep the doctors in mind but keep the patients in mind as well.

That is what happened, and what I learned on my first of many sprints to come. See you next time readers!

Doctors Don’t Like Their Computer’s Huh?

Good day again my fellow readers! Today, I have read (well more like listened but I digress) an article titled, “Why Doctors Hate Their Computers”, from the New Yorker. It tells the findings of a Massachusetts doctor and his experiences when his employing hospital sends him to, “16 hours of mandatory computer training,” to learn the new electronic medical record system, EPIC. This experience then kicks off a search for the reason why these systems make doctors hate them, and the effects it has on those doctors.

The hospital was switching from proprietary software to the EPIC software and as the author has used the system, it has worn him out. To make a long article short, EPIC had added many more steps, clicks, and time to processes that had in the past, gone much quicker. The author mentioned that in the first month of the EPIC rollout in the hospital the IT Helpdesk logged 27,000 tickets. Working in an IT department currently, I may have done a spit-take when I heard this. The author also mentioned that because of these new systems, for every hour of patient interaction there are two hours of paperwork that has to be entered in the system. There was also a Mayo Clinic study that discovered a link between the burnout of doctors and the amount of screentime that they are subjected to. Bad software is literally driving doctors out of their career. This really surprised me. All of us have come up against some bad software design before, but I would never guess that bad software would cause someone to quit their career. As the article went on, the writer revealed that the software creators of EPIC tailor the software to the hospital utilizing it. For his hospital, meetings were held where both doctors and administrators were invited. I immediately thought that the culprit here was the administrators. The folks higher up, or in a different department got their hands in the part and got their interests, prioritized over the doctor’s ones. Then later in the article, he talked to the chief clinical officer at Partner’s Healthcare, who turned the argument on its head. The software is not for the doctors or the administration. It’s for the patient as more patients look at their records and visit notes and want more understanding. This gave me pause as I myself take advantage of these features as a patient. Having access to all this information is very comforting. I had to mull this over for a bit but I came to the conclusion that the patient should be the main customer in this scenario. The whole point of a hospital is to serve the patient and with how care is extending beyond the hospital, the software is going to reflect this. For the Software Capstone, I will be working with AMPATH on their EMR for charity work in Africa. In that scenario, patient interaction will stay primarily in the hospital. In such a scenario I would say that the software should be directed towards the doctor. This reasoning is because the major usability that the patient will get out of it, is not an option for the patient due to their situation. We will definitely leave the option to shift the priority to the patient but, at the moment it appears that the doctors are the current priority in this situation.

This was definitely an interesting article and the next time I visit my doctor I do have an inclination to ask what EMR that they use and how they “like” it.

Until next time readers!

Bringing Back the Apprenticeship

Good day again my fellow reader! Today, I have read a chapter and some excerpts from the book, Apprenticeship Patterns. This book focuses on changing the mindset of the reader in regard to learning the art of programming. The traditional mindset of learning programming is more of a being talked at model. A teacher will talk at the students, and the students will repeat what the teacher says through classwork, homework, quizzes, and tests. This method of teaching does not lend itself well to programming where problems can crop up out of nowhere, and curveballs are always just around the corner. Apprenticeship Patterns puts forward the idea that for software craftsmanship, the apprenticeship model is a more fitting model to create well trained software craftsmen.

The apprenticeship model that Apprenticeship Patterns champions, is the classic model from the medieval era of apprentices, journeymen, and masters. The apprentice begins learning and doing small tasks and over time, will graduate to bigger and larger tasks and responsibilities. An apprentice, when he is ready will graduate into a Journeyman. A journeyman studies directly under the master. In addition, a journeyman is tasked to travel from master to master, expanding their knowledge in the craft and learning multiple styles from multiple different masters. This rounds out the path of a journeyman and eventually, they will attain the rank of a full fledged master. They will then continue the tradition and take on apprentices and journeymen just as their masters before them.

This cycle of apprentice to journeyman to master is a cycle that worked well in the medieval times but in today’s world, this model no longer fits anymore. I do agree with the statement that the apprentice’s apprenticeship was the sole responsibility of the apprentice alone and their success ultimately depended on them. This holds true today for the modern student but to a lesser extent as a student does not learn in the same method as the traditional apprentice. For the traditional apprenticeship to be revived in today’s modern times, there would be a drastic change in today’s society and in how the educational institutions operate. I am not sure how a modern apprenticeship for software craftsmanship would look like, but I believe that it would definitely produce a high level of software craftsmen.

The other chapter introductions discussed patterns that a software apprentice would go through in their educational journey. The first few patterns form a solid base for the apprentice to learn and grow in their journey. The next couple chapters have patterns that continue to grow the apprentice and nurture them into the position of a journeyman. These patterns take the journeyman outside of their comfort zone and allow them to grow through agitation of what they are comfortable with. The final patterns take the journeyman into a master by having one constantly learn and creating a feedback loop to keep one learning. These patterns look very interesting and I do hope that I will be able to apply some of them to my learning journey as well.

Let us see where these patterns lead us and see you next time!