Category Archives: Week-14


KISS is an American rock band formed in New York City in 1973. The band is known for its elaborate stage shows, which often feature pyrotechnics, fire breathing, and other special effects, as well as the use of makeup and costumes by the band members. In all seriousness…

The KISS principle, or Keep It Simple, Stupid, emphasizes the importance of simplicity in design and systems. By keeping things simple, you can better understand and meet the needs of customers and create products that are more user-friendly and effective. In the world of software and technology, the KISS principle is especially important, as people often have many options to choose from and may not understand complex technology. By following KISS, you can build a minimal viable product (MVP) that allows you to confirm or disprove your hypothesis with minimal work and deliver your product in a straightforward way that is easier for users to understand. Amazon, for example, lists the KISS principle as a core leadership principle, stating that leaders should always find ways to simplify. When designing, it is important to wireframe religiously, use universally understood concepts, and avoid distractions. By following KISS, designers and developers can create products that are more efficient, effective, and user-friendly, and that are easier to maintain and update over time. The KISS principle is often applied to the design of systems and user interfaces, as well as to the development of code and algorithms, to create products that are intuitive and user-friendly.

I selected thispost because I have always been interested in the principles of good design and how they can be applied to create better code as a result. The KISS principle is a concept that I have heard of before in other classes and especially in the Robotics class last semester. I wanted to learn more about this principle and after reading this post was impressed by the emphasis on simplicity and how it can lead to better products and user experiences. The post also focused heavily on real world applications and its outcome which helped me visualize it better. I found this material to be very informative and made me think about how I can apply the principles of simplicity and user-friendliness in my own projects and for other CS classes in the future. I expect to use what I learned from this resource in my future practice by being mindful of the KISS principle and always striving to create products that are simple, efficient, and user-friendly.




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

Blog Week 14 (Token)- Abstraction and Composition

The Two of the fundamental aspects of coding, Abstraction and composition, are discussed thoroughly in this blog as well as the overall impact these processes can have on the code as a whole, we discussed these two towards the beginning of the classes and how they have there rolls in being able to not only code better but to understand and lay out the structure of the code.

At first I didn’t really understand how reducing a problem to its most basic form could help when I need to make code to very Specific actions and work a certain way, however after utilizing those processes in order to simplify the problem, then follow up by building up from those basic models allows me to utilize basic code to solve my more advanced problems. This opened up my thought Process when it came to Writing code as now I could think of all of the previous Projects I had where I had to create multiple objects and set Attributes for each specific one, and now I could seamlessly do it on a larger scale reusing other basic code.

For abstraction, it is the process of reducing all of the but the most important details in the code and leaving all of the extra out, it is important as it all owes for the most basic process to be worked on, and then subsequent work can be delegated to the more advanced versions of that the problem. an Example would be to rather than making multiple functions for different things, we could makes basic function that can be implemented repeatedly and reused. We can look at an example of the duck Project where we looked at different models of these classes and we noticed that certain ducks needed specific flying actions or squeaking actions, so rather than making multiple classes for multiple different types of ducks we made a basic duck class and created specializations for them In order to better the overall structure and reduce clutter. Then the using Composition you may make the connections to the different Objects in order to share information. Using the Duck Project Again, we made different types of ducks with Connections being made to the main Duck class with all of the Parameters, then we made connections for the squeak and Fly behaviors.

The Writer Focus on some key Traits for Good Abstractions, that being Simple, Concise, and Reusable. These are the things to look for when you want to simplify the work you do.

Elliott, Eric. “Abstraction & Composition.” Medium, JavaScript Scene, 28 May 2020,

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.


This week I learned about concurrency in software. I read “Concurrent Programming Introduction” by Gowthamy Vaseekaran. Vaseekaran explains what concurrency is in programming as well as its positives and negatives of it. Overall it was an interesting post to read and I think it gave me a better understanding of how computers work.

Vaseekaran starts by explaining concurrency is the ability to run several programs or parts of a program in parallel. This can be a huge benefit for performing a time-consuming task that can be run asynchronously or in parallel. Vaseekaran then goes on to explain the reasons that led to the development of operating systems that allowed multiple programs to execute at the same time.

These factors are resource utilization, fairness, and convenience. Resource utilization is needed because when some programs have to wait for external operations there is downtime that could be used to let another program run. Fairness is when multiple users and programs have an equal claim on the computer’s resources. It is more beneficial to let them share the computer through finer-grained time slicing than to let one program run until it is down and then start the next one. 

The next thing Vaseekaran brings up is threads. Threads are a series of executed statements that are lightweight and have their own program counter, stack, and local variables. Threads are used to help run background or asynchronous tasks. They increase the responsiveness of GUI applications and take advantage of multiprocessor systems. Java uses at least one thread when running. Threads help java run more smoothly but there are risks. The main risk is when there are shared variables/resources. Deadlocks can also happen when threads are used and multiple processes get stuck waiting for each other.

This was a good amount of information to learn and I think Vaseekaran did a great job explaining what concurrency is and its ups and downs of it. Starting with the reasons why we use it and then explaining how it is useful for a programming language like java was a good way to make it easy to understand what it is and how it is used today in software development. I think it would be interesting to learn more about how threads can be used in java. Vaseekaran’s post was useful for understanding concurrency and what threads are but how exactly a java developer implements them was very brief here. I would like to know more about how that works exactly but this was a good introduction to the topic and was an easy read. I would definitely recommend Vaseekaran’s post to anyone trying to learn more about how software is run and how to make it efficient. 


From the blog CS@Worcester – Ryan Klenk's Blog by Ryan Klenk and used with permission of the author. All other rights reserved by the author.

Blog Week 14- Good Software Technical Writing

One of the most Relevant and important aspects of programming that I have neglected for a while is commenting and proper technical Writing, when I first started out I figured I would just remember all of the changes I would make to my code and didn’t require the small notes in-between methods. later on I began to understand the importance when I began working with many different files that needed to work in tandem and couldn’t remember what each method I wrote did or how it worked in the system as a whole.

In this blog the author Goes over many of the different aspects of technical Writing from either commenting on each method to adding context to the code overall, the biggest take away I got from it is that code without Comments is Worthless, by reading the documentation you should be able to understand why the previous engineers made changes or added functionality to the code. this allows for other developers to come in and quickly understand what is going on and be able to delete or insert sections of code in order to continue the development cycle.

the Writer goes on to show many different examples with one being a sequence diagram that gives the step by step explanation of what the Sequence of the systems in play, much like the different design architectures we discussed in a previous class where it shows the link between user and the database. The Importance of this kind of writing is that it can convey the was the system is supposed to work together so if another developer were come along and look over the schema they would understand the process and be able to work off of that.

Oliveira, Vincent. “HOW TO WRITE Good Software Technical Documentation.” Medium, Medium, 15 June 2022,

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Some APInions on REST and GraphQL

Whenever you’re new to a thing, a comparative look at different tools can help you understand the problem by learning how each tool approaches a solution. As someone new to consuming and designing APIs for the web, I’m interested in understanding APIs by looking at the difference in approaches of the REST specification and the GraphQL query language. This post is based on Viktor Lukashov’s GraphQL vs. REST blog post, which explores some GraphQL basics from the perspective of a REST API user.

Priority: server-defined endpoints or client-defined queries

The largest difference mentioned by most sources is that a well-built REST API relies on extensive backend definitions of endpoints, while GraphQL puts the onus on the consumer to carefully query the correct data.

In REST, accessing multiple entities requires visiting an endpoint for each entity. These endpoints expose data through predefined parameters and responses. Meanwhile, GraphQL exposes a single endpoint while only returning data that corresponds to the consumer-defined query. This approach requires higher effort from the user, but allows them to construct tailored queries without the need for forethought from the API designer.

As a fan of query languages, I think this comparison is very favorable to GraphQL. For any interesting or useful dataset, a user exploring the data should have more ideas about how to observe it than its maintainers and gatekeepers will. Providing flexibility for query writers lets your interface be used in ways you can’t predict.

Implication: caching and performance

One upside of REST’s focus on a planned set of endpoints and parameters is that expected frequent responses can be use HTTP caching to improve performance. Responses to GET requests will be cached automatically, reducing server requirements and potentially improving response speed for future identical requests.

In GraphQL, the query writer is responsible for using a unique identifier to generate useful cache data. That said, the consumer may be able to use single queries across multiple tables that would require more than one REST API call to access.

Relying on architecture over following best practices is probably the better way to make performance accessible, which is a point in favor of REST.

Consequence: rules and security

Another difference Viktor mentions is how developers implement secrurity rules. REST’s default to the expansion of endpoint-HTTP method combinations includes setting rules on this basis. In GraphQL, with it its single-endpoint, rules are instead set per field. This may require a steeper learning curve, but it also provides more flexibility for easily making some attributes of an entity more available than others.

Conclusion: rigid or demanding

One recurring theme of this comparison is that REST APIs are built to be rigid, and another is that GraphQL requires higher effort from the client. This is how I would decide between the tools. If writing something that I expect to be querying frequently myself in new ways, I’d want the query freedom offered by GraphQL. If I wanted a small and fixed feature set, REST seems like the spec to follow.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Confront your Ignorance

The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Software Apprenticeship Post #4

Today I will be focusing on the Apprenticeship Pattern “Use the Source”. This pattern talks about reading other people’s code to learn by their example of how to do things, so that you have a solid foundation of where to go when you actually start writing the code. As if your code disagrees with your intentions, it will never work.

The pattern also talks about how the “Practice, Practice, Practice” pattern will only reinforce bad habits if you do not know any good ones to practice by. This is important as habits can be hard to break, so it is best to start with good habits rather than bad ones that you may need to break later on.

A good idea is to start by reading code for applications and tools that you use every day and learn by their example. This helps you learn how the other programmers code, and helps you understand the thought processes that create the infrastructure of the programs and tools that you use. Another good idea is to download open source projects, downloading them from the current version of the source code, using source control, to learn the history of how it has changed and so you can learn how future changes are affecting it.

You can then also try to refactor the codebases to try to understand why the programmers made the choices that they did, and also any consequences there might have been if you were the one writing the program instead. This helps you further understand the projects, and it also helps you to build the projects as well.

However, during your exploring you will eventually come across some decisions you may disagree with. It is important to ask yourself if the developers knew something you did not, or vice versa. It is good to realize that maybe there were things outside of the developers control that required them to make those kinds of decisions.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Kindred Spirits

During the job interview that I have had. There is one question that I ask most recruiters which I believe is essential for job seekers who are looking for their first job. Deciding whether to work at that company, the question about the culture of a company is important. I think that if a company with a toxic culture and working environment, it would discourage the employees. There is this saying by Paul Graham “Nothing is more powerful than a community of talented people working on related problems”. In this “Kindred Spirits”, the author thinks that organizations’ cultures that encourage software craftsmanship are rare which I also think is true. Every day, tech workers complain about the working culture in big tech, that it’s not how they think it was when they first applied for the jobs, and that their jobs demand more time than just 9 to 5. So, I think that having a good culture is not only good for employees but also makes sure having better productivity.
The solution for those people who work in toxic culture is to be in frequent contact with people who are walking a similar road. Therefore, we should be able to seek out people like ourselves who are also looking to excel. The long road is not a road that anyone walks alone and especially in our early career, we should have a mentor. On the other hand, the culture encourages a safe environment for exploration and learning, a culture that does not limit its employees in what they should learn and that they can feel free to show each other what they’re learning to tend to attract more talents. Having no obligation to follow others’ lead would interest workers to explore and not be afraid of risk-taking. However, despite the benefits of a community of like-minded folk, we should be aware of groupthink. Avoid the questions that shock our community. Try to be respectful and use intellectual thinking to keep the community healthy. The culture and the community around us can be measured in the way it reacts to new ideas. Whether it embrace the idea after the intensive debate and experimentation? Or the ideas are quickly rejected? The most value we can provide service is defending it against those who believe that marching in lockstep is the price of membership.
To be able to do so we need to join the community where the people we work with, the blog we read, and the ideas we are intrigued by are respected. We can create our community but don’t be too strict on the ideas and topics too early. Advertise anywhere that software developers in our area might see it. Over time, these would pay off, as the group becomes larger and energetic enough, it will sustain itself even when we are not there. That’s when we have a community, good culture, and a non-toxic environment.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

“Practice, Practice, Practice”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice…


The pattern is about emphasizing the importance of practicing our skills, coding in this scenario, to become the master in that particular skill set. The pattern states that we need to keep practicing every time we try to master a new skill. The pattern also recognizes that our work life balance does not provide a safe or stable enough environment for us to keep practicing. The solution provided by the pattern is that we organize our days. To join people, face to face or online, and to practice coding or other skills as part of a community. The pattern also points out that we need to make time and create safe & stress-free environment, because if we are not in a relaxed state then we will not be able to learn from our practice.

Why this pattern?

From the first year to last year, I have been using and writing codes in Java language. Entire semesters have been dedicated to learn and practice Java concepts. However, in a span of few months, I had to learn languages like python, R, JavaScript; frameworks like Junit, mocha, and many other things like VS code, Node.js, docker, R studio, Jupiter notebooks, etc. Therefore, I may not have mastered Java completely, but I am definitely far more confident and competent in Java than any of the things I have learned in the last year. Its like Bruce Lee said,” Practice makes perfect. After a long time of practicing our work will become natural, skillful, swift, and steady.”

Where I disagree:

To put the practice of practicing over and over is far easier said than done. Over the last few months, I have been swamped. Unless I start polishing my skills when I am eating and using the restroom, I do not see a way I can manage a time schedule where I can successfully complete my workload and carve time out for practicing.

The problem with community practicing or group learning is that every has their own schedules. It is next to impossible to co-ordinate meet times and even if that some how works out, different people want to work on different set of skills.

The point where I disagree the most is that while working in this safe and personal environment, we have almost no help or oversight. If we are stuck on some problem, it will be difficult to find help; or worse we keep practicing the wrong way without anyone there to correct us and now we have wasted all this precious time.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.