Category Archives: Week 9

What is microservices architecture?

I chose the topic after googling about the different types of software architecture and realizing I’d never read about microservices. I chose this specific article titled “Microservices” because I know Martin Fowler’s blog contains reputable information as he’s also been referenced in class. Microservices architecture is a way of designing applications as groups or suites that can be deployed independently as a service. While he mentions there is no exact definition, this style usually has similar characteristics around capability, automated deployment, endpoints intelligence, and decentralized control of data.

The microservice style is a newer and more common approach for enterprise applications. It’s a single application as a suite of small services. Each service runs in its own process and usually communicates with an HTTP resource API.

One key feature of microservices architecture is componentization via services. The different services of an application are a way to break down the software by components. These services are out of process components that communicate using web service requests. An advantage of using services as components instead of libraries is that they can be deployed independently. Therefore only requiring a single service to be deployed when there is a change.

A second key feature of microservices architecture is that it is organized around business capabilities. This approach combats the negative effects of separate teams working on an application as management usually splits focus between the technology layer, leading UI teams, server-side logic teams, and database teams. Services allow teams to be cross functional and include a full range of skills as products can be split up by individual services and communicate via a message bus.

Some of the more brief features of microservices architecture include the idea that a team should own a product over it’s lifetime and not just treat it as a project. Additionally microservices usually follow a decentralized governance which is less constricting and allow each service to take advantage of different technology that best suits the service.  Lastly decentralized data management is common using microservices. Typically each service will manage its own database.

After reading this article I definitely have an idea of what microservices architecture is but I think I’d need a more beginner level article to explain it. There were definitely some terms and concepts that Martin referred to that I wasn’t familiar with. One thing I did like about the Article was that he mentioned how well known companies use some of the technology he was talking about such as Amazon and Netflix. Seeing as microservices are mainly used for enterprise applications I have yet to gain any experience with them but most likely will in the near future.

 

 

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 Functional Testing?

For this blog I’ll be covering the basics of functional testing based on the article I read titled “Functional Testing Tutorial“. Although this topic is a pretty broad topic, it will compliment my previous blog covering “What is non-functional testing?” Functional testing is when each function of an application is tested and verified that it satisfies the specifications and requirements. Most functional testing is black box testing and does not deal with any of the actual code. To test all of the functions in an application testers provide input to the function and verify the output with what is expected. This is carried out either by manual effort or automated testing.

Aside from testing each individual function, functional testing also checks system usability, system accessibility, and error conditions. Basically a user should not have difficulty using a system and in an error condition, the correct error message or procedure should be followed. In order to carry out functional testing there is a basic testing process that must be followed. First identify the test data or input, then calculate the expected outcome and values, execute your test cases, and last conduct a comparative analysis to make sure all expected outputs match the actual outputs.

The article moves on to compare functional and non-functional testing to give an idea when each is used. Functional testing is usually done first and can be manual or automated. The testing coverage is used to ensure business requirements are met based on inputs. Functional testing is more a description on what the product or system actually does. There are a lot of ways to implement functional testing for a system. Some of the most popular types are Unit Testing, Smoke Testing, Sanity Testing, Integration Testing, White Box Testing, Black Box Testing, User Acceptance Testing, and Regression Testing. A few of the popular tools used to execute these tests include Selenium, Junit, and QTP.

After reading this article I’m confident I’ll be able to classify a type of testing between functional and non-functional. The article didn’t go too specific into the execution of functional testing but that’s because there are just too many types to generalize the implementation. When I want to actually execute and implement functional testing I’ll have to read more in depth into one specific type in order to actually test a system. I think the most important concept of functional testing is to remember that the business requirements are most important. That being said it will be important to make sure the business requirements are fully understood through the development cycle to ensure proper test coverage.

 

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

Why TypeScript?

We’re beginning to work on our final class projects using Angular and TypeScript, both of which I was previously unfamiliar with before this semester. Since our projects will be implemented using the Angular framework and the TypeScript programming language, I want to learn more about the concepts behind these applications. I found an informative blog on the subject; it is entitled Angular: Why TypeScript? by Victor Savkin. The main topic here describes the benefits of using TypeScript in general, and how it is an efficient means of producing quality Angular projects.

Victor points out that while using TypeScript for Angular projects is not required, but is encouraged to be used within the framework for several reasons; many of which I will summarize here. I will also offer my personal thoughts and takeaways regarding the content.

Prior to reading Victor’s blog, I was not familiar with the fact that Angular was written in TypeScript. Now it makes more sense to me why we are going to be using TypeScript to code our projects; since Angular was written in TypeScript, it ought to have high compatibility with that particular language.

Another encouraging aspect brought up by Victor is the fact that TypeScript is equipped with many useful tools, such as “auto-completion, navigation and refactoring.” Based on his explanations, I feel that TypeScript is a very flexible language; for example, if we need to rename an instance, it seems that TypeScript will automatically change all implementations of that instance to its new name without having to do it manually. I find this to be a very powerful and efficient feature that I look forward to using while coding future projects.

Victor also eludes to the fact that TypeScript is actually a superset of JavaScript, something I was completely unaware of. I find this fact very interesting in the sense that it suggests that anything that can be done in JavaScript can be implemented in TypeScript. Victor even suggests we can rename a JavaScript .js file with the .ts extension, and with the proper annotations, the program could theoretically run completely in TypeScript.

Victor further explains that TypeScript simply makes code “easier to understand” rather than other languages such as JavaScript. I tend to agree with him in the sense that it seems that TypeScript offers explicit declarations, such as that of parameters, interfaces and abstractions. It seems that JavaScript does not offer much of this functionality. Victor offers sample code, first implemented in JavaScript, and then again in TypeScript. In my opinion, the TypeScript code is much easier for me to comprehend due to the explicit declarations that are lacking in JavaScript.

Reading Victor’s blog has made me further intrigued with the capabilities of TypeScript; I learned that it is even more flexible and powerful than I originally thought. Based on Victor’s insights, I feel that learning TypeScript will be useful to me during my professional career, since he states that it is widely used in the field of Computer Science.

 

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

Writing Great Test Cases and Becoming a Great Software Tester

I completely agree with Kyle McMeekin when he states in a blog post titled “5 Manual Test Case Writing Hacks,” from April 11th, 2016, that it should come as no surprise that great software testers should have an eye for detail. What may not be as obvious, however, is that great software testers should be able to write great and effective test cases. McMeekin goes on to observe that writing effective test cases requires both talent and experience. In an attempt to begin my journey to become a great software tester, I decided that I should pay close attention to the advice offered by experienced testers as they reflect on the skills they have gained from their time in the industry. Hopefully, by following the tips of more experienced testers, I too will someday be able to contribute to highly valuable test cases the improve productivity and help to create high quality software.

The first step to writing great test cases is knowing what components make up the test case. While many of the components were obvious to me, there were others that I had not thought of. The test steps, for example, are important because the person performing the test may not be the same person who wrote the test. Knowing how the test should be performed is important to obtaining a valuable result from the test.

What I found most valuable about McMeekin’s post, however, were his tips on how to “write better test cases that will lead to better quality software for your company.” His first piece of advice is to keep test cases simple. They should be in simple language, and follow the company’s template. Although not specifically mentioned in this guide, I remember reading that if a test case seems to become too complex, you should begin considering breaking it up into smaller pieces. Second, McMeekin recommends making test cases reusable. Taking into consideration that your test cases could be adapted to other scenarios or reused in another application should help to develop test cases that are reusable. Third, McMeekin suggests placing yourself in the shoes of the tester or developer rather than the test-case writer, and being your own critic. Considering what parts of your test-case may be ambiguous or frustrating for others using them will often help to create better tests. This goes hand in hand with the fourth recommendation, which is to think about the end user. Understanding the expectations and desires of the end user will certainly help to create test cases that lead to better, more successful software. The last recommendation that McMeekin gives is to stay organized. This suggestion could apply just about anywhere, but with hundreds or possibly even thousands of potential test cases, staying organized is certainly essential to being a great tester.

Although I am sure there is a great deal more to consider in my quest to one day become a great software tester, I think that keeping these things in mind will certainly improve the quality of the test cases that I write. In the rapidly advancing field of computer science, I don’t feel that I will ever stop learning new and improved ways of doing things or further developing my skills.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Thoughts on the Angular Material Datepicker

While researching how to make the dreams of developing a countdown clock Angular application for the final project of Software Construction, Design, and Architecture, I came across an interesting writeup on the Angular Material Datepicker by one of the Angular Material developers, Miles Malerba. With plans of creating a user-inputted countdown timer, a datepicker component sounded like welcome alternative to making one from scratch. I decided to look further into the Material Datepicker to see if it would be something that could prove useful.

The Material Datepicker includes support for the required attribute, which is used for data validation when a form is submitted. This seems like a worthwhile feature, as it would make little sense to allow the user to create a countdown timer without inputting a date to countdown to. The datepicker also has an additional mdDatepickerFilter attribute, which allows for “finer grained control of what’s considered a valid date.” This also seems like an important feature for a countdown timer input, as I would want to disallow users from selected a date in the past, as this would be invalid to count down to.

While I had not previously thought about supporting mobile users with my countdown timer application, the Material Datepicker’s mention of a specific “touch UI mode” made me reconsider. I think that a countdown timer that is tailored mobile users would be an important audience to appeal to. Perhaps mobile users would have more use for a countdown timer on their phones than on the computer. I will have to look into the possibility of supporting mobile users.

While it does not apply to my project, I thought that the Material Datepicker’s DateAdapter and support for any locale was an interesting addition. The DateAdapter is an abstract class that allows developers to specify the formatting of dates, which allows for representations of 1/2/2017 to mean January 2nd, 2017 in America and February 1st, 2017 just about anywhere else. Since my project will only need to include support for the American date representation, the included NativeDateAdapter class should fill my needs. This class uses the Javascript Date to represent dates, which is the American version mentioned earlier.

In conclusion, I think that Angular Material Datepicker will certainly help in the development of my Angular Countdown Timer Single Page Application (SPA). Having a datepicker component that is already written will allow me to focus on the more important aspects of design, such as allowing users to save their countdown timers by implementing database calls. While there is certainly still much work to be done on my Angular SPA, reading about the Angular Material Datepicker has me excited to get started developing.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Stubs, Mocks and Service Virtualization

We’ve been discussing the differences between stubs and mocks, along with the fact that many software testers may initially assume the two are the same concept. But as we have learned, mocks and stubs are not synonyms; they are two different techniques used within unit testing.

I wanted to learn more about some specific differences between stubs and mocks, such as potential advantages and disadvantages of using each of these techniques. Wojciech Bulaty has an informative article on the subject. Before getting into the pros and cons of each aforementioned technique, Bulaty explains the main concepts of stubs, mocks, and service virtualization.

He asserts that stubs use hardcoded data within the testing program itself, where the tests depend on this data. Based on Bulaty’s description of stubs, it seems it would be most beneficial to me to apply stubs when testing simpler code where no more than minimal implementation of an interface is required.

Mocks on the other hand seem to be most useful in situations for larger, more complex tests to “verify output against exceptions.” In my opinion, mocks ought to be used in addition to stubs to further satisfy the integrity of our testing. For instance, mocks may produce findings that stubs could not, due to the limitations of the hardcoded data within stubs. On the other hand, I feel it may be useful to use stubs as well, to help compare its findings with that of the mocks within our tests.

Bulaty introduces a third method to use within our unit tests: service virtualization. I found this particularly interesting because we haven’t discussed much about service virtualization in class yet, and this article helped me learn more about it. He explains that service virtualization supports testing through multiple protocols, and employs “test doubles” which are usually offered as Software as a Service (SaaS). It seems to me that service virtualization relies more on recorded data from a wide scope of different projects, whereas stubs and mocks are typically written by developers of their own projects.

My main takeaway from this article was recognizing some differences in particular between mocks, stubs, and service virtualization that were previously a bit unclear to me. Whereas stubs seem to concentrate on state verification, mocks tend to be more focused on behavior interactions within our code. I also learned which testing techniques may be most appropriate in regards to the particular code we are testing. For instance, if I am testing simpler tests with limited resources, based on what I’ve learned from this article, I will likely use stubs for my testing. But for larger, more complex tests, I feel I ought to implement mocks within my testing as well. Finally, when I am involved in large scale projects during my professional career, Bulaty’s article has convinced me that I should look into using service virtualization in addition to stubs and mocks when performing unit testing.

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

B9: Chain of Responsibility

Chain of Responsibility

      This week I chose to write about a blog that talked about the behavior design pattern known as the chain of responsibility. The post explained that behavioral patterns are used to build foundations that allow objects to communicate and give each other jobs to do. The chain of responsibility pattern makes it easier to chain objects into an order set and when a logical requirement or command is sent through the chain, it checks through the chain until an object is found that fulfills this requirement or command. It then goes on to explain some real-life applications for this design pattern like government and business systems where there is high value in order of commands. The post also clarifies that in the chain of responsibility the order moves upward rather than downwards which means that it starts at the bottom of the list and moves up. There is code shown afterwards that shows how the pattern works in a programming setting using book titles as an example. Using book titles, authors, and cover types, a chain of responsibility is created and tested by calling those objects based off one of those specific properties.

      This post really interested me because it was noted as a foundational design pattern which made it seem important to learn. The examples were helpful in this post as they allowed an easier understanding of the material using real code. The analogies that were used could be a bit better but overall, they weren’t too hard to grasp. The real-life applications that were shown were interesting but in my opinion there could have been more explanation as to what specifically this pattern could accomplish within business and government. The blog helped me solidify the idea that the chain of responsibility is created with objects and goes through each object to find the specific requirement needed. I did not know that the chain started from the bottom and went upwards which is good to know but I would like to know more about the efficiency of the order in the chain. More specifically, is there a way to efficiently order the objects in the chain to make it run faster? Does the order matter within the chain enough to influence efficiency? These were some questions that I still had after reading this post, but it was a good source of information to help me get an introduction to the design pattern. This material affected me by showing be a new way to code using a foundational design pattern. This will affect my future coding practices as I can now identify situations where I can apply this pattern to make it easier to organize and run better.

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

Java Testing Tips

Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on ZeroTurnAround.com by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.

The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.

To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.

The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.

Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.

Link:

https://zeroturnaround.com/rebellabs/top-testing-tips-for-discriminating-java-developers/

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Some Traits of Smelly Designs

In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.

Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.

Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.

Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.

Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.

Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.

Link:

http://www.codeops.tech/blog/linkedin/what-causes-design-smells/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Most Used Programming Languages

https://www.inc.com/larry-kim/10-most-popular-programming-languages-today.html

 

This article lists the top ten most commonly used languages for programmers in the real world industry. It also talks about each one for about a paragraph explaining its strengths and weaknesses, as well as what specific fields of programming use each. Since I am still learning programming, it makes sense to see which ones are going to be in higher demand as i seek jobs after college. Knowing more languages is like having more tools under your belt to solve a problem, and being able to put more down on your resume will set you apart from other candidates.

The programming language with the number 1 spot in the top ten list, is java. Java is mainly used for building server-side applications, video games and mobile apps. It is the most commonly used language because a lot of developers start by learning java first, since it is fairly user friendly. Java excels at being able to run on multiple platforms, as it is designed with the concept of WORA (write once, read anywhere).

The second most popular language is python. This is interesting news to me because I’m not very familiar with python, so now i might just look into it a bit further. Python is a general framework for mostly anything involving coding, you can find it anywhere and write pretty much anything using it. It is credited as the easiest programming language to learn because of its uncomplicated syntax, so if you already know a language its very easy to adapt to python.

Moving a bit further down the list, number five is JavaScript, which is entirely separate from the language of java. JavaScript is mainly used for online web applications. This language makes it very easy for developers to create interactive elements to their website and allows a lot of online customization options.

Also pertaining to web development, number six is PHP (personal home page, renamed to Hypertext Preprocessor). PHP is a very heavy duty language, used for dynamic big data websites, making it a great language to learn for any aspiring web developer. Another great feature is that PHP is a completely open source language, meaning the community has created many free modules anybody can use to perfectly fine tune their program to fit their exact needs.

The last but not least language on the list is C. C is the basic programming language that modern object oriented languages such as java and C# were built off of. The advantage to knowing C is that you have an understanding of the bare-bones of your code, being very close to how the machine reads it. C is more of an academic language, taught in colleges but not very used in the industry, although the knowledge and experience you gain from learning C you can use anywhere.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.