This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about user interface programming for software. Most of the hard-core C++ programmers Joel knows hate user interface programming. This surprised him, because he found UI programming to be quintessentially easy, straightforward, and fun. It’s easy because you usually don’t need algorithms more sophisticated than how to center one rectangle in another. It’s straightforward because when you make a mistake, you immediately see it and can correct it. It’s fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly. Most programmers’ fear of UI programming might come from their fear of doing UI design. They think that UI design is like graphics design, which is the mysterious process by artistic-minding people creates cool looking artistic stuff. Programmers see themselves as analytic, logical thinkers, being strong at reasoning, weak on artistic judgment. Therefore, they think they can’t do UI design. However, UI design is quite rational. It’s not a mysterious matter that requires a degree from an art school. There is a rational way to think about user interfaces with some simple, logical rules that you can apply anywhere to improve the interfaces of the programs you work on.

User interface interacts with users working with software. UI is important because it affects the feelings, emotions, and mood of users. If the UI is wrong and the user feels like they can’t control software, they literally will not be happy and they’ll blame it on software. If the UI is smart and things work the way the user expected them to work, they will be cheerful as they manage to accomplish small goals. So, UI must respond to the user in the way in which the user expected it to respond; other way the user is going to feel helpless and out of control. A psychological theory called Learned Helplessness, developed by Dr. Martin E. P. Seligman, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment. To make people happy, you have to let them feel like they are in control of their environment. To do this, the user interface needs to correctly interpret user’s actions.

The post gives us a thinking about designing and programming user interfaces for software. UI design should be considered as rational and logical process rather than a mysterious process that needs highly artistic judgment. UI must behave in a way that users feel like they are able to control the environment when they are using software. The cardinal axiom of all user interface design: “A user interface is well-designed when the program behaves exactly how the user thought it would.”

Article: https://www.joelonsoftware.com/2000/04/10/controlling-your-environment-makes-you-happy/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

This week’s post is going to be about Dynamic and Static testing from testbytes. Static and Dynamic testing are the two major methods of software testing.

Static Testing is done manually or with a set of tools. This type of testing is useful in finding flaws. It is mainly done in the early stages of the development cycle, also referred to as verification testing. Specifications, design documents, source code, test plans, test scripts, test cases, and web content, all have to pass the static testing. Some advantages of Static Testing are: identifying flaws in the code since it is done in the early stage of development, the testing is conducted by trained software developers, and it is a fast and easy way to find and fix errors. Some disadvantage to using it are:  it demands a great amount of time when you’re doing it manually, not all automated tool works with the language, and that automated tools only scans the code.

Dynamic Testing is done when the code is executed and checks how the software performs in a run-time environment. This testing checks the functional behavior and performance of the system. The purpose of this testing is to ensure that the finished product is designed according to the specification given by the clients. It is also known as validation or execution testing. Some advantages to Dynamic Testing is that it identifies weak areas in a run-time environment and it can be applied to any application. Some disadvantages are: it is not easy to find a trained professional for dynamic testing, and it is difficult to trace vulnerability in the code and would take longer to fix the problem.

At first, I thought that Static and Dynamic testing are different kinds of testing but it’s actually more like a primary and secondary test. I really like this blog because it lists the advantages and disadvantages, for me it makes it easier to understand if the layout is like that. Also, they mentioned that eighty-five percent of flaws of the software can be detected during Static Testing, I think that is really interesting. You would’ve thought that most of the flaws in the software would be found in the Dynamic Testing where they test the end product.

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

We just wrapped up a section going over various design patterns used in software, so I wanted to do a bit more research on a different design pattern to get more of an idea about how they work. One pattern that looked interesting was the composite design pattern (https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/), which appeared to combine a couple of concepts that I had seen from taking data structures: inheritance and trees. This structure of the composite design pattern essentially takes on the form of a hierarchy, with 4 types of items: a component, a leaf, a composite, and a client.

The component is the abstract entity in which common behaviors and operations are defined so that repeated code can be prevented. In the example provided in this post, a program to simulate the retrieval of banking information, the “component” expressed a list of other Component objects, methods to add and remove from such list, as well as other abstract and non-abstract methods that can be utilized by other classes extending from the component.

The composite and the leaf (or leaves) both inherit from the component. For this example, the CompositeAccount class served as the composite. This class implements the methods defined as abstract in the Component class. Because the composite and the leaves all inherit from Component, all of these objects from the different classes can be defined as Component objects. Thus, in the CompositeAccount class methods, all of the leaf objects are taken into account by traversing through the list of Component objects. For this example, the DepositAccount and SavingsAccount were leaves, with their own behaviors that were exclusive to the leaves.

Finally, the client puts it all together as the driver for this design pattern. New objects are created in this class, and each individual object is treated appropriately with the correct behaviors (i.e. the DepositAccount and SavingsAccount), while also being part of the bigger system, in this case the CompositeAccount, all of which are underneath the Component umbrella.

This was a great read for me! It was simple enough to understand coming from an extended introduction to design patterns and other programming courses using this kind of structure. I’m currently reading more about the Decorator design pattern for an assignment, so I hope to post more about that soon!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

As I take another step into Software C.D.A. I remain in design pattern. I will point out the bases of adapter pattern and will also talk about a new pattern I just learn about the Facade pattern, and the Memento pattern. I will also point out the main difference between adapter pattern and facade pattern. I chose to do this topic because I was mainly trying to just focus on the facade pattern but my search in the internet for podcast on this topic lead me to “Design Patterns Part 4 – Adapter, Facade, and Memento by Joe Zack”. Where as the topic indicates its topic is on the design pattern of adapter pattern, facade pattern, and memento pattern. For this blog I will briefly summarize what they discuss on adapter pattern and memento since my main focus is the facade pattern. Since I must do my own research on that pattern for a homework assignment and I might as well hit two birds with one stone. That being said if you wish to listen in the podcast click on the highlighted link above of the podcast tittle.

Alright let’s dive into the facade pattern…

What is Facade Pattern?

Facade pattern is used with object-oriented programming it is an object that aids as an interface masking complex code structural.

What is facade intention?

The facade intention is to make combined interface available to a set of interfaces for example wrapper.

When to use Facade?

We use facade when there is a complex system you wish to make more simpler either by necessary or for your own personal wants in a system.

Okay now that we pointed out the basic of facade lets cover adapter bases and then compare them both.

What is Adapter Pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say you’re at your friend’s house and you have an i-phone USB charger cable but no power adapter, and let’s say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

What are the differences between facade and adapter?

Although both of them are consider to be wrappers. The difference is that an adapter only wraps one object while a facade wraps multiple. Adapter solves non-compatible interface problem by making them compatible by using an existing interface. While facade takes complicated interfaces or systems and transform them into simpler interfaces/subsystem by defining a new easier interface a wrapping them up.

What is the Memento Pattern?

The memento pattern has the ability to undo its previous state by restoring the object. Also described as “undo via rollback”. As described in the podcast memento aims to “rolling back changes to an object”.

How is memento pattern implemented and how it works?

The memento pattern has three objects of implementation known as the originator, a caretaker, and a memento. The originator has an internal state, a caretaker is able to undo the change and does something with the originator, but the care taker must first ask the originator for a memento object. The idea of “undo via rollback” is done once the caretaker returns the memento object to the originator. Another way to think about how memento is implemented is by taking a snapshot of the internal state and then you can restore your object to the internal state by passing that data back (this is similar to how describe in the podcast).

The memento pattern is categorized as a behavior design pattern. Both facade and adapter are categorized as structural design pattern but are used for different reasons. I will end this blog by saying Design pattern is a very important skill to have for software developers. That being said do your research on Design Pattern and look for examples and understand how it works in order to be a successful software developer.

Thank you for your time. This has been YessyMer in the World of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For today’s blog I am going to be referencing another blog called “What is Boundary Value Analysis and Equivalence Partitioning?” by Ulf Eriksson. The article talks about boundary value testing being a way to test values between the valid input ranges in test cases. Boundary testing is important so that we as testers can figure out where our valid input range lies, and we do not mistakenly use inputs outside of the valid range (the invalid range). This is also important to do so that if an end user does enter an invalid input, then the program knows how to handle it rather than crashing and burning. One other area the article talks about is called equivalence partitioning. This one is a little different from boundary value testing in that it divides the test into a range of values and selects one input from each range. This is a form of black box testing because you are testing the value without knowing what is going on inside and in turn, not knowing the exact output. There is, however, an expected output that you determine before testing and it will be proved either true or false based off the actual output of the test. The best way to differentiate between boundary value and equivalence partitioning is summed up very nicely in the article. The basic idea of the point being made in the article is that boundary value testing is testing for the valid range of inputs whereas equivalence partitioning is slicing that valid input area (as determined in the boundary value tests) into equal parts and selecting one value from each partition to test. I think this is is a very constructive way to test within a valid value range because you are getting a “good spread” of test values. In other words, the test values you are getting will be from across the spectrum of valid test values because of the equal partitions and selecting a value from each partition. I have been using this idea of equivalence partitioning in class by selecting test values such as min, min+, nom, max-, and max. We have learned in my software class that testing from each of these values will give you a good showing of how accurate your tests are and how good your tests are. Thinking about these five test values as equivalent partitions within the valid boundary range will help me find these values easier in the future.

Link: https://reqtest.com/testing-blog/what-is-boundary-value-analysis-and-equivalence-partitioning/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

As I take another step towards Software Quality Assurance Testing. I start to think and learn about how would I write a good unit test. That lead me to a podcast about “Clean Code – How to write amazing unit test” by Joe Zack. This podcast does a very good job on explaining the idea of clean code and also about how to write amazing unit test. This podcast also touches Test-Driven Developing.

The blog first starts out talking about a few interesting things however unrelated to the topic it finally gets into the topic 17 min into the podcast. For this blog I am only going to touch on the clean code part of the podcast to hear the full podcast please click on the following link https://www.codingblocks.net/podcast/how-to-write-amazing-unit-tests/#more-2483 otherwise…

The podcast mentions the following things about clean code:

There are a few problems with keeping test clean. For example, keeping test clean could outgrow your prod code and become unmanageable. However, there are more problems with having dirty code. Such as when/if code changes the test must also be change causing double work and harder to change. If test is extremely dirty it could become a liability.

Clean test is important because it keeps all test code readable, simple, clear, maintainable, and reusable. When you have tests it makes it easier to change code and less scary. A clean test makes it easier to improve the architecture.

A great way to have a clean code is by using the “Build – Operate – Check Pattern”. Which stands for building up the data, operate on the test data, and check by insuring that the operation yielded the expected results. Test should be written in a specific way so it will be able to be used in different testing platform. Another way to have clean code is to only have one assertion per test. Since, it makes the test easier to read. Although sometimes using multiple assertion is necessary and more beneficial to do so. Clean code can also be achieved by making sure to have a single concept per test. This idea is actually more important then having a single assertion. That is because it makes sure to only test related things, instead of un-related items.  A good general practice to follow for clean code is to remember “FIRST”. The F in first stands for Fast, meaning a test should run quickly and be fast. The I in “FIRST” stands for Independent, meaning each test must be independent. The R in “FIRST” stands for Repeatable, meaning test must be repeatable in different environment without the need of infrastructure specification. The S in first stands for Self-validating, meaning a Boolean output or either true or false is required. The T in fast stands for Timely, meaning a test must be written in a timely manner particularly before writing the production code in order to ensure they are easy to code against.

To sum this up practicing clean code is a very good idea to practice. From the testing to the code production clean code has more benefits then not. It is important to create unit test in order to be confident when needing to change the production code. Over time this practice will prove to be more beneficial since it allows improvements to be flexible and maintainable.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.