Author Archives: jwblash

MINIX3: Setting up the Environment

Over the past week, I found myself running head-first into a wall with MINIX. I ended up having to do lots of reading before I could even begin with development/tinkering. Having never done a project like this, I found rather quickly that the hardest part is getting started. Persistence is key, though!

In my research, I found that many resources were giving me mixed results. I saw a lot of people cross-compiling from their host machine into their VM, and I also found a lot of resources compiling from within MINIX itself. I really wanted to get a bit more experience with the feeling of low-level programming and using things like vi as an editor, even if it ends up making my life harder than necessary. So as a result, I was pretty set on the idea of compiling and rebuilding from within MINIX itself.

As it turns out, MINIX was originally designed with this type of native development in mind. From 1.0 to 3.2.1, they included the source files along with the install. In following versions, like the stable release of 3.3.0 shown on their download page, the /src directory isn’t even included within /usr. In order to obtain the source code, you need to use the git repository (also found here on Github) to clone the files. I found a section of the MINIX developer’s guide called “Tracking Current“, which explained how to go about using git within MINIX in order to track the most recent stable increments of MINIX’s development. On this page, it explains that the current stable release of 3.3.0 is not compatible with tracking current, as there have been key changes to the system since — the most recent snapshots are on version 3.4.0.

So, after a reinstall using a 3.4.0 snapshot, I finally have the source files included in my VM! I’ll start refactoring and show off what I do in following posts. I already played around a little bit by changing the startup text and rebuilding the system so it displays my name before I log in, just to make sure I actually understand how the “make build” command works. I’ll go more in depth on that subject next time. My task this coming week is to do a lot of reading through source code to understand what functions do what, and thinking about what changes I want to make exactly.

Until next time!

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

Apprenticeship Patterns: Expose Your Ignorance

To start off with Apprenticeship Patterns, I’m going to look at Expose Your Ignorance from Chapter 2. This pattern jumped out at me largely because of something I brought up in my introduction post regarding “putting on airs” in order to appear more qualified than you currently are.

The problem that this pattern is looking to solve is for when external pressures are demanding that you deliver high quality software. This often becomes an issue when you’re unfamiliar with a required technology. Sometimes you’re brought onto a team for a particular skill and you haven’t expanded your skillset to encompass all of the team’s work. Or, perhaps, you’re the only one that they could find to do the job, even though you may not be as qualified to do it as they’d prefer. Those around you are relying on your ability to perform in the face of inexperience.

The solution that is offered is to approach the situation humbly. Accept your inexperience and seek the answers. “Putting on airs”, as I said before, will only make your job harder. If you convince those around you that you’re more experienced than you are and you end up delivering a subpar product, your inexperience will be exposed. On top of this, you will have inadvertently rejected learning opportunities to maintain your image of expertise. Instead of this, aim to be open about your lack of knowledge in this area. This will allow you to perform better than you would otherwise, as you get to genuinely learn the technology on your path towards development. It shows those relying on you that you’re capable of learning and doing sufficient work (or better) in a pinch — and it’ll strengthen your bonds with them as well. We want to work with people who are capable, and including your peers on your journey in self development will show them exactly that. Not only this, but as the book says, rejecting this opportunity to grow can cause people to get settled into one particular niche and become experts in their area. That’s never a bad thing, the industry needs experts. However, an expert is not the same thing as a craftsman. A craftsman is flexible and always searching for the chance to learn and grow as opposed to locking themselves into one discipline and learning it through and through.

What action can an aspiring craftsman take to usher themselves towards the solution for this problem? Make visible your ignorance to your coworkers — the book suggests a list with 5 items on it that is in a visible place. Maintain that list well, update it and refresh it as you expand your skillset. It’s important to show others that you are constantly seeking growth in your craft.

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

Apprenticeship Patterns: Introduction

In my Software Development capstone class this semester, we’re reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover. I’ve read the first chapter and the introductions for chapters 2-6, and I’m hooked on this book so far.

In the introduction chapter alone, several ideas really jumped out at me. The authors encourage the reader to place emphasis on self development, preparing themselves to go out and confront the world as opposed to seek to change the world as a route for their success. They talk highly of personal responsibility and “lowering” oneself to the status of apprenticeship until those with greater achievements in the hierarchy of craftsmanship recognize the apprentice’s work. To revel in the fact that you are in the phase of your life where your primary goal is to learn and hone your skills. “This is a time for you to delay your ambitions of immediately maximizing your earning potential in order to maximize your learning opportunities.” Personally, I find genuine comfort in feeling that an apprentice doesn’t need to put on airs in order to look like they know more than they do. A willingness to grow will show for itself, and in practicing that mentality you will find yourself to be a capable and skilled craftsman in no time.

Each chapter in the book outlines a group of “patterns” that can be followed along one’s journey from apprentice to master. I think they’re all full of genuine wisdom so I figured I’d give an outline of each:

Chapter 2, “Emptying the Cup”, contains patterns regarding letting go of the knowledge you’ve gained as to allow yourself to learn as much as possible during your apprenticeships. Chapter 3, “Walking the Long Road”, is about saddling yourself up for the journey ahead. Understand that there are others who are further along the road than you are, and accept that. The only way that you reach that same spot is to keep walking the path that they have previously tread. Chapter 4, “Accurate Self-Assessment”, is similar to “Emptying the Cup”, except this time it is for the purpose of preventing yourself from getting too comfortable. Never become complacent in what you’ve learned — there’s always more to know. Chapter 5, “Perpetual Learning”, is a direct follow up to Chapter 4 because once you’ve assessed yourself, you know that there is more to learn. This chapter discusses techniques for continued learning and the extreme importance of it along the career of a software craftsman, in particular. Finally, Chapter 6, “Construct your Curriculum”, offers advice for the apprentice seeking further education. While resources on the internet are great, acquiring a library (of sorts) of books written by master craftsmen will always offer material that just cannot be found elsewhere. On top of this, it’s important to actually read the material that you acquire. Creating a curriculum, quite literally, to chip away at the vast material at your fingertips will help amplify your skills perhaps more than anything else.

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

Introduction: MINIX 3

For this Spring ’19 semester, I’m going to be delving into an Independent Study of the MINIX 3 operating system under the guide of my professor, Karl Wurst. My goal is to dissect and tinker with the underlying systems of an operating system — Processes, I/O, Memory Management, and File Systems. I’ve already gone ahead and installed MINIX 3 on a virtual machine using VirtualBox. Next step is to delve into the MINIX 3 book and see what’s going on under the hood. MINIX 3 actually has a really great wiki with a section catered towards hacking the OS as well, so I’ll likely be drawing a lot of my information from there, too.

As part of the Independent Study I will be writing a weekly blog post here to discuss what I’ve done every week, as well as a paper that I will finish as a summary of my work at the end of the semester.

Here’s to lots of learning and a great final semester!

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

CS-448 Introductory Post

Hello everyone! I’m James and this is my introductory post for CS-448, Software Dev Capstone!

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

Design Patterns: Proxy

Earlier this semester in my Software Design class, we had an assignment where we were to choose to write a report on either the Proxy, Facade, or Decorator design patterns (or any combination of the three, for extra credit). I had chosen the Decorator pattern, and due to the amount of assignments I had due I never went back to examine Proxy or Facade. So I’m here to do just that with the assistance of Sourcemaking’s article on it, starting with Proxy.

The Proxy is a structural design pattern that adds a wrapper to an object so that the object itself doesn’t suffer from excess complexity. There are actually a large number of reasons where this is useful. Sometimes objects get excessively resource heavy, and you don’t want to instantiate them unless absolutely necessary. Sometimes you’d just like an extra layer of protection from the access of an object for the sake of security or for general ease of use. Consider getter and setter methods for an example — you don’t want open access to the data within your object, so you make the data private (hidden from outside access) and you instead create public methods for retrieving and change the data of the private variables. In a way, getter and setter methods are mini proxies. Of course, the difference is that proxies are meant to be entire objects in themselves.

For a real-world example I’ll reference Sourcemaking’s article. In order to make a payment, someone would use the funds that they have in their bank account. Instead of needing to add methods such as “makePayment()” to their account and increasing the Account’s complexity, it is possible instead to pay with a check which can indirectly access the funds of the account. In this example, the check is the proxy to the Account class. Here’s a UML-like diagram:

Taken from Sourcemaking.com

The Proxy design pattern serves many purposes and is perhaps one of the easiest design patterns (in my opinion, of course) to understand and use. It’s very similar to Decorator in structure (which I did a project on earlier this semester) but its’ implementation is slightly different. Decorators are used to add new functionality to an object, whereas the Proxy is designed to encapsulate existing functionality into another, “adjacent” object.

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

An Introduction to Code Reviews

In my Software Quality Assurance & Testing class, we recently did a group-based code review of a simple Sir Tommy Solitaire program that my professor wrote a few years ago. It was a really fun and interesting group activity that I enjoyed quite a bit, so I decided to look more into common Code Review practices to get a better understanding of how to conduct them in a better way. This article written by Trisha Gee I found on DZone.com was a great resource for learning more about them.

First and foremost, the most important thing to remember when conducting code reviews is that your job is to view the code within the parameters of the project you’re working on. For example, if your company uses Checkstyle and prefers Google Java Conventions vs Sun Code Conventions, then the team must keep that in mind when reviewing code. All reviews must be viewed through a lens that corresponds with the vision of the project at hand.

When you’re actually conducting the review, what are the easiest things to look for? The article from DZone mentioned these four topics:

  • Formatting: Things line curly braces, spacing, line breaks. 
  • Style: Is the code laid out in a logical way (variable declarations near their usage, etc.)
  • Naming: Are naming conventions upheld throughout the program? Are they descriptive enough?
  • Test Coverage: Are there tests that cover the code and what it interacts with?

However, there are plenty of tools that exist to mitigate the potential errors which come from these easily spotted issues. Humans aren’t so great at noticing minute details — something that machines are perfect for. Formatting tools like Checkstyle that I referred to earlier will usually ensure that formatting standards are upheld, and tools like JaCoCo can assist test coverage (we’ve used both of these in class and it’s remarkable how helpful they are).

Really, the job of the reviewer is to focus more on the design choices and quality of the code. Not only should the code run, but it should be readable, maintainable, it should be written with good design principles in mind. Are any parts reused, are design patterns used in elegant ways or do they needlessly increase complexity?

I haven’t quite yet read through all of Clean Code by “Uncle Bob”, but from what I know it seems like many of the principles in that book are ones that should be deeply considered when conducting a code review. I think anyone looking for further elaboration on the topic of Code Reviews should read both the article I found on DZone (and other DZone material, frankly), and Clean Code — it’s as popular as it is for a reason.

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

Design Patterns: Iterator

I’ve been discussing AntiPatterns quite a bit lately, so I elected to switch it up and talk a bit about Anti-AntiPatterns, aka Design Patterns. As a quick recap: If AntiPatterns are common bad practice traps that developers/teams can fall into, then Design Patterns are good practices which help guide them to either avoid AntiPatterns, or to lean towards a more efficient solution.

One design pattern we’ve used many times in my Data Structures class is the iterator, and personally feel as though it was never fully explained to the class as to what an iterator even really is, let alone why we were writing one. This post from Sourcemaking.com helped a lot in terms of learning what the use of them is.

As covered in the article, there has been a push in recent programming towards something called “Generic Programming”, and the iterator is a core idea within it. An iterator is an attempt to abstract out the traversal of data items in a data structure into a separate thing. The usefulness of this is outlined by an example given in the article:

“As an example, if you wanted to support four data structures (array, binary tree, linked list, and hash table) and three algorithms (sort, find, and merge), a traditional approach would require four times three permutations to develop and maintain. Whereas, a generic programming approach would only require four plus three configuration items.”

– Sourcemaking.com

So essentially, your iterator is an object in itself that handles the job of traversing through the objects in a list. A real-world example of this may be the AM/FM radio controls in your car. The radio stations are the objects in a list, with their station name and frequency (or channel, I suppose) as their data. The iterator would be your “scan” button, which skips over the stations with fuzzy signals in order to reach the next one whose frequency is available to you, while all you did was press the one button. Each station is a data point in your list (your data structure) with a station name and a frequency. You, the driver, don’t need to know anything about the details of the stations you’re scanning over, because the iterator (the scan button) handles that for you when finding the next available station.

The article from Sourcemaking has several really great UML diagrams and other examples to pick apart which help elaborate on the subject even further. I highly suggest visiting their website to read more about it — they have detailed explanations on almost every type of AntiPattern and Design Pattern I’ve looked into so far.

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

Testing vs. Debugging

If you’ve been immersed in the tech industry for any amount of time, the difference between Testing and Debugging is probably pretty clear to you. The two concepts are interlocked and cannot exist without one another, even if they are very different. I recently found this article which outlines the differences between them, the purposes of each, and some tips to help with the debugging process. To start off, let’s examine a really great graphic they used to describe the differences: 

Credit to Test Automation Resources

As shown above, testing is a process usually maintained by a dedicated team (or at least a few individuals who assist the development team). The job of the tester is to ensure that the product adheres to guidelines, and that it doesn’t execute in any way that it isn’t supposed to. Tests can be automated or manual (or a mix of both), and are intended to not only find an incorrect result, but also to find specifically where the failure happens and what may result from it. Given this information, the correction of the error becomes much easier.

So then what exactly is debugging? Once the testing team observes a failure, they bring that failure to the attention of the development team. It is then again the job of the development team to run through a few instances of the error and find out what exactly is going wrong, attempt to fix that issue in a way that still adheres to the project guidelines, and then resubmit it to the testers. If the testers find an issue, it is no longer their responsibility to ensure that a solution is found. It is the development team’s job to figure out what is going wrong and implement a good solution — and that is debugging.

A lot of this is probably common knowledge in the field, however “debugging” is a term that is haphazardly tossed around (kind of like “refactoring”) that I feel its’ meaning is easily lost. Especially for those breaking into the field or students just learning about what these concepts are, having loose definitions can be confusing. Essentially, if you’re fixing a known error, you’re debugging the code. If you’re trying to find errors, you’re testing your code.

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

Choosing Testing Techniques

I recently landed upon this article, which is essentially an introduction into software testing. It gives a great overview of why different types of testing techniques are important, what different types aim to achieve, and the ins-and-outs of each.

The last section though is perhaps the most interesting, as I think it covers a topic that we haven’t discussed quite as much in our testing class (although my professor would probably beg to differ) — different reasons for choosing each type, and what may influence your choice.

In this article, the author mostly reflects on outside influences as opposed to outlining which technique to use to solve technical challenges best. I suspect this is because each technique has its pros and cons in each technical situation. Some influencing factors are:

  • The Type of System/Software App
  • Regulatory Standards
  • Customer Requirements
  • Type/Level of Risk
  • Test Objective
  • Tester’s Skill & Knowledge
  • Time and Budget
  • Development Life Cycle
  • Previous Testing Experience

By now, I’ve learned that different companies/teams will follow different testing paradigms (usually they’ll implement several of them, to be more accurate). There doesn’t seem to be an industry standard, and I’ve heard that even things like code reviews aren’t necessarily used everywhere. What I find interesting about the points listed above is that it gives some insight into the reasoning and motivation behind why teams may choose different techniques to implement for their particular scenarios.

For example, some software systems may work better with static vs dynamic testing as their primary methodology, and some (although probably most) would prefer a decent blend of each. Obviously the time and budget for the development cycle of the app will influence how rigorous the testing process is, which will influence what specific techniques teams implement as well.

Another interesting point I felt the article made was that the customer may actually have a preference for how they want their product to be tested. I think this was an interesting point because, while a customer probably wouldn’t say “I want you to use more white-box testing”, their requirements may actually require the team to modify the tests that they had intended to use in indirect ways.

I felt as though this article was an interesting overview of different ideas in software testing, from the different types of testing, to the advantages and disadvantages of each, to the reason behind choosing which one may be best. This website, Test Automation Resources, seems to have a lot of interesting and easy-to-read testing articles. I’ll likely be reading more from it in the future!

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