Sprint Retrospective #1

I learned a lot from this first sprint. A lot of issues were being run into and as a team we were able to overcome these obstacles to all continue. Something that I learned that collaboration can often lead to success because you may learn something about a topic that you may not know. Next I will explain some of the tasks our group has completed. First, we had to make sure all of us had a sprint backlog. These included tasks for our sprint timeframe that we should be able to complete. We setup a group environment on GitHub to clone our ng2-amrs repositories so we could get oiur AMPATH portal up and running. This is where we, and many others, ran into most of our problems. A lot of us had many different errors so it was very confusing trying to find fixes for all of us at first. We coordinated with other groups via slack channels in order to first find out who was having what errors. After posting about the errors and discussing them in the slack channels and amongst each other at our meetings, we started to research for solutions.

For example, one of my teammates was getting an error upon trying to run the “ng serve” command in order to get the virtual server running to launch the AMPATH login portal. This error was stating that there was an incompatibility with Windows 64 bit operating systems and would keep failing at compilation. In order to solve this, we needed to research the issue and eventually found a fix online that worked for the majority of people having issues with this. One specific issue that also seemed to affect people trying to run the “ng serve” or “ng build” commands was that it was throwing that certain dependencies were missing. After trying multiple things, we eventually found out ourselves that this was indeed and issue with the installation of node.js. In one of our previous software developement classes, we had already installed node.js. However, there was one major issue that kept us from compiling the project succesfully. This issue was that the first time we had installed node.js, we did not specify it to install all of the dependencies, therefore “ng serve” was not able to run because it would fail at compilation due to these missing dependencies. The fix we found for this was to completely uninstall node.js and reinstall it, but this time also installing all the dependencies (python, net framework, etc.) This fix corrected the issues for us and we were finally able to run the command and go to the local host AMPATH portal. Next there seemed to be an issue where compilation would hang at around 92% and fail. The fix for this was to run two different commands that we had found on stackoverflow for someone who was having this same issue: https://stackoverflow.com/questions/50621043/fatal-error-call-and-retry-last-allocation-failed-javascript-heap-out-of-memo

The fix fix for this was to run two commands in the node modules folder that fixed the package.json file. After this, we ran “npm run build-prod” and then this fixed the issue.

Advertisement

Expose Your Ignorance

Often times we feel as if we may know how to do something, when in reality we may not know. Some problems that arise can may seem familiar but often times need more digging to figure out the answer or solution to. The Expose your ignorance pattern explains this by growing yourself in order to find a solution. The pattern states that we are not going to know every little detail about every software or domain we need to use in our jobs. There are people depending on us to perform a task, but the issue is what exactly do we do when we can’t overcome these obstacles? Even if you don’t know what you are doing or aren’t aware of a certain situation, it is always better to atleast look like or be willing to be competent in whatever the task at hand is. One great point that I think this pattern brought up was conceding your pressure and just telling your clients or colleagues that everything is okay, even when it is not. If you just tell people that thing are okay even though they aren’t this can lead to a massive snowball effect.

For example, maybe you don’t understand how to use the companies’ software that you are working for yet and there is some things you either want clarified or need more time on. If you were to just say that you understand everything, what does this precedent set? It tells people that you are okay to move on to the next thing and most often than not, whatever that “next thing” is, it most likely builds upon the previous task or requirement you should understand. Sometimes it is just better to be honest and let your team understand that  although you may not currently understand what is happening now, you will be able to learn it. As long as you show you are able to learn the materials and keep up even when you are behind, you will always be valuable. Ask questions because not only will it help you, but it can often times help whoever is answering the question with something they may not have known about either.

 

Why Doctors Hate Their Computers Response

A lot of the times in the office, people can get easily frustrated with their tech. This article talks about how there seems to be some sort of disconnect between the technologies and the doctors. To start off, when a software is developed for a certain field, there are certain expectations and requirements that should be met depending on what the service is for. if you are delivering a software for a food business, you should expect it to handle some sort of client interaction along with employee interaction. This also can translate to mass scales where more and more people are using it. When a lot of people are using the same software, there should be a type of initiative to make it simple yet effective to use. If the software that is being developed for a specific purpose isn’t developed correctly or with those things in mind, it can sometimes be detrimental to that business’s practices. In this case, it was a matter of updating a lot of records and technology to keep the systems “relevant”.

In the case of a hospital system, the records are computerized and the new system that was being put in place would be able to handle a lot more. This is the reason why the upgrade was good. The new system would be able to deliver a single platform for recording and communicating medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, and sending insurance bills. However, with these new systems seem to come a lot of overhead for the people using it. There were quite a few tensions that actually made it more difficult for doctors to get their jobs done. One of these tensions was between the doctors and administrative staff. Often times they disagree on what should and should not be included in the software. Sometimes the staff said adding certain procedures would be more time consuming. Certain fields that doctors didn’t have to fill out before were now being required due to administration simply telling them that they had to be done.

I feel as though the real customer in this situation seems to be the administration. Whenever a new system is implanted, hospitals often have to schedule less appointments just to accommodate for training of the new system. This puts, not only the patients, but doctors and other faculty way behind. From the article, it states that in the first five weeks of a new 1.6 billion dollar system upgrade, there were about twenty-seven thousand help desk tickets were just simple how to questions about the system. The lessons from this implementation don’t only apply to the Electronic Medical Records systems, but other systems dealing with these same mass software upgrades for facilities similar to hospitals. This reading has changed the way I think about the topic because although upgrading something to make it current, doesn’t always necessarily mean it won’t add additional overhead. I agree with the fact that upgrading systems can be important, especially when dealing with thousands of medical records because you want to keep things secure. But at the same time it is important to understand that there should be more efficient ways of training with these software to make them more accessible and understandable for the people using them.

PayPal’s Interesting Design Pattern API

PayPal is a massive online American banking and currency handler that allows users to transfer funds electronically. PayPal originally started out as a company that developed security software for handheld devices. This article describes the different design guidelines through the years of developing the API. All of PayPal’s platform services have been connected through RESTful APIs. REstful is an API that uses HTTP requests to GET, PUT, POST, and DELETE data. It is commonly known as the architecture style for designing networked applications. We have learned that, through design patterns, we can optimize and organize our code in efficient ways to make later implementations of other objects easier. I chose this article because it is another look at practical implantation of design principles for large businesses.

From the article, we can see that the basic principles for PayPal’s design foundation are very similar in what we are currently implementing in our code. Some of the principles include that are discussed in the article are Coupling, encapsulation, stability, reusable, contract-based, consistency ease of use, and externalizable. Since these APIs are developed with consumer business in mind, each of the principles follow a catered idea for each. For loose coupling, the services need to be loosely coupled from each other. This makes it so that components in a network can work together, but do not heavily rely on each other. Encapsulation is also important in order to group certain attributes together. This makes it so that we can restrict direct access to certain part of an objects components. The stability principle important in that we need to make the program stable. The code should also be reusable so that it can be used across multiple different instances and by different consumers and users. This is important for team collaboration and organization as well because if multiple people can understand where an issue is occurring, it can be solved a lot faster. For contract-based functionality, it needs to be shared using a standardized service. This makes it better to create a standardization because it loops back to the reusable principle and makes accessibility more seamless. As for ease of use and consistency, these both work hand in hand because since the service needs to follow a specific set of rules and attributes, it also needs to be easy to create for consumers. The last design principle is externizable, which requires that the service can save and restore the contents of its instances.

I learned that these design principles are interesting because they seem to be a great tool to use when designing a program because it offers fundamental guidelines for optimization. I expect to apply these principles in my future practice by remembering the importance of how code should be organized to make it accessible to the consumer and to the programmer.

Source: https://www.infoq.com/news/2017/09/paypal-api-guide