Category Archives: WSU

The 9 Principles of GRASP | Part 1

GRASP stands for General Responsibility Assignment Software Patterns. It is a set of principles applied to Object Oriented Programming.

There are nine principles or “patterns” which help programmers understand the responsibilities in software design. In10se on Medium writes a detailed summary on each principle in the article, Mastering GRASP Design Principles for Better Software Design.

  1. Information Expert
  2. Creator
  3. Controller
  4. Low Coupling
  5. High Cohesion
  6. Indirection
  7. Polymorphism
  8. Pure Fabrication
  9. Protected Variations

When developing code, programmers need to identify where to assign responsibility in the code. In software design, responsibility refers to two things: behavior (doing) and data (knowing). Different parts of the code have the responsibility or obligation to “do” the thing itself, such as creating an object or modifying the data.

Programmers can also assign responsibility to the data used by the code such as when the data is public or private, or when to relate data objects for reference, or how the data can be used to generate dependent data.

To keep this post within the acceptable length, I will cover the first four principles this week.

  1. Information expert: this principle states that “responsibility should be assigned to the class with the most knowledge or information required to fulfill the responsibility” (In10se).
    For example, a professor object that has access to every student’s homework and test scores should be responsible for calculating each student’s final grade since this object has access to all the necessary data to do it.
  2. Low Coupling: there should be as little dependencies as possible to reduce the effects of changes in the data and code so to keep different systems separate from each other.
    Instead of having one object be dependent on another, it would be better to create a separate interface that connects the two.
  3. High Cohesion: groups that have related responsibilities should be simplified to a single class for better clarity and maintainability. This also means keeping things that have no related responsibilities separate.
  4. Controller: this principle says that all system events should be handled through a single class that manages and coordinates the system behavior. In10se gives the example of a UserController class that is dedicated to handling user-related events like registering and logging in. However, the actual processes are in other classes.

While writing code is certainly difficult, I find designing the code the hardest part. Just as being fluent in a language doesn’t make me an excellent author, so too does knowing a programming language well not necessarily mean that I can write software that is efficient and effective.

Designing software requires a strong understanding of how to assign responsibility in the code. GRASP contains principles that help guide a programmer’s decision making when designing the software structure so to write a program that not only works, but is also secure and maintainable.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

How to Effectively Manage Software Licenses

There is no doubt that licenses are incredibly important in a world where knowledge is being shared and compiled on a global scale. However, there is also no doubt that licenses can be incredibly complex. For this reason, organizations have designed systems to manage software licenses that help make the often convoluted licensing world easier to understand and follow.

Michelle’s blog, Software License Management Best Practices, defines software license management as, “The process of tracking, controlling, and optimizing software licenses within an organization” (Michelle). Through such a system, businesses can more easily maintain legal compliance, reducing unnecessary expenses that results from licensing conflicts, thereby maximizing the value of their software investments.

So how can one create an effective software license management system? Well, just as it is true for all solutions to a problem, here requires a clear and defined strategy.

An effective strategy can take on many forms, and it often varies from company to company depending on the specific circumstances. However, the key is that the strategy must be clear. It should outline the purpose and responsibilities for the organization’s license management system, establishing clear license usage policies and guidelines that are communicated to the executives and developers alike.

Another way to effectively manage licenses is to determine the usage of different software throughout the company. This can be done by cataloging and organizing the software inventory, as well as conducting regular software audits to identify and rectify any software uses are in non-compliance. Having an organized inventory will also help companies keep their licenses up to date, which will allow them to avoid temporary access disruptions and any service fees that may occur from mismanagement.

While many of strategies mentioned above can be done manually, it becomes more and more difficult to manage for larger companies that work with dozens of different software associated with different licenses. For this reason, it is recommended that in such cases, companies use software that utilizes license management tools, which can facilitate the license management process. Of course, it is always better to automate, when possible, to decrease the chances of error.

Software license management is a side many software developers would rather ignore, but it is a necessary aspect of software development that cannot be overlooked. Though I have never developed software that required strict licensing, I will be working on my capstone project next semester, which will require a good understanding of software licensing. For this reason, in addition to learning about the different licenses and how they operate, I also decided to research more about how licenses can be effectively managed to better prepare myself for my capstone project and later in the future when I enter the professional software development field.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

The DRY Principle

One of many important programming principles is what is called ‘Don’t Repeat Yourself’ or ‘DRY’.

The DRY principle focuses on reducing the number of unnecessary repetitions in code. This goal can be achieved through multiple methods detailed in Tahmeed Tarek’s article Understanding the DRY Principle — the three most common being:

  1. Abstraction
  2. Automation
  3. Normalization

Abstraction is often used in Object-Oriented Programming. The strategy is to create a super-class containing the necessary attributes and methods which each class can then inherit. This reduces the number of times common attributes and methods have to be defined.

Automation focuses on communication within the team and between teams working on a project. Cross-functionality between team members and different teams is vital as it gives everyone an opportunity to discuss mutual problems and thereby capable of formulating a mutual solution.

Normalization is often used in designing databases to prevent the occurrence of redundant data. It works by “extracting duplicates into a separate entity” (Tarek), ensuring that the data is consistent and properly distributed so the data’s integrity is maintained at a single source and the database is flexible and scalable.

In addition to the three methods, there are some important things to keep in mind to practice the DRY principle.

The first is to design code that is easy to reuse. This includes elements of clean code such as abstraction and documentation. Code that is simple and easy to read and understand is also easier to reuse. Sometimes, however, this process can be long and tedious, which bring up the next point to keep in mind.

The second is that shortcuts make for long delays. While they may save time in the present, shortcuts introduce what is called ‘technical debt’ which causes problems later in the future. Failing to discover and resolve technical debt early on can be a costly mistake for a project.

The third is to focus on active communication and project awareness. I have personal experience with this point relating to my research project. While still a learning intern, I found myself focusing in on the singular task assigned to me and failing to see the project in its wider scope. This became a problem because I did not think to write my code in a reusable manner for later steps in the project, creating areas of unnecessary redundancy that led to an accumulation of technical debt.

While not a seriously costly mistake — thanks to my advisor — I still had to go back and redesign my code to remove the redundancies. From then on, I learned to apply the DRY principle to my code to prevent the same scenario from happening again.

As I learned from my personal experience, the DRY method is an important principle that guides programmers to develop code that reusable and scalable, making life a lot easier.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Writing Clean Code

As many programmers know, running code does not exactly mean good code. In addition to being executable, code also needs to be what is called “clean”, referring to code that is easy to read and understand.

In the article, How to Write Clean Code, Germán Cocca gives explains a large scope of what makes code clean. I have selected three areas that I found most beneficial to me as a CS student:

  1. Format and Syntax
  2. Conciseness and Clarity
  3. Documentation

Firstly, Format and syntax refer to how code is organized. Good format and syntax includes proper indentation, spacing, and variable naming that is consistent throughout the code. Furthermore, it is also important to make sure that variable names are meaningful so that its purpose is clear to the reader.

Secondly, It is good to be clear, but it is also important to keep it concise. Code that is too concise become difficult to understand because it sacrifices too many important details to minimize length. Code that is too detailed however becomes convoluted. Having clear and concise code makes it not only easier to read, but also easier to reuse, and so it is up to the programmer to know when to make the tradeoff between clarity and conciseness.

Thirdly, documentation cannot be understated. There is only so much information that can be expressed through the executable code itself, which is why clean code will always have comments that help guide the reader through what each part of the code is doing. That being said, it is important not to abuse the utilization of comments as this may affect the conciseness of the code. Therefore, comments should be used deliberately and formatted consistently.

Writing code requires a lot of planning and refining. Code will inevitably have to change and improve to meeting new requirements. Having clean code helps make this process more smooth and effective.

I learned this the hard way during my summer internship while using Jupyter Notebooks. Notebooks were especially useful because I was able to execute snip-bits of the code using its multi-cell functionality. However, this put me into a bad habit of not always using meaningful variable names or properly document what I was doing. And worst of all, I would often modify the notebook in ways that blurred the purpose of my code making it difficult to reuse later on.

After being set back a number of times, I realized my mistake and started fixing the way I would write my code. I started utilizing markdown and meaningful variables and would never delete or modify any of the finalized code I wrote, but instead make a new notebook or Python file with a new version noting why the new version was needed.

Poorly writing code may still compile, but it becomes very difficult to maintain. Writing clean code requires practice and awareness, but it is essential to making code easy to read and reusable.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Comparing REST and SOAP API

APIs are what allow different applications to communicate with one another, making the intricate web we have access to today possible. Because the present world basically runs on the web, it is important to understand how the API system operates.

REST and SOAP API are the two main standardized types of APIs, and while the two work towards the same goal, that is, application-to-application communication, they operate differently.

Simple Object Access Protocol or SOAP API was developed by Microsoft in the late 90s. It was designed to be highly extensible so that future created functionalities could be added depending on the task for the API would be used.

Because of this extensible design, SOAP needed to be highly standardized, which is both an advantage and disadvantage. On one side, services written using SOAP API are very easy to error handle. SOAP is able to implement a built-in error handling system that even gives code suggestions for automated solutions, making it especially useful for users who do not own the web service.

However, on the other hand, while SOAP is compatible with any programming language, it was designed to rely solely on XML for messaging services. Though much of the process of writing the XML file can be automated or at least heavily simplified by the IDE using the Web Services Description Language (WSDL), this tool can only be used by NET languages (such as C# or F#). Other languages like JavaScript have to write each XML structure separately for each task, something programmers would rather not do.

Because of the more complicated nature of SOAP API, programmers later developed a simpler API system called REST.

Representational State Transfer or REST API operates using URL instead of XML to make requests. These requests are made through four basic methods: PUT, POST, GET, DELETE.

REST API is simpler than SOAP because it has the ability to use smaller messaging formats. It is also easier and often cheaper to use as it does not require the expensive tools to interact with web services that SOAP often utilizes. REST is also often faster than SOAP because it does not require extensive processing and can utilize the cache system.

Overall, the general consensus is that both systems are good at what they do and have their advantages and disadvantages. Programmers select which API to used based on multiple factors such as the language used, the environment, and requirements for the system or project.

In terms of my personal experience with APIs, I partook in an internship last summer which involved using Slack API and Python bolt — which are based on JSON-RPC — to send commands from a Slack channel to a raspberry pi. It was a simple program, but it helped me learn more about how APIs work and their important role in facilitating application-to-application communication.

For the future, I hope to look more into XML files/structures and familiarize myself with HTTP to learn more about using other APIs like REST or SOAP.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Exploring Agile Methodologies: Extreme Programming

The purpose of the Agile Manifesto is to help development teams work more efficiently and sustainably. Within the manifesto, four key values and 12 principles are outline.

Though the Agile Manifesto was created to help make software development more efficient, most of the agile methods can be applied to any work situation. However, the XP method is one of the rarer methods geared specifically towards software development, which is why it caught my attention to learn more as a Computer Science major concentrating in Software Development.

The XP method was developed by Kent Beck in the 90s and is based mainly on five agile values: communication, respect, simplicity, courage, and feedback. These values support three greater principles: humanity, economics, and mutual benefit.

Humanity refers to fact that computer software is created by humans. Therefore, to efficiently create working software, it is important to take into account human needs, strengths and weaknesses through a healthy work environment and a supportive community.

Economics refers to being able to evaluate the risks and needs of the team and the collective project, weighing both the business values and technical concerns.

Mutual benefit refers to avoiding solutions that benefit one party at the cost of another. How this works exactly depends on the specific problem/solution.

In addition to these general principles, the XP method also details specific strategies for coding and managing projects, emphasizing communication and teamwork. The two strategies I believe to be most effective are “pair programming” and “informative workspaces”.

In pair programming, developers code in groups of two sitting at one computer. This strategy allows them to work together through direct communication and teamwork, producing code with fewer defects while also making the process more engaging.

I believe that pair programming has great potential, especially when the two people working together have good synergy and are good at communicating. However, while the strategy is highly effective for code production when pairs are compatible, it becomes a hindrance to progress when pairs are not.

The informative workspaces strategy is meant to make team progress and work details easily accessible. Whether through physical notes, charts, or dashboards, the workspace used by developers should display information that lets anyone know at a glance, the project progress.

I think informative workspaces is a great idea as it makes communication so much more efficient. Instead of having to ask a team where they are at before I can follow up with more specific questions, I can just go find out myself. Having such information also helps project management as it allows teams to know what parts of the project need special attention.

Teamwork is often difficult — and I say this from personal experience — but with a proper strategy like the XP method, working together on a project becomes not only easier, but also more enjoyable. For my capstone project next semester, I hope to apply some of these strategies to build on my teamwork skills.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Encapsulation | One of the Four Pillars of Object-Oriented Programming

There are four pillars in Object-Oriented Programming (OOP), one of which is ‘encapsulation’, which refers to the good practice of hiding the inner works of an object and its implementation details, where access is only possible through public methods. As one of the pillars of OOP, it is beneficial to me as a learning programmer to understand about the purpose of ‘encapsulation’ and how it can be effectively applied.

I realized during one of my classes — when we were reviewing these four pillars — that while I knew the principle by name, I had never learned encapsulation in detail nor how to best implement it into my code. Looking back at code I had written in the past, it was clear that I did not always follow this practice (i.e. using dangerous global variables as attributes in my objects).

The blog “The four pillars of object-oriented programming — part 1 — encapsulation”, written by Bas Dijkstra, helped better illustrate for me what encapsulation is supposed to do.

Firstly, encapsulation is all about making attributes private. By doing so, an object’s attribute is protected from being accidentally — or maliciously — altered. Instead of accessing the attribute directly, the value can and should be returned through a public method within the object, essentially making the attribute ‘read-only’.

By doing this, a programmer gains more security and control over the code, reducing the amount of unwanted behavior in the system as a whole.

Secondly, good encapsulation is the product of good design. In another blog, “Encapsulation in Functional Programming”, by Mark Seemann, which I found by looking deeper into the strategies of implementing encapsulation into code, talks about creating a ‘contract’ for each class. The contract outline three properties of a class:

  1. Preconditions — what are the minimal requirements for the object to function?
  2. Invariants — which attributes of the object do not/cannot change?
  3. Post-conditions — what are the boundaries/rules of the object after it is created?

Though the article focuses more heavily on encapsulation for functional programming, the design strategy also benefits OOP. Having these properties outlined in the contract of a class helps the programmer understand not only what needs to be encapsulated, but also how it can be encapsulated.

In addition, because of the nature of encapsulation and the amount of control it provides a programmer over the code, testing for such classes that follow the principle becomes much simpler and easier to do .

While a simple principle, encapsulation is a powerful and practical strategy that makes code secure and easy to manage by hiding the inner works of a class behind public methods.


From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Software Craftsman Chapters 15 and 16 (05/09/17 Week 14)

In chapter 15 of the software craftsman goes about covering the whole “quality over quantity” shebang which I can not express enough on in terms of development. Now a days people would something that works properly than a whole bunch of half-broken features that seem like they are rushed and poorly done which ruins the reputation of the team when its not completely their fault.  In the end the author blames lack of skills which will defect the quality which ends up revolving around the whole “software craftsman” value around this entire book kind of symbolizing how having craftsman on your team will avoid these poor quality issues. In the end, quality and something that works is the most important part no matter what the requests made by the higher-ups.

If you do not understand “quality over quantity” comment, its not wise to lead without understanding this. Something short but sweet is much more preferred than huge and sloppy. Art is never rushed and creations are always viewed as an instance of beauty in the world, where its up to you to lead team to make sure it doesn’t look like a really bad smudge.

Finally, in the finale of finals. We take a stroll in the 16th chapters of this interesting book where we find out that the last topic the author covers in order to wrap up the craftsman story which is a career of a software craftsman. In the end, the career revolves around one thing which has been mentioned numerously here and other in the Clean Coder, and that thing is the feeling of passion. A true craftsman needs to love what they do, then they see the light of how awesome what they do is. you can’t get enlightened if you don’t have a spark to guide you. Simple enough just take it slow one step at a time and your milestones will reach you and your goals will be rewarding. Its an adventure worth taking only if you love it.

As the end of this course ends, as well as this book. Looking back at this as well as clean coder taught me many things mainly because they have been repeated in the same books, which isn’t a bad thing to be honest. They both tell the tales of professionals and their stories along with their experiences that crafted the advice that they give to us and in the end it all comes down to where you have to love what you do to enjoy it and be good at it. That is the biggest stepping stone, not just in programming, one needs to realize in order to advance far into life, into a world full of adventure.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Software Craftsman Chapters 13 and 14 (05/02/17 Week 13)

One of the ways to keep the workforce up and running is to continue providing fuel to everyone’s curiousness by giving them something to learn every now and then. Chapter 13 of the Software Craftsman focuses on the culture of learning and how it can spark and continue everyone’s motivation and morale. Some of the ways the author increases learning is having extra activities on the side for everyone to participate in, whether if its just a book club or a time slot dedicated for lunch and talking geeky things or even if it means having occasional group discussions to keep the environment engaged. Switching projects is also another tip that he mentioned however it could be a bit risky, but it is definitely effective especially if one has a hobby project they are working on and boredom of the current project lets them want to work on their hobby project.

What interested me was the fact that there is a chance not everyone wants to join in on the side fun, and that is perfectly ok as the author puts it as well. You can not change anyone and people have their own interests and stuff to do, but at least the opportunity is there for anyone who wants to give the side activities a try which is nice. The best part is you have done everything you can to make things better, and that’s something to be proud of.

In Chapter 14, the author takes a different turn and goes back into talking about technical aspects. In this chapter, driving technical is the main topic that is cover and if its one thing that author made clear, it is that taking on that challenge is very difficult. You are put into calling the right choices that will critically affect your project and the team and its a time where you must hope none of your choices carry consequences. As a leader you have to get used to everything and everyone’s different approaches against you or the project and it can be very stressful if you do not carry the same language.

Leadership on a more intimate and personal note means you have to lead a small team that you actually know how they work and you know their names by heart. While this is the most preferred structure to work with in my opinion, leadership for thousands of people will lead you to think of them as just numbers on a chart with no value as you do not know all of them which is scary. Knowing who you work with is critical as a leader and it is a greater chance you will not lose control.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Reflections (4/26/17) Week 12

On our last sprint, we were flooded with challenges and problems (mostly not on our side) in a way most of our issues to solve is not in our control. Regarding the button, we knew how to fix it and decided on a location to put it which was on the header of the patient dashboard. The button was also not fixed still and we have not gotten any replies from the devs regarding the issue that Pat put up on JIRA. While we were trying to apply the solution to moving the button, we did not have enough time to actually implement it let alone also get the approval at the same time from Jonathan Dick about how the button should be handled, if it even worked for the matter.

Other than the button, the issue I was working on regarding changing color to reference a patient’s status took an interesting turn. After figuring out how to make a proper if statement in an HTML page within an element, I was notified by Ryan the repo was updated and they already addressed part of the issue which was putting a color on whether the patient was dead or not. They put a mutual operator as an if statement and made another style bracket with the right properties to call. There was a patient.person.isdead component that I could have used to tell if the person was dead and they used that. I decided to do the rest by adding in whether if a patient is defaulting or transferring but I could not because there was nothing to declare those statuses. When I asked Ampath about it, they said I can not do anything from here and they have to do some server side coding in order to tell the default and transfer statuses which led the rest of the issue out of my hand let alone the issue status was put to critical.

Regarding the contacts Kyle and Pat were working on, they were still not functional for some reason as the properties put into the contacts list were not saved and always resets to blank every time.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.