I found the readings from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye to be enlightening. I have liked the idea of apprenticeships and the varying stages of skill for a long time, but I have not thought of it as something to consider using in my life before. Considering my CS skills as a craft to be honed is fun and energizing. It reminds me of a game. Starting as an apprentice, learning and improving skills. Making your way to journeyman by fostering connections with others and finally becoming a master and contributing to the industry.
I found the section in chapter 2, “Exposing Your Ignorance,” to be particularly useful for me. I frequently find myself in situations where there are one or more areas of a project that I do not know adequately. It is important to remind myself that most people feel this way at times. This section describes that it is better to be transparent with your knowledge, or lack thereof, than to feign competence. Let colleagues know that you are learning what you need to learn to complete your tasks. This is a bit of a challenge for me. “The need to appear competent is ingrained into people of most industrialized societies.”(Hoover & Oshineye, 2009) Thankfully, this section has reminded me that while I have a lot to learn, it is okay if I am willing to learn.
Another section I read into was chapter 3’s “Sustainable Motivations.” This section is about holding on to motivation through the good and the bad. I empathize with Hoover in “Dave’s low pain threshold.” I too have difficulty with working jobs that I have no passion for. This is what lead me to computer science in the first place. I quite liked this line from Hoover, “While many programmers could probably find higher-paying jobs in the short term, the money that follows from doing what you love will pay off handsomely in the long run.”(Hoover & Oshineye, 2009)
The last area I focused on was chapter 5, “Perpetual Learning.” This chapter’s introduction is about how you must continuously learn new skills or improve old ones to be an accomplished developer. The first section, “Expanding Your Bandwidth,” is about expanding your knowledge through widely available resources. The book recommends following software blogs and “software luminaries.” With the internet, there are countless communities for developers to share knowledge. This section does warn not to constantly use this pattern. Developers should switch between research mode and development mode.
These readings have helped me re-frame the way I view my future career in a more interesting way. I am sure that the rest of the book will contain similarly useful information and I look forward to reading more of it.
For my CS capstone’s setup task 5, I have decided to write about my thoughts on the Principles of the Agile Manifesto linked to in the values section of the about page for LibreFoodPantry. Like the name suggests, the Agile Manifesto keeps you on your toes. Developers must be ready and able to respond to any necessary changes that may arise. The manifesto also requires regular communication. I really like how the principles of the manifesto promote living, evolving projects that adapt to situations as needed. I can see how following these principles will greatly assist in project development and achieving all the project goals. I look forward to adopting these principles and experiencing a project that abides by them.
With the semester starting, my blogs are back. CS 448, the software development capstone, requires regular posts. As such, I will be writing posts about my sprints and about readings from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye.
I’m looking forward to this course and I think I’ll get a lot out of it. This will be my first time working on a project that is not purely academic.
For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.
In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.
With CS 343’s final presentation tomorrow, this will be the last post for this project. (Unless I choose to keep playing around with it later) The work on this project has really helped me learn HTML, CSS, and TS.
The newest feature I added to my Pokedex SPA was having the background colors linked to the selected pokemon’s typing.
This took a bit a time, figuring out how to dynamically link the HTML background color to the TS pokemon data. I eventually found the use of angular’s [ngStyle] to be very useful. This method injects a JSON object with CSS properties defined in it. With it, I simply used a method in the TS to grab the pokemon’s typing and return a created JSON object with the CSS property ‘background’ with either a solid color for single typing or a gradient for dual typing.
This project was a lot of fun and I’ve learned a lot. I am tentatively looking forward to tomorrow’s presentations.
At the end of the article is a link to another article by testbytes that caught my attention, “What is TMMI (Test Maturity Model Integration) in Software Testing?” TMMI is essentially CMMI with a focus on testing. While the two are similar, the focus of TMMI makes the implementation of CMMI on software testing smoother. TMMI has the same 5 stages of CMMI with some differences.
Level 1: Initial
No test processes in place
Failing to meet deadlines
Level 2: Managed
Tests are planned and monitored
Set test designs
Level 3: Defined
All projects are tested from early stages onward
Level 4: Measured
Properly defined test strategies set in place from beginning of development process
Projects tested at every stage to ensure bugless code
Level 5: Optimization
Testing practices are structured
All processes and outcomes are measured
TMMI is an interesting model that optimizes the testing process and while it is similar to CMMI, I’d still recommend a quick read through this of this article to others.
Time to read up on mutation testing. Jasper Sprengers’ article, “Sensible mutation testing: don’t go on a killing spree,” gives a small overview of mutation testing and then explains how killing all mutants is not always necessary. The article uses an example to show how a simple class requires extensive testing to kill all mutants. The example shows how a small class of around 10 lines and a single method requires 18 test assertions to kill all mutants. This shows that it is important to consider letting some mutants live. It is not always efficient to use the extra time expanding the tests. My takeaway from this article is that mutation testing should be used to find situations where your tests are not thorough enough but not all mutants are worth the time killing. Use mutation testing with discretion.
With the semester coming to an end and the holidays, I’ve been busy and have not made as much progress as I would have liked on my SPA. I did find a better way of obtaining the evolution chains. The looped API calls were a sloppy solution, but I realized I could simply make multiple calls per input. After that I tried to find a way to visually organize the evolution families, but my nested Angular loops make it difficult to style and I haven’t found a satisfactory solution yet.
I have implemented the popup that displays the entire evolution family. The popup blocks interaction with the underlay and forces focus on the popup until dismissed.
A general issue I have ran into is the SPA updating as it fetches data. This causes the images to load at different times, affecting layout. I also have an issue where the page does not always grab the evolution family causing it to occasionally pass a null evolution chain. Searching a second time often fixes this but I am not sure of its cause.
My goals for this project now are to polish up what I have and find some new useful functions to add.
For my final project in CS 343, I have chosen to create a
Pokédex SPA that uses a public database, PokeAPI, with RESTful API. So, my
focus has been on page layout and how to search for data with limited methods
since the backend is all set.
I went through several different ways of trying to set up
the page layout, but eventually I settled on CSS grids. I found these grids to
be intuitive and easy to manipulate. It was not long until I was able to
successfully create a basic layout to work with. I used the grid-template-areas
CSS property to set a dynamically resizable layout.
I used the CSS fractional units to determine the width of
the columns (1:4) and static sizes for the height of the header and footer with
the content in-between filling the page. Now that I have a basic layout to work
with, I can focus on added functionality.
A function I have currently implemented is a search for Pokémon
by id number or name. For now, the page simply displays the name, image, and id,
but the API provides much more data that I haven’t included. The evolution tree
function is still a WIP. Connecting the evolution chains to the specified Pokémon
was a small issue. The API does not provide a way for an evolution chain to be
searched for by Pokémon. I eventually settled on creating a map, at page load, by
looping through all available chains and pairing them with their respected Pokémon.
The plan is to use the chain to render a pop-up that displays the entire evolutionary
tree. I also have a moves search that works similarly to the Pokémon search.
I am now trying to think of ways of using the pokeAPI in interesting ways. I will probably add some more search options to the menu as well as adding more options for linking relevant data. Even though my project is still fairly new, I have learned a great deal about HTML and CSS so far.
The article starts off by explaining the reasons for code
coverage. Put simply, code coverage calculates the behavior of test code and sees
which lines and branches are tested. This is useful because testers can see
where their test code is incomplete and missing test cases.
Levy then describes four types of coverage. First, statement
coverage is the amount of code statements that were used during testing. Next,
branch coverage is the number of branches caused by conditional statements that
have been tested. Function coverage test which functions have been used during
testing. And finally, line coverage tests which code lines have been used
during testing. By using all four, a tester can easily see what cases are missing
in the tests.
I found Garrett Levy’s article, “The Importance of Code
Coverage,” to be a quick read that helped me get a clearer idea of code