Category Archives: #Week5

Semantic Versioning (There’s a standard?!?!)

Through a bit of coincidence a friend and I were having a discussion on version control and how we went about naming our versions a few days ago, and I say coincidence, because it seems like we’ll also be working on Semantic Versioning sometime along the line in class.

Being the person that I am, I made my own rules without being influenced by anyone else. For me, I simply though that

Well… It’s my code, right? That means I can name things however I want, right? So if I said this is version 0.9, then it’s version 0.9! Or if this is version 2.0, then it’s 2.0!

In response, my friend informed me of a few soft rules, since he was more familiar with versioning through an internship opportunity than I was, and he shed some light on a few details. Like how versioning is not just a made up number that you assign to your project/code. Hearing this, I was honestly pretty confused, but I looked into it and discovered Semantic Versioning!

And wow, did that blow me away. Looking back at the way I approached things, I was no different from a headless chicken running around! Learning about Semantic Versioning, through this video, it is both so straightforward but also so useful. No longer will I have my versions be numbered willy-nilly, nor will I even forget my own versions and what happened in this update! It’ll finally make sense!

To break down Semantic Versioning, consider versions as three parts!

The Major version, so think 1.0.0
The Minor version, such as 0.1.0
And finally, patches, like so 0.0.1

Major versions are, well, major! These are versions that leap forward and have large changes! Making a major version usually implies that the code is changed in such a way that it will no longer work with older versions. These changes might be large architectural changes, or other large scale changes that usually break the existing structures or APIs.

Minor versions are NOT as massive (duh), but they come with plenty of other things compared to, say, patches! Minor versions could be added features, or updates to existing features, and most of the time, nothing should break. Functionality that existing before should still work, and further development of new features shouldn’t impact or break anything either (ideally).

Patches are like bandages! These are where the bug fixes are! If something is broken in an unintended way, that’s when patches come in, and they should be used to iron out problems that were not accounted for. It could be something minor like the output of some code is a 2 instead of a 1, or it could be a bit more major like a whole portion of the code crashes when run, but patches are for fixes!

As an example, I’ll run through a brief bit of versioning on a made up project! Let’s say… I’m making a program to print out a leaderboard. It connects to an online library to gather scores, and then displays it to whoever connects to it.

After long and grueling work, I did it! I finally completed it and so, I release…
Version 1.0.0
It’s done and completed, but then… It turns out, my leaderboard only prints out the WORST scores! Dang it, I flipped the list around by mistake! So off I go, fixing this bug. After everything is working again, my next version should be 1.0.1.
But then… I think to myself, wouldn’t it be cool if I added region support too? Then we could see where this score is from, and potentially even group regions by high scores!
So, after adding this new feature, my next version will be 1.1.0!
Pretty straightforward, right? It’s really clear what is going on too!
Let’s say another bug is introduce, bam, 1.1.1!
Then more features, 1.2.0
And finally another bug is squashed! 1.2.1
And… another bug ! 1.2.2
But… then wait, there’s another bug. 1.2.3
Things feel good and everything works, but I learn about a whole new library that does what I want it to do, and gives me more room for growth. So rework the whole program with this new library! The old stuff still works, but since I’m switching to a whole new system, this version will no longer work with the old one, and now, this is when I jump a major version.
We’re now on version 2.0.0!

I hope that example made sense! There is more to semantic versioning as well, but that is the quick break down. Introducing things like alpha/beta and also ^ and ~ adds some other intricacies, but for now… Let’s not think about them! Alphas/betas are optional for testing purposes, and to be honest, ^ and ~ are a bit out of my grasp. I don’t fully understand them yet! I’ll look into them more, and maybe I’ll have a future update post detailing what I’ve discovered!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Let’s talk about adapters

This week I will be touching base on a structural design pattern called the adapter pattern. This pattern has two different versions, the class adapter – which implements the adapter using inheritance and can only be used in C++, and the object adapter – which uses composition to reference an instance of the wrapped class within the adapter. For the purpose of this blog post, I will be speaking only of the object adapter pattern.

Structural design patters are supposed to simplify your design, the adapter pattern in particular makes doing so easy as pie. The adapter pattern reuses old interfaces and provides different interfaces to its subject in order to make things work after they’ve been designed, even if the previous interfaces were incompatible. So what can this pattern do? Let’s break it down a bit:

– Change the interface of an existing object.
– Provide a different interface to its subject.
– Make things work after they’ve been designed.
– Reuse old interfaces.

The adapter pattern addresses incompatible interfaces and lets classes work together that previously could not due to incompatibility by converting the interface of a class into another interface that the clients expect. This conversion process allows software to exchange and make use of information. When you are dealing with different interfaces with similar behaviors, it is best to use this design pattern to help develop a clearer, more easily understandable code. A brief list of some of the benefits of using adapter patterns are:

– It is a low-cost solution.
– It is easy to understand.
– Incompatible code can communicate with each other.
– It makes things work after they’re designed.
– Helps to reuse existing code.

Information gathered for this blog post:
https://stacktraceguru.com/adapter-design-pattern
https://www.geeksforgeeks.org/adapter-pattern/
https://www.java2novice.com/java-design-patterns/adapter-pattern/
https://sourcemaking.com/design_patterns/adapter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog: Confront Your Ignorance

Hello and welcome back to benderson’s blog! This week we are discussing a different pattern that is found in the book Apprentice Pattern called “Confront Your Ignorance”. Confront your ignorance talks about identifying gaps in your skillset that is relevant and will affect your everyday work. The book talks about a common problem with most people trying to master computer science and that is where to start. There is so much in computer science that you don’t know where to begin, you got to decide on a language to learn, what to program, etc. There are too many pathways just to choose one. The solution though is to pick one skill/technique that will help you actively fill the gaps in your knowledge, and you can do this in many ways as well, some suggestions that book has is to look at overviews or FAQs of different computer science topics. Either you eventually master it, or you get good enough in the skill and you move onto other gaps that you need to fill. To find the gaps in your skillset, you need to do another pattern known as “Expose Your Ignorance” which confronting your ignorance attacks.

Confronting your ignorance is a challenge of mine as I want to be proficient in other programming languages other than java, but I don’t know which one to choose half the time. I have tried python and a little C but I always get caught up in something else and never finish learning all the ins and outs of the languages. I feel like I’m familiar with all my ignorance’s, so I’m passed the exposing my ignorance’s phase and I just need to confront them. As I have said before, I’m worried about getting into my first job and not being able to work efficiently enough so getting experience and filling my gaps is something that I need to do to gain more confidence. I probably will start learning another programming language soon that most workplaces use just so I’m ready to use the language right when I get into the job. Eventually though, I will do my best to fill all by gaps and get the job I need to succeed. Thank you for joining us this week on benderson’s blog, make sure to comeback next week for more patterns.

 

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.

Post #4: Testing Documentation and Formatting

Hello and welcome back to Benderson’s blog! This week’s blog will focus on the documentation and formatting you would use for testing software. I found a blog that talked about the right format for documentation and formatting by Chris Kenst. At the beginning of his blog, he talks about how you know what is the appropriate documentation for a test and says it will depend on the degree on the test technique and approach you use. He talks about a couple different techniques in a short sentence but in the end says cramming all of them into one system isn’t really a good idea. The next paragraph talks about how much you need for documentation which he sums up with a small amount because you need to focus more on the project itself than the documentation that you put in there. The time it would take to make all the documentation for the test, you would run out of time for the test and documentation it self. The next and final paragraph focuses on stay agile, “Focusing on the appropriate documentation for your tests and then creating the smallest amount you need to do your job well also allows you to have agility”, this sentence from the blog sums up the whole paragraph really well.

This blog was very informational on the topic of test documentation and formatting and how much you should focus on it. I haven’t really been big on documentation in my four years in college as I always find it as an additional thing that I really don’t have to do but over the years, I’ve began to realize how important it is to have in your code. My reasoning usually is that I know what each of those methods do so it doesn’t need to be documented and formatted but I realized that in the actual work world I will have other people reading my blogs and they won’t know exactly what each method does unless I document it. So going back to this blog, getting all the information I need to know how much I should document and how I should format is very helpful for not only me but my future colleagues who will have to read my code. Knowing exactly what you’re testing is probably a pretty good thing to know. Also, knowing some tidbits such as focus more on the testing than the actual documentation and write a small amount so you have time, will help me make sure I get the tests done and have a good amount of documentation.

Link: https://www.kenst.com/2018/09/appropriate-test-documentation-formatting/

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.

CS@Worcester – Le Blog Spot 2017-10-16 19:24:48

Week 5

AB Testing – Episode 68 by Brent Jenson and Allen Page.

 

-In this episode, Brent and Allen begin by talking about their stressful lives as software QA engineers. Working late hours and trying to stay up to date with the latest trends in the industry. From this brief intro I was able to get look at the potential challenges that exist in the field of Software testing. One needs to have the ability to be able to learn and implement new technologies regardless of how qualified or advanced one is at software QA and testing. As the podcast continues, allan talks about his position and how much work goes in to generating and creating substantial testing procedures that gets the job done and optimizes the testing process. To me, a student majoring in Computer science with a focus in software development, it’s easy for me to understand and know what Alan is talking about. Due to my class studies, I understand the importance of software testing and how a bad-testing process can be of little to no value to a product whiles a good testing procedure can make or break a product. HE emphasized on all the intangibles that only a person in the industry could understand and enumerated on how useless his positions appears to be to the average person. Brent expands on this topic by saying that organizations generally see the QA department of organizations as a cost for the organization without realizing the true benefits of this department. They are often not given the credit when things are going well and consistent but they are often the first department in software industries that deals with layoffs and budget cuts should there be a need for cuts.

With this topic both Allan and Brent went off on a tangent and began comparing and contrasting Traditional testing and modern testing. Prior to this podcast, I didn’t know there were “traditional testing era” and   “modern testing era”. According to them, the old way of testing followed the following sequence. Requirement => Design =>Code & Build => Testing => Maintenance whiles the modern way of testing follows the following sequence.

Requirement => Testing => Design => Testing => Build & Execution => Testing =>Test => Testing => Installation => Testing => Maintenance => Testing.

As we can see, the modern way implements more testing stage with might appear to be more costly that the old way but overtime saves more and enables modulation of components. The software gets built by parts instead of one giant big project.

LINK 

https://testingpodcast.com/category/ab-testing/

 

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.