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.

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.

Testing is an essential tool when it comes to software development. This week I listened to the podcast “Code Newbie Podcast”. In the episode “How to make sense of the testing landscape”, they talk about the importance of testing, and why people test, what kind of testing is done. They bring in Sergei Egor who is the CEO of AtomicJar. His company works with Testcontainers a java library that supports JUnit testing. The reasoning for looking into this episode, in particular, is so I could get more familiar with how testing works and its intricacies. The experience with testing my programs is very minuscule, and so having a veteran QA developer explain the little details of testing is just what I need personally.

Sergei goes on and explains that when discussing software, new features are being implemented almost all the time and so in order to make sure that those features work as intended, testing must be done. When working on a program, it’s fair to assume that the program must meet a certain amount of requirements and so testing ensures that all those requirements are met. The whole point of Sergei’s company is to optimize testing for software companies that don’t want to create miscellaneous code just to test a certain feature or task. The question that Sergei brings up is why can’t it be done through the backend of the program? And so Sergei’s company basically specializes in these software developing phenomena.

He goes on to explain different types of testing such as automated testing, performance testing, and the most popular type of testing which is unit testing. Unit testing is basically low-level and it will tests individual methods and functions. I’ve worked with unit testing in my previous computer science courses so I am most familiar with this type of testing. I would use unit testing in java for the most part. I had a project that involved me creating a banking account class, and basically, I had to create a JUnit class that would test all my methods such as my “getFirstName” method or my “getBalance”, so on and so forth. It would basically tell me if these methods succeed or not. When Sergei started talking about unit testing it felt very familiar with assignments I’ve worked on in the past.

When he started going into performance testing which is a test that evaluates the speed and reliability of an application, it made sense on paper but with my little experience, I began to struggle with how one may go about doing something like that. With the implementation load test as Sergei mentions, load tests are used to work the application to its full potential and record its response times and request counts as he goes on to explain. Something else that I found interesting while listening to Sergei is the question of why can the developers test the code so that the company doesn’t have to hire a crew of QA engineers. In Sergei’s words, he explains that many developers don’t want to think of all possible inputs for a program they would rather have an algorithm such as property testing do it for them.

Property testing relies on properties and makes sure that a program abides by those properties. It would be interesting to see this type of testing work with my mobile application which word recorded finance information- it would typically crash when inserting a record of payments occasionally and so having an automated testing algorithm such as property testing could have helped me figure out why my program failed in some instances. Automated testing would serve me in testing my programs and their functionality, running multiple tests whenever it’s needed.

Link to “Code Newbies Podcast” S18:E4: https://open.spotify.com/episode/51gZ0yQATZQ8twsJzRb7YE?si=39e4585f9db143c0

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