Author Archives: rainiery

Test Automation

Link: https://www.testim.io/blog/what-is-test-automation/

This week I’ll be writing about test automation since the class has already covered this topic; specifically with section five and homework assignment two. According to the link above, test automation is the practice of running tests automatically, managing test data, and utilizing test results to improve software quality. In order for a test to be automated, it must fulfill three criteria. First, the test must be repeatable since there’s no real sense in automating something that can only be run once. Second, a test must be determinant meaning that the result should be consistently the same given the input is also the same every time. Third, the test must be unopinionated which means that aspects that are tested shouldn’t be matters of opinion. These criteria allow automated testing to save time, money, and resources which results in software to be improved efficiently.

Personally, I’ve experienced how efficient test automation is through simply working on assignments; for this class even. I don’t quite remember what assignment I was working on, but I recall using gitlab’s built in automated testing environment. I was nearly finished with the assignment but there was one function that wasn’t working correctly. Instead of having to go to the directory, run the tests, edit the code, and push the changes to gitlab, I had the option of simply running the tests and editing the faulty code on gitlab. The option was extremely convenient and freed up a decent chunk of time, and that was just a minor assignment. I’d imagine that applying automated testing onto larger projects would save even more time.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Behavior Driven Development

https://cucumber.io/docs/bdd/

            Since my last blog post for CS-443 focused on test driven development, I thought I was appropriate to talk about behavior driven development, also known as BDD for short, for this blog post. The reason I chose to write about this topic aside the reason just mentioned is because BDD is one of the topics covered in this class according to the syllabus. The article linked above acts as a tutorial for this type of development going through the specific procedure of BDD. According to the article, behavior driven development works as a three-step iterative process. The first step is to take a small upcoming change to the system, also known as a user story, and form concrete examples of new functionalities until they’re generally agreed upon. The second step documents those examples in a way that can be automated and checked for agreement. The final step implements the behavior described in the documents written in the previous step and begins with an automated test to guide the development of the code. This process continually adds a new behavior to the system each iterative loop.

            Before I wrote this blog post, I assumed that behavior driven development would have been a new concept to me unlike test driven development. However just like TDD, BDD is actually a concept I’m familiar with on some level. As I’ve taken computer science classes in WSU, I got into the habit of writing out what specific functions a program I’m working on needs. I wouldn’t go as far as create a user story for each task I’d have to do; that’s still a fairly new concept for me. But, just like the iterative nature of behavior driven development, I would document what behaviors a program needs to function and implement them into the code with some tests to guide development. Another thing that caught my attention is the last step of BDD which utilizes tests to give direction to the development of the code. Because of this, you could say that behavior driven development implements test driven development in its own way.  I don’t have much to add to this point, I just thought It was interesting enough to point out.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Craft over Art

            This week I read the section “Craft over Art” which is found in chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section focuses on a software developer’s struggle in balancing their own personal want of making something with artistic merit and a client’s need of a product fulfills their requirements. The developer might add components that may be impressive but could also be pointless to or be an outright hindrance to the client’s wants. The developer may also want to polish up a project to a mirror sheen that deadlines would simply not allow for. And additionally, a software developer is a craftsman and not an artist. That doesn’t necessarily mean that a developer can’t produce something with beauty; a craftsman creates beauty by fulfilling a request to their utmost abilities. It just means that the client’s wants should be balanced with the software developer’s personal standards.

            The whole “Craft over Art” concept I agree with and in fact, I’ve thought of the concept on some level before through a practical point of view. Like why would I add features to software that wouldn’t benefit the user in some way? I’d just be wasting time I could use to polish up the existing components of the software. For example, If I were to work on a program that kept track of the transactions of a business and I added an option to play chess, that’d seem kind of pointless. If I really wanted to make a chess program, then I’d set that aside as a side project that I could do for fun. That doesn’t conflict with the “Craft over Art” concept since there have been plenty of craftsman who’ve worked on personal side projects in between their main commissioned projects. Even when just talking about software, I’ve heard of a fair number of programmers who’ve made little side projects like a game for example on their off time. And when working on main projects, I at the very least try to fulfill the minimum requirements so I can go back and polish it up as much as I feel the need to. But even then, there are time where the circumstances don’t allow for much polish so I just have to suck it up.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Wiki: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home

For our first sprint, we mostly focused on learning what we need in order to build the inventory system such as Vue.js, Express, and API. I worked on researching Express by finding, studying, and recording resources such as Express tutorials and syntax guides among other sources. I also got in some practice writing and running Express JavaScripts, though not as much as I’d like to since there weren’t many examples I could find online. The team also created repositories for each component of the inventory system and a wiki where each member can place links to helpful resources. The link to the wiki, which include the resources on Express that I found during the sprint, can be found in the link above. If I were to describe what worked well, I wouldn’t know what to say since this sprint focused on learning rather than building. The same also applies for what didn’t work well since components can’t work incorrectly if you don’t build any.

Overall, I feel our team did fairly well considering one of our team members was incapacitated for a good amount of the sprint. We were able to finish tasks that amounted to 13 weight out of the tasks planned that amounts to 18 weight. That’s six weight for each remaining team member with one extra. The only thing I remember the team really struggling on was getting used to working in the structure of a sprint. So, I can’t really think of a way the team can improve outside of getting use to the workflow and structure of a sprint. It’s about as specific an area I can think of for improvement and it’s a pretty general area. And when I talked to my team in our sprint retrospective, they couldn’t think of much to improve on as a team either.

However, I can think of a bit more to say if we’re talking about what to improve as an individual. For example, the entire sprint I had a general feeling that I didn’t have a clear goal in mind outside of “study Express”. This probably resulted me to not have as fast of an output as I could have and also caused me to worry more that I wasn’t doing enough work. It’s also one of the major reasons why I couldn’t practice writing and running Express JavaScripts as much as I’d like to outside of the other reason I mentioned earlier. Another area I could improve on is summarizing the outcome of each task assigned to me. I say this because I didn’t realize I was supposed to do this until the meeting near the end of the sprint. But then again, this issue kind of ties back to what to improve as a team; getting use to the workflow and structure of a sprint. So, all I can really think on what to improve on as an individual is planning on a specific goal for each sprint to give a clearer direction and remembering to summarize the outcome of each of my tasks.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Ch 1 and Ch 2-6 Introductions (Revised)

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye begins with its first chapter which centers on the concept and nature of apprenticeship. In it, the authors compare and contrast the apprenticeships of medieval Europe with the software apprenticeships of today. The following five chapters, of which I have read the introductions of each so far, focuses on individual concepts and attributes important to software apprenticeships. Chapter two focuses on “emptying the cup” or how an apprentice should set aside their existing knowledge in order to fully open themselves up to the different approaches of their colleagues and teachers. Chapter three reminds to not be too discouraged of the achievements of your peers as they’re still learning like the rest of us. Chapter four also reminds to not become too complacent or conceited and instead find ways to improve your weaknesses. Chapter five follows that up by advising that an apprentice should learn how to learn since software development is composed of two primary activities: learning and communication. Chapter six finishes off with the point that even though we live in an age where anyone can access limitless information through the internet, books still have some knowledge you can’t find online.

I mostly agree with the points made in the book save for the one in chapter six and even then, it’s mostly with the wording. The way the authors described their point made it seem that physical books have value outside of the internet in the information they have. This is despite the fairly likely chance that many of these books, such as Apprenticeship Patterns, already exist online in some form or another. I’m assuming that the authors only had sources exclusive to the internet like blogposts and websites in mind when comparing them to books. Taking that point of view in mind, I can see where they’re coming from especially with how easy it is to find inaccurate or outright wrong information. I’d go even farther than the authors though and suggest that people check the validity of their sources since physical sources can lie like online sources, the only difference is that it’s easier to lie with the latter.

Outside of the point in chapter six, many of the topics and attitudes covered I feel are not only important for software apprenticeship but also for any skill that an individual decides to devote themselves to. Optimizing one’s learning skills, constantly learning, constantly improving one’s weaknesses, not getting discouraged by the accomplishments of one’s peers, and opening oneself to other viewpoints are all extremely important to cultivating a craft. That’s because these skills all contribute to developing oneself into a well-rounded person, which in turn allows for an individual to learn and improve more quickly.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Test Driven Development

Link: https://www.thoughtworks.com/insights/blog/test-driven-development-best-thing-has-happened-software-design

            The article linked above talks about test driven development, also referred to as TDD, and how it effects software development. I specifically chose this article since it centers around a topic that we’re supposed to cover in this class. The author explains three key reasons why this type of development is used. The first reason is that test driven development is an iterative cycle comprising of the three steps of failing tests, passing tests, and refactoring code. The “failing tests” phase establishes a baseline to work with, the “passing tests” phase develops that baseline into code that meets minimum requirements, and the “refactoring code” phase further develops that code. The second reason is that TDD forces a developer to question their code on multiple levels. For example, a developer would be pushed to question how a specific component works or what they expect from their code. The last reason is that test driven development allows for faster feedback on software design as poor design is often the reason why testing features fail. The article goes on further to explain how to apply TDD on code that is impossible to test.

            Reading this article, I found myself agreeing with a lot of what the author had to say. What stuck out to me in particular was how TDD forces a developer to question their code. It got me thinking about the habit I developed writing code where I began to write down and plan the general structure of a whatever project I worked on. The way that test driven development pushes someone to understand their code in what component does what reminds me of my habit but on a smaller scale since a developer would usually test a single feature at a time. And this type of development is really a new concept for me since I’ve used that iterative cycle that the author mentioned without even realizing it. The only major difference is that is that I typically didn’t use a test class which is what I’d assume is a given in the context of the article. I usually manually tested my projects which obviously hurt my productivity and deprived me of the benefit of faster feedback in TDD.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Ch 1 and Ch 2-6 Introductions

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye begins with its first chapter which centers on the concept and nature of apprenticeship. In it, the authors compare and contrast the apprenticeships of medieval Europe with the software apprenticeships of today. The following five chapters, of which I have read the introductions of each so far, focuses on individual concepts and attributes important to software apprenticeships. Chapter two focuses on “emptying the cup” or how an apprentice should set aside their existing knowledge in order to fully open themselves up to the different approaches of their colleagues and teachers. Chapter three reminds to not be too discouraged of the achievements of your peers as they’re still learning like the rest of us. Chapter four also reminds to not become too complacent or conceited and instead find ways to improve your weaknesses. Chapter five follows that up by advising that an apprentice should learn how to learn since software development is composed of two primary activities: learning and communication. Chapter six finishes off with the point that even though we live in an age where anyone can access limitless information through the internet, books still have some knowledge you can’t find online.

I mostly agree with the points made in the book save for the one in chapter six and even then, it’s mostly with the wording. The way the authors described their point made it seem that physical books have value outside of the internet in the information they have. This is despite the fairly likely chance that many of these books, such as Apprenticeship Patterns, already exist online in some form or another. I’m assuming that the authors only had sources exclusive to the internet like blogposts and websites in mind when comparing them to books. Outside of that, many of the topics and attitudes covered I feel are not only important for software apprenticeship but also for any skill that an individual decides to devote themselves to. Optimizing one’s learning skills, constantly learning, constantly improving one’s weaknesses, not getting discouraged by the accomplishments of one’s peers, and opening oneself to other viewpoints are all extremely important to cultivating a craft.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Code Smells

https://blog.codinghorror.com/code-smells/

This blog post will center on code smells which was a topic covered in class fairly early on. The reason why I’m going back to it is mainly to refamiliarize myself with the subject since it wasn’t a major topic in class. Code smells are defined by the blog post linked above as general warning signs in code, hence the name. There are different types of code smells that signify different coding problems. For example, long comments, long methods, overly large classes, duplicate code, dead code, inconsistent naming, uncommunicative naming, et cetera. Keep in mind that these issues won’t necessarily stop a program from running, rather they negatively effect on the performance and design levels. Also, all of these different types of code smells share the common trait of not quite looking right when looking at a larger scale. So at first glance the code might seem fine, but given a closer look the flaws whether it be dead code, inconsistent naming, or whatever become readily apparent.

A code smell isn’t something concrete like a detailed recipe, it’s more abstract than that. It similar to a suggestion or a tip and can lead to improving code both on a functional level and a design level. Take for example, noticing the code smells of long comments and dead code which suggest removing the useless code and either simplifying or outright deleting the comments. This will make the code more readable which also improves it on a design level. On the other hand, noticing the code smells of duplicate code and long methods and correcting each issue accordingly will improve the code on a performance level top of the possible design improvements. All of the types of code smells that I listed earlier still hold true but they act as more of a general guideline. There are some scenarios in which some smell types blend together such as long methods and overly large classes to name one. Detecting code smells isn’t going to always be the same in that what someone is looking for will differ every time and the outcome will also differ every time. This process is kind of like trying to find freshly spoiled food; sometimes it looks fine and sometimes you won’t know what exactly you’re looking for. But what you do know is that something smells off and you probably don’t want to risk the chance of getting sick.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

DRY (Don’t Repeat Yourself)

https://thevaluable.dev/dry-principle-cost-benefit-example/

I’ve chosen to talk about a very simple design principle this week called “Don’t Repeat Yourself”, DRY for short. It’s a topic that is covered in this class according to the syllabus and I chose it since its similar to another topic I covered YAGNI in that they’re easy to understand design principles. The meaning is quite self-explanatory, don’t repeat code since if you need to change the behavior of a certain project, you’d have to rewrite numerous lines of code if DRY wasn’t applied. However, applying this principle to everything isn’t efficient either. Trying to apply DRY everywhere causes unnecessary coupling and complexity which also leads to more difficulty changing behavior. According to the link above, using DRY means emphasizes knowledge above all else. What it means by that is that when designing and constructing software, one should have the knowledge of when to apply DRY and when not to for the sake of the readability and efficiency of the code.

In that context, DRY reminds me of the importance of resources in a computer when running something. If you want something run faster, you’ll have to sacrifice more memory. And when you want something to have more memory, you’ll have to sacrifice more speed. Both are valid choices; it really depends on the needs of the software and the user. Say for example, I want to create a program that lists all numbers from one to 100 which I do by writing out a thousand lines of code in which each prints a number. However, if I implement DRY, then I could create an integer variable r and a loop which prints the value of that variable and increments it by one until r equals 100. But the case where I want to alter the behavior to list every odd number between one and 100 is where thing get a bit interesting. In the DRYless scenario, I can simply delete the lines of code that print even numbers. Yet in the scenario with DRY, I’d have to add a condition that skips printing variable r for that iteration of the loop. You have to sacrifice complexity for readability and vice versa. Though the choice is ultimately up to what works best in the current situation. Like in my example, the added complexity from DRY doesn’t really harm the readability, in fact it improves it in some ways, at least in my opinion.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.