Your Interfaces Are Your Responsibility

This week, I looked through the Google Testing Blog and spotted a great post regarding your job as a programmer in writing good interfaces. I thought it touched on some great points and used some great examples, so here I am, writing about it. The blog post is part of a series of posts from Google called “Code Health”, which essentially outlines some of their standards for code quality.

“Code Health: Make Interfaces Hard to Misuse” uses an example of an empty Vector which has a “num_slots” slots available for use. Marek Kiszkis, the author, outlines two ways to write this class. The first way relies on the person who implements it to manage the expansion of the number of slots of the vector. They must check the slots remaining before adding into it to ensure that it has the room for a new item. The second way the Vector class is written has the Vector automatically expanding by a certain number of slots as items are added in. The implementer has very little control over the function of the Vector, however the Vector’s lack of flexibility can be a desirable outcome, as misuse much more difficult. The author provided a few different examples beyond this of easy-to-misuse Interfaces, such as requiring the caller to run initialization functions, perform cleanup, etc.

The article is finished off with a reminder that, while making interfaces this way is a good thing, you still need to be selective with this methodology. Sometimes writing an interface in a “overly-defensive” way will result in needlessly complex code, where implementation is more difficult to execute than necessary. The documentation is equally as important as the structure of the code, and keeping that in mind will help you write usable, stable, and effective code for others to utilize.

I found this blog post surprisingly relevant to my current course-load. In both this class (CS-443) and the Software Architecture & Design class (CS-343), will be implementing interfaces much more frequently than we have in previous courses. Having a better understanding of safe and effective ways to writing them will be extremely useful in the long run.

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

Blog 3 CS 443

My blog this week is about an article which talks about things that could possibly go wrong while discussing about testing and how someone could improve their testing. In the article, the author points out several flaws which many testers tend to make. Some of these mistakes testers make include things such as caring about how many tests there are instead of the quality of the tests, how many people have a hard time adapting to creating new tests as a test case evolves and when people believe there is only one way to test something.

I thought the author had a lot of good reasoning behind his thoughts on testers, which can be applied to more than just testers too. This applies especially to his first point which pertains to when people care more about the volume of test cases they have written versus the quality of those test cases. The author’s point, which I agree with, is that it does not matter how many test cases you write, if they do nothing to actually test the code, than they are completely useless. This thought also makes me want to pay more attention to the test’s that I write to make sure that they are effective and proper to what I am actually testing for. Another comment the author made which makes me want to look more at the way that I move through testing is that many people have a hard time adapting their tests as the strategy of said tests changes. Being able to change and adapt your tests as the test strategy changes shows a true understanding of the purpose of the testing that is happening. Finally the author brings up the point that people often have the thought that if they are testing something one way, they have tested that thing fully. However, if they run the same test with a different data set they could discover some new bug that you would not have seen before. This is another good example by the author of pointing out a flaw that many people can and tend to make, and one that I plan to focus more on myself.

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

Blog 3 CS 343

My blog this week will be based on this article that argues that a certain form of testing, “lean testing”, is far more helpful than something like normal unit testing and test driven development. The author goes on to explain their way of testing, “lean testing”, is essentially focusing on different kinds of tests then unit tests which will be more beneficial with the finite amount of time you may have to get certain projects done. With unit testing, you tend to test bounds of the program that will affect very few users and it is better to focus the tests on more real world scenarios that a user might encounter.

I feel the author raises a good point in this testing, to focus tests more on what a user of a program will likely run into rather then on the bounds of the program which very few to no users will encounter. With that though, I do still feel it is important to at least include some tests to make sure the bounds of a program are working and will notify the user of such. Another thing that the author included was the three dimensions they think best help to follow in testing and that is speed, cost, and the most important one; confidence. This quote from the article which I feel reflects what the author is trying to make clear in the article is from Kent C. Dodds, who said “The more your tests resemble the way your software is used, the more confidence they can give you”. The author also provides another reasoning for this testing of what the user is more likely to encounter when using the program, and that is that testing those cases tend to cover more of the code then something such as boundary testing. One final point that the author brings up that I think helps reinforce their way of “lean testing”, is that unit test code is often not resilient to code changes. While some of the test code may be reusable, most of it is often not.

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

Designing the code is more important than you thought

Personally, I always think that the design phase of a program is very important and it should be done almost immediately after I started setting up my git project. Like all other new developers, at first, when me and my cousin were working on an Android project, we thought it would be just a waste of time. Surely after a month, it started to really fall apart as we have all sort of problems like our implementations does not work well together with a lot of lengthy methods that is definitely not necessary to be that complex, and we even used some dependencies that are obsoleted just to make another piece of code compatible with the situation. We learned our lesson and from then, we developed a habit to jot down some idea and implementation to at least let each other and ourselves how we would carry out the project. I actually found this article months ago and I think it’s already pretty neat, so I decided to write my blog this week based on it.

For a start, this article is written by Marcus Biel and it mostly talks about what he called “Clean code”, which is basically the idea to have your code be precise and as close to perfect as possible, even though it is a small project. I really like the part where he says “If you have more code than you need, it shouldn’t be there. There shouldn’t be anything superfluous, and I go so far as to say that there shouldn’t even be superfluous whitespace. You want your code to be as efficient, readable, and maintainable as possible, and instead of only solving the problem.” This is probably what everyone should expect to achieve after finishing their “first draft” of the program.

Some would ask why is it so important to spend a lot of time on this phase. He gave two simple cases that are really relatable to programming. Imagine living in a house that was built without any blueprint and when it falls apart, you would not even know where to start to fix it and eventually, the roof caves in. For instance, when you have a shopping cart, of which function is to put things that you would buy into but people keep throwing trash into it until it spills out and you don’t know which one to put on the checkout counter. In these cases that he gave, it was really clear that there are no boundaries or rules to maintain your object and prevent it from long-term problems. The lazier you are at first, the more efforts you have to put in in order to have it up and running. Even if most of us are not perfectionists, this problem can’t be ignored as our projects would get more complicated the more we develop it.

Now that we know that it is critical, we can look at a few ways to accomplish clean code. The simplest thing that you have to do is to not think it as a coding project, think of it as a design and planning process. Let’s pretend that you are building a house. A strong foundation is what we really need and that can be seen from the coding aspect as file structure, classes, and methods without any bodies. When you have a solid foundation, it would cost fewer resources to maintain as it is already hard to fall apart and even if you want to expand, it is much easier to base on the old foundation, rather than having to build another one.

Not only a solid foundation that we need, but we also need the coherence, or should I say it is easy and makes sense to everyone who read it. The author of this article makes a point that we should follow the idea of “ubiquitous language”, which is to have your variable names, class names, and package names to make sense to whoever is reading your code. This design is called Domain-driven design. In addition to this, I also think that it is important to follow the naming convention, use detail unique name for variables and practice proper indentation so that myself and the one I work with can see the structure and what words mean without having to scroll up and down a lot.

Without any further reading, I think these pieces of information that I have given are quite enough to convince you to think and start to develop the habit to have a design phase before carrying out the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

DRY over DAMP?

Ever since I picked up my first Java book and read through it, one thing always stuck in my mind when it came to writing any program and that is to not repeat yourself when you don’t have to. Leonardo Brito wrote an interesting piece, “Don’t obsess over code DRYness”, and he gave a few good points on why we shouldn’t try to make our code as complex as we can. He starts off by saying that we, as humans, are good at pattern recognition but sometimes we over-do it. He uses the example codes below:
____________________________________________________________________________
# Example 1
class Car
include Checkups

def maintenance_10k
check_break_fluid
check_battery_terminals
check_engine_oil
end

def maintenance_30k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
end

def maintenance_50k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
check_gearbox
end
end
____________________________________________________________________________
# Example 2
class Car
include Checkups

def maintenance_10k
basic_maintenance
end

def maintenance_30k
basic_maintenance
check_spare_wheel
end

def maintenance_50k
basic_maintenance
check_spare_wheel
check_gearbox
end

private

def basic_maintenance
check_break_fluid
check_battery_terminals
check_engine_oil
end
end
____________________________________________________________________________
After DRYing the code we see that it produces a new method called basic_maintenance while the original maintenance method conveys exactly what the method is expected to do. He then added a change such that we no longer need to check the break fluid on the 10 thousand miles checkup, so now we must remove the method check_break_fluid from basic maintenance and only add it to the upper maintenance methods. What he was trying to illustrate is that although one set of code was easier to read and follow, a simple change could have us altering out code in more ways than we’d like.

Brito talks about the trade off between some duplication over the wrong abstraction because overly DRYing your code could result in more confusion than simply repeating SOME code which is where he introduced another concept: DAMP – descriptive and meaningful phrases. The purpose of these two terminologies is to guide is to write better code and not going to any extremes.

I found that the concept of over DRYing your code interesting because I never thought about it that way and that there was a such thing. I’ve heard of DRY but never DAMP so I found that amusing how they’re opposite from each other. Looking back at my projects I feel as though I stand somewhere in between both concepts. I try to not over-do simplifying yet at the same time I make sure I apply DRY when necessary. I agree with what the author said about repeating sometimes to make it easier on yourself in the end.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Reasons to test your code

For every person, there are things they like and things they don’t. One such thing for me is testing my code. Is it laziness? Is it the fact that I’m awful at it? I’m not particularly sure why but in “5 Reasons why you should test your code” by Frank van Wijk, he talks about five important reasons on why we should always test our code.

Reason number one: Regression testing. The example he gives is that your code is fully functional and working but then one feature breaks in your code and now you’re left staring blankly at your code. Given that if you have 100% code coverage, you know there is a fully functional test suite. For example, you run the test suite, then you modify some parts of your code and then you run the test suite again. Now if tests are failing after the modification, there is an assertion done for this case. This is good because after every modification or as your program becomes more dense you could repeat this process each time to get rid of newly formed bugs.

Reason number two: Improve the implementation via new insights. After you finish your writing your program the first thing you might want to do is walk away grab a beer and reward yourself but before doing so you should write start writing tests for your methods. If you find that it is difficult to write tests for your methods then in may be an indication that there is room for improvement in the way you wrote your methods.

Reason number three: It saves you time. Although it takes up a huge chunk of your day writing tests for your code, in the long run it would actually save you time. The reason being, if you refactored your code, your tests should catch most of the bugs and allow you to fix it without having to sift through the entire program searching for what went wrong.

Reason number four: Self-updating documentation. There are many ways to understand code; read comments, read the implementation, or by reading the tests. It serves as a type of documentation that allows the reader to know what is suppose to happen.

And the final reason Wijk gives is because it is fun.

For the most part I found this blog quite fun to read because the author made a few valid points. Writing tests may be a pain but in the end it does make you a better programmer and ensures that there is less room for errors. I know my biggest weakness is testing my code because I never have in the past and moving forward I will start to.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

QA Career Paths

I’m a Computer Science major, about to graduate this year, without a real understanding of where to go after my degree. Since my future is fairly open, I was curious to research the professional QA field and how some testers got their start in the industry. After a quick google search, I followed the link below and found some helpful insight from current professionals on the topic.

https://techbeacon.com/6-new-careers-paths-ideas-software-qa-testers-professionals

Firstly, it surprised me to find out that many QA testers ended up in their positions without a lot of intention. To quote QA professional Shelley Rueger, “I don’t know that there is a standard way to start in QA.” Originally, Rueger went to MIT to become a research physicist, quite a long step away from her current career of 15 years so far. Its surprising to me how somebody could invest so much into their future but mysteriously end up in a different field entirely, a trend common across all majors. I suppose the future is just that unpredictable, which actually offers me relief since I’m so unsure of where I’ll end up.

All that being said, going into QA is certainly worth planning out long term if anybody is considering it professionally, since the first few years are typically rough. Jeremy Hymel, the QA manager at QAlytics, shares his experience; “The early years in a tester’s career are rough, the pay is not great, and they are not treated as well as developers.” Once the hardships are over however, this article lists multiple points to jump off of as a QA tester. I will summarize the following paths: Product Management, DevOps, and Customer Experience.

Product management is a common fit for advancing QA testers, since they have extensive experience ensuring the best software possible. This quality is essential to the success of software reliant companies and they will often recognize a good QA tester to take the role of feature development.

Testers are more suited than software developers in the advancing role of DevOps. QA testers can easily practice the skills needed for a career in release management, product stability, or automation engineering.

It also makes a lot of sense that a QA tester could pursue a Customer Experience role. The tester assumes the role of the customer with every software test, therefore they have plenty of experience seeing the point of view of the user.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Our Future Role

Before shifting into the details and techniques of how we, as developers, can design and improve software for the future, I felt as though it would be better to start off with a more general post about where software is taking us.

As people in this particular technological age, we depend on software to be effective every minute of every day of our lives. In this way, we are spoiled. With new advances in technology being released rapidly, we have almost become accustomed to having so much technical capability right in our back pockets. With this, we have begun to catalog and store everything about ourselves, since the amount of data storage we have is at a relatively infinite capacity. With such capabilities at the touch of our fingers, is it our jobs, as future software developers, to protect the general public against the possible repercussions? Are there evils afoot that come with such good?

To find out more information (and a few answers to these daunting questions), you may turn to non-other than Jeff Atwood, a software developer, who created the blog post “To Serve Man, with Software” on his blog, Coding Horror. He begins by describing the role of programmers today, beginning all the way from the early decades of coding, in the sense that programmers have always been the ones ruling the world. This, at first, seemed like a good thing. Programmers and software developers could change the world and do all sorts of good with their powers! However, is it always good?

What do you do when you wake up one day and software has kind of eaten the world, and it is no longer clear if software is in fact an unambiguously good thing, like we thought, like everyone told us … like we wanted it to be?

This should be a reminder to each of us how powerful software is, especially in our world today. Ensuring that all of the software that is being developed has a morally and ethically right purpose and that it is so specified that it cannot be used for anything other than it’s original intent is gravely important. As software developers, this is a critical concept to keep in mind.

 

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Post #3: What/Why Software Testing is Important?

Hello and welcome back to Benderson’s blog where we discuss computer science topics that are happening in present time. This week we are going to discuss what is software testing and why it is important, I got this topic from a blog post posted by Harshit Satyaseel at Technotification. He talks about everything to do with software testing which is very helpful for people to understand and get what is software testing. He first starts by talking about what is software testing and he defines testings as “confirming that whether the actual results match the expect results”. Testing is a long process that makes sure that each and every software component/system passed the expected standard of performance set. Testing in software can be done manually or using automated tools. He then goes into why it is important to test your software and lists off reasons like finding defects/errors in the code, the quality of the software, and some more important reasons. Then he goes into software testability and lists off some characteristics of testability. Generally, what testibility is, is the guidelines and rules of testing and what you should look for to fix and make an improvement on.

The reason I choose this blog to write about besides the fact that the course I’m taking is focused around software/code testing is because it had some interesting tidbits and good guidelines to look for when testing mine or someone else’s code. The writer also talked about what software is which most blogs really don’t do when they are talking about something inside computer science, they always assume you know exactly they are talking about regarding the topic. For me, I know what software is but for the common person trying to gain knowledge on software being told what software is and why software testing is important makes the reader more knowledgable on the topic. He even gives the fact about Alan Turing in 1935 with the theory of software which was a nice touch. When he talks about the reasons for testing software, I like how he listed them out instead of creating a huge paragraph that is a jumbled mess about it. They are also very well listed and easy to understand regarding to software development. I will keep the guidelines and rules that the writer talks about in my mind whenever I test my code now, they are very good things to keep in mind. Thank you for joining me this week and reading my blog post.

Link: https://wordpress.com/read/blogs/74482552/posts/18309

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

Testing & Planning

The podcast that I had listened to for this week was again by Joe Colantonio with guest host Kinga Witko. The two first begin with talking about what Kinga does for a living and as a job. She speaks about the difficulties of her job and how demanding it can be. She also discusses how laws that differ from the U.S to Europe can affect how your testing goes in a job like hers. Afterwards, Joe talks about one of her youtube videos and how she states that you need time for big fixes. She specifically talks about the hardest thing people do not understand is the comprehension behind their project or software being a whole. Many tend to divide their project in two sections, so when they need to do deal with bugs or fixes, they see as something completely separate from their core features. People think that bugs are different from functionality, which is wrong, Kinga expresses. She then goes on to give tips on how to be aware of this. To know that testing is part of the process and bugs should not be part of a separate bit. One tip that she recommends is that a tester should always keep in mind that they should 25%/30% of each task/ development task for something which is unexpected. This doesn’t mean that it has to be a bug, it may be an environmental issue, or something you can not predict from the beginning. She also mentions that people should state problems early on, to avoid risks of even more problems. Lastly, her best approach for testers is to do exploratory testing. Get along with exploratory sessions and try to think outside of the box.
There were a lot of reasons why I really liked this article. The biggest being was that she was a women talking about testing, and computer science as a whole. All of the podcasts that I have listened to thus far have all been by men. I do not mind that because I knew from this beginning that this was a male dominated field, but I am always looking for female coders or testers. I also really liked that she was from Poland because I have not heard/ listened to any European CS people. What she had to say was even more interesting. Even I myself, who has not worked on hardcore projects for a job so far, feel like I already separate my projects into certain areas. I like that she was big on trying to keep it as a whole. A lot of her tips and tricks were very interesting to hear.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.