Author Archives: Kat Law

Software Development Capstone – Sprint 2 Retrospective

This past sprint was, to me, significantly less eventful than the first, but still very important in the progress of our capstone project. Over the past couple of weeks, I spent a lot of time focusing more on preparing for this upcoming Sprint 3, familiarizing myself with the tools and technologies that we will be using for our AMPATH project. We just received word about the kind of specific development work that we will be doing for the project, so keep an eye out for my Sprint 3 Retrospective for more information on that!

As I mentioned, Sprint 2 ended up being less productive for me, for a few reasons. We had a couple of class sessions cancelled (snow and other outside circumstances). While this fortunately did not slow our progress (everyone on our team has the AMPATH project built and running successfully!), our team has been taking advantage of each period of class time to discuss our progress, help each other out with any issues what we may be having, and planning our next courses of action. So, missing a couple of the sessions definitely slowed down some of the work that I could’ve been doing.

Another reason why this sprint has been a bit quiet is that we have not heard much about development ideas from the AMPATH team until yesterday, the final day of Sprint 2 and the beginning of Sprint 3. I’m very excited to start coding more, now that we have more of a plan, which involves mobile app development!

Our team had 2 tasks to complete this sprint – reading about Angular testing, and building and running the AMPATH project. Because I completed the second task during the previous sprint, I only had to concern myself with Angular unit testing, along with working together with my teammates to make sure that everyone could run the AMPATH project.

At the beginning of the first sprint, we had been tasked to learn about Karma and Protractor, two popular Angular unit testing tools. I, like other classmates working on development for the AMPATH project, utilized documentation for each tool in order to better understand how they work. My resource to understand Karma is found here, and for Protractor I used this source. Angular automatically incorporates Karma testing when creating any new project, so I spent more time reading about that tool. Karma and Protractor are similar, though, in that both load up servers on one or more browsers (specified when configuring) and runs the developed source code with the written tests. Then, the developer is notified whether each test passes or fails, via command line or through the browser.

This sprint really made me appreciate the quality assurance testing course that I took last semester. Learning about Java unit testing and its basic framework made the comprehension of this newer concept a bit easier.

Once again, I’m looking forward to posting more about progress that our team makes during this upcoming sprint! We have a lot of exciting ideas to discuss and potentially work with.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – The Deep End

Overall, I consider myself a person who tends to enjoy my comfort zone. I appreciate settling into a routine, whether this routine appears in my part-time job or is reflected in my academic projects. But is remaining stagnant the best decision for me, going forward into my career? Probably not, considering that I want to grow in knowledge as I gain more experience in the field. This week’s apprenticeship pattern, called “The Deep End,” provides more insight about how I can nip stagnancy in the bud, so that I can break away from a more comfortable routine and challenge myself further, becoming more confident in myself and my skills at the same time.

The problem that The Deep End aims to solve is one that I’ve started to already describe. As I spend more time in my career, I may become concerned that establishing a more mundane routine (like sticking to familiar projects which keep me in my comfort zone of work) is not the ideal choice if I want to continue to improve my skills.

In order to fix this issue, I need to jump into the deep end. To do this, I should seek out projects or other opportunities that are challenging enough that they are straying away from my comfort zone. I need to also understand that this sudden change to more difficult work can come with risks, including the possibility of failure. This balance of striving to test myself with different, tough tasks, while keeping an eye on my progress so that I am not in over my head, must always be maintained. If the likelihood of “drowning” continues to increase, it is also essential that I have the capability of reeling myself back in and find help if needed.

I completely agree with everything this pattern encompasses. Even though it would be nice for me to remain comfortable with the work I am doing, I know that it is imperative for me to continue tackling difficult problems and projects so that I can remain at the top of my game and keep my skills fresh.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 1 Retrospective

Over the course of this sprint, I have started to understand more about various aspects of software development that don’t necessarily include coding. Between getting to know the other members of my team and troubleshooting the errors upon errors that I encountered while setting up my development environment, there was plenty to learn about and work on each day. These skills are definitely applicable to countless other scenarios – for example, troubleshooting is necessary on a daily, if not hourly, basis. If I had a chance to go back and redo this sprint, I would probably have distributed my time more evenly for the task that took the longest to complete (troubleshooting the provided Angular project so that it built and ran successfully), rather than working on it somewhat irregularly, which was during working class sessions and occasionally outside of class.

For the past couple of weeks that made up the sprint, we have been spending time completing various set-up tasks related to the user stories given during our sprint planning session. Our team is collaborating with AMPATH (more information about their organization here), working with their medical record software. The tasks completed this week included cloning their “ng2-amrs” project repository onto our own local machines, successfully running the project, and downloading any additional programs to prepare for writing and testing code. Using a Trello board, we organized these tasks (and will continue to do so throughout the semester) into “Doing” and “Done” columns, with the user stories either staying in the overall Product Backlog or the latest Sprint Backlog if we wanted to get those completed during this sprint.

In order to clone the project, we first created a GitHub organization, adding each team member to the group. Then, one of us forked the project from the AMPATH repository to our organization repository. Finally, each team member cloned the project to our computers. None of us had any issues with this task. When we were downloading other programs that may come in handy later (like a TypeScript IDE, as well as Insomnia for work with REST APIs), there didn’t seem to be any issue with this either.

The vast majority of problems arose when it was time to build and run the ng2-amrs Angular project. When I initially ran the build command (“ng build –prod”), a bunch of errors popped up, preventing compilation and building of the project. Fortunately, several classmates have been posting discussions and solutions to many of these errors on our Slack channel, and these were so helpful when I was trying to troubleshoot my project. These discussions combined with frantic Google searches got me through this process of fixing my project.

One of the errors had to do with inadequate memory allocation when running the build. This was solved using the commands presented in Reference #1, which adjusted the memory used to extend its limit. Another error had to do with a package (“ngx-openmrs-formentry”) used in some of the many TypeScript files not being imported or recognized properly in the program. I spent a lot of time trying to fix this issue, even going so far as to re-clone the project twice to no avail. Finally, once I realized that the error messages were coming from the same reappearing package present in the files, I simply reinstalled that package (with the installation command in Reference #2), and that fixed the problem. A third error that I encountered involved the Angular Dev-Kit not being recognized when attempting to run the build. Using the command from Reference #3, this issue was easily resolved.

As of yesterday, using the command “npm start,” I FINALLY got the project to run! This was great timing, as it is now the end of the first sprint and the beginning of the second. I’m looking forward to the upcoming sprint, especially once our team is all up and running!

References

  1. https://stackoverflow.com/questions/50621043/fatal-error-call-and-retry-last-allocation-failed-javascript-heap-out-of-memo – used to fix the memory allocation error
  2. https://npm.taobao.org/package/ngx-openmrs-formentry – installed to ensure that the specified “ngx-openmrs-formentry” package is being imported properly
  3. https://www.npmjs.com/package/@angular-devkit/build-angular – installed to have the Angular Dev-Kit on my local computer to build the project

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Sweep the Floor

It’s fair to say that I am nervous about entering a computer science job and working with a professional software development team for the first time. While I will be fortunate enough to graduate with knowledge of agile development, I have a feeling that it will be quite different to participate in development with more experienced coworkers, rather than with classmates with similar skill levels as me. This week’s apprenticeship pattern, “Sweep the Floor,” described various ways that I can potentially overcome this initial worry of fitting in and being able to contribute on the team to the best of my ability.

Sweep the Floor discusses my exact predicament: being the new apprentice on the team and struggling to find my place within it. The solution for this issue is to work on simple and more mundane, or unglamorous, tasks which the rest of the team may find more tedious. Or, the apprentice may focus more on the “edges” of the project (rather than the “core”) to minimize any risks to the project that could come with putting a newcomer on the more difficult parts of the work. These tasks are still necessary for team success, and therefore make great experience for an apprentice who is just starting out in the field. By completing these seemingly unimportant tasks, the apprentice can show the rest of the team that he or she is capable of producing quality work that benefits the whole group.

Before I read about this pattern, I was already aware that as a new member of the software development team, I wouldn’t have as much responsibility or experience as other coworkers who have been on the team for a longer period of time. This pattern gave me a better sense of direction, in terms of more specifics for the kind of work I could expect to complete when first starting out on the development team. I have always found some reassurance in the thought that new employers and colleagues expect fresh college graduates to not have much experience outside of the coding projects they completed for classes. This pattern helped further encourage me that I can make the most of this “newbie” status by finding important tasks to do and still gaining valuable practice.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Why Doctors Hate Their Computers”

This week, our class was asked to read the following article, “Why Doctors Hate Their Computers” by Atul Gawande, which discusses the adaptation of healthcare professionals transitioning to a more digitized system to perform care. When Epic, a highly popular electronic medical record software, started to become more prevalent in hospitals and other healthcare settings, the costs of deploying the system on such a widespread scale had to be considered, not only for patients and especially for the healthcare providers who had to learn how to properly use the system.

After reading the article, I thought about how much time my own healthcare providers spend documenting on their computers, because I honestly hadn’t really thought about it before. Most, if not all, of my providers do in fact take a decent amount of time before, during, and after my appointments to work on my medical record. So, it was really eye-opening to read about the various clinicians who take lots of time outside of their workday to learn and use the system, not only because of the number of patients whose information is stored, but also because of the amount of time it takes to become fully acclimated to the extremely versatile software. It must certainly become exhausting to lose more time outside of work, after already having obscenely long workweeks.

That being said, I think that the primary tension that caused the system to make the doctors’ lives harder is the sheer number of patients who need to see a physician, along with the amount of pressure to become proficient with the new system at the same time. Each healthcare provider already has an obligation to visit as many patients as possible. They barely have time as it is outside of each appointment for documentation. Adding another responsibility of being comfortable with the new electronic medical record software (which has a function for just about anything related to health documentation) is definitely a hefty task.

With all this in mind, I feel that the true customers of the system are both the patients and the clinicians. While Gregg Meyer from this article described the patients as the real customers (because the number of patients accessing their records far surpasses the number of providers maintaining the records), it is also imperative that the healthcare providers fully understand the system. While each patient can spend several minutes examining their record, each provider spends hours per day working with many different patients’ records. With this much time spent, I feel that it should be argued that in fact, the providers are the customers system.

I think that some of the lessons described from this article could really be applied to any organization that may be switching to a more digital setting. The cost of familiarizing everyone with the system, both in cost of time it takes and the financial burden of training, can become high. These should all be taken into consideration when digitizing a company.

My main concern with such high dependency on these electronic medical software lies in the risk of some sort of organizational shutdown, should the system fail at any time. Because there is always high traffic due to the massive demand, these sorts of risks should be kept in mind. This software is revolutionary to the development of quality healthcare, but ensuring that the organization as a whole can still be successful in the case of malfunctions is essential.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Breakable Toys

When I was reading each of the introductions of the “Apprenticeship Patterns” book, the term “breakable toys” came up a couple of times. I wasn’t sure what the authors were trying to describe, so the Breakable Toys pattern was the next that I read. As it turns out, this pattern resonates deeply with me and my workstyle.

Breakable toys are essentially more private projects or spaces where practice is encouraged, without being concerned about the potential consequences of failing. For an apprentice who works in a high-stakes environment with no room for failure, this pattern is key to better understanding and learning about the tools used in their workplace. It removes the pressure of having to consistently be correct when developing software, which would be daunting not just for apprentices, but also for those with more experience. Breakable toys are great for anybody who simply wants a safe spot to work on projects away from their work environment.

Whenever I am writing code, or really doing anything in general, I am always nervous about failure. In conjunction with my previous post (which touches upon the apprenticeship pattern called Be the Worst), I also get intimidated when working with those with more experience, which in turn causes me to get worried about causing any failures when working with such individuals. For me, implementing a Breakable Toy would be great so that I could comfortably learn at my own pace, without fear of messing up in front of the development team and further affecting my ever-present impostor syndrome. I already have started various personal projects and courses, which I can now view as Breakable Toys of sorts.

Reading about this pattern didn’t really change the way I’m thinking about development and my apprenticeship process. Rather, it helped me realize that the kinds of activities that I’m already taking part in (like coding projects on my own or working my way through courses/textbooks outside of my schoolwork) are great steps that I should be taking in order to fine-tune my skills while also embracing any failures that may arise. By encountering these failures now, I can also better prepare for being a part of a development environment with less room for error.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Be the Worst

As I mentioned in my last blog post, I have a bad case of impostor syndrome and oftentimes get discouraged when comparing myself and my work to more experienced developers. This week’s apprenticeship pattern helped me understand that being farther behind on a stronger development team with intent to catch up (a small fish in a big pond) can be more beneficial than being more of an outgrown member of a team that doesn’t challenge me as much (a big fish in a small pond).

“Be the Worst” describes the problem of plateauing in new knowledge, as the apprentice continues to work in a team that doesn’t push them to challenge themselves. As a result, the apprentice may start to grow out of the team. The solution is simply for the apprentice to look for opportunities in stronger teams. By establishing themselves in such a group, the apprentice should be more motivated to work harder to catch up to the level of their teammates. While this poses a risk of potentially falling even farther behind, it has the immense reward of learning more, at a faster rate.

This section definitely reassured me that even if I am farther behind than my team members, it just means that I have more room to improve, as long as my teammates are supportive of my growth, in spite of me not being as strong of a team member (yet). I’m sure that initially, I will have difficulty removing the feelings of intimidation of working in a more challenging group. One of the additional risks of joining this kind of group is the possibility of feeling incapable or under-performing. However, as the section explains, I would be able to recognize how much I have truly advanced in skill when self-assessing.

This section also changed my thinking regarding comparing myself to other developers. With my current mindset of impostor syndrome, it may not be best for me to compare to those who are more experienced than me. But, as my attitude towards my own skill improves, it’s not a bad thing to look up to those people as an example of what I can also achieve. By seeking out more challenging opportunities, this comparison to other developers is also necessary.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Chapter 1, and Chapters 2-6 Introductions

Over the next several weeks, I will be posting my reflections on different sections from the book, “Apprenticeship Patterns,” by Adewale Oshineye and Dave Hoover. This book is a great resource for soon-to-be computer science graduates, like me, who are preparing to transition into the field of software development.

The first chapter explains what it means to be an apprentice in the context of a software development career, as well as the specifications that each step along the journey to becoming a software craftsman would entail. As I was reading this chapter, I enjoyed the imagery of a medieval setting that the authors created. This certainly helped me better understand the expectations of someone in each role, especially the apprentice. The descriptions of higher-level roles (the journeyman and the master) were also very well done, because they gave me a vivid picture of what I am aspiring to work my way up to.

The concept from the chapter that took me the longest to understand was that these tiers not only reflect my growth in position while in the software development field (like receiving more tasks from a boss or just having more responsibility in the workplace), but also the growth in mindset. I was initially confused because I was under the impression that the book would describe the type of work that I would be expected to complete as a new graduate and later. However, I feel that explanations of the attitudes and mindful habits that I should use are just as beneficial, if not more so, because each work environment isn’t the same!

With this new expectation of the book contents in mind, the introductions to the remaining chapters of the book made a lot more sense. Each of these brief sections made me more excited to learn more about how to solidify good apprentice practices.

While I intend on reading through the whole book, there is one chapter that I will need to spend more time going over. Chapter 3, titled “Walking the Long Road,” discusses how long our path to mastery really is. It also puts into perspective that all software developers travel on the same path, whether some are farther along than others. I tend to get easily discouraged when examining the work of others who have done more in the field. So, hopefully by spending more time on that chapter, I will become more focused on my own progress, rather than implicitly comparing myself to other developers.

There is also one chapter that I feel like I won’t have as much trouble working on. Chapter 5, titled “Perpetual Learning,” goes over the importance of keeping up with new knowledge in the field. This can be achieved by reading more on the subject or practicing skills, to name a couple of strategies. I love to learn new topics related to computer science; in fact, I have bought several online courses to go through when I have the time to get to them. So, I have some confidence that I will find the apprenticeship patterns described in that chapter easier to implement in my own life.

This book looks extremely informative and has been very well-written from what I’ve already read, so I’m excited to dive in further!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Welcome Back to My Blog! Let’s Talk More about Software Development!

Hello once again! I am back to blog more about my Software Development Capstone course taking place this semester. I am looking forward to documenting my progress and contributions throughout our semester-long project that this course entails, as well as discussing other discoveries about transitioning from an undergraduate student to a new software developer.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

What’s the Buzz about Fuzz Testing?

Whenever I’m testing any of my programs that allow users to input data, I usually try to remember to enter invalid values to ensure that the program does not function when such values are put into the system. Then, in one of my lectures, we briefly covered fuzz testing, which does this process for you! So, I wanted to know more about it and why it is very important to include as part of testing. I found this information from the following tutorial: https://www.guru99.com/fuzz-testing.html.

Fuzz testing, or fuzzing, is used in the context of security testing, where loopholes or vulnerabilities are exposed. It can be a form of black-box testing, so that even without source code, the tester can still determine faults that come up.

The steps that fuzz testing takes to perform are as follows:

  1. Identify inputs taken by the system to be tested
  2. Generate random input or data
  3. Executing tests using this data
  4. Monitoring behavior of the system and its accompanying tests

There are multiple ways that fuzzed data can be created for use, including the 3 listed:

  • Mutation-based fuzzing – alters already-provided, valid data samples to create new test data
  • Generation-based fuzzing – creates new input data based on the type of input needed for the system
  • Protocol-based fuzzing – based on the protocol format specified by the program, invalid data or packets are sent to the program being tested

Through fuzz testing, several different kinds of bugs can be uncovered, which go beyond simply finding invalid input. Some bugs may severely affect the security of an application, like causing memory leaks. Other bugs, called correctness bugs, may come up, which are errors in the overall function of the program. Because it can become time-consuming to come up with many fuzzing inputs, there are various tools that automate and speed up this process.

Fuzz testing provides crucial advantages. It can expose serious security threats and holes in the program which may not have already been covered. If there are other, possibly less significant bugs in the program that may have been overlooked, fuzz testing is a great way to find these as well. However, while fuzz testing is incredibly useful, it cannot be used alone. Rather, it can be a supplement for other testing strategies that may be used to enhance security testing or discover other bugs. Fuzz testing only really looks for simple errors that may arise from invalid input, but there can easily be other, more complex bugs in the program as well.

This post concludes my blogging for the fall semester! Thanks for reading, and I’ll be back next semester!

 

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.