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.

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.

Sources:

• Encapsulation in Functional Programming
• The four pillars of object-oriented programming – part 1 – encapsulation

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.