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.

By now, I’ve become rather accustomed to Typescript, Angular, and even CSS. Once the basic functionality of this project was working, motivation and momentum made it easy to continue adding more features. As evidence 14 out of 21 commits have been made in the past week, and although some are small it shows how easy adding features becomes when you have a good base built.

The database building and making sure it was in sync with file uploads was the most challenging part of this project so far. Two new services were created: one to handle all interactions with the database and another to provide information about the user that is currently logged in. Having Components communicate through a service decouples them from each other and the parent. The Components can simply subscribe to the data they need. This blog post was most helpful in determining the best approach for my needs, but Angular’s documentation filled in the blanks as needed.

An interesting bug I encountered was that uploading a new file overwrote all previous files. This was occurring because I was using the same reference to storage, but a new one is required for each upload. This was a simple solution, but puzzling at first. This was only noticed when I tried deleting a file: other files were still in the database and storage, but the link to all files returned a 404 error.

Then my least favorite part came: improving the UI. I love making things work, but making them flashy and fancy frankly seems like a waste of time, as long as it doesn’t detract from the user experience. Still, I quite enjoyed making it look nicer, despite some frustrations with CSS. The biggest issue I’ve had is CSS styles from outside components affecting the inner ones. I also wish browsers were more standardized. It has been difficult creating a consistent user experience across browsers, save for creating new elements from scratch. In the case of file uploads, for example, it is much simpler to hide the actual element and forward user clicks from a custom text input and browse button.

My last task will be to add some graphs to process information and display it to the user. This is of little use for the project as it stands, but will be incredibly useful for my Independent Study project next semester when I re-brand it. I have to give some credit to the Angular framework for making it easier, but using software engineering principles has allowed for an iterative project. I have a working project at every step with a much bigger end goal in mind.

There is still some polishing I’d like to do, and of course there could always be more features. This project was a great chance to dive into Angular and web development.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Hello, again my fellow readers!

This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.

The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.

The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.

This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.

That’s all for this week. I wonder what pattern I will get to read about next?

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

One of the many proverbs which I was raised on that I think about to this day when I am trying (and often struggling) to learn something new and master it, is “practice doesn’t make perfect; perfect practice makes perfect”. And while perfection is an impossible goal to set for oneself, the idea that it is important to analyze how you are practicing is instrumental in developing your skills.

This apprenticeship pattern “Learn How You Fail” speaks volumes to this idea. The main idea the authors are trying to impart is to not only accept that perfection is an impractical goal to strive towards, but to analyze and remember the qualities or areas that make you fail. By applying the practice of becoming aware of what you don’t know that you don’t know, my perspective and ultimate success will be much better for it.

Specifically, the authors make it a point to demonstrate this practice by suggesting to create an implementation of a common problem, in this case binary search, in a simple text editor. Once the problem is implemented we are to design tests and iterate the code until we believe it is perfect and only then can we compile and run the tests. The focus of this exercise is to illustrate that even when we think something is complete or as perfect as possible, there will be gaps in our knowledge that we are not aware of, and applying this practice will make you more familiar with the holes in our understanding, allowing us to get a better view of ourselves and our limitations, with the goal of overcoming them.

This apprenticeship pattern definitely spoke to me, because I am very interested with not only the concrete skills in software development, but also the process of learning and finding new ways to learn more efficiently. One quote from this section of the book which stuck with me because of its blunt honesty was “someone who has never failed at anything has either avoided pushing the boundaries of their abilities or has learned to overlook their own mistakes”. I will definitely be taking this lesson to heart and do my best to get as accurate of a self-assessment as possible, so I can practice honing my skills as perfectly as possible.

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

So for this week, I have decided to read “Reading List”  pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I chose this one because I believe there is something that should be done on a daily basis. Since that reading is exactly that, it should be wise to read this pattern at least once.

This pattern starts off with the context of having so much information that is needed to learn after developing the language. The problem is that the number of books to read is increasing than that of actual reading them ourselves. There is also the issue of figuring out where to start from the number of books. To solve this issue, one must maintain a reading list that not only helps in remembering the books read but also track the books that are planned to be read. Creating a text file is an option to write the list down as it is under source control and simplest implication of the pattern. For what it is worth, there is a need for a clear understanding of which books to prioritize in reading and in order by the subject.

From this pattern, what I found useful is identifying the books that would be worth reading based on a list given by any book. This will help in finding hidden connections related to the topic or language to an extent.  Mentors may recommend must-read books that even peers can discuss with one other and advise with the aspects. With data gathering over the years, patterns, gaps, and trends is starting to be seen. This pattern has changed my mind in giving suggestions to other people in what to read. I don’t disagree with anything since it does give clarification in what to do with the knowledge gained thus far and all the books needed to be read in due time.

Based on the content of this pattern, I would say this is a great and simple read as a way in reflecting on a reading habit. This pattern has helped me understand in which to read first for what topic I could have next. For future practice, I will try to write a reading list in different ways beside a text file in case anything happens to that specific device.

Link to the blog: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06.html#reading_list

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

This week, I’m reflecting on the Use the Source pattern from Chapter 5: Perpetual Learning. We all know the best way to gain expertise in programming is to actually program. However, it’s tough to know what tools are the best ones to learn from. This pattern suggests learning concepts by viewing the works of others — you’ll pick up on tips and tricks and can directly understand how to solve difficult problems if you learn from material from those who are great at solving problems. Even if the work you read isn’t from master software craftsman — just reading code vastly improves your ability to utilize code in your future.

I like this pattern a lot for a few reasons. I have always been timid about contributing to open source projects due to a lack of feeling comfort with handling others’ code. However, recently I started looking at a few open source projects and felt as though I could really contribute to the projects if I wanted to. I get the sense that this comfort has come from me handling and reading code more regularly on a daily basis. Another reason I enjoyed this pattern was reassurance. I’m starting in a Software Engineering position at Stratus Technologies in a month and a half’s time. I’m feeling extremely fortunate that I got hired, and I also know that I have a tremendous amount to learn — both when start the job (about the code they have in place) and beforehand. Their codebase is vast and complex, and in order to be an effective team member, I’m going to need to get used to dealing with large, multilayered, and complex systems.

In the arts, there’s a learning concept where the artist does “Master Studies”. Essentially, the idea is to choose a piece of art from a great artist and try to recreate it from scratch, by using the work as reference. This puts the artist’s skills to the test, but it gives them a framework to work within. I see this pattern and the concept of “Master Studies” as related, in a way. By examining the work of those who have made a name for themselves in the field, we get insight into how their mind works. There are many brilliant “Master” engineers out there, and they’ve written a tremendous amount of code that I can conduct my own “master studies” of. It’s like reading great literature — it will impact your work for the rest of your career.

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