Monthly Archives: November 2017

What to Consider When Doing a Technical Review on Object Oriented Code

For this week’s blog post I decided to write about important things to consider when doing a technical review on object-oriented code.  I chose this topic as I figured it would serve as a good refresher on key object-oriented concepts that we should keep in mind going forward with the next software testing project.  I thought that reminiscing on good practices of object oriented design would enable us to be more aware of what to look for while writing out software technical review on the Sir-Tommy Solitaire program.

I found a short book entitled Object Oriented Programing that was written by a software professional named Carl Erickson.  Erickson is also the CEO and founder of a software company called Atomic Object.  Although the book was written in 2009, I still think it is relative in the world of object-oriented design today.  There are many sections to Erickson’s book but I plan on looking at just a few sections that I thought were most relevant to writing our software technical review.  The sections I intend to focus on in this blog post are the following: sections 4 – OO Naming Conventions, 8 – Encapsulation & Modularity, 9 – Object-Oriented Hierarchy.

In section 4, Naming Conventions, Erickson briefly touches upon good practice for naming classes, methods, and variables.  He explains that class names should have the first letter of the first word capitalized along with the first letter of every word after that whereas, object variable and method names should have the first word begin with a lowercase letter and all following words begining with capitalized letters.  This probably isn’t news to any of use in CS-443 but it’s definitely something to consider when writing our software technical reviews.

Next, in sections 8 and 9, Erickson explores the ideas of class encapsulation and hierarchy.  Encapsulation is an important idea to consider when writing software technical reviews because improper use of encapsulation such as instantiating a variable as public when it should be private can lead to serious headache down the road.  For example, if something in the code were to go wrong with regards to a public variable that you instantiated, it may be very difficult to track down the culprit of the bug since the variable in question is not private. Also, Erickson brings up the notion of the “is a” relationship between classes, sub-classes, and interfaces which will be significant in determining the flexibility of the code in question.

It’s also worth reading over the rest of the sections in Erickson’s book. In particular sections 10 -14 as they go over essential concepts regarding to object-oriented design.  Section 13 does a good job of explaining how to evaluate whether or not a piece of object-oriented code is designed and implemented efficiently by focusing whether the code adheres to user specifications and object-oriented design techniques. Keeping in mind the foundational concepts of object-oriented design may allow us to make more insightful suggestions and write better technical reviews.

 

 

 

 

 

 

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

Software Analysis and Design Tools

I chose the article “Software Analysis and Design Tools” because I think it’s important to know how to put design knowledge to work using the common tools and practices. Software design and analysis allows the requirements of an application to be converted to actual code. I chose Tutorials Point for this article because I’ve used them quite a bit as I’ve learned different topics in computer science.

The first tool that is mentioned is a data flow diagram. This is basically a graphical representation of the path of data in an information system including incoming, outcoming, and storage. It’s important to know that this flow does not convey underlying “how” the data actually flows, it just shows the path. The two types of DFD’s are logical and physical and they use a set of components to represent data flow and relationships. This includes entities, processes, data storage, and data flow which are organized into different levels which represent a layer of abstraction.

DFD Components

The next tool used is called a structure chart which is actually derived from a data flow diagram. It shows a system in much more detail down to the lowest functional modules and describes the functions of these modules. The actual chart depicts a hierarchy of modules where each layer performs a specific task. The charts use special symbols to represent things like conditions, jumps, loops, data flow, and control flow.

SC Modules

The next tool is called a HIPO diagram which stands for Hierarchical Input Process Output. This diagram represents a hierarchy or modules in a system and depicts all the functions and sub-functions of a module. They are a good tool to represent system structure and allow designers and managers to picture the overview of a system.

HIPO diagrams

There is also a diagram called IPO which stands for Input Process Output. This diagram shows a good representation of control and data flow in a module as the HIPO diagram does not depict the flow of any data.

IPO Chart

Some of the other tools mentioned in the article include pseudo code, decision tables, entity-relationship models, and data dictionaries.

After reading this article I think I realized there’s a step in the software design implementation that I’ve been overlooking. Creating these models and diagrams mentioned is a pre-cursor to choosing a design pattern or implementing any code. Creating a usable understanding of how a system will work is a crucial first step in any design. I think this article did a really good job or covering some of the more popular software analysis and design tools. When it comes time to design an application I will definitely make sure I’ve represented the system using one of these tools before I think about the actual design pattern or architecture I want to use.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

What is system testing?

I chose this topic because I tend to forget exactly what kinds of tests are being done when system testing is mentioned. The term is very vague so I thought it’d be smart to write my own explanation of it. I chose the specific article “What is System Testing?” because I’ve used articles from this website before and have found them to be helpful.

To start, system testing is the testing of a complete and integrated software system. The important part of this is to recognize an entire system and not just one program. Interfaces, programs, and hardware are integrated frequently and there needs to be a way to test how they all work as a system. System testing is how this can be achieved.

System testing is one type of black box testing (as opposed to white box testing). System tests examine how software works based on a user’s perspective. One of the things being tested are the fully integrated applications in an end to end testing scenario. This checks for how components interact with each other as well as the system as a whole. Inputs in the application will be tested and compared to what is the expected outputs are. Lastly, a user’s experience is also part of the system testing to ensure the system flows and can be navigated smoothly by the end user.

While system testing is extremely important it’s not the only type of testing needed and it’s important to realize when it needs to be conducted. Typically it will be towards the end of the development cycle as most of the system needs to be operating correctly in order to properly execute the test cases. Unit testing and integration testing will come prior to system testing and usually acceptance testing will follow.

While there are quite a few types of system some of the more popular types include usability, load, regression, recovery, and migration.

After reading this article I definitely have a better and clear understanding of what system testing is. I think this article gave good explanations and included a helpful video as well. In order to actually implement system testing on a project I’d need to do some further reading on one of the specific types in order to decide what type best covers my system. I haven’t had the need to really implement system testing so far mainly because my programs have been relatively simple. As I head to the work force this type is testing will become very important working on much larger systems.

 

 

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

B10: Mediator Design Pattern

Mediator Pattern

      This week, I chose to talk about a blog I found that went over the mediator design pattern and its implementation. The blog post starts off by explaining that the mediator design pattern is a famous pattern found in the Gang of Four book. It is known to reduce coupling between classes that can communicate with each other. The basis of this pattern is to create a mediator object that has control over the channels of communication between the objects. All messages to other objects essentially must go through the mediator to be directed to another object. The blog post says that this eliminates the need for the deploy objects to have knowledge of the receiver objects. The post goes on to talk about the removal of direct dependencies as it can simplify communication in programs with a large number of classes. It then talks about some of the positive effects this may have like making the code easier to read overall and the maintainability for future editing. The post then goes on to explain the pattern with an example that uses communicating between colleagues and mediators within a project.

      I chose this blog because it was a design pattern that focused on communication between classes which I find very interesting. I found that the explanations this blog uses makes it very easy for me to understand how this design pattern works. The easy to digest wording allows for an easy read that works well with the examples used. The phrasing within the examples allowed the UML diagram and the definitions of the classes underneath to make more sense. The only issue I had was with following the code at first glance due to the fact that it was written in C# but it didn’t take me long to piece it all together. The test classes were well written to show meaningful variable names as well making it easier to understand the parallels they were making from the examples. Through this information I was able to learn that if there is a mediator it can be implemented to make sure all the objects don’t hold unnecessary amounts of code in terms of communication. This will cut down on code within class heavy projects that need objects to remember each other’s addresses. This will help me in my future practice by making the code run much more efficiently and create a better sense of organization that makes it easier to read when dealing with many classes.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Writing Clean, High Quality Code

https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer

This blog discusses various techniques that can be used to make your code cleaner and easier to understand. Writing high quality code is very important for software that is updated over time, and the following tips will help improve your code readability and quality.

Variable and Method Names

  • Use names that reveal the intention of the variable or method
  • Use names that can be pronounced
  • With programming languages that support namespaces it is better to use them rather than prefixing names
  • Use one word per concept throughout the program. For example, don’t use get and fetch to do the same thing in different classes
  • Use solution domain names
  • Use verbs for method names and nouns for classes and attributes

Better Functions

  • The smaller the better
  • A function should only do one thing (single responsibility principle)
  • Less arguments are better
  • Functions should only do what the name suggests and nothing else
  • Avoid output arguments. If returning something is not enough then your function is probably doing more than one thing.
  • Throwing exceptions is better than returning different codes dependent on errors
  • Don’t repeat yourself

Comments

  • Don’t comment bad code, rewrite it
  • Explain your intention in comments
  • Warn of consequences in comments
  • Emphasize important points in comments
  • Always use doc comments
  • Any comments other than the above should be avoided
  • Never leave code commented. With source control software you can always revert back to old code. Comments can be used when debugging or programming, but commented code should never be checked in

Code Smells and Anti-Patterns

The following should be avoided:

  • Dead code
  • Speculative generality
  • Large classes
  • God object
  • Multiple languages in one file
  • Framework core modifications
  • Overuse of static
  • Magic numbers (should be replaced with const or var)
  • Long if conditions (replace with function)
  • Call super’s overwritten methods
  • Circular dependency and references
  • Sequential coupling
  • Hard-coding
  • Too much inheritance (composition is better)

I selected this blog because being able to write high quality code is extremely important in software development. Quality code decreases time spent trying to understand it, making the code easier to maintain and reducing the possibility of bugs. I thought this blog was very well done because it was entertaining to read and gave plenty of examples. Reading this blog helped cement ideas that I learned previously from this class and taught me new techniques that increase code quality. Since none of the information is hard to understand I can begin applying what I’ve learned right now, and hopefully I will continue to get better at writing clean code.

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

HTML (Hypertext Markup Language) and CSS(Cascading Style Sheets)

HTML which stands for hypertext markup language and CSS(Cascading Style Sheets). Are what i decided to read about since with our final project with the typescript and angular , we will need HTML and CSS for it to work properly. Also giving it a better graphical look or user interface with the help of CSS.  Hope you viewers enjoy the article.

 

HTML stands for Hypertext Markup Language, and it is the most widely used language to
write Web Pages.
* Hypertext refers to the way in which Web pages (HTML documents) are linked
together. Thus, the link available on a webpage is called Hypertext.
* As its name suggests, HTML is a Markup Language which means you use HTML
to simply “mark-up” a text document with tags that tell a Web browser how to
structure it to display.
Originally, HTML was developed with the intent of defining the structure of documents like
headings, paragraphs, lists, and so forth to facilitate the sharing of scientific information
between researchers.
Now, HTML is being widely used to format web pages with the help of different tags
available in HTML language.

HTML Tags
As told earlier, HTML is a markup language and makes use of various tags to format the
content. These tags are enclosed within angle braces <Tag Name>. Except few tags,
most of the tags have their corresponding closing tags. For example, <html> has its
closing tag</html> and <body> tag has its closing tag </body> tag etc

A typical HTML document will have the following structure:

Document declaration tag
<html>
<head>
Document header related tags
</head>
<body>
Document body related tags
</body>
</html>

HTML Attributes

Attributes provide additional information about HTML elements.

  • All HTML elements can have attributes
  • Attributes provide additional information about an element
  • Attributes are always specified in the start tag
  • Attributes usually come in name/value pairs like: name=”value”

 

Now let get into CSS(Cascading Style Sheets).

CSS(Cascading Style Sheets) describes how HTML elements are to be displayed on screen, paper, or in other media. It saves a lot of work. It can control the layout of multiple web pages all at once

CSS is designed primarily to enable the separation of presentation and content, including aspects such as the layout , colors , and fonts . This separation can improve content accessibility , provide more flexibility and control in the specification of presentation characteristics, enable multiple HTML pages to share formatting by specifying the relevant CSS in a separate .css file, and reduce complexity and repetition in the structural content.

Separation of formatting and content makes it possible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. It can also display the web page differently depending on the screen size or viewing device. Readers can also specify a different style sheet, such as a CSS file stored on their own computer, to override the one the author specified.

Changes to the graphic design of a document (or hundreds of documents) can be applied quickly and easily, by editing a few lines in the CSS file they use, rather than by changing markup in the documents.

example of Css

<!DOCTYPE html>
<html>
<head>
<style>
body {
background-color: lightblue;
}
</style>
</head>
<body>

<h1>Hello World!</h1>

<p>This page has a light blue background color!</p>

</body>
</html>

output:

Background will turn lightblue. try it!

Even though i know much about this article. It really helped me refreshed my mind on some stuff i forgot. now with no doubt , i know i will utilized this info to work better on my final project. Hope you guys also find this article very useful.

references : 

https://www.codecademy.com/courses/web-beginner-en-HZA3b/0/1?curriculum_id=50579fb998b470000202dc8b

https://www.w3schools.com/css/css_intro.asp

https://en.wikipedia.org/wiki/Cascading_Style_Sheets

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-11-13 23:46:47

Knowing what you know

knowing what you don’t know

not having a means to discover what you don’t know

not knowing what means exist to learn what you don’t know

not knowing how knowledge acquisition works

can we answer these questions concretely or only philosophically?

What is quality?

one answer: How well the customer or user of a thing views it as useful/helpful

feels good to use it

easy to operate

know what it can do and can’t do and am happy with that

joy out of using it

customized, personal, based on individual

quality =/= bug-free

one piece of software has a lot of known bugs but is heavily used by thousands or hundreds of thousands of people, another one is bug-free but only used by 10 people, which is higher quality?

The context, its ability to solve a problem in that context,

does it solve the problem in the context in which we’re expecting to solve that problem, without unexpected consequences

chair w/out a seat is low-quality bc you expect to be able to sit on a chair. can’t serve its basic purpose

different chair with seat, but front right leg is 3 inches too short. Leaning back is fine but leaning forward you might fall on the floor. A higher quality chair wouldn’t “crash” like that

how delightful is it to sit in the chair

not just requirements or fitness for use

value to some person

what is a test case?

Specific action and outcome

thing u wanna try and a result you wanna verify

ex. post a message to slack, verify it shows up

1 dude argues it’s still one test case if you perform the action and verify the result across different OSes

any time inputs are applied to a program, outputs generated, and a judgment call made.

Judgment call might be different based on context

judgment calls are the hardest part of testing, and it’s based on your own definition of quality

what is testing?

1: Investigating, evaluating, learning, sometimes judging?

Vs

2: only judging, that’s what we hire testers to do

1: not only judging: giving new ideas for inputs and outputs

new ideas for tests can follow from results/judgment calls of previous tests

breaking things, discovering where things fail

identifying those judgment calls? The judgments that would put the product at risk

what’s a tester?

Keenly focused on risk-to-return

lowering risk on high-value quality propositions

what is integration testing?

Making sure all the pieces fit together

the tests you write to make sure other people don’t break you

input, output, judgment call = does your component still return the expected results that my component is counting on?

performance testing

inputs and outputs that let you know product is performing as expected

how long actions take in application over a variety of scenarios

key actions product takes and how long each of them takes in different contexts

output = time, judgment = is the time it takes acceptable/good?

Is faster always better? no. only has to be fast enough for the customer

easy to increase performance in the wrong areas. Make the parts that matter fast

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Future of Testing Continued

A while ago (long while), I talked about an interesting post about the something called Test Ops in this post: https://fusfaultyfunctions.wordpress.com/2017/09/20/the-future-of-testing-taking-an-interesting-turn/.

Now I’d like to talk about a post by Awesome Testing describing an important topic in Test Ops, Testing in Progress. Essentially, its a set of ways of testing that utilizes real users and the different ideas and implementations that arise in a production environment. So how do you test a new feature or update produced for a service.

Obviously, the one metric is that it works without errors for the users. But the next most important metric, is the number of users it retains. The amount of people using the service and continuing to use the service is the most important thing for these applications. And this needs to be tested.

Now what do you do when you produce a new feature and need to test it? You could just throw it out into the wild and then see how the statistics work out. If it worked, keep it, otherwise throw it away. But that can annoy users and make you lose people.

There is no one best way, but there are several different ones used. There’s risks that need to be mitigated. So the first method outlined is Blue-Green Deployment, or Canary Deployment. You deploy the new feature or software on a separate series of servers, the blue pool. Preliminary tests are done, internal, users, and then if it looks good 5% of users are redirected to it from the original servers, the green pool. Then you can see how well the new software is working. If it doesn’t look good, move everyone back to the green pool.

Test Flights are similar. You hide a new feature in a code path, with another code path without the feature. By changing a config file, you show the new feature to users in the same manner as in Canary Deployment. First internal users, then lets say 5%. The feature can always be reverted with a change of a config file. A/B testing is a bit more extreme, essentially you have, say, two variations of an application. Fifty percent of users see one and the other, and the one that retains the most users becomes the finalized version.

There’s also a technique where faults are intentionally injects in software. In this way, it leads to a design that focuses on being secure. And then there’s one popularized by Microsoft. Developers are forced to use the applications that are being developed locally, to ensure the program is a reasonably good user experience.

Overall, it’s really interesting seeing the considerations required when dealing with testing new software. I never considered that not only would testing test for working product, but one that works well too. It makes testing a much more complicated, yet exciting field. It also makes the job of a tester much more integral to the success of an application.

Original Post: http://www.awesome-testing.com/2016/09/testops-2-testing-in-production.html

From the blog CS@Worcester – Fu&#039;s Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-11-13 23:23:40

The resource I discovered this week is partially a blog post, but mostly the mobile app that the blog post is about. The app is called Enki. It’s similar to the language-learning app Duolingo, but its purpose is to help people learn new software development skills in small chunks every day. The blog post explains why the app was developed: the options that currently exist for ongoing learning about software development take a lot of time, something developers tend to be short on. They can also be boring and inefficient. The app creators wanted something fun, engaging, useful, and quick. The mobile platform was selected so that users would always be able to have it with them, and therefore be able to squeeze learning into limited free time like a work commute or the time it takes for their code to compile. The daily lessons, called workouts, stick to small tips and bits of applicable information instead of getting bogged down in details that people who’ve passed the beginner stage probably already know. They’re also designed specifically with avoiding boredom in mind, so the workouts contain engaging challenges and game-like elements.

I chose this resource because it’s one of the only

books and video courses

Blog post explained why the app was developed

current options for [continuous] learning

they wanted something that could help you practice a little bit each day

Affected me immediately because I downloaded and started using the app. So far have only brushed up on html skills, but it seems interesting, and I intend to keep using it. It seems like a fun way to learn new things or to get a refresher.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Web Application Testing

Source: http://www.softwaretestinghelp.com/web-application-testing/

This week I decided to look up different types of testing and I found a blog that talked about web testing. This website called software testing help had a blog that talked about web application testing and it gave a complete guide about testing web applications. I tried to find who the author of the post is but I could not find the name but the author talks about some web testing cheklist that programmers should go through before deploying their website. Which are

 1) functionality testing:

you should test your website to make sure that all of the links, forms, cookies, html, css, and database all work fine. It is important to make sure that the links are not broken links and that the code that you want to display onto the website are displayed correctly and in the right position.

2) Usability testing:

The usability test means that the website should be easy to use, any and all instructions that are on the website should be clear. There should be a main menu link on every page and it should be constant though out the website. You should also make sure that there are no spelling errors, all the fonts, colors, frames, etc. are all on the right setting.

3) Interface testing:

Check if the interacting between the website and the servers are functional and any errors that are given are handled properly.

4) Compatibility Testing:

Make sure that the browsing compatibility is available for all sorts of browsers and OS such as Firefox, google chrome, AOL, windows, MAC, Linux and other OS and brewers that are available today.

5) Performance testing:

You should make sure that the website can handle heavy load of traffic though the webpage so it does not crash and would be able to handle large user request simultaneously. A web stress test is to test the specific limits of the website and sees how the system reacts when it crashes and recovers from those crash.

6) Security testing:

Finally you want to make sure the security for the website especially a website that would take personal data and save it on its data base be secured enough for people to log in and feel safe that their personal information is protects.

I like this blog because right now in our class we are going to be devolving our own website and even though we are not going to have it be deployed to the public there are some testing in here that are good to remember when writing our code. In future situations when I am writing programs for websites this blog is a good reminder of what kind of tests I should do to make sure that I am doing everything before I deploy a website.

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.