Author Archives:

Why proxy pattern?

You probably heard or saw the term “proxy” multiple times in your browser or your OS, and just like me, you did not know what it means or what does it do. In computer science, that is a term to describe a design pattern and I think it is one of the most interesting design pattern. It is such a simple concept, yet effective and it has been used by a lot of developers, especially in the field of networking.

For starter, according to the Gang of Four, proxy pattern is categorized as Structural design pattern. Its purpose is to act as a simple wrapper for another objects. In other word, the proxy object can be directly accessed by user and it can perform its own logic or configuration changes required by the underlying subject object without having to give the direct access to the subject. By using this pattern, it offers both developers and users the advantages. This pattern is used when commonly used to hide the internal structure and only enable user / client to access a certain part of it, or access control. It can also be used to replace complex or and heavy objects as a skeleton representation. Less popular function of proxy pattern is to prevent data redundancy(ie. load data from disk multiple time) every time the object is called.

The concept of proxy is actually used a lot the real world. Taking the example of a debit card, it is one of the most commonly thing that used this pattern. Every time you swipe or check out with debit card, you are basically telling the system to transfer the money from your bank account to the vendor that you are paying. You can really see that the debit card does not have the trading value, it just represent the amount of money you have in your bank account so that you don’t have to carry that amount around.

This applies the same way in computer science. For instance, if you are working on a project where you have to have multiple server to run on separate subdomain, but unfortunately, you only have one server machine, then reverse proxy is definitely a way to go. In Object Oriented Programming, access an object through another object is also really common and useful to ensure security and convenience.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Facade Design Pattern

For this week’s blog on Software Architecture and Design, I will revisit the same assignment that I have blogged about before. For the assignment, I had the option between three design patterns to write a tutorial for. I picked the proxy design pattern, and then I blogged about the decorator design pattern. Now, I would like to watch a tutorial on the third design pattern, facade, so that I might learn about all three.
I chose to use the same YouTube, Derek Banas, that I used before for the other blog. I found his videos engaging and informative that I would like to learn about it again. I also like that it is fairly concise (11.5 min), which makes it much easier to rewatch sections that I don’t get the first time around. 
It turns out that I did not understand it after finishing Derek’s video, so I turned to another video by another Youtube channel by Christopher Okhravi. Derek went straight into coding, whereas Christopher just drew diagrams and did not code. I needed more of an overview to understand it, not an example of code.
The thing that confused me about Derek’s example is that I did not see how it was in any way different from code that I have written in the past. In fact, he said, “You may have used this pattern already, but you may not have realized it.” When I watched his video, I did not know why it was so special.
Christopher’s video made it make sense. I used him for the original “proxy tutorial” assignment, and he was the one that made proxy design pattern make sense. His videos tend to run on the longer side. At 16.5 minutes, this one wasn’t too long, but the proxy video was almost forty minutes.
Christopher’s diagrams were helpful to explain what made the facade pattern what it is. I also now understand why it is called a “facade” pattern — one class acts as a “facade” to every other class and interface. The end user only interacts with the facade class, which calls what it needs from the other classes. The advantage to this is everything is highly uncoupled. 
Although I think this concept is something I intuitively knew, it was helpful learning about this. Now I know there is a name for it.
Derek Banas: https://www.youtube.com/watch?v=B1Y8fcYrz5o
Christopher Okhravi: https://www.youtube.com/watch?v=K4FkHVO5iac

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

A Review of Mockito

For this week’s blog on quality assurance, I wanted to review what we learned most recently in class. I decided to watch a relatively short (24 min) tutorial on Mockito. It has been over a week since I’ve seen it, and there’s another few days until we meet again. I could use the refresher before then.

The tutorial I chose to watch was by a YouTuber named Walter Schilling. I thought he explained the concept very well. I will definitely bookmark his page for other concepts that I find challenging.

I thought it was a little bit of a complicated set up. I don’t think it was necessary to see the UML diagrams or as extensive of a walkthrough of how his code worked. He didn’t go excessively in depth, but I understood it pretty well after he gave a  demonstration of the final code in action. (He typed in some inputs and showed what the output would be.) I didn’t need to know as much information on his example code. That’s not what I had come to see.

When he got to the mockito section, I was surprised at how little there seemed to be to it. I remember when we went over it in class, I didn’t think it was a very difficult concept, but I probably could not have done it without a little bit of review. After watching this tutorial, I have renewed my confidence that I am able to do it again.

I could see how someone might not like that his method wasn’t polished and rehearsed. He would say something such as, “Why is that giving me an error,” or “I don’t think I spelled [my variable name] correctly.” It didn’t take him long to diagnose any of these problems. I kind of liked this style. It gave me more confidence in my own abilities when I could sometimes diagnose something as quick if not quicker than he did on his own example. (To be fair though, most of them were simple fixes.)

Towards the end of his video, all of his tests were failing, and he couldn’t figure out why for a moment. Something small that I gleaned from this is that no matter how good you get, no one is ever perfect. I have a habit of putting myself down for not knowing everything or making simple mistakes. I should not be quite so hard on myself. Even the experts make mistakes. You could go one step further and say that if they never made mistakes, they would never learn from them and become experts.

https://www.youtube.com/watch?v=8PgH0PwgEa8

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

Comparing REST and SOAP, which one should you use?

For this week blog post, I will write about the basic and differences between REST APIs and SOAP. Some people would say one is better than another, but that statement, for me I think, is incorrect because each protocol does have its own advantages to make use of and of course, there would also be a lot of annoying disadvantages that we all have to deal with. For this blog, I will have my information based on this article.

Firstly, I would go through a quick overview for both protocol. For stater, they both provide an answer to a same question, that is how to access to web services. SOAP stands for Simple Object Access Protocol. It has been around for a while and originally designed by Microsoft. While Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (COBRA), which are old technologies, fail because it rely on binary messaging, SOAP is designed to replace them as it works better over the internet. SOAP was initially released and submitted to Internet Engineering Task Force (IETF) and they standardize it. So how does SOAP works? SOAP heavily relies on XML to provide messaging services. It is also designed to support expansion and they have an abbreviation associated to their name such as WS-Addressing, WS-Policy, WS-Security, etc. and you can find out about these standards here. The reason to use SOAP is because it is highly extensible. For example, if you have a web service that you would like everyone to have access to it, then there is no need for WS-Security, but in case you change your mind, you can always add in to your service.

Let’s look at REST APIs. REST or Representational State Transfer is somewhat simpler to use and also known as a lightweight alternative. Instead of having just XML, REST APIs usually relies on the URL and sometimes Javascript Object Notation (JSON), XML, EDN or some other type of body is required. REST can use four different HTTP 1.1 verbs, GET, PUT, POST and DELETE to perform a single task. Unlike SOAP, REST doesn’t use XML to provide the response, it can have the data returned as Command Separated Value (CSV), JSON or Really Simple Syndication (RSS). The point of REST is not just because it is lightweight, but also because it returns the data in a form that can easily parsed within the language that you are using.

There are a lot of reasons to put one over another, it depends on how you see it and also depends on what your project is about. It is actually really hard to choose between these two, so I will compare them and let you decide.

Consider the using SOAP over REST, SOAP does have the feature that allow user to use without using HTTP or in another word, it has the language, platform and transport independence. You can read more about using SOAP with Simple Mail Transfer Protocol here. Another point to consider is that SOAP works well with distributed enterprise environment, which REST always assume it is going to be just point-to-point communication. SOAP does have to potential for extensibility, it is standardized along with a built-in error handling and it has the automation when using certain language products. 

How about REST, after disadvantages about it, should you still use it? The answer is absolutely because it does not required expensive tools to interact with the web service. Moreover, it has much smaller learning curve to go through, so if you are new to the field, you might want to consider having this on your project. I did point out that while SOAP is using XML that makes it so complicated, REST makes it more simple to just return a form that can easily parsed by most language, which simpler and decrease the time of the development process.

Overall, I think both are very powerful protocol for developer to make use of. It is true that sometimes you should consider one over another, but to understand that each protocol has definite advantages and equally problematic disadvantages is very important. I think it is amazing that we were given two choices to fit our project needs.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Quality Assurance at Apple

For this week’s blog for quality assurance and testing, I decided to read an article from Wired Magazine that focused less on the testing process itself and more of how a company can benefit from it. The article I chose is a little less than a year old about Apple’s securities and vulnerabilities. The article confirms some of what I had hoped — that Apple still has a strong reputation for security. However, some vulnerabilities have damaged how the company is perceived by many. 
In High Sierra, all that you had to do to gain root access was type the word “root.” They fixed it impressively quickly. However, the article wonders if the security flaws like this are emblematic of deeper problems. There have been many more bugs and vulnerabilities found, such as wonky autocorrect on the iPhone. Although not every bug (like the autocorrect) is not always a security issue, it is incredibly irritating. 
One advantage that Apple has over its competitors is that most of its customers update as soon as there is an update. The advantage of this is that people will not be vulnerable using a software without the security fixes in the update. However, Apple might lose this edge if people are wary of updating if it seems like there are always too many bugs in every update.
One of the big problems these days is that it seems that everything seems rushed out. There is a big focus on new features, and not as much focus on fixing the bugs on the features that already exist. The article talked about a 2009 release of “Snow Leopard” which built on the previous release “Leopard.” It heavily focused on getting bugs fixed.
Another issue about perceptions is that even if the mistakes are fixed quite promptly, they are still remembered, with what is described as a pile-on effect. That is, a fixed security flaw won’t be “erased” from a customer’s mind.
The takeaway from all of this is how important quality assurance is to any product. It perhaps is more important than new features. If the old and new features are continuously full of bugs, it is hard for a customer to trust that company anymore. It is better to have solid core software than one with a million extra bells and whistles if it means there’s just as many bugs. Unfortunately, the article concluded that it seems like Apple is leaning towards the latter.

https://www.wired.com/story/apples-security-macos-high-sierra-ios-11/

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

Decorator Design Pattern

For this week’s blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn’t pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I’m going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won’t be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post.
The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas).
Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has the benefits of inheritance, but is better to implement in many cases because it is more flexible. Instead of rewriting old code, you extend with new code.
This seems like a more intuitive way of doing things. In the example in the video, he uses the example of creating different kinds of pizza. If you were to design a menu for the same pizza place and there was twenty ingredients and different prices for each, it would make more sense to list the cost of the sizes “Small $5, Medium $7, etc.” and the prices of the toppings in a similar way, with Pepperoni and Sausage being 50¢ and 65¢ respectively. The customer would then choose the size and toppings and add all those together to get the total price.
It seems like the decorator does exactly this. It would seem silly for a pizza shop to list every permutation of toppings and sizes. It would make sense if there were only a handful of pizzas to choose from, but it does not make sense to do this if there are too many ways to list. Same with inheritance instead of decorator design pattern. The same logic is true with inheritance. This seems like an incredibly useful and versatile tool to use. I think learning about this will be incredibly invaluable for the future.
http://www.newthinktank.com/2012/09/decorator-design-pattern-tutorial/

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

Quality Assurance as a Career

I decided to take a somewhat different tack for this week’s post for software quality assurance and testing. Instead of focusing on testing itself, and all there is to it, I found a video from a tester in the field, Alan Richardson, on his advice for someone who is interested in getting into the field.
He strongly urged someone getting started not to think of a position in quality assurance as a “stepping stone” to being a software developer. If you do, you will inevitably find yourself in a dead end because you really aren’t interested in the field. “If you want to be a software developer, start as a software developer.” 
He encourages the viewer to read everything they can on the subject. A lot of it is free, so there is no reason to necessarily buy anything. However, he gives some book recommendations. He gives a good insight why books can be so valuable to learning. “An expert in the field took a year to concentrate everything they know into those pages,” (paraphrased).
He doesn’t value certification, but he realizes that many companies do. I didn’t realize there was certification. Even if I don’t end up getting it, it’s useful to know that it exists. He also said that it is easier to go into testing from designing software. 
He also urged testers to find companies that valued the work they did and that provide opportunities for them. He said that oftentimes testers are paid quite a bit less than they’re worth compared to software designers. Not only is picking the right company important, but you should advocate for yourself because the work you do is important.
I thought that he offered some sound advice. I haven’t seen that much other software quality assurance career advice, but this all seems to fit what I’ve heard over the years for computer science or general career advice. I am excited to start working for a company, perhaps one day as a tester.
Strangely, I don’t often think about all the different positions within the computer science field. I tend to lump everyone as a “software developer,” even if I know there’s a lot more to it than that. I am starting to rethink that and consider going to quality assurance. It is something I enjoy, and it is something I can see myself doing.
YouTube Channel: EvilTester – Software Testing
https://youtu.be/iOA3lxZyFwA

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

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect. 
They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about. 
He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things.
He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this field, by establishing why a need exists and then later explaining the concept.
There are three things covered that influence architecture. First, agility, which is the speed and coordination to change. Most companies try to embrace this, but many businesses fail at it. Second, velocity, which is the speed of something in a given direction. Third, modularity, which is when independent parts can be combined in lots of ways. They went over the upsides and downsides to each, and you have to compromise many times at one aspect for another
I thought one of the most interesting parts of the podcast was when he said that if you wanted to see what was coming next in technology, read academic papers from twenty years ago. It takes that long for one level of the level of architecture, hardware, to catch up to another, software. It is only recently that we can implement this technology.
Another interesting thing he said was that one of our biggest inhibiters to evolution is the integration of data and functionality. He foresaw a paradigm shift in how we handled this.
As a parting message, he was asked, “what would one piece of advice you would give to an aspiring software architect,” and his answer surprised me. He said to work on people skills, and that was the “hands down” most important advice he could give. This skill is so key in everything you do, including lead and mentor. I found this incredibly interesting, because I am often reminded about how we never do everything in a bubble, and it is extremely important to be able to “play well with others.”

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

A simple design principle

This week blog will be talking about DRY design principle and it will be based on this article. These principles are really useful for software development yet there are still quite a lot of people tripping over it.

A bit background about DRY. DRY stands for Don’t Repeat Yourself. It is really simple but important to understand. It is essentially know as a philosophy that packages the logic into representation. This design principle has been known for a long time and its acronym is mentioned in the book The Pragmatic Programmer, which is published in 1999. The concept of DRY wouldn’t be a big of a deal when you are writing a small program, a code snippet or a short script. However, when it comes to a big software project, not applying this principle would not only cause a lot of problems but also can waste resources and increase the length and complexity to your programs, and all of these would lead to the increasing requirement of your clients’ machine. Besides, it is not just bad for the hardware itself, it would take more time for you and other developers to just understand your code.

To achieving DRYness, a simple way to put it is to divide your system into components, where each of these components represents its own subsystem’s functionality. For instance, if you are building a file sharing system, your program should break down into multiple pieces like git system, file management system, etc. and inside user management system, there can be subcomponents like role management system and access control system. As the program is divided further, there would be a clear hierarchy where each subcomponent would only have one function to support the components themselves, and it would greatly reduce the complexity.

I really like the part where the author quotes that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” meaning that if you are repeating any piece of information, you are doing it wrong. This can be really easy to make mistake and I actually did quite a lot when I first started programming. For example, instead of making the connection to the database every time you need it and then close it immediately after you are done with it, you should make a separate class that handles the connection to the database as a singleton and it should open the connection to the database when the first time you call the function and close it when a specific event is triggered. In a perfect implementation, every piece of information should be encapsulated its knowledge in the form of variables, objects or a class property.

It is absolutely impossible to achieve 100% DRY, but the more DRY your code is, the better for you and other developers to maintain it. It is a concept that is worth looking into while revising your code whether it is a small or large project to develop a good habit of doing it.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/
In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject.
Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out. 
The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at it, although it is amusing, and I’m sure many developers might harbor some resentment towards testers for telling them their code is flawed.
An interesting side note was something that it sounded like the host said, which was that testing was not in any curriculum that he’s aware of at the college level. He said a lot of computer science majors coming out of college doesn’t know much about testing. I would have thought testing would have been taught more broadly. Perhaps he should take a visit to WSU and audit this class if it truly is not very common. 
She came from humble beginnings, starting to code at nine by fixing bugs in her computer games so they would load faster. Not all of us can say we started coding at such a young age. I was introduced to my first programming class when I was in college. She encouraged listeners to “go to a meet up,” and if there are none around, “make one.” “Be curious and go do stuff,” she said.
I was heartened that she said this because the new chapter of the Worcester State computer science club is holding our first code jam this upcoming Saturday to design out own website. I am excited to do exactly what Noemi is encouraging a beginner coder like myself to do. Although there is probably not going to be as much of a focus on testing at this meet up, I’m sure she would be proud.

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