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.

This week I learned about anti-patterns by reading “Anti Patterns” by Ilyana Smith. Smith explains “An Antipattern is a description of a “negative solution” and a corresponding “positive solution.” In other words, an Antipattern describes a common way of solving a problem that actually causes more harm than good, alongside an example of a better way to solve that problem”. Smith then gets into the details about each pattern and the problems they cause.

Smith tells us that there are seven deadly sins of software projects that are the root causes of problems. These “sins” are haste, apathy, narrow-mindedness, sloth, avarice (overcomplicating things), ignorance, and pride. There are 18 anti-patterns Smith talks about. These anti-patterns are analysis paralysis, architecture by implication, the blob, copy-paste programming, death by planning, design by committee, functional decomposition, functional decomposition, golden hammer, intellectual violence, lava flow, and poltergeist, reinvent the wheel, spaghetti code, stovepipe enterprise, Swiss army knife, vendor lock-in, and singleton.

As you can see, there are a lot of anti-patterns. I will not be able to describe all of them so I suggest reading the article yourself, but I will go through a few of them. Analysis paralysis is when a software team gets caught up in the design and planning phase and fails to start any development.  The blob is building a class that does most of the work and there are a few secondary classes that contain mostly data. Copy-paste programming is a problem because if there is a problem in the code you copied it will be everywhere you paste it. These are just a few of the many anti-patterns.

After reading about the seven deadly sins of software projects and the anti-patterns associated with them and how important they are. I also learned there are a lot of things I should avoid when working on a project. Some of these anti-patterns could be easy to get caught up in like analysis paralysis. Being too caught up in trying to get the perfect design is something I could see myself doing so keeping these patterns in mind is something I should do. I think Smith did a great job explaining these patterns in a way that is easy to understand but still gets the point across. I would recommend this post to any software developer looking to improve their skills. Even if only one of these patterns is a new concept, I am sure it would be worth the read.

Link: https://ilyana.dev/blog/2020-11-24-antipatterns/

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.

This week I read about frameworks by reading “What’s a framework? All about software frameworks” by Lucas Stahl and Sean Higgins. Sean and Lucas did a great explaining what a framework is by making it easy to understand and giving many examples.

A framework is like a template that can be used to build your code on top of. Frameworks are premade code that take care of some aspects of the program. They are also reusable functions that make programming easier. Most programming languages have at least one framework that use them. The content of a framework can be very different, and it depends on the needs of the programmer for which one they should use. Many frameworks are open source that are maintained by the community of programmers but there are some from large companies like Microsoft or Meta. Frameworks might sound like code libraries but there is a difference. A quote by David Fateh helps explain the difference. Fateh said, “A framework,” he says, “is like a construction blueprint: A template that defines a basic structure for your build. A code library is more like a carpenter’s tool belt: It has tools designed to perform specific tasks”.  Lucas and Sean go on to explain the benefits of using a framework. Some of the benefits are being able to focus on one area of development, easier testing, development speed, reliability, documentation, and better security. There are many benefits to using frameworks but there are a few challenges as well. These challenges are structural limitations because frame works can’t do everything, having to learn the framework and the language it is based on, as well as having to pick from the many frameworks that are available today.

I learned a lot from this article, and I think frameworks could be a useful tool to use when programming. The diverse selection available seems like they could help in many situations. Being able to use a framework to cover a part of a program like the backend for example so another part like the front end can be focused on sounds interesting. Being able to focus on your area of expertise is a major benefit of frameworks. Although there are some limitations of frameworks the benefits seem to outweigh the cons. After reading this article I am now curious about all these frameworks and how I could use them to better my development skills. In the future I suspect that frameworks will be a common use for me.

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.

The topic I wanted to cover this week is GRASP. GRASP stands for General Responsibility Assignment Software Patterns. I read a blog post by Kamil Grzybek called “GRASP – General Responsibility Assignment Software Patterns Explained”. He does mention his post is inspired and based on Craig Larman’s book “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development”.

Grzybek explains GRASP is a lesser-known set of rules that can be used in object-oriented programming and there are 9 patterns to follow within GRASP. The nine patterns are the following.

1. Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Indirection
7. Polymorphism
8. Pure Fabrication
9. Protected Variations

Grzybek goes through each pattern, explaining them, and gives some code from Larman’s book to help give the reader a better understanding of the uses of the principles.  The information expert is to assign the responsibility to the class that has the information needed to fulfill it. The creator pattern decides which class should create an object. A class needs to have at least one of the following responsibilities to be a creator, contain or compositely aggregates of the object, records the object, closely uses the object, or initializes data for the object. The controller pattern is to assign the responsibility of controlling a system operation to an object that represents the overall system or use case scenario. Low coupling is a pattern where responsibilities are assigned with the idea of reducing the impact of change by lowering coupling. The high cohesion pattern is used to keep objects focused and easy to use and understand by making sure all responsibilities of an element are related. Indirection is used to avoid coupling by making an intermediate object between two components. Polymorphism is how alternative types of classes are handled by using polymorphi operations. Pure fabrication is making a new class when it is hard to figure out where responsibility should be placed. The last pattern-protected variations is to create stable interfaces around points of variation or instability.

I chose this topic because I thought learning more patterns that could improve my code would be beneficial to me. SOLID and GRASP are the first two sets of rules I have learned about but there are plenty more that Grzybek mentions at the end of his post so perhaps one day I will learn about those too.  I did find GRASP to be a bit more confusing than SOLID to understand but I am glad I had a chance to read about it. The main conclusion I took away from this post is the management of responsibilities in software is crucial to creating a high-quality architecture and code that can easily be changed. Grzybek ends his post with the words “the only thing that is certain is change. So be prepared”, which really emphasizes his point that software must be flexible. I will have to keep this in mind when developing code in the future.

Link: http://www.kamilgrzybek.com/design/grasp-explained/

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.

This week I read a blog post titled “SOLID Principles every Developer Should Know” by Chidume Nnamdi. Chidume taught me the important things I should know about SOLID and gave good examples to help make it more clear. SOLID stands for Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

The Single Responsibility Principle is a class should only have one job. This is because if a change is made it can affect more than just the one class that was meant to be altered. The Open-Closed Principle is software entities such as classes, modules, and functions should be open for extension, not modification. This makes sense especially with dealing with larger programs. If something new has to be added to a function it makes more sense to extend it than to edit the function. In larger programs, the function might need to be edited a lot which could fill it with if statements which can get messy. The Liskov Substitution Principle is that a sub-class must be substitutable for its super-class. This basically means if a subclass is called instead of a parent class the code still should still work properly. The Interface Segregation Principle is “Make fine-grained interfaces that are client specific”. This is done so that clients are not being given interfaces that contain parts they do not use. Finally, there is the Dependency Inversion Principle. This principle is that dependency should be on abstraction, not concretions. This basically means abstractions should not depend on details and that details should depend upon abstractions.

I selected this blog because it seemed like it was easy enough to understand and had code examples to demonstrate the principles in action. There was a lot of information to gather from this one blog post but it was well worth the read. Chidume does a good job explaining each principle and the pieces of code uses throughout the post helped clarify any confusion. I think following these principles will be a big help in the future when coding, especially larger programs that could easily become messy if I did not follow the SOLID rules. I think it will take some time and practice to be able to implement these rules in all my programs but it will be worth doing in the long run. I think that focusing on one rule at a time will be the easiest way to master these principles since it looks like it can be a lot at once if all of them are needed in a single program. 

Link: https://blog.bitsrc.io/solid-principles-every-developer-should-know-b3bfa96bb688

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.

Object Oriented Programming is a topic that I wanted to brush up on because it has been a long time since I have programmed with it or learned about it.

 I read a blog by Omar Elgar called “The Story of Object-Oriented Programming” which was a great help with relearning the terms and use of object-oriented programming. Omar goes over the major aspects of object-oriented programming which are objects, abstraction, encapsulation, inheritance, and polymorphism. Omar explains objects in programming are meant to represent real-world objects like a car, phone, etc. When Omar gets to abstraction, he sums it up by saying it is focusing on common properties and behaviors of objects and getting rid of what is not important. For encapsulation, Omar explains it is breaking down a program into small mini-programs in the form of classes as well as hiding content that is not necessary to expose. Inheritance is when we take the common properties we created in an abstract class and apply them to the class that is more specific. The last topic Omar covered was polymorphism which is when an object takes the shape of many different forms. Omar even gives some code at the end of his post to show the readers a real example of object-oriented programming being used which is a nice touch and helps to see.

I chose this blog post to read because I wanted to get a clearer understanding of object-oriented programming and how it worked. I have coded using object-oriented programming in the past, but I do not think I had completely understood it and how useful it can be until now. Omar did a great job going over all the important pieces of object-oriented programming and explained them in an easy to understand way.  After reading his blog I feel like I got exactly what I was looking for out of his work. I will be able to apply what I learned from Omar’s blog to my programming and be able to effectively explain object-oriented programming to someone else if I needed to. I have a feeling that having a strong understanding of how object-oriented programming works is going to be important to have not only for my university classes but my future career as a software developer. I would highly recommend this blog post to someone who needs a straightforward and easy to understand overview of object-oriented programming.

Link: https://medium.com/omarelgabrys-blog/the-story-of-object-oriented-programming-12d1901a1825

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.