For this sprint, my team and I continued our work on trying to mock the server aspect of the project so as to give other teams a way to test their code. We had followed the tutorials on nock to make sure we understood the way that it worked and how we would have to translate it over. However when we went to the AMRS code to try to find something to try to mock we ran into some problems. Going through the code, there is a lot of moving parts to each element with the program which made mocking just one thing look like it may not be possible. Not only that but almost everything we found looking through the code, returned html responses from the ng-AMRS server they have set up already. For example one of the main things we looking into mocking was the patient-creation-resource part of the simple App, since it seemed to be one of the smaller files and less requirements/calls to other classes. In trying to mock one of the methods from this, this is where we started to feel that this may be a little too high of a task for us without the AMRS server itself. I feel as though if we had access to their already made server and could have just mocked the tests at that point we would have had much better success. There were just too many moving parts to each thing for our current way that we planned on mocking to be realistic. During this sprint though, I feel we were able to work more on the project and were actually making headway till we hit the wall on what we could actually wind up mocking. At the end of this sprint we also started talking about the possibility that we might not be able to achieve what we set out to do originally, so we also started looking at the bottom navigation bar element that still needed to be completed. We chose this as our backup and I had started to get some of the smaller stuff out of the way for that. I have gotten together all of the CSS and HTML components for the bottom navigation bar with what was provided from Greg Schmidt on the Zeplin app. Since this seems to be the direction we will be heading in the next sprint I felt it was smart to try to get ahead on some of the smaller/easier stuff. What I will need to be looking into and finding out how it works is the button elements that Greg Schmidt wants and how I can recreate them.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

In this week’s sprint, we reviewed videos provided by Greg Schmidt, detailing what he wants from us to complete. From these we were able to see the possible directions, we as the team, could take to completing some of these story tasks. Our team, team Tapmah, was split between designing the bottom navigation bar or working on mocking the server for the project. Ultimately, we decided that we should focus on mocking a server that all groups could and would need to use to test that there aspects of the program are working. One utility that Andrew found that we have started to explore the use of is Nock, a mocking tool that is used for test modules which rely on http requests. When Andrew found that, I started looking into how this mocking works, finding several videos on Youtube which helped. It was through these videos that I found out about a feature of “mocha” called hooks, which is something that I had not seen previously. These hooks allow you to define code that will be run before or after each test suite, which is how we will be able to mock these servers. Learning about this mocking will definitely help me in the future with project, now having this knowledge. Knowing about this now and looking back at previous projects done with API’s I feel this knowledge would have helped me in testing some of the features I had tried. Also during the week I had looked at the video’s by Greg Schmidt about possible items the team may need to “mock” when other teams start requiring tests for their contributions. Some examples of things that will need to be mocked by the team will be the navigation points for the bottom bar, patient list, separate form selection, and multiple tabs. Each of these items will need to have a mock test to know that they are working as intended, without requiring an actual server to be getting replies from. Another bit of information that I found while doing all this research, as coding work has not really begun much yet, is that something like does have its downfalls with things like if the http response is complex.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

During this sprint there was not much for me and my team to get done other then getting the program to be able to work on all of our computers. I feel as part of this sprint was also combined with the first sprint, hence why we still trying to get the program to still work. At first there were several issues for all of us, with all of us getting a massive amount of errors when we first tried to “build” the program. It was during this sprint though that I was able to educate myself further on things that I had started to learn last semester with Angular design and testing of code. One of these errors that this program presented when we were first trying to get it to start was a problem of “circular dependency” which was one problem my program was having building. After looking for sources on this and learning about it I found it was essentially because in the files of the program, multiple files are depending on each other but had not been imported/exported properly(source). Another problem that my team and I had thought could be the problem for some people’s program not building was their version of NPM, or rather the dependencies they had installed with their current version. While everyone else in my group was on nearly the most recent version of NPM, I was still running on version 6.4.1. Yet I did not have issues with NPM because I believe I had installed the correct one with correct dependencies in the previous semester for CS-343. I had issues that my team couldnt help with because we were not experiencing any of those issues from a mac. I feel that this being the first time I had worked in a “scrum” type environment was interesting, having only just learned it in CS-348. Despite all being individually working on getting the program working, as a class we all worked together to try and solve each others problems. When one person would find a possible fix to an issue they would share it, and then through the collective effort someone would find a fix. Going into the next sprint though, something I will be looking for more is a better understanding of the goal of the sprint. This past sprint felt very scattered still with some people not being able to get their program working still at the end of the sprint.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

My blog post this week will be on the chapter “Rubbing Elbows” of Apprenticeship Patterns, in which the reader is encouraged to seek out working with another fellow software developer. The basic thought behind this is that if you develop software alone you can reach points where your learning can stagnate, and cooperative work can get you to learn things in new ways. One very important point that the author made was the aspect of “micro-techniques” (small ways one developer has found to handle certain problems or situations) and how important learning them from other developers can be. This is important to me, and should be to others, because I feel I had to figure out how important those “micro-techniques” are first hand. When I first started working with software I was very independent, not wanting other people’s help. But, the longer that I have worked with software, and just worked in general, I have found out how important it is to see problems and fixes for them from other people’s perspectives. Towards the end of this pattern, the author again points out this importance of being able to see problems from others points of view, even if in the end you do not agree with another person’s perspective. One thing that I found interesting, and wound up doing more research into, was the idea of pair programming. The idea behind this programming technique is to have two programmers work together on one terminal with one programmer writing the code, while the other reviews each line written. This approach of matching a journeyman programmer with an apprentice I can see being very effective way for both the apprentice to gain critical knowledge and for the journeyman to progress further towards becoming a master by passing on his knowledge. One downside to implementing this technique with pair programming that the author points out is that the apprentice may often feel lost, but I feel this can be combined with another one of the patterns(Expose your Ignorance). In essence I feel that as the apprentice in this case, you have to be humble, acknowledge you won’t know much, and to ask a LOT of questions. Don’t ask just  one person these questions too, but ask other’s the same questions to see their perspective on the same problems.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.