As we have been Progressing through the weeks and we work on the pogils as well as the homework I find myself slowly getting the hang of the work flow as well as utilizing VSCode, I for once understand what is going on in the classes and am eager to continue to learn as it finally is being pieced together in my head. the biggest part would probably have to be the feedback that I receive and probably mostly everyone else gets as well its not some random jargon about how something is wrong but it seems like a guiding hand to get you to the solution that you aren’t to far from. the biggest take away I have gotten as organizing the UML diagrams on the Homework really connected the dots on how these classes and models work together better than it ever has , I can understand paths a little better than I did before.

I only hope I continue to understand the work I continue to do, and im eager to see what work I can get done.

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

While looking through my blogs, I came across a familiar acronym that I used all the time when it comes to developing software and system. The acronym is called “YAGNI”, which stands for “You Ain’t Gonna Need It” according to the blog “Automation Principles – YAGNI/Premature Optimization, It’s the principle of extreme programming that states a programmer should not add functionality until deemed necessary. The blog takes about how many engineers will spend multiple hours trying to build the “right system” the first time. In some cases, trying to build a flawless system in the first go can be rather difficult to achieve. The problem is that programmers spend too much time worrying about efficiency in the wrong places and having that premature optimization can cause more harm than good. The blog goes over Big- O notation which explains that it does not care about constants but the long-term growth rate of functions. This is a good rule to consider because having to introduce something before a fraction of the code is even written can make a program a lot more difficult to support as explained, it would increase design considerations, the likelihood of race condition, and the ability to troubleshoot. Optimizing certain processes might not lead to any time savings or real optimization. In fact, it could do the exact opposite, a good example that the blog states are when using Python, constructing lambdas and list comprehensions over simple for loops. The blogger has mentioned that in his personal experience he would add non-functional requirements, such as authentication and logging, too early, adding features before needed. With that being said, I remember spending so much time on adding the ability to connect my bank to my finance application, that I didn’t have the time to code the application itself. The blogger talks about network automation which explains more about how networking is all about speed and not creating YAGNI isn’t really in the cards. They would go into detail about real-world examples when it comes to the network automation process, explaining issues about multithreading, in which he explains that overloading the TACACS server with too many requests at once is very problematic, or scaling wide too fast can cause processes to slow down and too much resource utilization, overall, it’s very inefficient. Configuration Generation takes too long and is very inefficient, and with all these in mind, the blogger isn’t trying to not consider tomorrow’s problems but is more in line with building things up as they go.

“Automation Principles – YAGNI / Premature Optimizations” :

https://blog.networktocode.com/post/Principle-YAGNI/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

These past few weeks, I’ve been getting myself refamiliarized with UML Diagrams. These diagrams have made a frequent appearance in my CS career. From my complete understanding, they are a great way of analyzing one’s code from the top down. At first, I thought it was just another hassle. Some of these UML Diagrams can get rather difficult to understand, and with all terminology and ways to draw out these charts, it can get pretty hectic to understand how the code works. I learned to take in the information given one at a time. In the blog “Types of UML Diagrams” by Lucid Content Team, it explains that when it comes to any formal code training, UML diagrams are essential but take some time to build and become really out of date fairly quickly, in an Agile environment. But they are very useful for quick visual documentation so that employees can give stockholders a quick overview of the system so developers don’t waste time in meetings.

UML stands for Unified Modeling Language, which is a way to visually represent the architecture, design, and implementation of complex software systems. It is supposed to keep track of the relationships and hierarchies within a software system. It’s hard enough to keep track of thousands of lines of code and so the UML diagram is supposed to keep track of all these components of the software. UML diagrams can be used with basically any programming language and so all software developers should be able to understand it. UML diagrams keep things productive and focused, and they are very helpful to engineering teams. This can include bringing in new team members or developers up to speed, source code navigation, and planning out new features before programming them, and it helps communications between a non-technical audience more easily- which means that most people will be able to understand the process regardless of programming experience.

There are many types of UML diagrams. The first is structural UML diagrams, which show how the system is structured, with classes, objects, packages, and the relationships between them. The component diagram is a more specialized version of the class diagram, which breaks a complex system down into smaller components and will visualized the relationship between the components. Deployment diagrams show how software is deployed on hardware components in a system. Composite structure diagrams are essentially blueprints for the internal structure of a classifier. Object diagrams show examples of data structures at a specific time. And package diagrams are used to show dependencies between different packages. Obviously, this doesn’t even cover half of the UML diagram spectrums since we didn’t even Behavioral UML diagrams which are used to visualize how the system behaves and interacts with itself and other systems.

I’ve come to realize that UML diagrams can be very useful, it’s important to read code from the source but that can be rather time-consuming sometimes. UML diagram is a lot easier to take in and can explain how the software works in just minutes. In my future projects, I want to be able to utilize UML diagrams so that I can better explain my own work to others. I feel it would have been very easy to explain my past projects to people if I was able to have one. The blog was quite interesting because it explained the many types of UML diagrams that exist and their practical uses.

Link to “Types Of UML Diagrams” by Lucid Content Team: https://www.lucidchart.com/blog/types-of-UML-diagrams

From the blog CS@Worcester – FindKelvin by Kelvin Nina 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.

The computer has gone a long way compared to now. Modern computers have several CPU cores or CPUs. We utilize these cores to create high-volume applications. This week I read a blog discussing concurrency in programming. This blog, “Concurrent Programming – Introduction” by Gowthamy Vaseekaran, defines concurrency as the ability to run several programs or several parts of a program in parallel. Vaseekaran then goes further by saying that programs that take longer to perform certain tasks can benefit from using concurrency and that tasks can be done in parallel or asynchronously. This will, for the most part, upgrade the performance of the program. Vaseekaran also goes on to say that computers didn’t have operating systems back in the day, so single programs were executed from start to end. These programs had access to all the resources of the machine. Nowadays, executing a single program at a time is seen as an inefficient use of expensive and a waste of computer resources.

 Several factors led to the development of operating systems that allowed multiple programs to run, such as resource utilization, the author explains that programs must wait for external operations, so using that time to let another program run was way more efficient. Fairness would allow multiple users and programs to have equal claims on a machine’s resources. It is fairer to let them share the computer rather than having one program run from start to end and then another. Also having convenience is very neat, so that several programs can coordinate to perform a single task. It’s interesting while reading this because currently I’m taking a class on algorithms, and so in this class, we will discuss how some programs will take longer than others. There is the worst solution to how a problem or program in this case should be run, and the best solution. Concurrency could fit into making programs run more efficiently.

 The author then goes on to discuss computer threads which are a facility to allow multiple activities within a single process, a series of executed statements, a nested sequence of method calls, etc. We use threads to help perform background or asynchronous processing. The thread takes advantage of multiprocessor systems, and it simplifies program logic when there are multiple independent entities. Java will utilize threads very often. Every Java program creates at least one thread.

Threads can also pose risks; the main problem is the shared variable/resource problem. Solutions for this problem include not sharing any variables, making variables immutable which is the process of making variables unchangeable to their value or state, and using a lock. A lock is a thread synchronization mechanism in java. Another problem includes race condition which is the most common concurrency correctness problem, which pays attention to compound actions, which is when two threads access a shared variable at the same time. Vaseekaran also goes on to explain deadlocking which is a condition where two or more threads are blocked forever, waiting for each other. Deadlocks are caused by inconsistent lock ordering and limitation of resource capacity when a thread is waiting for another lock.

It’s very interesting to see how important concurrency is when it comes to making or even running programs, it brings a whole new understanding of how modern programs work. It’s also interesting to hear about terms such as “deadlock” because it’s a refresher of what it means and what role it plays when talking about concurrency. Reading about how computers used to run programs gives me a new perspective on how these programs run within a system and seeing how solutions were created so that we can run programs more efficiently. When making software I want to come back to this, knowing that one of these days’ problems such as deadlocking or shared variables will happen to me and so using the solutions Vaseekaran has listed in the post they wrote will help me a ton.

Link to “Concurrent Programming – Introduction”: https://gowthamy.medium.com/concurrent-programming-introduction-1b6eac31aa66

From the blog CS@Worcester – FindKelvin by Kelvin Nina 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.

In my last post discussing testing and QA development, I went into depth about a project I was working on last year. I was developing an app that was supposed to track one’s financial history. It was the first project I had ever worked on that gave me free liberty to do whatever I wanted. I explained that it took a lot of my time and I ran into a lot of issues regarding the organization of the code, for the most part, I was most concerned about making something that worked rather than making something that worked effectively. Recently, I read a blog from Thesoftarch discussing how to write object-orientated code effectively.

The blog “Simple & Effective Way to Write Object Oriented Code” basically explains that most developers, like me, will only look to write code to reach functional requirements and not advocate for the technical quality of the code. The blog post explains that writing code to be functional can be acceptable during initial releases but can slowly turn complex if not managed correctly. So, it is important to maintain quality so that in the long term we can avoid struggling with maintaining the application. Different ways of writing effective, approachable code include making it simple to read, easy to test/verify, and having a low cost of change. The blogger goes by explaining the three basic steps of writing effective and well-designed code.

First, they go on to say that writing is easy but writing effective code is not easy, especially when you don’t have an approach. There are many design principles that developers go through in order to design good code. This includes SOLID, DRY, Design to Interface, and many more.

The second step is Unit Testing, as explained in my last blog post, it’s important to ensure that the code written works as intended. it’s best to write unit tests every time a method or class is created instead of writing the unit tests all at once.

The third and final step is to refactor. Refactoring is an activity to improve the quality of code without affecting its behavior. Making this a habit will help “maintain the code in the long run without adding much effort or risk.” As the blogger puts it, the coder should be able to identify “smells” in the code, refactor code to remove the smell and fix unit tests. Smells are certain structures that indicate violations of fundamental principles and negatively impact quality.

While reading this blog I’ve been able to keep note of what I need to do and look out for when it comes to developing a program. If I had read these steps last year, I think I would have had a better time developing my phone application. Reading this over I realized that there is a lot that goes into the development process and simply writing the code isn’t enough. It’s like baking a cake, everyone can follow the instructions to bake one but if key details are left out then it might not taste good, software development is the same way. It’s important that the code is designed in a way so that it can last. In my next project, I want to focus on refactoring for the most part. Code quality is very important and being able to make quality code will save me time and prevent any struggle.

Link to “Simple & Effective Way to Write Object Oriented Code”:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.