Category Archives: Week-15

Hashmaps Blog 2

Today I read an article on about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

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

White Box Testing Blog 2

Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

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

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to Captureproduce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC refers to whole process of software development. It defines and describes, each and every phase that contributed towards the development of the software.

What is the need for SDLC? Software Development is a tedious and complex job. As such, standard guidelines and established framework works well to carry out the development process in an effectively organized manner, repeatedly for each unique software product. Segregates the process of development life-cycle into separate phases, for their independent and smooth implementation. And to minimize failures in a software project. There are six phases of Software Development Life Cycle in a subsequent manner:

Requirement Gathering and Analysis: This phase visions the gathering of business requirements, followed by the analysis to study and validate the feasibility of these requirements for implementation in the system. Client and Project Manager are the key persons in this phase.

Design: blueprint/software design is prepared, based on inputs, provided from the requirement gathering and analysis phase. This blueprint helps in determining the requirements, needed in the development of software such as hardware and system requirements. The outcome of this phase is software design.

Implementation: The software design is implemented in this phase through coding and programming. This phase generally involves modules and codes. This phase is developed or working software product that acts as an input for the next stage.

Testing: developed software is handed over to the testing team, to evaluate and validate the functioning of the software product, in accordance with its pre-defined requirements and meet the end users’ expectations.

Deployment: After getting through testing phase, successfully, software product is ready to get deployed on customer’s side for its use

Maintenance: Maintenance phase is all about resolving defects or issues, occurring on the customer’s side, while using the software product. It ensures the fixing of all issues post the deployment of software product at the customer’s site.

This is the main steps of software review, it is a standard practice that empowers organizations to follow systematic & well-defined approach, for carrying out the development in an effective way, so as to achieve desired software product of highest quality. I find this blog helpful to follow and make sure product is going to the direction.  These steps need to apply to future product., as I have seen so many products got issues and have to call back.

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


Hello dear reader. After explaining what API is, now I would like to talk about Architectural Styles for API. One of these styles is called SOAP.

SOAP stands for Simple Object Access Protocol. SOAP is a standard based Web services access protocol that enjoys the benefits of long-term use. SOAP is developed by Microsoft.
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet. These technologies are bad and fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-ReliableMessaging, WS-Policy, WS-AtomicTransaction, WS-Federation, WS-Coordination, WS-Security, and WS-RemotePortlets. In SOAP you can only choose to use the pieces you need for a particular task.As we know, in some programming languages, you need to build requests manually, which becomes problematic because SOAP is intolerant of errors. However, SOAP provides shortcuts to help in this issue. The difficulty of using SOAP depends on the language you use.
One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports.
As SOAP is an ordinary XML file that consists of the following parts: 1. Envelope, which is the starting and the ending tags; 2. Header, which it allows you to extend the SOAP message in a modular way; 3. Body, which contains XML data that the server send to the receiver; 4. Fault, which carries the information about errors occurring during the process of sending the message.

SOAP is mostly used for enterprise-lever web service because that require high security. Some examples of SOAP that I found online were: financial services, payment gateways, identity management and telecommunication services. Also another feature of SOAP is that the API calls can not be cached. The biggest disadvantage is the poorer performance, more complexity and less flexibility.

I didn’t know SOAP existed until I searched for REST (the next blog). The reason why I choose to write about SOAP is that it is a wide used architectural style for API and it has its own place of use, places or situation where REST can not be used.

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

Fuzz Testing


This week’s reading is on fuzz testing. It is defined as an automated technique that is used to uncover errors that will most likely missed by manual inputs. As it is a black-box testing technique, it deals with the execution itself rather than going through the source code. Due to the way the technique works, it will be able to find serious defects and security loopholes in the software it is tested. It’s also stated that the technique is one of the most common method for hackers to find vulnerability in systems. The general steps to fuzz testing is identifying inputs, generating fuzzed data, executing tests using that data into the system, and logging all of its findings to be reviewed. Typical bugs detected by fuzz testing is assertion failures, memory leaks, invalid input, and correctness bugs. It’s very simple but will improve the quality of the software and improve security overall.

I found it interesting that the article mentions that it is a common method for hackers to use fuzzing in order to gain access into a system. However, I am not surprised that they do considering its overarching objective. Knowing that the technique is used by testers to find vulnerabilities in software, it doesn’t hurt for hackers to see if the common vulnerabilities have been accounted for through testing. Another interesting tidbit would be about correctness bugs, as I do not remember being able to test for corrupted databases, poor search results, and etc. using other techniques available. I also agree that fuzz testing alone will not solve all of the security issues. As it will account for invalid inputs, correctness bugs, memory leaks, and assertion failures. There are probably other methods available that are specialized towards handling complex security threats. In other words, fuzz testing will only help identify common vulnerabilities and sometimes help against major ones. Knowing that this method exists for black-box testing, as with other methods available through white-box testing. By using it in conjunction with other effective methods will create a product that is of high quality, secure, and cost-effective. Its similarity coincides mutation testing as it ensures the software is robust. In conclusion, it is fuzz testing is useful for showing presence of bugs in an application but will not guarantee full coverage.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

REST – Representational State Transfer

REST is a term coined by Roy Fielding to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.  It represents the state of database at a time. REST is an architectural style which is based on web-standards and the HTTP protocol. In a REST based architecture everything is a Resource. A resource is accessed via a common interface based on the HTTP standard methods. You typically have a REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.  Every resource should support the HTTP common operations. Resources are identified by global IDs. REST allows that resources have different representations, e.g., text, XML, JSON etc.

HTTP Methods

The PUT, GET, POST and DELETE methods are typically used in REST based architectures. The following table gives an explanation of these operations:

POST –> INSERT (adds to an existing resource)

PUT –> UPDATE (overrides existing resource)

GET –> SELECT (fetches a resource, while the resource is never changed via a GET request)

DELETE –> DELETE (deletes a resource)



Purpose Method Incorrect Correct
Retrieves a list of users GET /getAllCars /users
Create a new user POST /createUser /users
Delete a user DELETE /deleteUser /users/1
Get balance of user GET /getUserBalance /users/1/balance


Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

/cars instead of /car

/users instead of /user

/products instead of /product



  • Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET method or Query parameters for state changes.
  • If a resource is related to another resource use sub resources.
  • Both, client and server need to know which format is used for the communication. The format has to be specified in the HTTP-Header.
  • Make the API Version mandatory and do not release an un versioned API.
  • Use a simple ordinal number and avoid dot notation such as 2.5
  • Use a unique query parameter for all fields or a query language for filtering.
  • Allow ascending and descending sorting over multiple fields.
  • Use limit and offset. It is flexible for the user and common in leading databases.
  • To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths.



Thank you for your time!





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


SOAP and REST both allow you to create your own API. API stands for Application Programming Interface. It makes it possible to transfer data from an application to other applications. An API receives requests and sends back responses through internet protocols such as HTTP, SMTP, and others. Many popular websites provide public APIs for their … Continue reading SOAP vs. REST

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Behavior-Driven Development

Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.

BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.

Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.

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

Common Software Testing Techniques

Good day, again dear reader! With classes wrapping up this week and finals starting, I was a little curious at what other testing techniques there were for testing that were not discussed in class. Of course, this lead me to an article called, “The 7 Common Types of Software Testing“. This article had a mix of things discussed in class and some new ones as well.

The first type of test was a black box test, something we discussed in class. In fact, it was among the first we discussed. For a brief review, black box testing is when we are solely concerned with inputs and outputs and we don’t know anything about how the code works or calculates the actual results.

The second test mentioned is white box testing. Another testing method discussed in class. If I remember correctly, it was discussed on the same day as black box testing. Here in white box testing, we can see inside and get a feel for how the program actually works and calculates outputs.

Acceptance testing is a new one to me. Acceptance testing is two-fold. It tests both the system as a whole and it tests the actual requirements of the customer. This test is geared more towards user-friendliness and usability that some of the other tests.

Automated testing is simply any test that has been automated. This I think is more part of other test techniques and not its own technique.

Regression testing is testing the system to ensure that it works the same way as the previous system. This is done in incremental development to ensure that as new parts are added, the original system isn’t broke.

Functional testing is the testing of the system to see if it is functional. The author points out that there is more than just functionality to test for a program and uses that to justify functional testing as its own technique. I’m not quite sure about this decision but I can stomach it for now.

Exploratory testing is testing a system without any actual test cases and exploring the system looking for things that might be wrong or unexpected. Reading the description, it appears to be for testing systems in unusual ways that might not be conventional and testing the boundaries of a system, possibly uncovering bugs that normal testing methods might not find.

Of these new test methods, none of them have really captivated me. Exploratory testing, being honest, sounds a little silly and I can’t really see too many benefits to it. Out of all seven I quite like acceptance testing as it seems to keep the focus shifted to the customer and not just to it the system works or not.

Until next time readers!

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

Adapt or Git Left Behind?

CS SERIES (15)As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.

On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.

I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).

Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.

An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.

I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.


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