Author Archives: Justin Lam

Understanding RESTful API design principles – Upsun Blog

This quarter I decided to read “Understanding RESTful API design principles” by the Upsun blog, which talks about many aspects of RESTful API. I picked this because it directly relates to what we’ve been learning recently in class, and relates to a system I will have to work with next semester for my Capstone. I figured it would be a good idea to get more familiar with REST API early.

The article starts off explaining what REST (REpresentational State Transfer) actually is. It’s a “set of architectural principles that define how to design and implement these interfaces”, discussing the HTTP methods involved. Being the only API design principle I know of, I had no frame of reference for its advantages compared to other options, but the article provides a chart and compares RESTful to GraphQL (good for more efficient and specific data fetching) and gRPC (Good for microservices and streaming).

The RESTful architecture typically contains a Client, Server, and Database, but it can include additional elements such as a load balancer or a cache. The Client, Server, and Database are fairly straightforward, being the consumer, the server hosting and processing the requests, and the database to store the data. The load balancer is also intuitive to it’s name, but for the smaller scale system like the Food Pantry which is unlikely to experience a large server load at any time anyway, it’s probably unnecessary.

The article goes into 6 design principles of REST APIs. The first one, Client-server architecture, states that the client and server should operate independently to make long-term maintainability better. The second is Stateless communication, stating that each request from the client should contain all the information needed to process the request. Nothing is stored on the server, so that each request is self-contained and can be handled independently, simplifying the process. The third is Cacheable Responses. If an API response is cacheable, it should include caching headers such as “Cache Control” or “Expires”, so that the data can actually be cached and the server doesn’t need to be queried every time. The fourth principle is Layered System. In many ways this seems similar to the principle of Abstraction, where the API should operate across multiple layers without the client being aware of the layers, reducing complexity and making it so the client doesn’t have to interact directly with multiple backend servers. The fifth is Uniform Interface, stating that the way resources are interacted with (ie. HTTP Methods, URL patterns, etc.) should be standardized and uniform. The last one is Code on Demand, which the article states as optional. It states that servers can use executable code such as Javascript to extend functionality.

Many of these principles were fairly intuitive, but it’s good to have them explicitly stated anyway. Some were also directly connected to our class discussions. Things like caching and the executable code stuff are things we didn’t talk about, but I’ll keep them in mind as we do more with REST API.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

Mastering OOP Fundamentals with SOLID Principles – ByteByteGo

The blog post/article I choose to read and write about is Mastering OOP Fundamentals with SOLID Principles from the ByteByteGo blog page. This blogpost goes into many aspects of the OOP programming, some of which we’ve discusses in class. The first portion delves into Encapsulation, Abstraction, Inheritance, and Polymorphism. It explores some key concepts like single inheritance, multiple inheritance, multilevel inheritance, hierarchical inheritance, method overloading, method overriding, etc. It explains how these 4 fundamentals are important for creating and utilizing OOP effectively, but in and of itself doesn’t necessarily create code that is easy to work with and maintain.

That’s why it introduces the principles of SOLID, which according to the syllabus is something we will eventually touch on in the future. The S is for Single Responsibility Principle, stating that classes should only have a single reason to change. This ensures better organization, easier debugging, and improved testability, so it’s better to split a complex class into multiple simplified classes. The O stands for Open/Closed Principle, stating that classes should be open for extension, but closed for modification. Essentially, if we want to add new behaviors to a class, new subclasses or interfaces should be added without changing what already exists. The L stands for Liskov Substitution Principle, stating that “objects of a derived class must be replaceable by objects of the bass class without altering the program’s correctness.” A subclass shouldn’t break existing functionality while behaving like it’s parent class. This somewhat relates to the interface portion of what we did in class. The I stands for Interface Segregation Principle, stating that clients should not be forced to depend on unused interfaces. Essentially, interfaces should be small and specific, with only relevant methods. Finally, the D of SOLID stands for Dependency Inversion Principle. This states that high-level modules and low-level modules should depend on abstractions, rather than each other. This can help improve flexibility and mobility, so that it’s easier to test and work with without making as many modifications.

The reason I chose this blogpost/article is because it directly relates to what we’ve learned with the fundamentals of OOP so far, as well as introducing me to something that’s planned for the syllabus. I also saw it as a good primer for Java and OOP thinking to help me better understand the general ideas and concepts that hold it up.

Even though a good portion of what was written is just reiterating some of what we’ve discussed in class, I found it really helpful to have things explained another way with the examples the blogpost gave. It helped me better grasp the purposes behind these fundamental principles and ideas in a way that felt easily digestible. The SOLID portion was also interesting, and everything intuitively makes sense. I can definitely see myself referring back to this and sticking to these ideas as I do OOP programming in the future, because it genuinely does seem to make the code easier to work with and easier to understand.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

Blogging for CS-343

Since UMass notified me that they were deactivating my old school email, I’ve transferred all my old blog stuff to this new, separate WordPress blog. This semester, my blogposts will be about software construction, design, and architecture.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

How to review code effectively: A GitHub staff engineer’s philosophy

For my final blog post for the semester, I wanted to pick a topic that was different from project management, since I had already written about that a few times. Since our most recent topic in class revolved around GitHub and git commands, I wanted to explore a blog post that aligned with that topic. I came across a blogpost by GitHub staff engineer Sarah Vessels, from the github.blog page, about code review.

In this article, code reviewer Sarah Vessels discusses some practices to help improve code reviewing and make it more useful and efficient for everyone involved. She advises constantly checking your GitHub notifications inbox, anytime you have a spare moment. She also recommends using GitHub Slack Integration. Certain queries can help filter a slack group for finding outstanding pull requests that need review. We used Discord for our class instead of Slack, but as I understand it, Slack is more common in the professional world. I believe Discord has equivalent queries that can be used, anyway. The next piece of advice she gives is to use reviewer teams to manage notifications. While catch-all code owner teams can be okay as a fallback, it’s better to keep the number of code owner teams your own small, so that anything you get pinged for or anything that shows up in your inbox feels relevant to you, and not just something to ignore.

The next part she discusses, which I feel is the most important advice, revolves around giving good, constructive code review that doesn’t across as lazy. Good code review focuses on specifically saying,” I have a problem with this, maybe you should try xyz instead” instead of saying “I don’t like this” or “This won’t work” and leaving it at that. It’s good to ask questions, because the person who authored a pull request has more context for their changes, and gives them a space to explain and justify their reasonings. Personal preferences are fine, but approval should be about the overall integrity of the code. If the changes won’t break anything or affect production, leave the feedback with a comment but still approve the pull request anyway to keep the process moving. This is something I personally appreciate from the author, because while I don’t mind receiving feedback and improving my part of the process, I hate the feeling of holding back the overall process. This allows opportunities to open discussion without causing a holdup.

She has a few other suggestions in her blogpost, like being gracious and using draft pull requests, but I believe the most important things are her advice about the giving good feedback and managing notifications so you feel compelled to give every notification your full attention. I don’t know how much code I’ll be reviewing in the near future, but if I’m ever in this situation, on either side, this is good advice for me to keep in mind and remember.

Link: https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

A Serious Look at Playful Retros – Sjoerd Nijland

I’m writing this blogpost about Scrum, specifically about the Sprint Retrospective(although the author refers to it as a Scrum Retrospective) that takes place after a Sprint Review. This blogpost(possibly article?) caught my eye while I was browsing through some blogs, as it directly references something we’ve learned about in class, but from a different point of view. Does ‘fun’ and ‘silliness’ have a place in a professional setting like a Sprint Retrospective? My initial thought after reading this introductory question is that yes, a little playfulness is fine as a means to relieve tension and stress, so long as it doesn’t hinder productivity, and so long as everyone is comfortable with it. But while it’s fine in moderation, it’s by no means a necessity. If someone wants to maintain professionalism, then that’s completely fine too. But as someone who’s never actually worked on a development team, I was interested to hear an experienced person’s take on the subject.

In the referenced article, Sjoerd Nijland first addresses the common critiques of playfulness, where people call it unserious and unprofessional, and assume that it gets in the way of productivity. He counters by mentioning the benefits of playfulness based on neuroscience. Some of these include: Improving brain function, energy, and happiness, relieving stress, deepens connections and trust, and encourages creativity needed for problem-solving, amongst many other benefits. It’s something that everyone, even introverts, can benefit from. It’s a mindset. It provides psychological safety. It puts people in a comfort zone, leaving them open to new ideas and discussion. It keeps people trusting of one another, instead of checking and inspecting each other. And so he counters the common by saying that not only can it be beneficial in a professional environment, but that “Discouraging playfulness at work is profoundly UNprofessional”. When applied intentionally, it can be a great mechanism for helping your team deal with what would otherwise be a stressful environment.

I like the way he views playfulness, because he thinks of it in a different way than most people would. Playfulness isn’t slacking, it’s a tool, one that benefits team dynamic and productivity in the long run. Too much of it can be detrimental, and people shouldn’t be neglecting work for play, but ideally it should exist in some capacity. He references existing scrum environments and scrum professionals, and addresses how it’s helped in certain cases, and how some of the scrum critics aren’t viewing it the way they should. Playfulness and seriousness complement each other, and when used correctly, is a great tool for improving your team’s relations, stress levels, and ultimately, productivity. I’ve changed my mind playfulness being unnecessary. A little levity is important for the mind and body, and I’ll definitely keep that in mind when I’m in a professional environment.

Link: https://medium.com/serious-scrum/a-serious-look-at-playful-formats-in-retrospectives-73aed21aa083

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

TPM Podcast With Arjun Subramanian: Burnout

I chose to write about this Podcast episode in a blog because it’s a topic that resonates with me personally. This episode speaks specifically about the effect COVID had, and how burnout relates to that, which is something that affected me heavily during the COVID year. This isn’t really a topic we discussed directly in class, but Arjun Subramanian is discussing this with Mario Gerard within a technical project management context, which I feel relates to the general theme of what we’ve been discussing thus far in class.

Something Gerard and Subramanian talk about is establishing a boundary between work life and home life. This comes naturally when you’re clocking in to work from 9-5, and forgetting all about work as you come home, but when working from home it becomes harder to mentally separate the two. Working from home in the tech industry has its undeniable benefits, and there’s a reason so many people in the field prefer it, but with increased productivity also goes hand in hand with increased effort, or at least prolonged effort. It becomes harder to create a boundary between work and life when there’s no physical separation between the two. This is something that impacted me heavily, because prior to this I always kept strict separation of my school life and family life. Going to college in 2019 was really the first time I blended school life and social life, and I had the freedom to approach this in whatever way I thought best. Coming home from UMass due to COVID was a huge detriment to that, and having to manage my online courses with my tense familial struggles was something that wore me thin.

The podcast also discusses how toxic environments can contribute to burnout, and the necessity of having the agency to manage and create your boundaries. You can speak up, and you work as hard as you can within your specific timeframe, and you put your heart into it, and once that time is up you come back to earth and you don’t allow work to cross that boundary into personal life.

As far as toxic situations go, that doesn’t necessarily mean a difficult one. As Subramanian talks about, you can have a difficult situation that’s right, and you need to show “grit and tenacity”. But a toxic situation is one you need to walk away from, for your own sake. There may not be a clear way to identify a toxic situation from just a difficult one, but there are signs, and while they talk about some of the signs on the podcast, the bottom line is that you need to have your own well-being in mind as you work.

The discussion about boundaries and toxic situations is one that I feel are a major contributor to the way I was affected by burnout over the COVID years, and something I’m aware I need to look out for, now and in the future.

Podcast Link: https://www.mariogerard.com/tpm-podcast-with-arjun-subramanian-project-manager-burnout/

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

Our Approach to Testing – Rich Rogers

In this blogpost, Rich Rogers, a Testing Capability Lead for Scott Logic, discusses how the people there approach testing as part of their Development and Delivery process, particularly through their 6 principles. He emphasizes context as the first principle, and how when testing, things will always change. You can’t standardize testing, because every project will require different tests. In many ways, this resembles the Agile ideas that we’ve discussed in class, specifically the portion about “Responding to Change over Following a Plan”, and also goes hand in hand with another one of Roger’s principles, which is “Risks over Requirements”. I agree that you may be given a set of requirements as a team, and it may be satisfactory for a customer to fulfill these requirements, but there is value in looking beyond just the requirements and exploring other risks or potential problems that may not have been stated. A plan exists as a guideline, not a strict rule.

Besides those two principles, the remaining ones are: “Value in Tooling”, “Quality for Humans”, “Bring a Testing Mindset”, and “Collaborate and Cross-skill”. To elaborate, the blog discusses Value in Tooling as understanding the tools you have, and taking opportunities to run repeatable automated checks when applicable, so long as they are efficient in terms of cost and effort. Quality for Humans refers to the notion that at the end of the day, humans will be the ones using these tools. The goal is to provide something that humans will be satisfied with, and will be accessible for a person to use. In some manner, this resembles the Agile principle of Customer Collaboration, or even the Individuals or Interactions part of Agile. The Testing Mindset principle is a more broad, referring to a questioning mindset that is aligned with wanting the product to succeed. Every tester has a unique way in which they approach testing, and so long as the end goal aligns, every mindset is valid. Collaborate and Cross-Skill refers to the notion that, while the industry encourages individual testing, understanding your team’s skills and working to complement each other can be helpful.

Ultimately, I think these principles can be summed up as be flexible, similar to how Agile works. A willingness to understand and use tools in testing, taking the human aspect into account, a willingness to approach things with a level of curiosity and questioning, and a willingness to collaborate with others, especially those with skills and expertise that vary from yours, are all examples of disregarding the rigid plans and processes. To do your best work, you must be willing to approach anything in multiple ways and with multiple mindsets. Having chosen this blog post because of it’s insight into testing, I definitely find myself agreeing with the overall principle behind this testing approach. I don’t know how much control I will have over testing in the future, but I would certainly like to apply a similar approach to how I test things in the future.

Blog Link: https://blog.scottlogic.com/2024/10/30/our-differentiated-approach-to-testing.html

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

Hello World! pt.2 – Transitioning to Computer Science

Having never really used this blog during my time studying engineering, I suppose this will be the start of a CompSci dedicated blog. For the time being, these posts will be relating specifically to the CS-348 course at Worcester State, most likely to record and catalogue all of our learnings and group assignments.

I’ll likely try to find a way to move this site off of umasscreate eventually, and probably repurpose the entire site, but until then I’d like to keep all my things together. Probably also pick a nicer page color.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.