Understanding Linters: Enhancing Code Consistency

Recently in class we started to learn more about linting tools. In the class we used a linter to check all documents in a project to see which words are redundant or misspelled. After looking into some articles online I realised that linters could be used for many things. For example, if a company wants its developers to write code within a certain format so that other developers in the company can easily read it. It is not just for formatting it can be used for coding errors, bugs, security vulnerabilities and stylistic inconsistencies. In addition, linters can be used for many different types of programming languages that allows organizations or groups to set a standard for everyone coding in that project. 

A linter is able to do all of this by dividing the code into units for variables, types, functions etc. Then to make these units into tokens that then compare these tokens to the tokens already made in the linter. Next it checks if these tokens are different to the premade ones and will flag them depending on the reason the linter is used for that project. 

There are a lot of reasons why projects use linters. Here are a few examples: it decreases errors, it makes code more consistent, improves code quality, improves security, saves money by being time efficient, and setting coding expectations with the team. Let me explain further: no project or company wants their program to have errors that make it towards the end user. In addition, linters being able to save money is by checking the code to prevent issues from costing more time to fix and more money to fix. 

Many companies want to save as much money as possible within the different steps of development: production, design, testing, development and maintenance. Each of these steps requires a lot of people to verify if the code is working or if the code is what the customer wants. In addition, having developers be able to not spend as much time finding errors and solving them. That is why linters can save companies a lot of money for the next project or maintain operations. 

I do have a problem with linters personally, when I am focused on doing something. Then I have to use a linter, it makes me lose focus and creates friction to get back to focusing on the task at hand. This a minor problem because once I get used to using a linter then there will be less friction between focusing on the task at hand and solving errors caught by the linter.

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

The Role of Compilers in Programming Explained

In one of my classes this semester we started to learn about the purpose of a compiler in programming. After learning about a few things on how a compiler works, I just wanted to spend some free time learning more about the subject. Even though there are many different compilers out there currently they all still use the same steps on processing high level language to machine coding. The following steps are lexical analysis, Syntax analysis, Semantic analysis, Optimization, Code generation. 

  • Lexical Analysis: In this step it sends the high level code through a compiler’s lexer changing certain parts of the code like operators, identifiers into units that make up tokens. 
  • Syntax analysis: During this step it looks at all the tokens and checks the code for syntax errors and other programming errors within that coding language conditions. 
  • Semantic Analysis: Once the code is checked the compiler uses semantic analysis in order to determine the purpose of the code. In addition it tests for logical errors with the code for example the code could have an arithmetic error. 
  • Optimization: Within this step optimizations with a compiler are not always the same depending on what they want to optimize. For example, have the code run all the steps as quickly as possible or decrease the electrical demand for a coding language. 
  • Code generation: Once the code goes through this step the code will be converted into assembly code so that the computer can read the instructions needed to run the program. 

The convenience of using a compiler is that it allows programmers to code in high level language which is a lot more readable than assembly code. In addition it allows programmers to be able to learn any high level language. Which allows them to not worry about the steps needed to convert the code into assembly since the compiler will do it for them. Also having the compiler check for multiple different types of errors helps improve with quality assurance. Another factor to consider, certain hardware can only run specific types of code but with a compiler it lets programmers choose which language they prefer. 

Also compilers can reduce repetition due to only needing to run the code once and then it will be able to execute repeatedly from then on. Lastly Compilers can check for errors that we do not consider for example memory leaks and potential security issues with the code. 

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

Sprint 3

For the third sprint of the course, I was in charge of merging an environment path fix and updating the version in the docker-compose on the server, demonstrating the working system to OSILD (the department that runs the food pantry), and getting the docker-compose file to run when the server is started up.

These are the links to the tickets related to this sprint:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/deployment-server/-/issues/9

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/deployment-server/-/issues/8

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/113

The task of getting the docker-compose file to run when the server was started required some research on what were the best methods to get this done. During one of the course meetings, we had attempted to create a file in the server that had terminal instructions that would get this done but this was unsuccessful. The simple solution ended up being to add “restart: unless-stopped” for each container in the docker-compose file. 

The apprenticeship pattern I chose for this sprint was Record What You Learn. This pattern discusses the frustration of learning something that doesn’t seem to stick, then dealing with the frustration from the deja vu of doing that task and relearning again and again. I chose this apprenticeship pattern because I tend to fall into it relatively often and I have started to develop the habit of writing down new skills to remember them better. Due to the fact that I am in the process of developing this habit, it is further difficult to fall into this pattern of relearning because it is followed with the thought that I really should have written the process down. 

This pattern is suitable for this sprint because of how the meeting with OSILD (the department who runs the food pantry) went. I had worked on this issue and it was working right before I went to present and right as I sat in the room with the two women who I was trying to demonstrate the server to, the server would not start up. I was able to joke it off and explain what was supposed to happen but there was something frustrating and on the spot about not being able to start it up that made me wish that I had written down, step by step, how to start up the server and how to troubleshoot it. Once I left the meeting, I sat with the server open and troubleshooted what was going on, using f12 to open the web page and look at the error messages and do some research as to what could have caused the problem. I thought it was because the backend had a new version and wasn’t updated so I updated the container in the docker-compose and it seemed to work. Later we found out that the reason the server wasn’t responsive is because there was a delay and a portion of the code was preventing it from loading if it took too long. I wrote all of this down in my notebook, like the pattern recommended and since then I have referred back to it many times. 

If I had read this pattern prior to the this sprint, I would have taken more diligent notes and made sure to better track my steps so I would be able to reproduce them under more stressful conditions.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

REST API Design.

The Stack Overflow Blog post “Best practices for REST API design” caught my eye (March 2, 2020). Blog for Stack Overflow. The article explains what a REST API is and why it’s important to design it correctly. It then gives specific advice, like accepting and responding in JSON, making sure that endpoint paths are made up of nouns instead of verbs, using plural nouns for collections, allowing filtering, sorting, and panning, handling errors correctly, creating versions of your API, using standard HTTP status codes, and enforcing security and caching. The main idea is that APIs should be easy to understand, reliable, adaptable to the future, and simple for other coders to use.

As I learn more about financial systems, data analytics, and making tools that can reveal or use services, I need to know how to build and use backend components in a clean way. The piece caught my attention because it is both theoretical and useful, and it is written in a clear way that connects what developers expect now with what is best practice. Because the business systems I work on in the future might use APIs to connect billing, collection, or data analysis tools, this kind of advice seems very useful.

I felt a lot of things reading this. First, I liked how the focus was on using resources (nouns) instead of verbs in URL paths. This is something I have seen broken in older systems (for example, /getUserDetails or /updateBillingInfo), which shows right away that the design isn’t clear. “Use nouns instead of verbs in endpoint paths,” the paper says. Blog for Stack Overflow. This idea makes things clearer: when I make or use an API, I want to be able to look at endpoints and immediately understand what the system models (users, orders, and invoices), not what action is being taken. In REST, the action is taken care of by the HTTP verb.

Another thing is that the article talks about standard error codes, versioning, filtering, sorting, and pagination. These are important for growth and maintainability but are often forgotten when speed is the most important thing. When I build an API for a payment module today without planning for versioning, for example, clients may not work with future changes (like adding new fields or changing the way things work), which causes problems between teams.

Basically, I learned or reinforced the idea that designing an API isn’t just about “making something that works.” It’s also about making something that other developers can use easily and that can grow. This fits with one of my user goals, which is to be correct and organized with systems, documentation, and interfaces. A well-designed API makes things clearer, cuts down on mistakes, and allows for future growth, which is a lot like how I focus on detailed paperwork and efficient financial systems.

ReferenceStack Overflow Blog. (March 2, 2020). The best ways to build a REST API. https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.

Quarter 3

As I am approaching the end of the semester, I have been doing a lot of group activities on GitLab with my teammates. Switching roles and getting to know one another more while taking on the task we needed to. Working on Exam 2 and finishing that to access our knowledge then learning more about the different types code people write and how it can affect the entire team.

For the final few days of the semester, we will continue to put our skills to the test with these various challenges and fix some of our old code issues. I’ll finish off this semester strong!

From the blog cs@worcester – Software Development by Kenneth Onyema and used with permission of the author. All other rights reserved by the author.

Delving Deeper into Rest API

I have been learning more about REST API. Currently I have been working on backend implementation. Working on this is somewhat difficult. I understand how to implement new endpoints to get certain objects, but I have trouble in other things. It mostly has to do with the current homework.

So, I decided to learn more about it. I went to a blog from Stack Overflow since it is well known for having useful information about coding. If you need a question answered or a working piece of code you go there. I have used it before, and it was helpful. Hopefully, by the end I get a better understanding of the material and can utilize that newfound knowledge in the homework.

I used this: Best practices for REST API design – Stack Overflow

The article discusses the best practices for REST API design. It discusses using logical nesting to group associated information, and handling errors gracefully. It also discusses allowing filtering, sorting and paginating data. They are utilized to help deal with large data by only outputting the data that is needed. Let’s say there is 400 pieces of data and you only need 4%. By filtering, you can get that 4% without dealing with a slowdown and having to parse through data to see the 4%. The article also discusses versioning APIs, maintaining good security practices, caching data and minor things like using nouns instead of verbs in endpoints. It also discusses the importance of JSON and how it can be used for transferring data.

There is useful information but the one that stood out to me was the one about filtering, sorting and paginating data. There is a part of my homework that requires filtration. I need to make sure that when guest age is called, depending on the way GET is structured the resulting list is greater than, less than or equivalent to the chosen value. That section in the article gave me an idea. Like the example given in that section, I could use an if statement to filter out results. This may get the result I want.

To conclude, this article has been really useful to me. It has helped me understand what I have to do for a part of my homework assignment. It was interesting to learn ways to improve my REST API design. I may not know if you I will use this information in the future, but I know that I will use it now.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Strategic Web Systems Implementation: Key Principles for Modern Applications

For this week’s professional development blog, I delved into the article “Modern Web Implementation: Best Practices & Strategies” from NoPassiveIncome. The piece provides an actionable, business-oriented framework for building web systems that are performant, maintainable, and user-centric. Given our course focus on web architecture, design, and deployment, this article offers vital insights that closely align with our syllabus.

Summary of the Article

The article begins by establishing the importance of robust web implementation, arguing that effective execution translates design into a reliable, high-performance website. It underscores that a poorly implemented system can degrade user experience, SEO, and long-term maintainability.

Key elements of strong web implementation are described in detail:

  • User Experience (UX): The article emphasizes intuitive navigation, clean design, and accessibility, asserting that a stellar UX fosters engagement and retention.
  • Responsive Design: Given the ubiquity of mobile devices, implementation should prioritize fluid layouts that perform seamlessly across a range of screen sizes.
  • SEO Best Practices: From keyword placement to meta tags, the article recommends embedding SEO considerations into the implementation phase rather than treating them as an afterthought.
  • Performance Optimization: Techniques such as image compression, code minification, and browser caching are explored to minimize load times and maximize responsiveness.

The article also addresses common challenges, such as cross-browser compatibility and mobile optimization and offers practical solutions like extensive testing and responsive design. It highlights emerging trends in web implementation, including progressive web apps (PWAs), voice search optimization, and AI-powered chatbots. Finally, the piece recommends essential tools like Google Analytics for behavior tracking, SEMrush for SEO analysis, and Bootstrap for streamlined responsive development.

Why I Chose This Resource

I selected this article because it directly aligns with our Implementation of Web Systems course. We’ve been discussing architecture, design trade-offs, and the practicalities of building real-world web applications. This resource synthesizes those academic topics into concrete, industry-ready guidelines.

Moreover, as I prepare for future roles where I may design, maintain, or deploy web systems, I want a strategic understanding of implementation that goes beyond coding, one that balances technical best practices with user-centered concerns.

What I Learned & How It Enhances My Understanding

This article reinforced for me that web implementation is more than just writing code, it’s about strategic execution. The discussion of UX taught me that simplicity and accessibility matter just as much as backend logic. When I build web systems in class, I plan to pay greater attention to how every design decision affects usability.

I was also struck by the emphasis on SEO during implementation. In class, SEO sometimes feels secondary, but this article made clear how deeply it should influence how we build, structure, and implement web pages.

Finally, the performance optimization section resonated strongly with what we’ve learned about efficient web architecture. Minimizing asset size and leveraging browser caching are practical techniques that I aim to use in future projects to ensure speed and reliability.

How I Will Apply These Insights

In upcoming web development assignments and real-world projects, I plan to:

  • Start with user experience design and accessibility, not just backend features.
  • Build always with responsive layouts and test across devices.
  • Treat SEO as an integrated component of implementation, not an afterthought.
  • Implement performance optimizations from the beginning, including image compression, code minification, and caching.
  • Use analytics tools like Google Analytics to track performance and gather actionable user behavior data.

This article has deepened my confidence in building web systems that are not only functional, but also optimized, user-friendly, and future-proof, exactly the kind of approach this course encourages.

Citation / Link
“Modern Web Implementation: Best Practices & Strategies.” NoPassiveIncome, accessed 2025. Available online: https://nopassiveincome.com/modern-web-implementation/

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Choosing the Right Open Source License

Choose an open source license

For this week’s self-directed professional development, I explored the topic of choosing open source licenses, which is a fundamental but often overlooked part of releasing software. I based my reading on ChooseALicense.com and supporting resources that explain how permissive licenses, copyleft licenses, and public domain-style licenses differ. What I found most interesting is how a license doesn’t just define legal rules — it reflects the values, intentions, and goals of a developer or a team. Software licensing shapes how a project evolves, how a community forms, and how contributions are handled over time.

Open source licenses fall into a few broad categories. Permissive licenses like MIT or Apache 2.0 give users almost complete freedom to reuse the code, even in closed-source commercial products. Copyleft licenses like GPL ensure that any derivative work must remain open source under the same license. And options like the Unlicense or CC0 place code essentially in the public domain, allowing anyone to use it with zero restrictions. Before this week, I assumed licensing was just a legal formality, but now I understand how strongly each license type influences collaboration and long-term project direction.

I chose this topic because licensing is directly connected to the work we do in Software Process, especially when we talk about transparency, collaboration, and project ownership. As future developers, we will eventually publish our own tools, libraries, or contributions. Knowing how to license our work is part of being a responsible member of the open source community. Many people assume that posting code publicly means anyone can use it, but without a license, nobody can legally copy, modify, or reuse it. That detail alone made this topic worth exploring, and it helped me rethink how important explicit permissions are.

One thing I learned is that choosing a license is really about choosing a philosophy. If a developer wants to share knowledge broadly, enable commercial use, and reduce friction for adoption, a permissive license makes sense. If the goal is to ensure the code stays free for everyone and cannot be closed off by others, a copyleft license protects that intention. The reading made me think carefully about what I would want if I released a personal project. Personally, I lean toward permissive licenses because I want people to build on my work without worrying about legal constraints. But I also understand why larger community-focused projects might choose GPL to preserve openness.

Going forward, I expect licensing to be something I pay more attention to in both school projects and professional work. As software engineers, we’re not just writing code; we’re shaping how others can interact with it. Licensing is part of that responsibility. This topic helped me better appreciate the intersection between technology, ethics, creativity, and law — and it reminded me that releasing software is more than just pushing code to GitHub; it’s about defining how that code fits into the larger ecosystem of open source development.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Have Great Documentation with These 9 Steps

Through my past couple blogs of Object Oriented Programming, REST APIs, and frameworks, I often came across the word “documentation” but commonly overthought it and didn’t do any more investigating into it. With that being said, I came across this blog 9 Software Documentation Best Practices + Real Examples and I feel a lot more comfortable with documentation as a whole. https://www.atlassian.com/blog/loom/software-documentation-best-practices

Imagine, you and your developing team are coding away on an application, but then an error appears, by which no one present knows how to solve it.

To solve this error, your options are:

  1. Slack threads
  2. Stack Overflow
  3. Emails back and fourth 
  4. Documentation 

The most promising answer of these options are documentation. With great documentation, you will get a clear precise solution to the problem you are facing. 

Now, what exactly is documentation? Documentation is written information that clearly explains the program’s structure, functionality, and when/how to use it; should be used as a guide or as a reference pointer for developers. If the documentation is done right, it reduces friction, boosts productivity, and helps the user understand the code from all angles due to the information of processes, functionalities, and solutions.

With so many benefits, documentation should be at the forefront of software developing teams, but unfortunately, it often gets overlooked. One of the main reasons for this is because documentation can go outdated very quickly. 

That being stated, here are nine ways to make sure your documentation will always be great:

  1. Know your target audience
    1. General Audience (surface level) vs Developers (technical)
  2. Keep it user-friendly
    1. Having a table of contents with clear headings can make it a lot more easier to find what the user is looking for
  3. Use version control
    1. By doing this, you will be able to see all the latest updates
  4. Incorporate visuals
    1. Some people are visual learners, who work better off of a video, photo and/or diagram (within reason)
  5. Adopt a documentation style guide
    1. Consistent styling will make it easier for the user when going through each documentation type from said releasers (writers/developers)
  6. Update regularly
    1. By doing this, your documentation will align with the latest software functionality
  7. Encourage collaborative documentation
    1. Working together in person or remotely 
    2. Always good to have a peer’s input
  8. Provide troubleshooting and FAQs
    1. This enables users to find solutions for common issues very effectively
  9. Use documentation templates
    1. This will give a great start to all coming contributors of the documentation 

Overall, I really enjoyed this article and its purpose of making software documentation better. Furthermore, it mentioned how Google and Microsoft all stick to the same consistent documentation perspectively, which opened my eyes of how important consistency is in documentation within a company. Along with this, before “jumping” into something new, it will definitely be worth it to go over the documentation. Understanding and referencing any documentation is a skill.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

A look at REST API designing

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.