Apprenticeship Patterns: Unleash Your Enthusiasm

I thought this section of Apprenticeship Patterns presented a fascinating take on how newcomers might fit in with their more experienced counter parts when entering the professional world of computer science. The authors describe the role an “apprentice” might want to take when working in a team of seasoned computer scientists. They explain that it is common place for newcomers to “fly under the radar” and not speak their ideas due to lack confidence in their ability to be a contributing team member. They point out that while every team may differ, teams typically benefit from having team members of varying skill levels, even “apprentices.” The authors also cite a study involving aircraft carrier crews that showed that it is healthier for teams to consist of people with different degrees of skill and experience and found that newcomers played an integral role in the team dynamic. Finally, the authors propose that newcomers should in fact “unleash their enthusiasm” in hopes that their excitement will rub off on other team members as well as keep other team members on their toes through asking many questions on why things are the way they are as well as presenting fresh ideas.

I honestly found this particular pattern to be extremely relatable as I am currently a newcomer in a security team that is made of individuals who have varying degrees of skill level, experience, and expertise.  When I first started, I admit that I was a little intimidated by all the tools that were being used not to mention all the acronyms being thrown around in meetings that I had never heard of before. However, I feel like that feeling of being overwhelmed pushed me to want to learn more about security and obtain the same kind of knowledge possessed by my coworkers while at the same time applying the knowledge I have acquired throughout the course of my college career. I also feel like I really lucked out because of the willingness of each of my team members to answer my questions and give me advise. After reading this pattern I think I will ask questions and speak up more confidently at work because now I know that it is important to bring a fresh perspective to a team.


Sprint 1 Retrospective – Getting Started

This was my Team’s first sprint cycle for our Software Development Capstone.  I think the main takeaways my teammates and I got from this sprint was how a SCRUM team operates along with an idea of how angularJS works. Since there was not a whole lot of actual software developing going on during this first sprint, I do not have too many insights into what my team needs to do differently to make for a more successful SPRINT in the next couple of weeks. However, since my teammates and I are still fairly new to angularJS, reading up on angular documentation seems like a good start as the next sprint cycle will entail much more coding.

The main things we accomplished in this sprint cycle was getting our development environments set up on each of our individual laptops, setting up our team’s gitlab repository, and making sure we have access to everything we need to get started. Some of the things I did to help get my team started included setting up our team’s GitHub repository ( and helping everyone get the ng2-AMRS application running on their personal computer. Thankfully, we were able to complete every task that was set out in the beginning of the sprint. As far as failures go, I can’t say we experienced any for this particular sprint cycle. The toughest task that was included in this sprint was getting the ng2-AMRS application running on each of our computers. We all had to make some small changes to the code to get it working. I should mention that I am the only member of my group using the Mac OsX operating system so some of the fixes I was able find did not apply to my partners who are all using Windows 10 machines. To get the program running on my laptop I had to make a couple changes in the code to get rid of the following error messages:

Pasted GraphicPasted Graphic 1

I had to change the name of file paths that were being called in “styles.scss” and “ladda.directive.js” so that the application could find the “ladda” module. After I made those fixes the application compiled successfully, and I was able to get to Ampath’s login page.

Going forward, some of the things my team and I will have to figure out include how to write angular tests for the modules we’re working on, obtaining a deeper understanding of how angularJS works as well as how we are going to commit code to our team’s repository. Committing code to our team’s repository could present many challenges especially since we aren’t all using the same OS on our development machines. This could be particularly challenging for me since I’m on a Mac and all my teammates are using Windows 10.



Apprenticeship Patterns: Emptying the Cup (Chapter 2)

The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.


Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman – Chapter 1

At first, while reading this chapter of Apprenticeship Patterns I was a little skeptical of how software development could be thought of as a “craft” with some kind of software guild made up of apprentices, journeymen and masters. However, after reading the authors’ own definition of what they believe “software craftsmanship” is I started to agree with what they had to say. I actually found their interpretation of apprentices, journeymen and masters, in the context of software craftsmanship, to be pretty interesting. I think that if all developers took on this way of thinking about software development the software engineering community could benefit immensely. By adhering to an apprentice mindset, software development newcomers might be able to avoid making the same mistakes that past generations of software developers have made.

Another thing I liked about this chapter was the values in which the authors believed every programmer should adopt. I think that adopting these values and committing to the idea that the only way to become a true “master” is through continuous learning though trial and error is the best way to progress your skills and career in the software development field. Among the values laid out by the authors’, I saw a common theme in that they think it is important to be open and transparent when it comes to software development techniques. I feel that competition can sometimes discourage companies and individuals from sharing their ideas and innovations, but this is can be detrimental to the software development community.  If all developers shared their work and development experiences, then software in general could possibly become more reliable and efficient.

This reading definitely made me change the way I think about software development as a whole. One thing it has made me consider is my overall career goals. The book talks about how one of the most important parts of becoming a better developer is finding a position that provides good mentors rather than finding the position that simply has the highest paying salary. This is something I didn’t really think about before and it has made me realize that if I want to enjoy what I do for the rest of my working days I should definitely try to find a place that encourages learning and provides many opportunities for mentors to give me feedback and ideas. Also, I think this reading will change how I work in the sense that I will look at failure in a new light. Instead of being mad that I can’t get something to work the first try I will remember that even the best developer out there has made countless mistakes to get where they currently are.

Software Testing With Security in Mind

For this weeks blog post I wanted to take a look at the security aspect of software testing.  I feel that we have discussed many aspects of software testing in our CS 443 class but one of the aspects we haven’t really gone over is how to determine whether code we write is secure.  Many of us, at some point in our carriers, will probably write software that will be used in a web/ desktop environment. By testing such code for vulnerabilities before it is released we can save ourselves and the companies we work for from falling victim to data breaches and stolen information. I found this article titled, How to Test Application Security – Web and Desktop Application Security Testing Techniques, and it discusses the issues I have just introduced.

The author of the article defines security as meaning “that authorized access is granted to protected data and unauthorized access is restricted.”  They then go on to distinguish between desktop and web-based software and the different security needs for both. Essentially, they suggest that both types of software require similar security measures to protect sensitive data, however, most web based software will require a little extra security measures since this type of software is accessible to anyone on the internet.

In the Article the author brings up a number of interesting points regarding testing how secure a piece of software is but I would like to focus on three of their main points as I feel they are really important. The three points I’d like to focus on are data protection, brut-force attacks, and SQL injections/ XSS.  To test for data protection in your software, the author suggests, you should ensure all passwords in your DB are being encrypted when they are transmitted. Also, if your software is web based, you should be using the HTTPS protocol rather than HTTP and you should test certificate validity on the server side. When it comes to testing whether your software is vulnerable to brut force attacks, the author says you should have some kind include “some mechanism of account suspension” into your software.  Finally, in order to test for SQL injections and XSS attacks we must treat any part of the code that accepts user input as a vulnerability.  The author advises that make sure there is a maximum length of characters for valid input as well as a checking mechanism for basic SQL injection techniques.

What to Consider When Doing a Technical Review on Object Oriented Code

For this week’s blog post I decided to write about important things to consider when doing a technical review on object-oriented code.  I chose this topic as I figured it would serve as a good refresher on key object-oriented concepts that we should keep in mind going forward with the next software testing project.  I thought that reminiscing on good practices of object oriented design would enable us to be more aware of what to look for while writing out software technical review on the Sir-Tommy Solitaire program.

I found a short book entitled Object Oriented Programing that was written by a software professional named Carl Erickson.  Erickson is also the CEO and founder of a software company called Atomic Object.  Although the book was written in 2009, I still think it is relative in the world of object-oriented design today.  There are many sections to Erickson’s book but I plan on looking at just a few sections that I thought were most relevant to writing our software technical review.  The sections I intend to focus on in this blog post are the following: sections 4 – OO Naming Conventions, 8 – Encapsulation & Modularity, 9 – Object-Oriented Hierarchy.

In section 4, Naming Conventions, Erickson briefly touches upon good practice for naming classes, methods, and variables.  He explains that class names should have the first letter of the first word capitalized along with the first letter of every word after that whereas, object variable and method names should have the first word begin with a lowercase letter and all following words begining with capitalized letters.  This probably isn’t news to any of use in CS-443 but it’s definitely something to consider when writing our software technical reviews.

Next, in sections 8 and 9, Erickson explores the ideas of class encapsulation and hierarchy.  Encapsulation is an important idea to consider when writing software technical reviews because improper use of encapsulation such as instantiating a variable as public when it should be private can lead to serious headache down the road.  For example, if something in the code were to go wrong with regards to a public variable that you instantiated, it may be very difficult to track down the culprit of the bug since the variable in question is not private. Also, Erickson brings up the notion of the “is a” relationship between classes, sub-classes, and interfaces which will be significant in determining the flexibility of the code in question.

It’s also worth reading over the rest of the sections in Erickson’s book. In particular sections 10 -14 as they go over essential concepts regarding to object-oriented design.  Section 13 does a good job of explaining how to evaluate whether or not a piece of object-oriented code is designed and implemented efficiently by focusing whether the code adheres to user specifications and object-oriented design techniques. Keeping in mind the foundational concepts of object-oriented design may allow us to make more insightful suggestions and write better technical reviews.







Best Practices for Naming Your JUnit Test Cases

Over the past couple of weeks in our Software Quality Assurance and Testing course, we’ve been working on writing code using Test-Driven-Development as well as coming up with JUnit test cases based on code that was already written. Over this time, I’ve come to notice that naming conventions for test cases can prove to be a little challenging in some situations. This is especially the case when writing tests in a Behavior-Driven-Development (BDD) manor. BDD, I feel, has kind of become the norm when it comes to naming conventions for JUnit tests and what this means is that tests are written specifically to test certain expected behaviors of methods/classes and are named as such. To clarify this, let me give an example using the code we were working on in class; imagine you write a test case that is going to test our readToGraduate() method in our Student class. While you will most likely have multiple test cases for this method, since there are multiple factors to consider when determining if a student is ready to graduate, one of your JUnit tests might test to make sure the method returns false when the student’s LASC and major requirements are complete, and they have obtained enough credits but their GPA is less than 2.0. A possible name for this test, following the BDD practice of naming, might be:

Screen Shot 2017-11-04 at 1.34.20 PM

As you can see this is kind of a mouth-full. Even though this describes the behavior we should expect with the given input, the readability of this code is pretty lousy. That’s why I decided to do some research on different naming conventions for naming JUnit test cases for this week’s blog post.

I found a blog post titled, Getting JUnit Test Names Right, written by Frank Appel, a software engineering professional, in which he addresses the same problem I have just described. Essentially what Frank suggests in his blog post is that we keep naming simple, which may mean making our test names less descriptive, and use good naming conventions for methods and variables inside the test case to enhance readability. He explains that test names can be made simple through our test’s name only describing state information. Hence the test case I described earlier may look something like this:

Screen Shot 2017-11-04 at 2.21.36 PM

Although the name of this test may apply to multiple tests with different inputs we could address this by simply adding a number at the end of the name for different input values being tested.  Frank, addresses this issue as well in his explanation. He says that although this naming convention may lead to names that could apply to a variety of tests, using good naming conventions inside your test method will clear up some of the vagueness. Also, as Frank points out, since the JUnit reporting view provides pretty descriptive messages when a test fails, this will also help clear up some of the ambiguity.

A Closer Look into JUnit 5

For my blog post this week I wanted to take a closer look into what to expect with JUnit 5. Last class, Professor Wurst gave us a brief run down on some of the nifty features and functionalities that were introduced in JUnit 4, such as testing for exceptions and implementing the assertThat() function. Seeing as the new JUnit framework, JUnit 5, was just released this past August I though it would be interesting to take a look into what additional features were added into this new JUnit testing framework. I found this blog post, A Look at JUnit 5’s Core Features & Testing Functionalitywritten by Eugen Paraschiv, a software engineering professional and thought it gave a pretty good run down on what to expect with JUnit 5.

Paraschiv points out a few new and useful assertions that are implemented in the JUnit 5 testing framework; assertAll(), assertArrayEquals(), assertIterableEquals(), and assertThrows(). Assert-all is a pretty useful assertion because it allows you to group all assertions within one test case together and report back the expected vs. actual results for each assertion in your test case using a MultipleFailuresError object, which makes understanding why your test case failed easier. Next, the assert-array-equals and assert-iteratable-equals assertions are also highly useful as they allow you test whether or not your particular data structure (array, list, etc..) contains the elements that you expected it to. In order to use these assertions, however, the objects in your data structure must implement the equals() method. Finally, the test-throws assertion pretty much does what the “@Test(expected = SomeException.class)” annotation did in JUnit 4. I like this way of checking for exceptions much better though because it seems more intuitive and makes the test case easier to read.

In his blog post, Eugene brings up a lot of cool new features implemented in JUnit 5 but the two that really stood out to me were (1) the introduction to the concept of assumptions and (2) conditional test execution. First, assumptions are new to JUnit 5 and I think that they could prove extremely useful in practice. Essentially, assumptions are syntactically similar to assertions (assumption methods: assumeTrue(), assumeFalse(), assumingThat() ) but they do not cause a test to pass or fail. Instead, if an assumption within a test case fails, then the test case simply does not get executed.  Second, conditional test execution is another cool new feature introduced in JUnit 5. JUnit 5 allows you to define custom annotations which can then be used to control whether or not a test case gets executed. I though the idea of writing your own test annotations was really interesting and I could definitely see this being useful in practice.





Blog at

Up ↑