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.

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.

To kick off this week of blogging, the first article of the two I will be writing about this week is titled, “How To Keep Up To Date As A Software Developer”. Like all of the other articles that I have written about on this blog, I just happened to spot this article as I was searching for other articles to write about. Although, this one stood out to me because I recently had an interview for a software development internship near my hometown, and it got me thinking. Maybe I should actually stay up to date in the latest software development trends. Luckily, I happened to stumble upon this piece of coincidental, appropriate-to-my-situation, of writing. So without further adieu, let’s talk about the read of this week.

This article is actually written in the form of an interview. The article leads off with the question, “How do you keep up to date as a web/software developer?”. This was a question that was asked on Quora, which is kind of like Yahoo! Answers, but more credible… I think. Regardless, however, the person who answered this happened to be Mario Peshev, CEO of DevriX. DevriX, if you didn’t know, is a company that handles creating WordPress platforms for other companies. I also didn’t know that, but thankfully the internet exists. I still think the article could have explained that, but what do I know about writing articles. Anyway, Mario goes on to talk about what he does to “keep up to date”. Honestly, it was exactly what I expected it to be, which is disappointing, but I don’t know what I expected. He provides 12 ways to keep up to date, and they are exactly what’d you’d expect. (Collegues, Internet, Working, Social Media, etc.) He did mention books which is an obvious answer, but he mention the Gang of Four book, and that immediately caught my attention. It made me feel all professional because we used that book in class, so, in the end, Mario and I are basically the same, except he makes a lot more money than I do.

This article would have to rank low on the list of articles I read because it was predictable. I’m not saying that the article was bad, but obviously, books and the internet are good ways to keep up to date. Granted, I don’t know why I expected there to be some magical new way to keep up to date that only Mario knew, so I guess that is my fault. Overall, this was a good read, but you already know how to do this, so you are better off finding another article.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

For this week’s post for software architecture, I decided to explore pursuing it as a career. I have focused several of my posts in this blog to going into a career for software architecture and quality assurance, but software development is very appealing to me as well.

Although I have found this class more difficult than the quality assurance class, I find the work we have done in this class very satisfying, and I would like to do something like this in my career.

I found an article from “Lifehacker,” where they interviewed a software architect Harrison Ambs on what it was like to be a software architect. It focused less on what a software architect is, and more gave general career advice for someone in the industry.

The final question in the interview said, “What advice would you give to those aspiring to join your profession?” He gave a paragraph with some good advice. (Starting with, “Always be willing to learn something even if you know you’ll be terrible at.”) However, I wish more of the article expanded on this and made this more of the focus of the interview.

In one of the answers, he said he worked around 45 hours a week. There were a lot of answers that were like this, and these sort of things are good to know for seeing what a career in the field would be. However, they were good to know, but these didn’t seem like the most important things that the article could be focusing on

I suppose they didn’t want to flood the article with jargon that someone who was outside the discipline or was just starting wouldn’t know, but I think they missed a great opportunity to inspire someone to become a great architect.

There was some good information in there, though. He said he is always learning from blogs and newsletters of “as many individual app developers as possible because these people are honed like a samurai blade when it comes to software development.”

That is good to follow through on as I am pursuing my craft. It is always good to be continuously learning and growing your skills and mindset. This is something that these blogs have made me start doing, and it is something that I would like to continue to develop.

https://lifehacker.com/career-spotlight-what-i-do-as-a-software-architect-1699203274

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

A test double is a generic term used for objects that look and behave like their production equivalents, but are actually simplified. Test doubles are used to reduce complexity and verify code independently from the rest of the system. There are many different types of test doubles, and misunderstanding or mixing them will make fragile tests. This blog post discusses three different variations of testing doubles: fakes, stubs, and mocks.

Fakes are objects that have working implementations different from production ones. An example is using an in-memory data repository instead of accessing a database. The benefit of this is that integration tests can be carried out without performing the time-consuming process of starting up and requesting information from a database.

A stub is an object that holds predefined data and answers calls during tests with this data. Stubs are used when we don’t want to involve objects that would answer with real data. For example, if there is an object that needs to get data from a database to respond to a method call, a stub can be defined with the data that should be returned instead of using the real object. Stubs are preferred for methods that return some result and do not change the state of the system because it allows verification of a method’s return value.

Mocks are used for methods that change the system state but don’t return any value. Mock objects register the calls that they receive. Assertions are used in testing to verify that all expected actions were performed. Mocks are commonly used when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.

This blog was a good overview of the differences between fakes, mocks, and stubs. Reading this helped to solidify what I learned in class and gave me a better understanding of when each test double would be used. I especially liked the images and code examples used as they made the idea behind each one easy to understand. Overall this was a well-written and useful blog post that gave me a deeper understanding of material learned in class.

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

Today I will be talking about testing software! More particularly, testing by using dummys! So what exactly is a dummy and why do we use it in testing. Dummys are objects that are created for the purpose of testing but are actually never used. Think about it like a mannequin. The mannequin displays the clothes as how they would look on a human, but the mannequin is not actually a functional human, and does not actually use the clothes. Its only job is to make sure the clothes look (or function for the sake of testing) correctly. According to this blog by Tom Winter, “How our test data generator makes fake data look real”,  our test generator makes fake data look real for the purpose of testing our code. Why would we ever want to test fake data? The easy answer is this: sometimes we do not have all the data or all the code finished, and we want to test our code without having to play the waiting game. Sometimes it is even impossible to test our own code without dummys because we do not have access to the actually data. So we use these dummy objects to play the role of the real data (which we do not actually have access to, remember?) in order to test our code to ensure it functions properly.

Testing with dummy objects is something we have been doing in my software program at school, and I happen to find it very useful in the sense that I do not actually need the data to make sure my code works. Not only does this help pick up testing efficiency,  but it cuts down on the overall wait-time between developers and getting their product out. On the flipside of things, if another developer was waiting for me to finish my code before testing, they could use a dummy to test their code instead of rushing me to finish, which could possibly lead to me making mistakes and end up slowing down the entire development process. I enjoy being able to test right away, and using dummys can help with this. I hope to continue using dummy testing in the future, as it is an easy and very effective method of testing!

Here’s the link: https://medium.freecodecamp.org/how-our-test-data-generator-makes-fake-data-look-real-ace01c5bde4a

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

As I take another step towards Software Quality Assurance Testing. The blog I will talk about is “Mutation Testing: Watching the Watchmen” by Jasper Sprengers.

This blog is about an automated (unit) tests more commonly known as a mutation testing framework. This is a testing tool that purposely insert small changes that would cause a change to the the original code in order to verify your code against the intentional bugs that are created through this mutation testing framework. This testing framework is used in order to test and improve your code in a fun way. The writer also tries to stress the importance of unit testing and how integration testing is just as important if not more. Testing is important because it helps provide quality to your code. In order to be able to test your code you must understand it and what it is meant to do. It also covers “How to make sure our test are any good?”, that would be good code coverage and making sure test suite are testing a wide range of code that assure that most of your code is tested and that test are checked.  Using mutation testing is a pretty good way to make sure you have successfully written good test. Since mutation testing purposely changes your program test to cause it to fail. When test successfully fail then that means that a ‘mutant’ was successfully killed. If test pass then that means that a ‘mutant’ survive which means a mutant was not successfully killed making your test a not so good one after all. According to the writer a “useful mutation testing framework for Java is pitest.org“. In summation of what is talked in the blog using mutation testing framework would make you test your code more seriously without using shortcut.

I found this blog to be very interesting and useful. I like that it stresses the importance of having good test suites to insure quality and how it mention that using mutation testing framework will help insure that you have good test suites. I found the link to a mutation testing framework very useful.  I do not disagree with much of this blog. In fact I find it interesting enough to recommend others to read it. The title of the blog above provides a link to the blog, I suggest you check it out. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.