KISS

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

 

Source:

https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/

 

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

KISS

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

 

Source:

https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/

 

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

KISS

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.

 

Source:

https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/

 

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

Whats Next?

I have had this unhealthy assumption in my mind that CS is just preparing us to just sit at our desk all day and write code for hours upon hours(at least in the industry context). Although, in the cases where this may be true, for those that are in that position, there may be a good chance that they are doing what they enjoy. I don’t see this being the entire case for me. Knowing this, a couple questions and thoughts come to mind; in exploring different roles one can play in the tech industry, where may my own opportunities lie? Can I recognize what I am learning in relation to that, maybe even evaluate how/what I am learning to where I might see myself? Can I map out my career?

I think it is important to ask such questions while taking these CS courses. While asking such questions during the courses I can recognize where my strengths may lie and discover possible passions/interest. I am prone to overthinking(especially with complex ideas) and such practices allow me to step back a little. Going off previously stated questions, there is something about the front-end that is quite alluring to me. Which leads me to an article that I found titled “Exploring the front-end of project management”

Although it doesn’t talk about specific front-end development tools, (a topic in which I would like to look more into) and more so on what comprises the front-end and the role of management, it is a exploration into the front-end, or defined in the paper as the “earliest stages of a project”.  I think that the article is still relevant as we can recognize that the POGIL group work style of the class allows students to be able to work in groups, the prevalence of different roles is to almost simulate the professional setting in which on may work. This style teaches students to be able to work well with others and communicate very complex ideas. I personally find a lot of enjoyment in working in groups and struggling and learning together, specifically; exploring and playing with the different roles from manager to presenter, working through unexpected situations through analysis and modification, and sharing finding with the entire class. From my brief research, the front-end to me seems to be where I can explore not only different roles but explore even more broad experience from different aspects of the tech industry.

On a different note, I made an observation in my last post about the nature of the learning that is done in CS and how topics can connect. I described that connection of topics as niches. I wanted to make a correction and niches may not be the right word. Perhaps, layers, at least in the context of this class I could argue that front-end being a layer in software development is more suitable. If anyone gets what I am trying to say and can find a better way to word it, please let me know.

https://doi.org/10.1080/21573727.2013.775942

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

LimitsOfTheSagaPattern: UweFriedrichsen

CS@Worcester
 

CS-343
 

Week-15

Why I chose this post

This post intrigued me as it talked about microservices and since we had worked with the microservices that are makeup Thea’s Pantry it was a great opportunity to learn something new concerning microservices. Saga pattern was also a new concept that I had not heard or implemented before. Considering earlier posts that I had done with Friedrichsen I was sure that he would give good and relevant examples to understand the topic.

Summary of the post

Friedrichsen begins by introducing the concept, saga pattern. He describes it as, “if you have a transaction that spans multiple services and thier database, do not use distributed transaction. User the Saga pattern instead: Call the affected services in a row – tupically by using events for activity propagation.”

The author then goes to explain how the saga pattern might lead to limitation within a microservices systems due to technical errors. Despite the ability of the saga pattern to cover roll backs, Freidrichsen talks about how if a roll back fails it might lead to larger errors which cannot be solved. The main technique used to handle technical errors is to have a copy of the changes that were to be applied, go back to the last checkpoint by loading the last snapshot and then retrying application of the changes while avoiding the potential error that initially led to the technical error.

Saga’s pattern strength is in recovering from business error rather than technical errors. Friedrichsen states that recovering from technical error invovles a two layer approach where there is a lower layer which is hidden from the upper business layer. Also Friedrichsen cautions that if the saga pattern is used too often there might be an existing design smell within the system.

Reflection and Applicaition

As I have learnt about how important it is to consider the limitations and the advantages of using certain design patterns. In this case the strength of the saga pattern was in handling business errors but its downside was in handing technical errors. Also frequent application of a certain design might be a sign of an underlying problems which might require diagnosis. I also learnt of how the business and the technical layer can interact and work together and how to hide the functionality of the technical layer from the business layer.

I would apply the concepts that I have learnt from this post as I design systems which involve microservices. I will be careful to examine the pros and cons that different technologies might have before implementing them and relying on them to carry out roles within the entire system.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Blog Week 14 (Token)- Abstraction and Composition

View at Medium.com

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, https://medium.com/javascript-scene/abstraction-composition-cb2849d5bdd6.

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

Concurrency

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. 

Link: https://gowthamy.medium.com/concurrent-programming-introduction-1b6eac31aa66

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.

APIeXprience(AX),Concept Spill: UweFriedrichsen

CS@Worcester
 

CS-343
 

Week-15

##Why I chose this post
This post caught my attention as I was scrolling through Uwe Friedrichsen’s list of blogs. It had API in its subtitle and since we had covered RESTful API’s in class I though this would be a great opportunity to see his approach to API design. After scanning through the blog I saw the term concept spill which I had not heard before and I thought it would be interesting to learn something new about API through the lens of an experienced IT specialist.

##Summary of the post
The author begins by talking about how by taking technologies and fitting them into the entire system might work easily but we end up missing the important aspect of fully fullfilling the users needs. He introduces a concept AX which reffers to APIeXperience as to how the programmer will be able to work with an API design to fulfill the requirements of his users. Similar to UX in application design, a good AX might breed good results on the operational and functional side of a system or system software. He then introduces concept spill which is one of the factors that might reduce the AX of a programmer.

He defines concept spill as a situation where, “in order to use another service to solve your acutal problem, you first need to understand its internal concepts.” He gives a good example of how you would have to understand a city’s transport systems, such as zones, bus and train stops etc., when you want to move from one point to another in a new city. You are force to understand the city’s layout before you solve your initial problem of going to a particular place within the city, concept spill.

Concept spill pours over into the IT world in API design where a programmer is forced to learn how the creators of the API came up with the API’s stucture and inner workings on top of the issue that he is trying to solve. How do we solve the problem of concept spill? At the root of avoiding concept spill is to understand the user’s needs and design your API to cater for the user’s needs. An API designed without the user’s context/story in mind will lead to poor operations of the API thus futher complications. Understand common uses of the API and base your design on these uses.

##Reflection and Application
The blog post offered good advice on how to make API more user based which makes good design and acceptance by developers. Even as I look forward to working on my software capstone next semester, I think this will be great to put in mind as we work on improving Thea’s Pantry.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Thoughts on Front-End Development

I often find it hard to relate back to other courses and easily forget about what I have previously learned. Luckily, my memory is not as bad as I think it is and it eventually comes back to me, especially in the case where I have to come back to a skill/technique regularly. I find that with Computer Science the evolution of knowledge is one that is clear yet has a depth of knowledge that intertwines one course with the next.

On one hand, you can have a course that is so specific in a niche of CS that it may be hard to see its relevance in another CS course on the other hand you may have a course that is seemingly so broad that it is hard to pinpoint how it may carry over.

I think that with any specific area of interest, as one continues with their education, the degree to which prior knowledge is necessary and relevant to learning a new topic only increases the further you progress.

All this is to say that last semester I took a cloud computing course and I remember that course being broad in its application of cloud computing. I wanted to look into the use of cloud computing in the context of software design and architecture. Secondly, after only getting a taste of front-end development in this course I wanted more and I wanted to solidify my understanding of the back-end and front-end in an attempt to satisfy a goal of mine described in a previous blog post.

Overall I’m not seeing any major differences between implementing software through the cloud vs other options other than the vast benefits that cloud computing can offer. Benefits of cloud computing range from storage, server, database, software networking, intelligence, and analytics. The blog begins with describing what cloud computing is then goes into detail about what front-end and back-end cloud architecture is along with cloud based delivery.

I was then led to another blog about specifically front-end development as I was not satisfied with what the previous blog provided. This blog hooked me with its first line saying “Front-end developers need to design sites that are engaging enough to nudge the target audience toward a conversion.” I find this idea to be very interesting because it starts to dive into the purpose of front-end development.  In my next post I will discuss where I may see myself in the future and what role I might want to play in the tech industry. There is a point in the blog in which the duties of a front-end developer are laid out leading to an intrigue and wonder about whether this is a niche in CS where I may see myself, in front-end development I feel it might be a role in which I can use a variety of skills/techniques in order to develop myself.

https://www.clariontech.com/blog/cloud-computing-architecture-what-is-front-end-and-back-end

https://webflow.com/blog/front-end-development

From the blog CS WSU – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Resilience, the new paradigm of the 21st century: UweFriedrichsen

CS@Worcester
 

CS-343
 

Week-14

Why I chose this post

I chose this post because the author touches on an important topic, resilience, which is a term that I have heard before in relation to IT related fields but I have never really taken time to understand it or even know how it is applied. Again Uwe Friedrichsen gives relevant examples as he covers this topic. He gives examples both within the IT sphere and some examples outside IT making resilience as a concept easier to understand.

Summary of post

The author begins by defining resilience, “resilience means that a system can ideally withstand adverse external influences completely or at least recover from them quickly.” Adverse effects can range anywhere from external influences from illness, overload situation, a pandemic, extreme weather and so on.

Friedrichsen gives an example of how the COVID-19 pandemic affected German car manufacturers. Since they had found an efficent way of procuring car parts, they became dependetn on chip makers in Taiwan. And in a figure of speech he says that, “ they have put all their money on a single horse and expect that this horse will always be the first to cross the finish line. And their calculation already includes the prize money for the horse.” This show how reliant car manufacturers had become dependent on Taiwanesse chip makers. However, when COVID hit the supply chain was greatly affected.

The author then shows the delicate balance that exists between efficiency and resilience, he also shows that a highly efficient systems is also very highly rigid. A balance must exist by reducing the efficiency in order to maximize on th resilience of a system. In the post industrial world the author says that he has witnessed a lot of uncertainity and full control of varience has become hard. We should therefore as early as we could begin to embrace the fact that there might be adverse situations down the road

Reflections and application

The blog offers a lot of important advice for the age and time that we live in. Due to the inconsistent nature of systems and resources in the world we live in today it is foolish to be single minded, despite the security that you may enjoy for the brief period when disaster strikes it will be hard to recover.

In my personal life and even in my career, this will be an important principle to live by.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.