During this last sprint I spent my time working on two things, that of continuing to try to get the styles to work for the buttons on our program and our teams final presentation. In continuing with the styles of the buttons from the bottom navigation bar, I finally tried to create and apply a palette. Ignite UI uses a thing called palettes which is a built in feature that takes two colors as primary and secondary, as well as a few other built in color groups, to create a large “palette” of colors that you can reference. To do this you create an SCSS file, short for Sassy CSS, which is a super set of CSS allowing the programmer to create variables, nested rules, functions, etc.. When you create this SCSS file, you have to import the Ignite UI style index, as well as provide the primary and secondary colors. From here you can define a custom gray scale palette, or take the one automatically created which has a default color of black. Finally once the palettes have been set, this is where the SCSS comes in, by allowing you to create color variables which can be used over and over. To create these variables Ignite UI provides a function for creating these colors, with 3 inputs; palette, color, and variant. The palette is one that you have created, the color is one of the 8 available through Ignite UI, and then finally a number for the variant with the default being 500, lighter shades being 50-400, and darker shades from 600-900. An example of one of these color variables would be “$my-primary-600: igx-color($my-palette, ‘primary’, 600);” I did all of this trying to hopefully change the styles of the individual button elements of the bottom navigation bar, but instead it would apply to most or all of the document. Although I did not get what I had wanted working, I feel that I did learn a lot of the way that this Ignite UI worked during this sprint, having spent many hours trying several different possible solutions. I feel with more time I would have been able to figure out this problem but my team also had to start planning and creating our final presentation for the class. For this my portion of the presentation was to be on the Ignite UI as well as some of the style stuff involving SCSS. To help me with this I spent a long time reviewing the Ignite UI website which was very expansive and almost like a Wiki. On thing that was very helpful with there website was the inclusion of examples using Stack Blitz, which gave examples of how the code would be run, and which could also be changed. This sort of program example helped a lot in trying to understand how a certain element they have in the Ignite UI worked when compiled into code, and I would highly recommend a version of it being used in future classes.

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

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 – James' Blog by jdenesha and used with permission of the author. All other rights reserved by the author.

Week 9

My blog post this week will be on the Apprenticeship Pattern labelled “Kindred Spirits” which encourages the reader to seek out others with the same goal in software craftsmanship. This pattern applies to those that feel the current organization that they are in does not share the same goals as that individual; increasing his or hers software craftsmanship. Instead these organizations can be focused on one thing, getting the product out to consumers. Instead of letting this focus of the organization affect you, you have to seek out others with your same passions so that you can keep your own. The two stories the author uses I feel is a good example of showing how, despite either living on the other side of the country or from completely different organizations, finding a “Kindred Spirit” who shares the same goals of learning as you can be exactly what most people need. Something else that I like that the author points out is the dynamic of having a mentor, where if they start researching a new method or language, you as the apprentice may feel you need to follow suit and drop what you are learning. However, with a community of “Kindred Spirits” you are not obligated to follow their same paths but just to learn from them and show what you have learned in your own studies. One final thing the author points out that I think people forget about to often is the idea of “group-think”, or thinking about a problem as an entire group entity. The author makes note that you as the individual need to be able to still retain your own thought, and the ability to ask critical questions and not just go with the group answer. I like this particularly because I notice that I do this myself, when arguing with friends or work colleagues. People are far too often set in their own decision and I feel, from personal experience, it is always helpful to have someone there acting as the “devil’s advocate”. Even though I might not agree with some of the points that I am making, it is critical to be able to acknowledge and understand other viewpoints or ideas. Overall, this pattern to me highlights the benefits and encourages the reader about finding a community of like minded software developers to bounce ideas off of, as well as seek mentoring when you may not be finding the right mentoring at your current organization.

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

Week-8

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 – James' Blog by jdenesha and used with permission of the author. All other rights reserved by the author.

My blog post this week will be on the Apprenticeship Pattern “Be the Worst”, in which the idea is that you may have outgrown your current team and possibly even the entire job. If this is the case and you wish to grow as an apprentice, then you need to find a new team or job in which you are the novice again. I like the premise behind this because it is pointing out to the reader to be humble; you may have grown complacent where you are and to truly grow you need to be tested in a way you can’t currently. One thing the author goes on to do is reference a drawing in the article saying of it “shows that as the weakest member of the team, you should be working harder than anyone else”. To me, looking back at the previous work experiences I’ve had, this is what I would do without even thinking about it in that sense. In working this way, starting as someone new in the company or industry, while I may have been very inexperienced, my drive to learn and to grow showed through to my bosses. I did this similar to how the author points out by, “…mimicking the stronger developers until you are on the same level”, or finding the best people at the job and asking how they would handle a situation. While my aim might not have been for it, this effort resulted in several promotions in a short span of time, clearly showing if the effort is there then someone is going to notice. Something that the author points out about this approach though is that is very much a “sink or swim” method, which can work great or you could possibly find yourself drowning. I like how the author also points out that as an apprentice you should not be so focused on the big promotions or the high paying positions but those positions which will result in you learning the most; “…as an apprentice, you should typically look to be led”. Overall,what I liked about and, feel this pattern was primarily trying to get the point across to the reader to not let your road be easy, but rather challenge yourself. To work from the bottom up because that effort will show through both in your work and to those above you.

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

This weeks blog post will be on “Draw Your Own Map” chapter of Apprenticeship Patterns. This chapter of the Apprenticeship Patterns involves understanding that your idea of a career path does not match that of your current employer’s and how to move forward in what you want as a career. The first thing that the author points out is that is no one’s responsibility but your own to realize what you want to accomplish in your career and then to realize what small steps you have to take to start working towards that goal. This doesn’t mean though, that there still can’t be people that help guide you toward your goals. A point that I like that the author points out further on is that successful apprentices tend to go to companies that “share a certain family resemblance”. This is because apprentices tend to make choices on their career based on the values that they live by. I feel this is the author’s way of saying that as a programmer to not go to a company that you do not share a passion with or there will be no reward in working for that company. A point that I personally appreciate that the author brings up is the ability for an apprentice to make these decisions to move on from companies while still maintaining a healthy relationship with past employers. I feel that this is so important in an industry to be able to grow because having a bad “reputation” with past employers can possibly block you from more opportunities later in your life. Overall, I feel this chapter was mainly getting the point across for people is that change is good. Change can be hard, but if you want to continue to become the person you envision, change is necessary. One way the author pointed out of putting this change to reality is the exercise to write down jobs that your current one can lead to, and think “is this what I see myself doing?”.  This chapter has helped to enforce the idea that I’ve had to experience myself, that sometimes to grow as a person you need to move on from your current employer, even if that means taking a pay cut because the experience you gain in your new path far outweighs the money.

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

My reaction to the reading of “Why Doctors Hate their Computers” is that while the program implemented by Epic to try to help streamline the process for doctors, it only made it harder for the doctors, more time consuming, and less revealing about the state of the patients themselves. Overall, the computer systems seemed to make the lives of the doctors, much harder rather then simplifying and streamlining their work. An example of this is when Epic arranged meetings between doctors and administrative staff, and in doing so added more fields to the program to help make the staff’s job easier. In trying to make the job easier for the staff though, it created more work for doctors with questions that previously were an afterthought were now required fields to finish the form for that patient. Another issue that was highlighted in the article was by the author talking to “Susan Sadoughi”, which she highlights the problems with each patient’s “problem list”. While previously this could be used by the doctors to know what to expect when seeing a patient. However after the installation of the medical programs, anyone in the organization could modify these problem lists, and worse there was no conformity amongst those making the changes. “Three people will list the same diagnosis three different ways” is not very helpful to the doctors trying to make the decisions that will help people’s lives. Another problem that I see in this system by Epic is the “stay in your lane” mentality in which ways that assistants would be able to help doctors was removed. For minor things that the assistants were taking care of there should of been cross-training of some sort to help reduce the high workload of the doctor in comparison to the already relatively light workload of the assistant. Despite all of these hardships on the doctors, the real users of this program was not just the doctors but the patients themselves. This program, while it was meant to help the doctors in their job, was really meant to make sure patients had a place to check what medication to use, when their next checkup was, reminders to seek treatment for cancer patients, etc, etc.. While I do not agree with the hardships that are being put on the doctors, I do agree with the sentiment of the man who had this system implement, Gregg Meyer, when he stated, “If computers causes doctors some annoying but improves patient convenience and saves lives isn’t it time we all got on board?”. This hospital system was not the only one affected by technological advances, with the author’s example of the construction supervisor, who also faced almost all of the same problems that doctors faced with their computer systems in his own field. Ultimately I feel that these incorporated systems can cause major headaches to those who have to use them. However, if they are designed properly with the focus on the job itself, simplicity, and no extra ancillary information, then these programs can be massively beneficial. It is when there are too many inputs from too many sources asking for too much out of the program that the true problems with these systems come around.

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

This blog post will be on the chapter “Expose Your Ignorance” in which the author talks about how, especially as an Apprentice, you should not be afraid to simply ask questions. I feel the author points this out with a very simply line “the need to appear competent is ingrained into people of most industrialized societies”. For myself I can tell you that this is very much the truth, I have been that guy at a job trying to appear competent when I had no idea what I was doing. But, just as the author puts it, you have to be willing to take a few hits to your pride, to progress as a person and ask for help from those you know can. Not only do you learn yourself from this experience, but those around you that you ask for help see you being humbled, and see you growing, in admitting that you needed the help. “Your instincts tell you to hide your ignorance, to feign expert knowledge, but this only stunts your growth and inhibits the work you are trying to accomplish” (David H. Hover). Something else that the author points out is the need to continue this learning process, because this is what it means to be a software craftsman. It is when people stop their continued learning from one subject to the next become experts, and while this is not bad it is not the same path as that of the craftsman. If you stop growing yourself, you can never progress to being a master, but rather you will be highly specialized in one area. This expertise is not a bad thing, but with how broad of a scope software craftsmanship has simply having expertise at one or two subjects puts you nowhere above a Journeyman. Overall I feel this pattern is a very good one for anyone pursuing any subject, because it reminds the reader to stay humble and to ask questions when you do not know. Trying to act like you know something that you do not, will only have other people looking at you like you are a fool, when instead you can show those people your willingness to grow as a person.

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

This blog post is about the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, in which the authors talk about what makes an apprentice and how you can move on and up from that position, eventually to the point of Master if you are determined enough. The author looks to define what is software craftsmanship, and while other people have written similar ideas close to that, none have actually explored what it means to be that craftsman. A point that stuck with me was when the author talks about lessons learned from the Agile Development Movement. They state how when just telling people to do things by a set of rules they would eventually be lost, but when those same people learned the values that underpin said rules, they were able to grow and create new rules for new contexts. The way that the author decided to define software craftsmanship was with the roles from medieval times, that of the Apprentice, Journeyman, and Master, all of which having their own roles in the industry. One thing that stuck out to me personally was when the author began describing what it means to be an Apprentice, in that as an Apprentice it is important to understand there are people much smarter than you which can be resources of knowledge for you. “…-By teaching them to value learning over the appearance of smartness, to relish challenge and to use errors as routes to master” (Self-Theories, pg. 4). As an Apprentice it is also very common and smart for you to be focused inward, focused on growing your knowledge and resources that will eventually be how you transition to a Journeyman.  I feel the way the author described the transition into a Journeyman was basically, “one day you just are”, but goes on to describe how it involves more than just the inward focus on growing yourself. As a Journeyman you begin to be more concerned on growing the teams that are around you, and mentoring those around you who are Apprentices working themselves to become the Journeyman. Finally, the author talks about what it means to be a Master software craftsman. This, for me, was one of the most important part of this entire summary of how being a Master software craftsman was more than just your knowledge. Being a Master was more about bringing up those who are around you, some to the point of surpassing your knowledge. “Mastery involves taking that skill and turning it into a magnifying glass that can enhance the skills of others by orders of magnitude”(What Does It Mean to Be a Master?). Overall, I feel the explanation of the Apprentice, Journeyman, and Master of software craftsmanship was very spot on, in that Apprentices are focused on growing themselves. Someone is a Journeyman when they start trying to mentor those around them, as well as growing and developing the team that is around them. Finally, Masters are not just Masters because of their knowledge, but rather how they distribute and spread their knowledge, as well as trying to help grow the industry as a whole.

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

This blog will be for the 2019 Spring semester of Professor K. Wurst’s Software Capstone class.

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