The first of the patterns in Apprenticeship Patterns that I have decided to discuss is titled “Expose Your Ignorance.” This pattern deals with situations where we do not understand every skill we need to use for a project. In such situations, people tend to fake an understanding of things they don’t know in order to appear competent. Rather than hiding our ignorance in this way, the pattern recommends acknowledging when we do not know something and explaining to colleagues that we are still learning about it. This makes it easier to build relationships and improves our ability to learn, which are both important skills for a software craftsman.

I chose to share this pattern because I found it relatable. During many programming projects I have been a part of, I have had trouble understanding topics that my peers seemed to have no problems with. Despite this, I’ve avoided asking questions due to a fear of appearing inadequate or ignorant, and have generally tried to answer my questions through my own research. I think that following this pattern would greatly improve my ability to learn new skills quickly. I would likely have an easier time learning new skills directly from someone with experience instead of trying to teach them to myself.

Knowing that this pattern could improve my ability to learn new skills quickly, I think it may change how I approach future programming projects. Previously, I have felt ashamed of not knowing things and have felt responsible for teaching myself in order to meet the expectations of my team members. I think this pattern will help me accept that it is okay not to possess every skill required for a project. It will also encourage me to communicate better with other developers in order to gain the skills I need. I have always had trouble asking questions and communicating in general, and I think this pattern would encourage me to get better at it. I will try to approach future projects from the perspective that it is okay to not have every skill I need, and that I should try to learn from other developers instead of keeping to myself. This communication might also help me build relationships with other developers as well as a reputation for myself that could lead to a more successful future.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

In my last week of working on my CS-343 final project, I was focused on implementing the remaining features that I had planned to add in my original wireframe. This included creating a working puzzle game that the player could customize and developing my layout further to make it more appealing. While I was able to create a puzzle game and clean up my layout a little, I was unable to get everything to work the way I intended before I presented the project on Friday. My final version of my project, and the one that I presented, looks like this:

As you can see, I was able to create a simple grid-based puzzle game, which was my plan from the beginning. While working on my layout and data service over the past week, I finally came up with an idea for a basic game I would be able to implement in time for the presentation. I decided to use a puzzle I have seen before, in which the player interacts with tiles on a grid to change their color as well as the color of all adjacent tiles. The goal of the puzzle is to make all tiles the same color within the time limit. I was able to create a new Angular component to represent my tiles that alternate between gray and white when clicked. However, my attempts to make them change the colors of adjacent tiles let to many issues. I had the puzzle working in this way temporarily, but it would stop behaving correctly after the player reset the puzzle for the first time. I think this had something to do with how I was recreating my array of tiles in TypeScript and how that interacted with the HTML files. Clearly, I am still not an expert in TypeScript or HTML, even after a month of working on this project. Since I couldn’t get the puzzle to work the way I wanted, I ended up settling for a game where only the tile that was clicked would change colors. This makes the puzzle extremely easy, but at least it works consistently.

Aside from my troubles with the game mechanics, the rest of the development went pretty well. I was able to change the behavior of my width and height forms to alter the dimensions of the puzzle in tiles instead of the dimensions of a rectangle in pixels. I was also able to implement a timer that could have its time limit customized as well. If this timer runs out, a message displays saying that the game is lost. If all tiles are made white within the time limit, a victory message displays and the timer stops. You can see the application in action in the following screenshots:

Overall, I found this project to be an enjoyable experience that taught me a lot about creating web applications using the Angular framework. It not only taught me how to work with TypeScript, HTML, and CSS, but it also helped me figure out how to create GUI layouts in HTML using <mat-grid-list> and how to pass data between components using a data service. While my difficulties getting the game to work correctly prevented me from implementing everything I wanted to, such as a more appealing GUI or a back-end server to save player scores, I think the experience will definitely help me write better single-page applications in the future.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Yesterday was my final class meeting for CS-443. In it, I was briefly introduced to the concept of Software Quality Assurance (SQA). The presentation on it was mostly focused on Capability Maturity Model Integration (CMMI), which is one set of standards that is often used in SQA to ensure that an organization is capable of developing software well. While I received plenty of information on CMMI from the presentation, I felt that I did not gain a great understanding of SQA in general. For this reason, I decided I would do my own research into SQA to help me prepare for the final exam tomorrow.

I eventually came across this article from softwaretestinghelp.com which I think provides a fantastic introduction to SQA. The article starts of by defining SQA as “a process which assures that all software engineering processes, methods, activities and work items are monitored and comply against the defined standards.” This definition has helped me understand exactly what SQA is much better than the class presentation, which focused on CMMI. In fact, the article’s explanation has clarified to me that SQA can use any set of standards as defined by the organization, and that CMMI is only one possible example of these standards.

While the article emphasizes that SQA is a much broader concept than I previously thought, it also lists several activities and techniques that are generally used in SQA regardless of the selected set of standards. Some of the activities listed include having multiple testing strategies, measuring change impact, and maintaining records and reports. These techniques have all been discussed either in CS-443 or in other classes that I have taken, and seeing them listed here has helped me better understand exactly what happens when SQA is used during a software’s development. The article also discusses several techniques used to enforce SQA during a development process. The main technique that is used is auditing, which involves regular inspection of the products of development to make sure they follow the standards. Other techniques discussed in the article include code inspection, design inspection, and static analysis, all of which I have also been exposed to previously.

This article has made it clear to me that SQA is not simply the enforcement of CMMI, but a much broader concept that can enforce any set of standards using a variety of techniques. Reading this article has helped me better understand what SQA is and what it looks like to use it during development, and I definitely recommend it to anyone who is also having trouble understanding SQA.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Last Thursday in CS-443, I was introduced to Mutation Testing. This is a testing method which uses tools to embed faults into a project’s code before running its tests. The idea behind it is that, if the tests are written well, then they should fail when mutations are introduced. The in-class activity introduced Mutation Testing by having us clone a Java project and running the PIT tool to test the project with mutations. While the activity effectively demonstrated how to use PIT, I felt that it did not give me a complete understanding of Mutation Testing in general. This was mainly due to some confusion I had while trying to figure out how to run PIT. For this reason, I decided to research Mutation Testing on my own to help improve my understanding of it. I eventually came across an article from softwaretestinghelp.com that I think provides a great introduction to Mutation Testing.

Link to the Article:

The article demonstrates Mutation Testing with an extremely simple pseudocode example consisting of a single if statement. The example has five different types of mutations applied to it (called ‘Mutation Operators’) which demonstrate how adding mutations can alter the results of tests. Some of these mutation operators, like relational and arithmetic operator replacement, were demonstrated by the class activity. Others, like statement removal and absolute value insertion, were completely new to me. This taught me that there is a much wider variety of mutation operators than the activity demonstrated.

I also found that the article made it easier to understand how the mutations affected the results of the tests. In this article, the results of the Mutation Test are listed in a table with each column representing a different mutation made to the example code. This makes it possible to see exactly which test values either kill the mutants or cause them to survive. It also makes it easier to notice syntactically incorrect, equivalent, and trivial mutants, which the article mentions should be avoided. I disliked how the Mutation Test results were reported by PIT as a generic list of mutations with vague information describing why they survived or were killed. Having the results in the article be presented in a table and being able to refer back to the actual mutated code made it much easier to understand the results of the Mutation Tests. Compared to the in-class activity on PIT, this article uses a much simpler example to demonstrate mutations and presents the results of its Mutation Tests in a much clearer way. This has helped me better understand the fundamentals of Mutation Testing, and I think I will be able to use tools like PIT more effectively as a result.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Over the past week, my work on my CS-343 Final Project has been focused on creating a more interesting layout for my components. I have not changed the function of the program or added any more features yet, but I think I have made some great progress towards making the GUI look more like I planned it to in my wireframe. The program currently looks like this:

I managed to create this layout by making use of Angular’s Grid List material. Using material.angular.io as a reference, I was able to figure out how to import this tool into my project and use it to arrange components with the <mat-grid-list> and <mat-grid-tile> tags in my app.component.html file. By combining this information with what I learned about CSS and HTML last week, I was able to create the layout pictured above.

In addition to working on the layout, I made some major changes to the project’s organization. One significant change was the creation of a new Angular component: the options-menu. Previously, the input forms for changing width and height were simply parts of the app.component.html file. I decided it would make more sense to create a new component so that these options and the new options I plan to add this week will stay organized in my new layout. Another major change I made was in the way data is passed between components. Before, I simply had the input forms in the app component update the size of the rectangle by searching for it by its id. Now, the forms actually pass data from the options-menu to the rectangle using a data service. I decided to implement this method of data sharing after reading about it in this article on angularfirebase.com (see the section on Unrelated Components). I had difficulty understanding how a data service works at first, but I eventually understood it by messing with my own. Creating a data service has definitely made passing data between components far simpler than it was before, and I plan to add more to it this week.

As I am due to present my completed project this Friday, I have less than a week to finish working on it. My plan for this week is to finish adding the features I planned for the project in the beginning. This includes making a simple puzzle game that can be played in the rectangle area, as well as more options to configure it besides the width and height. I would also like to work on cleaning up my layout to make it more visually appealing. Finally, if I have time, I would like to create a back-end server that will allow users to store their scores form playing the game. It seems like a lot to add, but making this layout and creating a data service have only made me more comfortable working with the Angular framework. I think I will be able to complete much of what I have planned in time for Friday.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

In my previous blog for CS-443, I discussed my experience revisiting the class activity about static testing tools. I focused on figuring out the Checkstyle tool, which makes sure that the code complies with a set of style guidelines specified in an xml file. However, the class activity dealt with more tools than just Checkstyle. Today, I would like to look at the second part of this activity, which deals with tools that detect actual bugs rather than simple style issues.

The bug-finding tools that the activity focuses on are FindBugs, SpotBugs, and PMD. Much like Checkstyle, these three tools are extremely easy to add to a Gradle project by adding a few new lines to the build.gradle file. They each require just a single line to apply them as a plugin for the project. In addition, a small block of text can be used to set different properties for each tool, such as their version number. The activity also recommended adding lines to the options for FindBugs and SpotBugs to report their findings in an html file, since they use an xml file by default. This made the errors much more readable and easier to understand. Finally, a single line must be added to the Dependencies for SpotBugs to function.

Once build.gradle is properly configured, the tools are run simply by building the project (or calling “gradle check,” as I discovered). All three tools will then analyze the code and create reports explaining the types of errors they find. I ran the tools on the code provided for the activity, and I was surprised by how useful their reports were. They point out code that follows bad practice, code that may cause compatibility issues on different platforms, and even code that may negatively impact performance. I find it interesting that these tools are able to detect such errors without running the code, and I definitely see them being extremely useful as I often do not detect such errors myself even after hours of searching for problems manually.

Since these tools are so effective at finding errors, I was curious if there was even any benefit to using manual code review over one of these tools. I did a bit of research into this, and I found a blog post on synopsis.com that I think makes a great point – that these tools are unable to understand the context of potential errors in the same way that a human can. The blog also lists eight major limitations of these tools that should be considered when using them over manual review. Although static testing tools are able to find error in code quickly and easily, it is still necessary for the developers to determine whether the errors detected are valid or useful.

Link to the blog:

https://www.synopsys.com/blogs/software-security/static-analysis-tools-finding-bugs/

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Over the weekend, I have started working on my CS-343 final project by creating a simple Angular application that I will use as a base to build the rest of the project off of. The application simply draws a rectangle with a length and width that are entered by the user. When the user enters a new width or height, they can click a button to update the rectangle without reloading the page or loading a new page. The application currently looks like this:

Although this application is extremely basic, writing it has greatly improved my understanding of TypeScript, CSS, and especially HTML. While the in-class activity on Angular helped introduce me to the basics of HTML, researching and working with HTML on my own has definitely made me more comfortable with it.

I started writing this program by creating elements to take user inputs with text fields and buttons, using the class activity as a reference. I researched the HTML tags I needed to create these elements, and I came across a site called w3schools.com that provides documentation of HTML tags (such as <form>) as well as executable example code to demonstrate their uses. This site proved to be a valuable resource for understanding HTML, and I will certainly continue to refer back to it as I continue work on my project. Once my input forms were created, I quickly discovered that submitting data in a form refreshes the page by default, which I did not want to happen. I found out through research that writing ‘onsubmit=”return false”’ in the <form> declaration overwrites this behavior, and I quickly added it to my forms.

Next, I researched how to draw a simple rectangle that I would resize according to the input. I found that I could create one using the <div> tag and specifying its dimensions in its style field. I also discovered that I could change these dimensions code by setting an id for the <div> and using the ‘document.getElementById’ function to edit it from the TypeScript code, allowing me to pass data from my input fields to my rectangle

At this point, I could successfully resize the rectangle using user input. However, the ‘Text’ label was not centered in the rectangle, and I decided I would try to fix that. I came across another page from w3schools that explained how to center text both horizontally and vertically using CSS. I decided I would make the rectangle into its own Angular component so that I could put all the necessary style information into a .css file, and I managed to figure out how to do this by referring back to the class activity.

So far, this project has taught me more about HTML, CSS, and Angular components. It has also led me to several helpful references, such as w3schools.com, which I am sure will help me going forward. Now that I am feeling more comfortable with HTML and Angular, I plan to work on creating more elements that take user input and organizing my components into a more interesting layout similar to my wireframe. I am really starting to enjoy working with HTML and TypeScript, so I am looking forward to making more progress on this project in the coming week.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.