There are many parts that make up well designed code. One of these is the management of responsibility, whether in classes, functions, or databases.

GRASP (General Responsibility Assignment Software Patterns) is a set of principles that programmers use to make code that is “responsible”.

In the previous article, the first four principles of GRASP were discussed:

• Information Expert
• Controller
• Low Coupling
• High Cohesion

These four principle, in short, say that code should be written with as little dependencies as possible to reduce the effects of change (low coupling), meaning that classes with similar responsibilities and dependencies should be connected not directly, but through an interface, or otherwise simplified into one class (high cohesion).

Furthermore, system events should be handled through a single class that manages and coordinates the system behavior using the processes available in other classes (controller). Classes that handle processes should be those assigned with the most responsibility (information expert).

The final five principles of GRASP are the following:

• Creator
• Indirection
• Polymorphism
• Pure Fabrication
• Protected Variations

As in the previous post, I will be referencing In10se’s article Mastering GRASP Design Principles for Better Software Design.

1. Creator: This principle states that classes that require objects should be responsible for their creation. This not only simplifies the creation process, but also supports the high cohesion principle in unifying classes with similar responsibilities.
2. Indirection: For processes that are used by multiple classes, the principle indirection says that an intermediate class should be created from which other classes may reference (i.e. a notifications class from which classes email and SMS reference).
3. Polymorphism: This pattern is same one stated in the core principles of Object-Oriented programming by which classes with similar attributes and methods are grouped under a super class where similarities can be inherited and modified accordingly.
4. Pure Fabrication: There may be cases when there are no classes in which a particular function may fit. In this case, to maintain high cohesion, a new and separate class can be created to handle these functions. However, should too many of these exist, that may indicate that responsibility is not being handled optimally.
5. Protected Variations: Classes should be responsible for handling their processes; but sometimes, especially for classes that deal with modifying sensitive data, the changes should be encapsulated behind a stable interface to increase the overall system’s robustness.

GRASP taught me a lot about how to better design my code. Looking back at the code I’ve written, I can see that my code would definitely benefit from higher cohesion and lower coupling. Many of my classes and functions are dense with responsibilities that would be more clear if separated into their own dedicated classes.

The point of GRASP is to create cleaner code that is secure and easier to manage. I didn’t think much about programming responsibilities before reading in10se’s article, but now I will be sure to implement these patterns into my future code.

Source: https://medium.com/@in10se/mastering-grasp-design-principles-for-better-software-design-a21b5ec29e89

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.

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.

Source: https://medium.com/@in10se/mastering-grasp-design-principles-for-better-software-design-a21b5ec29e89

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.

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.

Source: https://tangent.com/blog/software-license-management-best-practices/

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.

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.

Source: https://www.plutora.com/blog/understanding-the-dry-dont-repeat-yourself-principle

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.

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.

Source: https://www.freecodecamp.org/news/how-to-write-clean-code/

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.

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.

Source: https://blog.postman.com/rest-api-examples/

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 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.