Category Archives: cswsu

Path of Most Resistance

In my last blog, I sought
to cover Integration Testing and in doing so we covered the two distinct types
outlined by Mr. Fowler. Of these, Broad Integration Testing (BIT to save time)
is most relevant to the next subject I wish to cover: Path Testing. BIT covers
the interactions between all ‘services’ within a program – meaning a program’s
completed modules are tested to ensure that their interactions match
expectations and do not fail some tests created for them. In this way, Path
Testing is very similar but with a focus on how paths through various aspects/modules
of a program, hopefully, work or do not.

           As
opposed to BIT, Path Testing (PT) seeks to identify not just the interactions
between modules, but instead any and all possible paths through an application
– and discover those parts of the application that have no path. The ultimate
goal is to find and test all “linearly independent paths”, which is defined as
a path that covers a partition that has yet to be covered. PT is made up of,
and can integrate, other testing techniques as well, including what we’ve
covered most recently: equivalence testing. Using this technique, paths can be
grouped by their shared functionality into classes, in order to eliminate
repetition in testing.

           When
determining which paths to take, one could be mistaken for wanting to avoid the
same module more than once; as stated previously, we are seeking paths we have
yet to take. However, it is very often that the same path must be taken, at
least initially, which leads to several modules. In fact, a path might be near
or actually identical to one that has come before it, but if it is required
that several values be tested along this path then it as well is considered
distinct as well. An excellent example of this made by the article I chose
states that loops or recursive calls are very often dictated by data, and
necessarily will require multiple test values.

           However, after this point the author begins to move away from the purely conceptual to actual graphs representing these paths, specifically directed graphs. While it was painful to see these again after thinking I had long escaped discrete math, they provide a perfect illustration for the individual modules you expect a path to trace through, as well as possible breaking points. Directed graphs represent tightly coupled conditions, and in this way they express how a program’s run in order and the cause and effect of certain commands upon execution. In this way, it offers a much more concise visual presentation of the testing process as opposed to something like equivalence testing. As well, these graphs are quite self-explanatory but I look forward to applying these concepts in class to actual code.

Sources

Path Testing: The Theory

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Putting the ‘O’ in SOLID

We
covered the Open/Close principle in a recent lab, and it prompted a desire to
cover some of the SOLID principles. I have determined however, that the length
of this blog is short enough that I should dedicate it to a single principle at
a time, beginning with the aforementioned Open/Close principle.

              This particular object-oriented
principle was outlined by Bertrand Meyer and states:

“…entities should be open for extension, but closed for modification.”

              This of course, is a complex way
of expressing a simple guideline for software development; which is that new
functionality should be able to added without having to radically change existing
code. The operative word, extension, is illustrative. If your code was a home,
and you wanted to add more square-footage (read: functionality), you shouldn’t
need to knock all the walls, or the whole thing, down to add a bathroom.

              In the blog chosen, the author summarizes
a talk he gave about the very subject. In it, he provides an example of a program
he is developing for a company that calculates the total area of a set of rectangles.
As the customer requests more and more shapes be added to the calculator, the original
code changes drastically and gets longer and longer. This modification is opposed
to this principle. In opposition, creating a Shape class that contains many children
of different specific shapes – each with their own area function – with the
ability to add more, eliminates constant modification of the main class, and
allows for constant extensionability in the form of new shapes.

              To say simply that code should be
modular is unhelpful, as it is broad and the general definition of so many more
good coding practices. Our class and homework provide another perfect example.
Why should we have to constantly Override and rewrite portions of a superclass’
methods in each of its child classes to achieve proper functionality. Instead, in
making a Quack/Fly Behavior interface we have established a broad mold that
many new behaviors can be built off of; access to all of which is then granted
by the relationship to the single respective behavior interface.

              Therefore, the ability of code to be
extended with new functionalities, using a single reference – in this case the behaviors,
or shapes – instead of needing to rewrite or overwrite code is what is meant by
extension; while keeping the existing code from needing constant revisions, is being
closed for modification. Like the house example earlier, you should constantly be
building out, not renovating what exists already.

Sources:

A
simple example of the Open/Closed Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Static VS Dynamic Testing

In Software Testing, the two
most popular or important methods for testing are static and dynamic. While both
are obviously named, its good to go over the distinctions, and more importantly,
the actual implementations of both.

           Static
testing involves review of project documents, including source code, to weed
out any actual or potential security flaws and general mistakes. This takes the
form of Informal and Technical Reviews, Inspections, Walkthroughs, and more. This
process can involve an inspection tool or be performed manually, searching
for potential run-time problems, but not actually running the code. Dynamic testing
conversely involves actually executing code looking for functionality,
resource usage, and performance. We have been using dynamic testing, specifically
unit testing, in our class so far. Dynamic testing is used mainly to verify the
program runs in accordance with the specifications outlined for it, specifically
called System Testing.

           Of
course, both have their own advantages and disadvantages. In static testing you
have the potential to find bugs that may have made later development more
troublesome early in the process, which can save lots of time and frustration in
the future. However, there may exist some flaw that only a running program can
reveal, but it only in the code that is executed. It would seem to me, that
these should not be exclusive and in fact, they have a logical order.

           You
would begin with static testing, like proofreading a paper, searching for misspelled
words (poor variable/method names), run on sentences (needless complexity or
repetition), and reorganizing to best get your point across (logical order of
declarations/methods, documentation). Like writing a paper, it is best to do
this ahead of run-time (reading through), that way you don’t have to constantly
stop to bandage small errors. In the same way it seems essential to ‘proof-read’
your code before execution to make sure it is free from identifiable errors
before you move on to seeking out run-time errors. You wouldn’t want to have to
fix both at the same time like with proof-reading.

           In sum,
these two could be grouped as pro-active or reactive, static and dynamic respectively,
and best explain their use. As mentioned, these also make sense to utilize in a
specific order, ensuring code is as correct as possible upon inspection, then
running it to see where flaws undetectable in a static environment have arisen.
These together ensure quality software that is optimized and secure.

Static Testing vs Dynamic Testing: What’s the Difference?
Static Testing vs. Dynamic Testing

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Refactoring: Spring Cleaning for Code

Depending upon the subject, some of us are lucky to finish a functioning project so the thought of improving code after the fact – especially if there’s a new project due soon – is a distant one. However, they may be tricked into refactoring their code if asked when you say the magic words: “Refactoring is not rewriting code”. The definition, as defined by its creator is:

“a change [or changes] made to the
internal structure of software to make it easier to understand and cheaper to
modify without changing observable behavior.”

In
reality, the process may involve:

  • new
    code, but it must not change the behavior of the original code;
  • ensuring
    the system works before and after each refactor, including original unit tests;
  • creating
    unit tests to verify our refactoring has not changed system behavior;
  • changes
    that individually are minute, but combined lead to a healthier program;
  • eliminating
    duplicate code, potentially changing variable names, and more.

It is not
simply cleaning up code, but rather reorganizing it in order to make it easier
to trace and understand, as well as add functionality to in the future.

              For our purposes, this may be a very
important concept to learn but it may be some time before we get to implement
it, unless we’re coding or maintaining an entire program for our capstone; however,
it is important to understand when to do so. According to my sources, the best
time to do so is before you add new features to an existing program, or right
after you’ve already shipped it. For the former, it makes these new features much
easier to add when the program is much more readable and makes the program better
for having made the changes. As for the latter, it makes a lot of sense to
snoop around for ways to reorganize code after you’ve spent so much time on it,
and in a mad dash to finish it towards the end no doubt. Years’ worth of work
is no doubt going to have some inconsistencies that fell through the cracks in
the course of development.

              As for implementing these changes, there are several methods, including Red-Green-Refactor, Abstraction, Simplifying Methods, as well as many others we won’t cover. In R-G-R, red means stop and determine what to develop – usually with a new test that fails, getting this new development to pass tests (green), and finally refactoring to optimize. Abstraction is used to address duplicate code and can be done by restructuring hierarchies using the Pull-Up [pulling up code into a superclass to be shared more effectively] or Push-Down [pushing down code to more subclasses from a superclass] method. Finally, Simplifying Methods is an effort to simplify older code by consolidation and reducing interclass complexity. Hopefully this helps develop an understand of refactoring, in fact, I had to do quite a lot of refactoring to this blog to get it down to size!

Sources:

Refactoring – Martin Fowler
Refactoring – Agile Alliance
Code Refactoring Best Practices: When (and When Not) to Do It

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Thinkin ‘bout KISS‘n you

KISS
(Keep it Simple, Stupid) is potentially one of the most culturally pervasive concepts
used in Computer Science, the other being maybe blockchain – the difference of
course is that people actually understand what KISS is, everyone who says they
understand blockchain is lying. Of course, KISS did not originate in Computer
Science, and instead was popularized at Lockheed Skunk Works by noted
tangential war criminal and engineer Kelly Johnson. While it may be difficult and
seemingly sacrilegious to try to explain something so self-explanatory that is
what I hope to do, flying in the face of the concept of simplicity to stretch
four words into four hundred.

Credit: csiaexchange

              It begins with, put kindly, making
distinctions about the semantics of the scant few words in this phrase; put
more bluntly, being pedantic. This examination is important, and the linked
article does a great job of highlighting first the distinctions between ‘simple’
and ‘easy’, which could be mistaken as synonyms, and contrasts it with ‘complex’.
His conclusion is this, a simple system is defined by what it is not, which is one
with too many parts which are interconnected – with the latter being worse in
software development.

              This all sounds wonderful on paper,
and about the same on a computer screen, but sometimes complexity is
inevitable. So, it is advised that you make things as simple as possible, until
you can’t, at which point you are vigilant in handling that necessary
complexity. For instance, I could try all sorts of methods to navigate a 2D
array in some mock-up code, but I don’t need to introduce recursion or anything
outrageous to shorten a method body if a simple nested loop will do.

              This idea of simplifying through pruning
code is expressed in the next sections of this post, stressing the importance
of cleaning up dead or underutilized code so that no resources are wasted maintaining
or reintegrating useless code. Additionally, YAGNI (yay more acronyms) states
more or less the same thing, encouraging programmers to implement the essentials,
that will actually be presently utilized, and skip the bells, whistles, and
maybes. Code with bunches of maybe methods require time and resources to
maintain and if they aren’t actively being utilized, then they’re a waste of
both.

              From here on, the blog introduces
many more concepts that are possible to cover in just this blog post – although
I do hope to mention Lasagna Architecture in another post sometime later. Instead,
I think it is time to bring this post to a close. What is the take-away then?
Well its exactly what you thought it was from the first line. In conclusion, it
may be appealing to get a jump on features you may want to implement in the future,
but it is best to keep things as simple as possible and/or only as complex as
needed but no more.

Sources

KISS Principle Explained
KISS, A Design Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Anti-Pattern Cannon

“…an
atomic plant is so vast, so expensive and so complicated that people cannot
grasp it, and rather than try, they fall back on the assumption that somebody else
checked all the details before it got this far… A bike shed on the other
hand.  Anyone can build one of those over
a weekend.” – Poul-Henning

While the blog post I have chosen
does not lead with Bike-Shedding, it is certainly one of the most interesting
examples of “Anti-Patterns” – practices in programming that are counterproductive
to both actual development as well as implementation – and provides a hilarious
anecdote, of which the quote above is from. While perhaps less entertaining, this
post outlines nine types of coding Anti-Patterns and defines what they actually
are, why they are bad, how to avoid them, and provides – my favorite –
examples, among other notes. Most importantly, these concepts are tied to code
smell, and I hope to explain the links between code smell and the practices
that cause it.

Credit: refactoring.guru

For instance, the first Anti-Pattern is Premature Optimization: As the name suggests, it is trying to code for bottlenecks you may have rather than using tried and true methods and finding the actual bottlenecks on runtime. As mentioned, in my own code I have a similar problem where I attempt to write everything perfectly, or in as few lines as possible, instead of building a working a prototype and then cleaning up code after review.

While perhaps not identical to this pattern, the tendency to get hung up on all the possibilities and edge cases just slows development and often the actual execution of the code. Code that has developed in this way is very similar to a code smell known as Speculative Generality, which is defined as excess code created “just in case”. The only difference is that instead of excess optimization code this smell is more interested with future features.

Another relevant example is the God
Class: a single class that contains and controls aspects for an excessive
amount of child classes. When code is structured in this way it makes maintenance
an obvious nightmare. This reflects two code smells most closely, Large Class
and Shotgun Surgery which are tremendously large classes that need to be split
into smaller pieces and the need to fix smaller problems spread across several
classes as a result of another change, respectively.

Credit: refactoring.guru

This trend continues with the Fear
of Adding Classes pattern reflecting the aforementioned Large Class smell;
Useless Class pattern and Lazy Class smell; and the trend continues. What I
wish to express mainly is that these two concepts exist on a continuum with Anti-Patterns
on the development end and code smell on the completed program end. So as we move
forward with the course I’ll try to be cognizant of the Anti-Patterns that lead
to poor code – as well as those which slow development cause of interpersonal
issues which I didn’t get to discuss in this particular post – and how this
poor code exhibits various code smells.

Sources:

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

AN INTRODUCTION

Despite the foolish blog title, this blog will hopefully be anything but; and not just for your sake but mine as well, as I’m being graded for it! I will be utilizing this blog for documenting both CS343 and CS443 class work and sharing other CS-adjacent content that I’m working on.

As such, it is appropriate that I introduce myself: My name is Brandon, I’m a senior CS student, doing both Software Development and Big Data Analytics, and am the PAL tutor for CS242 this Fall semester. If this blog is any indication, I like to keep things light, I love getting out, either up a mountain, on a lake, or bike trail. Between my job building computers and school I get plenty of time indoors as well.

OLYMPUS DIGITAL CAMERA

I unfortunately have not had much time to pursue independent studies or projects but I’m hoping after graduation to build my first program, likely in Windows, as well as my own professional website. No offense to WordPress but I don’t think this will bolster my portfolio.

Well I’m not sure how to end this so what if I did with my cat?

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

The Deep End

This Week I read up on the section called Deep End. This section talks about taking risks and not always taking the safe and easy route. With life it isn’t all about doing the bare minimum and playing it safe. Trying to cruise by in life by doing only what is needed of you. Also doing what you are comfortable with. This section has a story of a person who decided to take that leap of faith by accepting a new job that took him out of his comfort zone. He met with the CTO and CEO of the company he worked at and they wanted him to go to Lagos to work with a contract there and Lagos was rated the 3rd most dangerous city in the world and this would scare away a lot of people however he decided to go. When he started working there it was supposed to be a 3 month job however he stayed for nearly 2 years helping the client. He doesn’t regret taking that trip and because of the trip he has been all-over the west African country and now he is working in London. Because of the risk he took it opened his world by being able to experience different opportunity and meeting new people and go to new places. We can learn a lot from this because in life working on projects for companies we will not be doing things that we like all the time. There are going to be times that we would have to work on projects that take us out of our comfort zone and ask us to learn a new library or a new language and we would have to throw out everything we know and accept the fact that things change. Sooner or later we are going to have to make those hard decisions. But sometimes those hard decisions are just a test of our will to be able to move past those barriers that we have set in front of ourselves and to overcome the obstacles to become better and open new opportunity for ourselves. I think I will take this lesson with me in the future because there are going to be times that I am comfortable working at where I am at but when a new opportunity comes up where it asks me to move ½ way around the world and to work a new team. I will look back on this section and maybe take that opportunity and hopefully it would let me experience something new.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 5

This week’s Sprint retrospective we had some issues. So, there were still the issue of ng2-amrs not working for many of the people in group. However, thanks to Jason Knowles he figured out how to fix the issue of cryptojs not working on the Ampath’s website. So, we were able to try and write something for Ampath to be able to use or try to use. Our goal in the beginning of the sprint was to write all the methods for Ampath so that way they can have something they can use for the summer or give to summer interns or people who would be working on it later on. We decided to split up the work into different parts so that way we would be able to get more methods done for them. We decided to write methods depending on what the client told us in their stories. We then decided to make the method for hashing passwords, encrypting records, generating private keys, generating local salt, clear local salt, delete keys, and writing decrypt records. I started to work on deleting private key method however i wanted to work with Oren since he was generating the private key so this was one of the issues we ran into that because since we were working on a project that we just kind of picked up and we don’t know much about it there wasn’t a lot to work on for the project so when I talked to Oren to see if he could help me with the delete private key method but Oren was actually going to work on that as well. So instead we decided to work on that part together.

So, I started to do a little research about the cryptojs and how to make private keys we decide to write a private key using PBKDF2. PBKDF2 is a password strength algorithm that makes it difficult for computers to check that anyone password is correct Master passwords during a Brute Force attack so the way that PBKDF2 works is that it requires many computations to get from the master password to Turkey anyone that’s trying to brute-force try to automatically guess a master password has to perform the same calculations PBKDF2 with PBKDF2 it prevents password-cracking flows from making optimal use of the graphics card which reduce gas rates from hundreds of thousands of gas per seconds less than a few ten thousand guesses per second.

Finally looking back through throughout this project I’ve learned a lot about encryption services. Maybe not enough to be able to write my own encryption from scratch. But this experience was helpful for me and it will help me throughout my career. Between the two classes I was taking this semester and learning about Sprints and planning’s how to work with a group and team. It was different than all the other years that I have been in school. I didn’t learn a new language or more coding skills but I l was able to get a real-world experience. how time-consuming it was to even talk to the manager, how that we were a class who that was working on the same project but we are split into four groups and none of us really talk to each other about trying to put our code together and make it work with one another. Though maybe it was because no one was really experienced in this type situation or maybe the time constraint of working on this project and also having other class work and other personal stuff to do that’s it was a 10-week project if he really boils down to how much work was done it might have been a lot shorter so that’s why we weren’t able to finish I’m what we were assigned and trying to bring it together. so, the for the final Sprint we’re going to try to just finish up what we started and then start working on our presentation.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This week I read the section called Expose Your Ignorance. This sections is something i can relate to very well. I am a senior in college and by that time many people would think that you would be able to program thing by yourself.  You should know about at least 2-3 languages by now and have the knowledge to work in the real world however just like the section “White Belt” there are always going to be people better than you and you don’t know everything yet. It is still a learning experience and for me in the class that we are taking now the section we are doing for the project. Which is encryption services is still something I don’t know much about at all. Just saying that you know nothing about something would be better then you hiding and saying nothing. That is what a team is about. To help and encourage each other to do what you can do and that way you can help them when they need help. During hackatons that i go to when meeting new people if we wanna work on a project we all have to introduce ourselves to each other. We also have to tell people what we can and can’t do because if we depend on someone to the most important part of the project and they don’t have the knowledge to do it in the end we would not have a project to present. Also just because you don’t have the knowledge to work on the project you should not just sit around and do nothing. Take this time to learn a new language, download the library’s needed to work on the project, watch videos, and work with a project partner to see if there is anything you can do. Just like the section says people are more inclined to make themselves look competent then just to tell others that you don’t know what you are doing because there are people looking up to you for advice or employers looking to you for the knowledge. That is why this section teaches you that you that lying about knowledge inst worth it and to accept your faults and work on them another day.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.