Category Archives: Computer Science

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Looking Back on Sprint 1

The first sprint contained a lot of small tasks for setting up the environment and getting familiar with the ng2-amrs system. While some of these tasks were simple, others that originally seemed simple became difficult and took more time than the team and I originally expected. Overall, I feel that the team worked well together and that we were able to complete the bulk of the story items for this sprint. There were a few areas where I think we could improve for the next sprint, and these topics were discussed during our retrospective meeting in class.

One of the first tasks that was completed for the sprint was to Create a GitHub organization for your team. Dominique assigned herself to this task, and created the organization. She invited all of the other team members to the organization during a class work day and ensured that we were all able to access the organization.

Another task that was completed quickly due to its relative simplicity was the Choose a label color for your team. Matt assigned himself to this task and changed the label color on the appropriate card on the Class Scrum Board.

I assigned myself to the Fork ‘ng2-amrs’ from CS-Worcester-CS-448-SP-2018 to your organization task. I was able to complete this task only because Dominique had already created an organization for our team and gave me the necessary permissions.

The Read README.md and Read CONTRIBUTING.md tasks were relatively simple, and all members of the team completed these tasks early in the sprint.

The Decide how you want to manage your team’s GitHub repository was completed as a class rather than as a team, so little effort was required on the part of our team.

Everyone on the team was able to complete the Clone ng2-amrs to your computer task, as Dominique gave all of the members of the team access to the organization’s fork of the project.

Some of the tasks that gave the team a little more difficulty were the Learn how tests work for Angular, Build ng2-amrs on your computer, and Connect your ng2-amrs to the server. While the team members that had the project built and connected to the server attempted to help other team members get up and running, there were a few different and unique problems that gave people trouble in building and connecting ng2-amrs to the server.

Matt was able to fix one of the most severe of these problems, namely that of the ladda module complaining about missing files. Matt shared his solution with the team and the rest of the class, and was able to help many people in successfully building the project.

We were initially waiting on the Ampath Informatics team to provide us with a link to a server that we could connect to. When this link was provided midway through the sprint, we chose to add the task to our sprint backlog as some members of the team were ready to accept more tasks. For this reason, it was not a concern that the entire team was unable to complete this task.

The final task that was not completed by everyone in the team was to learn about tests in Angular. Once again, this task was not of critical concern because we likely won’t be using testing heavily early on in the development process.

I think that the team worked well together, and that members supported one another throughout the sprint. One thing that we may be able to improve upon is communicating when we are having difficulty so that others are able to offer assistance. Or, on the flip side, asking and offering assistance when another member of the team seems to be struggling. I am looking forward to working with my team and getting into some of the more technical parts of the Ampath project.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Constructing a Curriculum

After recently completing a difficult, humbling and valuable phone interview for a position that I thought I was well qualified for, I decided to make a renewed effort in educating myself outside of the classroom. The discussion helped me to realize the areas where my skill set was lacking, and where to focus my educational efforts. While some classes offer information of a specific, desirable topic, I often find that I cannot find the exact topic that I want to learn as part of a course. I perform a quick search on Amazon, which reveals multiple books on the topic, and I quickly order one according to user reviews and ratings. This is the process that has occured time and time again, leading to a bookshelf full of books on varying programming topics. For many of these books, I have only just begun reading (or I got halfway through and was distracted by something else), and never fully gained an understanding of the topic that I set out to learn.

For these reasons, I found the problem statement of the Reading List pattern in Hoover and Oshineye’s Apprenticeship Patterns to be especially applicable to my current situation. The problem statement says, “The number of books you need to read is increasing faster than you can read them.” While I am constantly increasing my understanding of certain topics, new and improved methods are constantly being developed. Keeping up with the rapid pace at which software development changes is difficult, but following the advice of Hoover and Oshineye will undoubtedly give me a leg up on the competition. I like that the Reading List that they propose is essentially a priority queue, with the books that are most important at the top of the list and the ones that may not be as important towards the bottom.

I also appreciated the advice that Hoover and Oshineye gave when they suggested looking at the books that are referenced in those that you do read. When you see a pattern of many books referencing one in particular, be sure to add that one to your reading list, as it may contain valuable information not covered in the material referencing it. Looking at references for which books to add to a reading list is also great advice if the style or organization of one book is not working for you and you are looking for the same or similar information to be presented differently.

It was reassuring to me to know that I was not alone in feeling overwhelmed by the amount of information that I need to attempt to gain an understanding of. The strategies in the Reading List pattern are sure to help me in organizing and creating a plan for learning new software development techniques and improving my skill set. Setting goals and prioritizing what I read will allow me to use books as a tool rather than simply being overwhelmed by what I don’t yet know.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Customizing a WordPress Theme

With literally thousands of themes in existence, there is sure to be a WordPress theme out there that fits the needs of you or your business. Why spend your own time designing a theme when some generous person has already done the work for you – and posted it  online for you to access completely free of charge? While some themes may no longer be updated or maintained, many receive regular security patches and feature enhancements to ensure your site is not at risk.

The main considerations when choosing a theme for the Massachusetts HOSA website were a banner image and feature area to mirror the appearance of Georgia’s HOSA website (http://georgiahosa.org/). The theme I found that most closely matched this desired appearance was the Trusted theme by uxl (https://wordpress.org/themes/trusted/). The theme was highly rated, installed and active on more than 5,000 WordPress installations, and recently updated to ensure compatibility and security.

No theme is perfect, however. The first changes I needed to make were to the color scheme of the theme. I’ve work with CSS before, but found that Google Chrome’s Developer Tools (https://developer.chrome.com/devtools) made it much easier to isolate a specific CSS attribute or tag rather than digging through the more than 5000 lines of code. I used the HOSA Style Guide to make sure that the colors and images that I was using in development matched the requirements of the organization. This was a new concept for me, but I found it extremely helpful that the organization published all of the approved brand colors, fonts, and logo requirements in a single resource.

The website is now up and running on a development server, and the theme has been modified to match the appearance of the HOSA brand. The next task that I will be working on is implementing a slider in place of the banner image on the homepage that displays conference information with links to register for a conference.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Mastery as a Lifelong Endeavor

While I think that it is relatively straightforward to begin the software development journey, it is another thing entirely to become a master. Mastery is nearly impossible to measure and may require a lifetime of dedication to the craft to achieve. While these facts may be almost universally applied to any craft, I think that when applied to software development in particular they are especially telling. In Hoover and Oshineye’s Apprenticeship Patterns, they discuss a pattern termed The Long Road. It is this Long Road that is representative of the lifelong journey that is mastering the craft of developing software.

Hoover and Oshineye urge that the true value of mastery lies not in making more money or gaining status and power, but in, “comprehend[ing] and appreciat[ing] the deeper truths of software development.” This focus on the craft rather than on typical indicators of success such as promotions or high salaries is what sets truly great software craftsmen apart from the mediocre. I found it both inspiring and a bit comedic that Hoover and Oshineye included the parts about surpassing legendary software craftsmen such as Donald Knuth or Linus Torvalds. When you think about it, however, such feats do not seem entirely unrealistic considering that anyone truly hoping to become a master software craftsman will likely dedicate over forty years to that end.

I feel that this pattern would likely be offensive to developers who chose computer programming simply because of the abundance of jobs or relatively high starting salaries, not because of a genuine appreciation of the craft. These software developer posers would have no desire to become masters of the craft, and would jump ship at the first opportunity for a promotion or raise. This is also where the lack of knowledge transfer between generations of developers mentioned in the pattern’s introduction originates. If developers are waiting for any opportunity to move on, then the void that they leave is constantly being filled with new developers, leaving few veterans to show them the ropes.

I can certainly appreciate why a promotion to project lead or some executive position would be a tempting opportunity for career advancement. These roles, however, often require giving up the very things that make software development such an exciting and rewarding job to begin with. The feelings of pride and excitement after finally figuring out a difficult piece of a program or passing every test case is something that software craftsmen on their journeys to becoming masters will continually experience.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Choosing a CMS

When choosing a content management system (CMS) to begin developing a website for myself or someone else, there are a few important considerations that must be made:

1. Who will be maintaining the website after development is finished?

I think that possibly the most important consideration that needs to be made when choosing a CMS for website development is who will be the one responsible for maintaining and updating the website once development is complete. Nothing is more frustrating than going on a beautifully designed website only to be faced with outdated and/or broken content. It does not matter how beautiful or complex the original design is if there is a need for dynamically updated content and nobody around who possesses the skill set required to make the changes or update the content.

2. What type of website is being built?

Another important consideration is the type of content that the website will serve. While many CMSs have support for multiple types of websites such as blogs, ecommerce stores, and static content sites, one may be better suited to a particular task than another. Choosing the right CMS for the job can make both the developer’s life easier and also create a more efficient, polished finished product.

3. How is the website being deployed?

In addition to considering how the website will be hosted and deployed, it is important to consider what the expected volume of traffic will be when choosing a CMS. If the expected volume is extremely high, then perhaps a cloud-based SaaS CMS is the best option. A cloud-based solution would allow for much easier load distribution and balancing and may be automatically handled by the platform itself. If volume is expected to be relatively light or the site is to be hosted locally, considerations must be made for the hardware/software support of the systems on which the site will be running.

4. Does the website need to integrate with existing infrastructure?

In addition to hardware/software considerations for deployment, another factor to think about is what types of IT infrastructure is already in place that will need to be integrated into the website. If there are already databases in existence, ensuring that the website will be able to integrate with them will save significant time and cost over having to migrate data between systems.

5. What kind of support is available for the CMS?

Whether it is for the developer, or for the client after development has been completed, what types of support and how easily accessible it is can be an important factor in deciding on a CMS. Are security patches regularly released so that the site will not be vulnerable? Is there a community that releases plugins, themes or other types of time-saving customizations for the CMS?

In deciding on which CMS to use for the development of the Massachusetts HOSA website, I considered these five points and decided on WordPress. My experience with WordPress as a CMS has been very positive, and I feel that choosing such a user-friendly CMS will allow for straightforward updating and maintaining of the website for many years to come. WordPress is flexible, powerful, and will be easy to scale should the needs of the organization change in the future.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Staying Open to New Ideas

After a few years of using mainly one language to accomplish programming assignments, I will certainly admit to becoming complacent with Java. If I was asked to write pseudocode, my mind immediately begins object orientation and even begins running through some of the Java syntax. While this can be helpful, as I feel my ability to think in Java means that I may be well on my way to becoming bilingual, there are also many drawbacks to complacency.

Applying this Java-like thinking to problems in other languages or under other frameworks is where problems may arise. Rather than being open to discovering and developing new skills, the existing knowledge becomes a hindrance to learning. Attempting to apply existing knowledge to problems of a different sort or in a different language may slow progress, and make learning even more difficult and frustrating.

The solution offered by Hoover and Oshineye in Apprenticeship Patterns is to put on The White Belt and allow oneself to be ignorant by putting aside accumulated knowledge and experience, leaving no choice but to learn the way through trial, error and reflection. Treating new learning opportunities in this way allows for more deeper understanding and helps to create more smooth communications with members of the existing community.

I recently decided to expand my software development experience by studying JavaScript. While I feel confident that I have stumbled over the most difficult learning hurdles at this point, I wish that I had read this apprenticeship pattern before my attempt. I feel that I had a difficult time initially overcoming how fundamentally different JavaScript is, and often found myself grasping for the comfort of Java. It wasn’t until I took a step back from what I was doing that I realized I needed to open my mind to fully understand and appreciate JavaScript for what it was rather than how it was different from or similar to Java. The example that Apprenticeship Patterns uses, a lottery program written in three languages (Java, Io and J) is especially telling of this fact.

While I would have previously described myself as open minded and always willing to learn, I believe that The White Belt pattern has helped me see a more valuable way to approach new learning. I will certainly be using the ideas of Hoover and Oshineye the next time I attempt to learn a new programming paradigm.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Software Apprenticeship: Becoming More Than Proficient

Reading the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye made me feel both anxious and optimistic about entering the software development field upon graduating this spring. As the authors very clearly point out, there is now an overabundance of developers but a scarcity of good developers in the workforce. In an effort to become one of the good developers, I have in the past kept up with many of the so-called masters referenced in Apprenticeship Patterns including Uncle Bob and Martin Fowler. I hope that by following the advice of Hoover and Oshineye I am able to make begin a career where I will make a difference as a software developer, and that someday I am able to pass along my experiences to future generations in an effort to continue the advancement of the industry.

What I found perhaps most interesting and important about the first chapter were the disclaimers that the authors gave. Statements like, “These tools are not algorithms that guarantee the same results on every execution,” really helped to reinforce the idea that there is no magic recipe for success. The truth that Hoover and Oshineye are trying to convey to new developers is that being successful is not easy. The path to becoming a great developer has many hurdles, it takes more than simply following an apprenticeship pattern or any other set of instructions. What the apprenticeship patterns hope to offer, rather, is assistance in beginning a software development career and advice on how to become outstanding rather than simply proficient.

As a new developer trying to make it, motivation and drive are key. Perhaps most important, however, is a willingness to learn. Not being afraid to make mistakes, and being able to turn mistakes into learning experiences is crucial to personal and professional growth. It is also important to share your experiences with others, rather than hoarding them. Just as apprentices learn from journeymen, so too can one apprentice learn from another. This collaborative scheme was especially interesting to me. Far too often, especially as a student, I feel that individuals are selfish about sharing information with one another. While this is certainly understandable in situations where only one party benefits, collaboration can be an extremely powerful tool. I feel lucky to be entering a field that places such a high value on teamwork and collaborative success. Working together is what most often leads to the most profound or impactful discoveries and advancements.

Although the first chapter of Apprenticeship Patterns did not go into much detail on any particular subject, I am looking forward to discovering how to improve my chances of a beginning a successful and rewarding career as a software developer.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Welcome to my blog

I will be using this blog in the Spring 2018 semester for CS-448 and an independent study project.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Writing Great Test Cases and Becoming a Great Software Tester

I completely agree with Kyle McMeekin when he states in a blog post titled “5 Manual Test Case Writing Hacks,” from April 11th, 2016, that it should come as no surprise that great software testers should have an eye for detail. What may not be as obvious, however, is that great software testers should be able to write great and effective test cases. McMeekin goes on to observe that writing effective test cases requires both talent and experience. In an attempt to begin my journey to become a great software tester, I decided that I should pay close attention to the advice offered by experienced testers as they reflect on the skills they have gained from their time in the industry. Hopefully, by following the tips of more experienced testers, I too will someday be able to contribute to highly valuable test cases the improve productivity and help to create high quality software.

The first step to writing great test cases is knowing what components make up the test case. While many of the components were obvious to me, there were others that I had not thought of. The test steps, for example, are important because the person performing the test may not be the same person who wrote the test. Knowing how the test should be performed is important to obtaining a valuable result from the test.

What I found most valuable about McMeekin’s post, however, were his tips on how to “write better test cases that will lead to better quality software for your company.” His first piece of advice is to keep test cases simple. They should be in simple language, and follow the company’s template. Although not specifically mentioned in this guide, I remember reading that if a test case seems to become too complex, you should begin considering breaking it up into smaller pieces. Second, McMeekin recommends making test cases reusable. Taking into consideration that your test cases could be adapted to other scenarios or reused in another application should help to develop test cases that are reusable. Third, McMeekin suggests placing yourself in the shoes of the tester or developer rather than the test-case writer, and being your own critic. Considering what parts of your test-case may be ambiguous or frustrating for others using them will often help to create better tests. This goes hand in hand with the fourth recommendation, which is to think about the end user. Understanding the expectations and desires of the end user will certainly help to create test cases that lead to better, more successful software. The last recommendation that McMeekin gives is to stay organized. This suggestion could apply just about anywhere, but with hundreds or possibly even thousands of potential test cases, staying organized is certainly essential to being a great tester.

Although I am sure there is a great deal more to consider in my quest to one day become a great software tester, I think that keeping these things in mind will certainly improve the quality of the test cases that I write. In the rapidly advancing field of computer science, I don’t feel that I will ever stop learning new and improved ways of doing things or further developing my skills.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.