Author Archives: rdentremont58

Sprint 2 Retrospective

This week’s Sprint was relatively uneventful due to a combination of reasons. First, due to the weather, we had snow days which interrupted our meeting. Second, we had issues communicating with the Ampath people, and we had classes cancelled for a week, so there were no concrete assignments for us to add to the product backlog to create our definition of done to deliver value. Finally, and this is a more personal reason, I caught a stomach bug so I was unfortunately not able to show up to the few classes we met up in.

Even though we weren’t able to produce any solid units of work, we still kept our team on track for our Scrum related tasks such as our stand-ups and kept our overall plan pretty solid. We are still in the process of completing the tour of heroes tutorial for angular, as well as installing and finishing the tutorials for the two testing frameworks Karma and Protractor.

After we began that, we took a look further at the tutorial for Karma, and installed the code into our computers. The Karma tutorial is relatively short, although we are expecting to have to allocate some extra time to researching about the Jasmine framework and syntax that both Karma and Protractor use in their testing commands. One thing we noted while looking through the tutorial is the fact that Karma tends to look similar to junit unit tests, so we are hopeful that Karma will feel somewhat intuitive when designing our unit tests.

The first major decision our group made based on the tutorials was that we are going to go with the tour of heroes for brushing up on our angular skills. We are allocating the most amount of practice time to completing the tour of heroes because we all believe that brushing up on our angular skills will be the primary force behind our whole project, while we can learn the testing frameworks slightly easier, is what we are hopeful for.

In light of the fact that our group was not able to produce any direct value this sprint, I still believe that we will be an efficient team. Even though we had no tasks, a few of our team members kept us on track for due dates of stand-ups, CATME surveys, and blog posts. The rest of us kept on track for preparing for when we had work to do so everyone in our group would be ready to hit the ground running.

So what I learned is that even though we did not contribute anything to the project during this sprint, I do not believe that we need to change anything about how we proceed or group organization or splitting of tasks. I am happy to have learned that team roles are naturally starting to develop due to the personalities of our team members, as one of us is adept at time management and keeping the group on track, while some of us can help out more with technical skills and troubleshooting skills. That is great because we will have less difficulties.


From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Craft Over Art

When I read Apprenticeship Patterns, the patterns which tend to stand out to me the most are those patterns which offer a unique perspective and an illustrative focus that is clear and easy to follow. Oftentimes when I am deciding how to proceed with my learning or implementation of code, I get lost in the possibilities, and the guidance the authors provide in this book gives me some much needed clarity.

This apprenticeship pattern is called “craft over art”, because the point of our vocation is to in the end provide a useful product to customers. The value the authors place in this section is on the practical and usable skills that makes up a good developer. The authors illustrate this point well by reasserting and contrasting what it means to be a software craft-person.

At its heart, craftsmanship is making something useful or necessary with an additional style or beneficial features that are added based on the creator’s methods. The authors definitely make this point clear when comparing software development to a craft, and even more so by comparing crafts with the arts. The key difference is that while crafts focus on making a functional product, the fine arts are focused on pure beauty itself.

So what the authors suggest we focus on as apprentices is not the beauty of the product but the functionality of it. Additionally, they describe how often in practice in order to deliver value in time a compromise might need to be made between utility and beauty.

This pattern definitely helped me hone in on which particular skill sets and goals I should be orienting myself around to be successful. Often I worry that I need to be focusing on making the most elegant code or learning the newest fanciest technology, which are definitely good things to aspire for, but in the moment of me beginning my professional journey, it is more important that I pick up practical, concrete skills, and that I focus on delivering the most value and utility. What I gained most from reading this was understanding that bells and whistles will make a product shine, but you famously cannot polish a turd.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Review

Our very first sprint went successfully by our measurement of done. We had five objectives to accomplish in the week long sprint; creating a trello board for our product and sprint backlogs, creating a github organization for our group, forking and cloning the AMPATH repository, setting up our environments to run the project, and learning about testing frameworks Karma and Protractor.

As it was our first sprint ever, we all learned about setting up and organizing the foundation of a group project, particularly through the lens of Scrum. We familiarized ourselves with the tools and processes Scrum uses that keep our team on track, such as the trello board and standups.

Also, we learned the value of inter-group communication, as our success is in large part due to the help of the entire class when it came to resolving errors. The organization skills and teamwork we have been practicing will definitely set the tone for how we will approach our goals in the future.

The beginning objectives of our sprint were straightforward and we accomplished them in a short amount of time. By the end of the first class we had set up our trello and github groups, forked and cloned the APMATH repository, and prepared to set up our environments to build the project.

That is where we ran into problems. When initiating nodejs to build and run the application, we all had completely different errors from each other. In my case, the first problem I had was building some of the modules. Thankfully,  Professor Wurst was able to help me solve the issue with the node –rebuild command, which drastically reduced the amount of errors I was getting.

Still though I had a few more issues. I knew we were getting close to being able to build the project because every member of our team was getting the exact same error messages. Sam, collaborating with others in different groups, was able to solve the issues by using the combination of ng build –prod and npm start commands. I admit I’m not entirely sure why that solved the problem, and it would be wise for me in the future to take a closer look into what these commands exactly do, will help me avoid errors in the future.

After a few more troubleshooting attempts, everyone in our team was able to build the project on our own computers. I was relieved at this because we were at the end of the sprint, and I was concerned that solving the errors would take all the time we had, and not allow us to learn about the testing frameworks.

Thankfully, Sam was able to help me with my remaining errors, so I had some extra time before the end of the sprint, so I did research and compiled summary notes for testing in Karma and Protractor. That really worked out well for us because we were able to essentially split the job and kill two birds with one stone. If possible I would like to apply this process in the future. While we definitely need to get more hands on and technical about learning the testing frameworks, I am satisfied to say that we realistically accomplished all of our goals in this sprint.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

The Value of “Toy” Programs

This Apprenticeship pattern “Breakable Toys” highlights the importance of creating an environment to experiment with important software development concepts, while affording us the opportunity to fail at no risk to ourselves.  The philosophy behind this apprenticeship pattern is the best way to gain meaningful experience is to practice and fail and learn from our mistakes.

In the context of software engineering, that means to create “breakable toy” programs that we can use to hone our skill set, while not having the pressure of success in the workplace get in the way of the learning process. We can experiment at our own pace, and practice the concepts that are integral to our careers in an environment where we are entirely in control.

What stands out to me the most about this pattern is the unique solution the authors suggest; create a “toy” program that is meaningful to you that you will use. Sure the goal is to practice the skills that will make us successful in our careers, but the authors suggest that by creating a program that we will actually have fun making will add to the motivation of the creative process.

The authors provide a few examples of people who create their own wikis to learn fundamental concepts of front end development and web design like HTML or REST, or those who make games when they learn different languages to cement the fundamental concepts. The emphasis is on creating a safe environment to test and experiment with different tools while still having fun and fostering creativity.

The main point I took away from this pattern is the importance of creating a safe environment to practice my craft, without having to worry about the scope or the severity of the task, while at the same time being intrinsically motivated to create something of personal value. Real learning and experience isn’t something that can be gotten on the first pass or on the fly; trial by error by far is the best teacher. After all, it would be illogical to expect a musician to perform in front of an audience without rehearsing first.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

As we all progress through the software development track, learning new skills and how to implement solutions to modern problems, we rarely stop to evaluate how our work or programs we create will affect other people. Yes, we have goals of efficiency, security, and user friendliness which guide us to develop the most useful technologies we can. However, even in following all of our rules to a T, we may create unforeseen consequences on the clients we develop for.

This article Why Doctors Hate Their Computers is a great demonstration of unintended consequences of modern software development as it behaves in the real world, being used on a large-scale. Essentially, the article describes a new electronic medical record software called Epic, whose goal was to create a single interface which doctors, patients, and hospital staff can share information and carry out their work more efficiently. The problem with this software was the scale of which it was being implemented. The upgrade from the old system was just too big with too many factors, and the robustness of the program actually served to make medical professionals jobs even harder and more tedious than before.

While they described Epic’s features and goals, my first impression was that it seemed like an excellent idea. Take all of the doctor’s online work tasks, bring them into a single program where patients and hospital staff can add information; it seemed like a grand unifying software that could easily be an industry standard. However, as I read the author’s experience with the hospital actually implementing the software, I became less convinced.

One aspect of this implementation which shocked me was the hospitals plans to compensate for the reduction in productivity that would accompany any large-scale change. According to the author, his hospital group allocated $1.6 billion on the transition – while the cost of the software itself was around $100 million. The majority of the cost was either being paid out to IT professionals who would install and train staff, or wrote off as lost patient revenues from temporary loss of productivity. This is a tremendous amount of investment to get the systems updated. The problem was with the scale of implementation. A possible solution is having “ambassadors” implement the change and then train the rest of their coworkers would be a better system. At least this way people could ease into the transition and get feedback.

This astronomical cost would be arguably worth it if it really cut down on the complexity of the existing system and resulted in a more efficient experience for the customers and a better workday for the staff. Unfortunately this wasn’t the case. The author’s colleagues experienced frustration, cluttered data, and longer hours at the computer. Significant time and energy that should have been given to the patients were now being spent on learning and/or fixing the system, which defeats the purpose of the upgrading the system in the first place.

Though the developers aren’t necessarily to blame. Without a first hand understanding of the needs and bottlenecks of the medical industry, developers rely on our tried and true model of efficiency, which may unintentionally have the opposite effect if complexity becomes too much. Large scale software updates like this should be taken slowly, where developers work closely with clients to fully understand their needs. When the system is ready to be released, it should be live tested with a few “ambassadors”, who can give constructive feedback and train their coworkers, rather than a company wide transition that can be exorbitantly expensive and time-consuming.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Building Concrete Skills

When I look for patterns to read and write about in Apprenticeship Patterns,  my interest is first directed at the context and problem sections of the text. Naturally, I’m drawn to patterns which most directly apply to my position right now. In this pattern, concrete skills, the context and problem could not be more true.

I am in a position where I begin my apprenticeship in a scrum team full of skilled programmers. I will be the intern and as such will have the least knowledge or experience out of anyone in the group. This pattern offers actions and solutions I can take so that I won’t need as much as what the authors put it “day care”.

I appreciate the simple wisdom of the advice the authors give. If I am worried about not being able to meaningfully contribute, learn a few concrete skills that will help me take on a few responsibilities, easing the burden on the team to train me.

A few actions I should take to achieve this goal are to make demonstrative applications using the concrete skills needed, as well as looking at similar code from other people and trying to figure out their logic and methods to solving the problem.

In my case, reading this pattern helped me decide a concrete skill that will help me be more of an asset to my future team. I know that we will be working with Spring, so I will try to learn about making components with spring and creating a simple program or two, so that on my first day I am already equipped with some kind of knowledge that will get my foot in the door and make me useful.

From my limited experience reading this book so far, I have already started to change the way I view how to take the first steps of my career. Up until this point I felt as though the wider your experience the better, but the examples the authors use really illustrate how much more value I can get by focusing on a few things, and taking small steps to build concrete skills which will be a bigger benefit for me and my future team.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Honing Your First Language

When I picked up Apprenticeship Patterns, on Chapter 2, Emptying the Cup, the very first pattern caught my eye when the context and problem they presented seemed to apply to my situation closely. The pattern is “Your first language”, and the authors hit the nail on the head in my case when they explain the case of a budding programmer who only has limited knowledge of one or two programming languages, but the job opportunities demand a high level of technical proficiency.

Their advice is to stick with one language and become fluent in it. The logic is to hone your language skills by solving real world problems, developing code through test driven development, with the guide of experienced programmers.

The authors stress the importance of deciding which language to take on as your first. It makes sense, seen as how that language will be the primary tool we use to solve problems. In my case, it seems clear to me which is the right one. As many of us, my first and most familiar language is Java. Not only that, I am fortunate enough to have an internship opportunity which uses Java and JavaScript. So I have the real world opportunity to hone my knowledge, and access to mentors who are more knowledgeable than myself.

One final piece of advice the authors gave which I will take them up on is to find a community of people who are focusing on the same language and have similar experiences as you. For me right now that is my peers, and it is plain to me the mutual benefits of working with others who are in the same boat.

As much as I feel internal pressure to learn a variety of languages like C++, Python, etc., reading this pattern resonated with me and helped me make an informed decision to focus on what is pragmatic, as opposed to getting caught up in the ocean of possibilities. Since my first professional opportunity is using Java and JavaScript, I will focus on honing my skills in those areas as opposed to spending that time getting a surface level understanding of a different language that I might not immediately use.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Introduction

My first impression with reading the first chapter and introductions of  Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman  left me eager to learn. Although I only read the first chapter and the subsequent introductions, I could tell immediately that this book contains a wealth of knowledge born of experience from talented software craftsmen that will greatly help me hone my skills over my career. Chapter 1 introduces us to the book by giving us insight into what types of character traits are the most beneficial for a budding software developer, as well as providing a background of the historical craft model and how that model applies and differs from the one that is used today.

In the first section of Chapter 1, the authors describe character qualities that are fundamental in a true craftsman. They demonstrate how important being self motivating is to mastering the skills of software development. We are in an industry that is constantly evolving, so being motivated to learn and improve on our skill continuously is essential to being a software craftsman.

Another aspect of the authors’ perspectives I enjoy is how they explore the traditional medieval guild model and how that applies to software development today. The concept of a progression from apprenticeship, to journeyman, and finally master is still used in many trades today, and I definitely agree with the authors’ suggestion that the model applies to our industry as well.

I also find it very interesting how the authors define apprenticeship patterns and how they go about deciding which ones work. They describe “extracting the framework from working systems”; the knowledge that comes from analyzing past successes and figuring out common patterns that aided in their success is extremely valuable knowledge that can be applied throughout our career.

I feel as though reading the introductory excerpts from the beginning of chapters 2-6 gave me a basic understanding for the tone and themes of the book. What I took away from reading them is each excerpt is a story or general example that relates to the topic of the chapter, and often the story illuminates a need for a fresh perspective, and emphasis is placed heavily on disciplining oneself to have an open mind, taking any opportunities to learn from those with more experience, as well as being able to learn for yourself, and be responsible for your own education.

I was at first a little bit surprised at how heuristic the book is, but I saw right away how this unique outlook offers valuable knowledge that will help all of us in our journey to becoming skilled developers. I’m excited to learn the apprenticeship process from this book, because I believe that if I can apply this knowledge early on in my career, I will be in great shape for being a skilled software craftsman for my entire career.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

CS-448 MW 11:30-12:30 Introduction

Hello everybody,

I’m looking forward to having class with you all this semester! :]



From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

A Unique Idea for Designing Tests

Katrina Clokie, author of “A Practical Guide to Testing in DevOps“, offers us her unique insight into developing effective tests in her blog post “Generic Testing Personas“. In this article, Clokie explains how developing personas can be helpful in modeling expected behavior of users. This information is very valuable when designing different tests.

Clokie begins by explaining how good tests should cover all possible behaviors, to make sure that the software being tested is as adaptable as possible for different individuals. Developing “personas” for expected or stereotypical behavior can give an informed perspective when designing tests.

When designing personas, each individual should have clearly distinct behavior patterns and needs from one another. In this article, the author gives us an example of six personas that could be helpful when writing tests. Here I will just briefly describe two that I feel compliment each other and demonstrate the point nicely.

“Manager Maria” is a persona who is always busy and rushes through the software, consistently using shortcut keys, making mistakes, and constantly going AFK while using the program. For example, Maria might be frustrated with slow response times, so the tester ought to make sure the software is running smoothly even during times of high traffic.

In contrast, “Elder Elisabeth” has trouble with new technology and may require simple user interfaces, need to zoom far in, or may need to reach out for assistance. In Elisabeth’s case, the tester should make sure the program is visually stable, and can be run on older systems.

Both of these personas are stereotypes of real users who have different needs and behaviors. The more defined the characteristics of each persona, the more information about their needs can be inferred. It is the responsibility of both the developer and the Software Quality Assurance professional to make sure all of these different needs and desires are met to deliver the best possible product.

I very much enjoyed this article and I found Clokie’s perspective both interesting and helpful. I definitely enjoy and find important the application of heuristics in software design, and it makes sense that this knowledge would be helpful in the context of designing tests as well.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.