Category Archives: Week-15

Hashmaps Blog 2

Today I read an article on baeldung.com 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.

https://www.baeldung.com/java-hashmap

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

 

https://apiumhub.com/tech-blog-barcelona/top-benefits-of-unit-testing/

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.

Fuzz Testing

Source: https://www.guru99.com/fuzz-testing.html

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)

 

USE NOUNS BUT NO VERBS IN PATH/URI:

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

USE PLURAL NOUNS

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

 

SOME TIPS FOR YOU:

  • 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.

 

References:

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

https://restfulapi.net/

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

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 vs. REST

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.

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.


Article: https://stackify.com/design-patterns-explained-adapter-pattern-with-code-examples/

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

I’m Sorry, an Anti what now?

Good day once again my fellow readers! In my readings this week, I discovered something that I had never heard of before, antipatterns. Now that is quite a striking name and it piqued my interest in this subject. So today I will be talking about software development antipatterns, particularly the Blob.

First, let’s discuss what an antipattern even is. An antipattern is simply just an industry term for a common solution to a problem that generates negative consequences. what antipatterns can do for us is twofold. First, they provide a template to help us recognize common problems that can crop up in software development. With this knowledge, we can recognize an antipattern when we see one and identify the cause of it as well. The second part is that antipatterns provide a constructive solution to fix the underlying cause of the antipattern and to implement solutions that can be applied at several different layers in design. Let’s look at the first antipattern I discovered, the Blob.

The Blob is much like its namesake of horror film fame, the Blob. Here one single complex controller class is surrounded by many smaller data classes that merely encapsulate data. In this architecture process is separated from data, thus making this procedural style architecture. Some typical causes of the Blob are lack of object-oriented architecture or lack of any architecture whatsoever. A common occurrence of the Blob is from iterative development where code evolves from proof of concept to a prototype to a functional system. Another cause is a lack of architecture enforcement. But how can we fix this Blob problem?

Refactoring to the rescue! The first step is to locate sets of operations and attributes that directly relate to each other under a common goal. The next step is to locate natural homes from these groups and migrate them to their new homes. We then remove all redundant, indirect associations and migrate associates to derived classes to a common base class. Lastly, remove all transient associations, replacing them if appropriate with type specifiers to attributes and operations arguments.

This discovery of antipatterns for me was quite the find. I don’t know what but I still get a strange feeling when I hear antipatterns. It just sounds so menacing. The Blob was an interesting first antipattern to read as I’m positive that over my past coding projects, many of them would probably fall into this antipattern. It is nice to be aware of these potential issues now, rather than further down my career where it could have a greater impact if I ever do fall into the trap of an antipattern. I definitely plan to read more about these antipatterns and I plan to write about another one next week.

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.

REST APIs – A Few Good Guidelines

Today I will be looking at an article that examines five basic guidelines when creating a REST API program. I thought that after spending over a month on our final project creating a REST API backend it would be good to review some good practices for creating these REST APIs. The article gives five basic guidelines to follow and a brief background on each of the guidelines. The five guidelines are: name and case conventions for URIs, the different HTTP methods, HTTP headers, query parameters, and status codes. Some of these topics were a refresher from what we’ve already been taught, such as some of the HTTP status codes, and others were new such as the query parameters or case conventions. I especially thought the name and case conventions for the URIs was interesting. I don’t think I have reviewed naming conventions in coding in a couple of years, I usually use camel case for everything since I mostly write in Java. But I have been wondering what was the best practice for endpoints since I remembered code with HTML being more case sensitive. Also, with using different naming schemes instead of just using verbs that describe the method as in Java. I will keep in mind going forward to use the spinal-case method when creating endpoints. The HTTP methods section was fairly straightforward with what I already know, and the use cases for most of them are the same, but it does have a couple of additional methods I haven’t seen before such as HEAD or OPTIONS. The HTTP headers section was interesting, giving definitions and names for the different types of headers you use for different requests. The query parameters section was the most interesting and something that I haven’t come across yet working with REST. The status codes were familiar too, I have mostly used OK, CREATED, and NOT FOUND in my endpoints. Although I will start using NO CONTENT when performing a deletion endpoint instead of just 200-OK, as this seems to be the more proper response code. The same with using a 400 error of BAD REQUEST instead of just giving everything a 404-NOT FOUND error when an invalid request is made or an item is not available. In the future when working with REST I will keep in mind these simple guidelines from this article, especially in regards to case conventions for endpoints and with using appropriate status messages.

Source: https://dzone.com/articles/5-basic-rest-api-design-guidelines

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