For this weeks blog post I will be discussing the pattern known as Draw You Own Map. The context behind this one is that any given employer can offer only a limited subset of all possible career paths. The problem that would arise from this is that none of the career paths your employer provides actually fits you. The solution that would come from this situation would be to simply identify the next logical but ambitious next step in your career. Realize that it is not up to your employer, your career counselor or your professors to give you a hand up or decide your fate. Arriving at the next step and charting the course is a decision that ultimately comes down to your responsibility. You need to take the first step that is the most important part, even if that step doesn’t seem to significant. This first step should generate the momentum needed to help carry you toward your goal, no matter the terror you may feel. Try to define small, yet achievable steps allowing feedback that you can use to modify your road map which could also make it easier to get help from Kindred Spirits to achieve said goals. If the vision of which your employer sees of you and the one you see of yourself do not match your preferred accordance examine the opportunities to see if they’re heading in the desired direction. Instead follow other successful apprentice paths that share a resemblance to what you are going through. You should constantly reassess your map as your circumstances and values change. Sometimes the map will be in accordance with that of those around you, other times the map will require you to chart your own path through the wilderness. The only constant is that the map is yours, and you are free to redraw it at any time. A good action to take with this is that you could list three jobs that you think you could do while following the current one. Then begin to list three jobs each of those would lead to. Are these really the full range of desirable jobs for the next few years of your life? Ask yourself if this set of jobs is more representative of the range of career options you have before you and what places you want to take in this career. If you are unhappy with the list so far, repeating the exercise with different jobs, business or technology domains could help. Then repeat the exercise again to see where you would end up. Yet again this is something anyone who catches themselves in should do, as it will help you in the long run and in general.

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

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.

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) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce 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.

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 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:

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.

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.

https://docs.cucumber.io/bdd/overview/

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

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.