Author Archives:

Documentation is important

Self-documenting code is one of the biggest myth in the software development industry. It is common for someone to think that their code is pretty much self-explanatory, either because it is so simple or they are the author so they should have known it better than anybody else. However, not all of us can realize the fact that while the code is pretty transparent for ourselves, other would not have the aspect as we do despite how much experienced they are in the field. In this blog post, I would like to reason that code comments have a lot of value and documentation has more value than just explaining how functions / software works.

From that all of us can understand, code documentation is basically a collection of descriptions to explain what the codebase does and how it can be used. It can be a simple explanatory comment that locates above a function or a block of code, or a full fledged developer handbook, usually complete with prescriptive style dos and don’ts overviews of each part of the application, and approaches to the most common types of coding task. Like a lot of people would think, the general reasons why we think our code is “self-documenting” mainly because our applications can be boiled down into functions or objects that have one specific task and that task should be represented by the name of the functions or the objects and for me, this is not true at all, especially with large project with lengthy codes and potentially has functions that is named a little bit similar and have some common traits with each other. What we mostly don’t really think about is that code without comments is basically force the reader to go through the how it is implemented to figure out the why. With that being said, we can see that documentation are important to transfer the knowledge of what that function really do so that people can reuse it by just not knowing how it was implemented and that is fine. Not just giving user the instruction, code comments are also used to provide example usage of the code, provide the trade offs or pros and cons of the current implementation, marking the possible improvements in the code, possibly how to use it effectively with others APIs, and it serves as the most effective communication between authors and readers.

Another flaw of self-documenting code mindset that we usually think is that because we are standing in the developer-only point of view. To be clearer, what I meant is that we only seeing the value of documentation as allowing people to understand how the code works and documentation should be for every possible user. Developers only think about developers when it comes to software. It is true that a vast majority of the software users are end users and by having a good documentation can make the software more approachable by users that are not developers.

Article reference can be found here.

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

Productivity for a Developer

For my final blog for “Software Design and Architecture” this semester, I decided to research time management for doing software projects. This is an issue that I ran into creating my final project, and I thought it would be worthwhile to learn from my experience while it was fresh in my mind.

I thought this would be particularly helpful because I would like to do a few projects for fun over the winter break. I don’t think that I’m alone in that without a looming deadline, what little time management skills I have tend to go out the window. I hope this will change this time. I doubt reading an article will transform me into an extremely productive person, but at least it might point me in the right direction. I can only hope.

The article that I found was from ** and was titled “Time Management Tips for Developers.” I thought it gave some good pieces of advice. Even if you are not a software developer, you could benefit from all the advice given. I will focus on three pieces of advice that I would like to work on.

“Set your goals: long term and short term”: This is something that I know I should be doing, but I never do it in a methodical way. I make myself a goal, but never stick to it. I also never write it down, either. It is an incredibly lazy process. Which, funny enough is the next point.

“Do not plan in a lazy way”: Guilty as charged. I don’t put very much effort into planning. It’s no wonder I don’t stick to it. However, I have found it is sometimes hard to plan a project that I have never done anything quite like. Strangely enough, this thought was the topic of the next point.

“If you can’t plan, just track”: You should keep track of what you are able to get accomplished in a day and note where you waste your time. This seems like something incredibly useful for accurately gauging how your time is spent. It is too easy to either get discouraged or have false enthusiasm because you have either under- or overestimated how productive you were.

It seems like the author has some experience in doing projects like I am doing. It is really impressive that he can follow my thought process when reading one point and have the next point agree with what I was thinking in the next point. There were several other points that were good as well. I highly recommend checking it out.

Work Cited:

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

No, A Bot Will Not Steal Your Spot

For my last blog for this class — Software Quality Assurance and Testing — I decided to look at what I could find about the subject in the news. After searching around, I found an article from Forbes that came out only a few days ago — December 17. The article was titled “AI In Software Testing: Will A Bot Steal Your Spot?”

My first impression before I read the article was, “Of course not! There will always be people whose job it is to test software.” Software is growing to touch every corner of our lives, and even if AI is incorporated, I would think it would be unlikely that they would entirely, or even partially, replace testers.

Halfway through the article, the author confirmed my skepticism by saying, “While it’s unlikely the testers will be wiped out, I think machine learning and other branches of AI will significantly alter the way software testing is conducted.”

The article seems to have a misleading title. The article goes on to give several examples of how robots will be useful for people, but they will be still be implemented by people, whose jobs are still be there, even with the robots. It didn’t even hint even some jobs would be lost. It just said the job would look different. Seems pretty obvious that new tools will come out that will change how the work is done. That is true for most all industries.

The article might as well been titled “Sharks in the Ocean: Will You Be Eaten When You Go Swimming?” And then once you read it says “probably not.” This is link bait at it’s finest. Have a sensationalized title for people to click on, and then say, “It’s not going to happen.” It would be one thing if it were titled something different.

However, at least I sighed a breath of relief when I read what the article concluded. I would hate for something that I have wanted to pursue as a career be automated before I even graduate.

I’m sure that many parts of the computer science industry that will change dramatically over my career. I hope like most people that I will always be able to find work, but I think that the field is going to be fairly stable for a long time. However, I’m sure there will be no shortage of headlines that have similar titles — “Is your job in jeopardy?” I also think that the article contents will usually say that it’s not.  I do think it’s a good idea to keep alert to changes in the industry because no career or company is invulnerable.

Work Cited:

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

Software Architecture as a Career

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.

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

Angular vs NodeJS

Javascript has been around for awhile and it is a simple yet powerful client-side language and now with the help of frameworks and platforms, it can also be used as a server-side language. Nowadays, more and more frameworks and platforms are released and that leaves us a tough decision to choose. Today, I would take Angular framework and NodeJS platform in consideration, since they are both powerful for front-end and back-end development. They feature rich cross-platform web app and enable developers to make a Single Page Application easier while maintaining Javascript as the main language, instead of AJAX, which is a whole new set of syntax to learn. Let’s dive into it.

Angular in general is an open source web application framework that is maintained by Google. It comes with two forms (or versions) which is Angular 1.X, which is usually referred as AngularJS, and the rewritten version of itself Angular 2+, which used mostly Typescript. With AngularJS, it can be added to a HTML page with the <script> tag and its general purpose is to help user in adding the dynamic views in the web application and integrate with Model – View – Controller structure, providing the flexibility to the framework. The application is usually built up form combining different modules together and more often, these modules have different logic and different purposes as the main module connect them by a general logic. The more you think about it, the more you will see how helpful this is. It speeds up the development process a lot since the application can be cut into pieces that does not have anything to do with each other for teams and then simply combines all of them by just some line of codes. Without it, imagine every time you write your component on others’ file and push it to git, you have to manually merge it without losing the functionality of other components. Not to mention it is so easy to use as it offers many features like directives, filters and automatic data bindings, which support us with optimizing our code.

NodeJS is an open source, cross-platform runtime environment for developing server-side and networking applications. While Angular are available in both Typescript and Javascript, Node can only deal Javascript. However, that does not make Node worse or better. According to Google Trends, after 2017, less and less people are interested in Angular while Node stays the same. NodeJS provides a rich library of various Javascript modules, simplifying the development process of the web applications to a great extent. NodeJS is highly scalable. By using one of two ways – Horizontal Scaling and Vertical Scaling (you can read more about it here), this helps improving your application performance a lot. Moreover, Node also offers Unit testing with any Javascript testing frameworks like Jasmin, server development with different types like HTTP server, DNS server, TCP server, etc. and better performance, since it uses V8 Javascript engine.

In conclusion, Angular and Node are both useful open source tools to build web app, while Node are more server-sided. This blog is based on this article.

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

Why favor composition over inheritance?

In the early stage of software engineering, there was no such thing is composition or inheritance, it only exist in the context of object-oriented programming. When object-oriented programming was introduced, every one pretty much ignored it until user interface heavily based on it. One of the most popular object-oriented design principles is to favor composition over inheritance.  I have been asking people about the advantages of using composition over inheritance and the answers always suggest that it makes your code so much simpler and increase its flexibility. That is somewhat an acceptable answer, but I thought, to convince you, I would need more than just simpler and maintainability, so I found a this article that provide five reasons and I will summarize it.

Firstly, there are a lot of object-oriented programming languages out there, but let’s take Java for consideration, since a lot of developers (including the new one) know how to use it. With composition, when class A uses the functions of class B, it doesn’t inherit class B, but instead, it sees class B as a variable or an object. This is why it is called “composition”. It is suggested to use composition and that does not mean inheritance is completely useless. While inheritance is referred as IS-A relationship, composition suggests more of a HAS-A relationship. With IS-A relationship, an instance of the sub class to a function as a parameter, which accept instance of the super class, offer somewhat of the flexibility.

On the other hand, the fact that people prefer composition, especially in Java, is that most of the time it does not support multiple inheritance. To be clearer, sometimes you need to use multiple function, but you can only extend one of the two classes that offer these two functions, that would cause a lot of pain to go through. For example, if you want to read and write a file, you probably want to reference the two objects and call the function from there, while it is almost impossible to extend the read and write class at the same time to call their functions. Composition also offers more test-ability than inheritance. While you only need to create a Mock object that represent the composed class for testing, in order to test the sub class, you would need the super class to be available at the same time. Flexibility is the most important one to talk about. Although both allow developers to reuse code, inheritance is more likely to break encapsulation. Because sub class heavily depends on the super class, even a slightest change can alter or break the functionality of the sub class.

There are a lot more reasons to consider composition over inheritance and you probably will discover it by yourself on your way making your own program. However, it is important to keep in mind these reasons so that you would not make a mistake when you start developing.

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

Importance of Quality Assurance

For this week’s software quality assurance Blog, I would like to revisit software testing as a career, because it is something that I am interested in pursuing. I found an article, “Software testing is big business,” from a South African website, “”.
In the article, it stresses the importance of quality assurance in software. I think I have said here in this blog how fickle customers can be with software that is buggy and jump ship at the first chance if the code causes them even a slight inconvenience. If I have not said it here, I know I have read something similar before. The article repeats this sentiment, and it is probably something worth repeating. 
The article continues and says that developers often rush to add new features, while leaving quality assurance as an afterthought. The article claims that when companies allocate resources properly, about one third of IT budgets are allocated to software quality assurance and testing.
The article says that often software testers are seen as “second-rate,” which should not be the case. I was talking to my dad about entering the field as a software tester. He is a software developer, and he said something interesting that a colleague told him. He asked a coworker of his why he decided to stay a QE (Quality Engineer) when he had a lot of opportunities to be a developer. The answer surprised him, and I thought it was a good mindset that I might think about when I enter the field.
The QE said that a developer will usually work on one project at a time, and won’t be able to influence what other developers working on other projects are doing. A QE, on the other hand, will be able to influence everyone’s work. He has his finger in many, many pies.
I am more resolved to get into quality assurance the more that I learn about it. It doesn’t necessarily have to be something I do forever if I find I don’t enjoy it. I’m sure it would be easy enough to switch tracks.
I once heard some advice that when you don’t know where you want to go, a step in any direction is a step in the right direction. It is better that than being so paralyzed to make no choice. I felt this way when I had to declare my concentration, and again before that when I had to declare my major. In the same way, if an opportunity presents itself to start a career in quality assurance, I would like to jump at the chance.

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

What is an Anti-Pattern?

In this week blog, I’m going to write about anti-pattern, mainly because I have seen the term a lot and think to myself that I should at least know something about it. This week blog is based on this article.

For a start, we need to understand what algorithm and pattern is. Algorithm has been around for a really long time and considered to be the most fundamental concepts in software engineering. The early concept of algorithm as it is written in “Fundamental Algorithms” by Donald Knuth, which was published in 1968, mainly provides Calculus-based proofs of its solution and code examples in outdated language like Algol or MIX Assembly. However, a lot of the subject was covered is still widely used today, for example like singly / double linked list, garbage collection or trees, etc. and it remains to be valid solutions to common software engineering problems for more than 5 decades and still going strong.

A “pattern” can be seen as a more general form of an algorithm, while algorithm may focusing on a specific programming task, pattern would offer more advantages in areas such as reducing defect rates, allowing an effective teamwork or even increasing the maintainability of the code. Four common patterns that are used in the industry are:

   – Factories: A concept in object-oriented programming that would eliminates the need for the creator of an object to know everything about it ahead of time, in other words, it would generalize the object as a square instead of knowing what details that contains in it. This pattern certainly simplify the program and encourage more efficient teamwork.
   – Pub / Sub: It is an async process between sender and receiver. Instead of having the sender to send the messages directly to the receivers, the sender publishes the messages to a queue. This pattern allowed multiple receivers to subscribe and retrieve those messages. The queue also have the ability to handles details such as transmission errors or resending messages. While factories pattern is more code-oriented pattern, pub/sub suggest to be more architectural in nature.

   – Public-key Crytography: A really useful and commonly used for security like in SSH or git server. It is a mechanism that allows two parties to communicate securely without interception without exchanging the secret encryption keys. Usually, each party maintain a pair of keys (public and private), and the public key can be shared anytime as needed.

   – Agile: A philosophy that establishes a set of guiding principle for software development to emphasize the customer satisfaction. It also embrace the need for flexibility and collaboration and promote the simple and sustainable development practices.

If a “pattern” suggest the solution to common software engineering problems, then should “anti-pattern” be the exact opposite? Anti-pattern actually is a term to establishes the concept of failure to do the right thing, maybe some of the choice in the development process seems right, but they would lead to problems in a long term. Wikipedia define anti-pattern as a common response to recurring problem that is usually ineffective and risks being highly counterproductive. As the sentence proposes that this is a common mistakes and they are nearly always followed with good intentions. Just like pattern, anti-pattern can be really broad or specific, depends on what we are considering.

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

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&#039;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:
Christopher Okhravi:

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