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.
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.
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.
While there are few people who would would argue that testing is easy, it also should not be prohibitively difficult. The difficult part in testing software should be in deciding what to test, not how to test it. In a post from late September 2017, Michael Bolton describes how important testability is in the creation of a stable project with less risk of bugs at the time of delivery. If releasing a project untested or with insufficient depth of testing sounds risky to you, you are in good company. Making testing easier, known as increasing testability, allows for more thorough testing and (hopefully) a more polished, bug-free finished product.
Bolton describes testability in terms of visibility and controllability. The examples that he gives for visibility are log files and continuous monitoring. For controllability, Bolton cites application programming interfaces or APIs as the most common method for the easy manipulation of the product. An important takeaway from the post is that while it is certainly helpful to the tester if a product has things like log files and an API, this is not all that testability encompasses. Bolton presents the idea of testability as a set of relationships between multiple elements in the design process including the product, the tester, the development team, and the development environment. The overall testability of a product is a result of the complex interactions between all of these people and things involved.
The first category that Bolton mentions is epistemic testability. It is impossible for a tester to know all of the bugs in the code before performing any testing. If this were the case, there would be no need for software testers at all. The act of testing explores what Bolton calls a “risk gap,” or the areas in the project that the tester is uncertain about or unfamiliar with. Next, Bolton considers value-related testability, which refers to knowledge of what the intended user of a program is looking to gain. Understanding what is valuable to others allows a tester to focus his or her efforts where it will have the most significant impact. Intrinsic testability refers to the product’s ability to be easily understood by the tester. If a program’s behavior is easy to follow and its state is transparent to the tester, he or she will have a far easier time properly testing it. Since most projects are assigned to teams of people in many different positions, with different tools and knowledge, access to these people and resources is essential for project-related testability. Finally, subjective testability refers to the skills of the tester or testing teams matches the requirements of the project.
Bolton’s more literary definitions of testing were a welcome change from the testing material that I’ve read online and in text. Bolton seems to focus more on the people and the environment that the testing is being conducted in rather than on what specific tests are used. I think that as a student, many of the points that he makes are important to carry with me into any potential professional positions. Evaluating the testability of products through Bolton’s methods will allow me to better manage risk and deliver products with fewer bugs.
What Konrad Gadzinowski describes in the opening paragraphs of his post on “Creating Truly Modular Code with No Dependencies,” the “emotional rollercoaster” of developing software, is something that I’m sure anyone who has ever written a program has experienced. I certainly encounter this each time that I’m writing code for a project, whether it is an academic project or a professional one. Eager to begin a project, I often dive in and begin completing the simpler parts first. During this time, it seems that progress moves very quickly. After all of these easy, simple pieces are done, however, progress seems to slow or stall. As the requirements become more complex, I often find myself going back to previous code and rewriting things so that they integrate more seamlessly with the new element that I am adding. This problem is what Gadzinowski describes as the “big ball of mud.” Gadzinowski provides Apache Hadoop as an example of a program with the ball of mud interdependencies that slows further development and makes tracing the source of bugs more difficult. In the image below, each class is represented as a point on the outside of the circle, and the lines between the points are representative of a dependency.
(Image source: https://www.toptal.com/software/creating-modular-code-with-no-dependencies)
With so many interdependent classes, I imagine that untangling the web to trace bugs in Apache Hadoop would be a nightmarish task. Gadzinowski offers a solution to the problem of the ball of mud, however, that seems like sound advice. His suggestion is to use the element design pattern when developing software. This modular pattern aims to create reusable pieces of code that are independent of other classes. This is done through the use of element classes and element listener interfaces. In this way, all of the required dependencies for an element are encapsulated within that element. Outside classes that wish to utilize the element are not concerned with the underlying design of the element, they interact with the element’s listener. Gadzinowski presents this as a way to increase the flexibility of the element, allowing it to, for example, output to any number of different external environments through an identical listener call.
While I was immediately willing to listen to the post’s advice after it described a miserable situation that I’ve encountered countless times, I think that reading Gadzinowski’s explanations and examples of the element design pattern has certainly made me a believer. I think that what makes him so credible is his willingness to acknowledge the value in initially jumping into design without worrying too much about the big ball of mud that you may be creating. While this may not be the solution for a final release, it can get the ball rolling and allow for the element pattern to make your code more reusable and stable for production releases later on. I will keep Gadzinowski’s advice in mind the next time that I begin to worry that I have too many interdependent classes to make my classes reusable or easily maintainable.