For a lot of the projects I’ve worked on, we didn’t really do testing in the traditional way of actually writing tests. Each method or function we created, we would just use debugging in the actual code itself to figure out which parts of the method is working correctly, which fail safes are activating, and which errors are throwing. There didn’t seem like a whole reason for writing tests using JUnit or something similar when all code went to a dev environment first, and then put to production.

Just recently I started using JUnit a little bit just to find out how useful it could be when practicing coding certain problems. It definitely had some perks to it such as without compiling and building the entire project each time, I could just run the test to check if that certain code piece will function properly or not. But for me, that isn’t really enough to warrant using it all that much, if you have access to a dev environment (which you should), even though it isn’t the “proper” way to do things, I believe that writing debug in code instead of tests, is way more efficient.

If you look at it from a different perspective though, writing tests can also be worthwhile if you’re more into the automation part of developing. Since tests will be ran automatically when compiling your projects, you wouldn’t need to keep adding in more debug statements manually. This could increase efficiency more than what I previously mentioned, but you may not get as much information as needed from the test. If one of your methods isn’t working properly but the test keeps returning an exception or error and you don’t understand the cause of why it’s happening, the previous approach of writing debug statements will be more efficient and in turn, will help you understand where you went wrong.

All in all, I personally believe that both unit testing / testing in general, and writing debugs have their own places when writing software. Obviously I don’t know too much about software testing yet, but the more I learn, there is definitely potential that my opinion on it would change. As of now, writing debugs if there is an issue, or even if there isn’t, seems to help me a lot when understanding each part of what I’m writing in a deeper level and I look forward to learning more about testing to where it could also help me reach that point.

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

Software quality is something that I discuss with a lot of my friends who are also interested in software engineering/developing. One of the main points that all of us make sure to implement in our projects is always clean and readable code. When working on each others code-bases, it has become so much easier when our style’s have become more similar in terms of quality and cleanness, obviously not everyone will have the same style of coding, but people should definitely follow certain guidelines when working on a product.

For the start of all of my projects now, I immediately make the layout in a specific way so that anyone who has to view or navigate the project will know exactly where to look. All packages written will be descriptive enough of what they will contain, all classes will have proper name cases as well, if it creates something it will usually be a factory, if its an object class, its a wrapper, and for core functionality we use services. There have been plenty of times where I’ve had to work on someone else’s code-base and I was immediately lost, everything was all over the place, packages didn’t have good naming conventions, classes didn’t belong to their own packages, even the code itself was just nasty.

This leads me to the next part of software quality, which is usually the most important part, code quality. If you’re coding and you use some obscure or weird naming conventions, that should probably stop. Working in production usually means someone else will eventually have to take a look at your work, and if they can’t even figure out what you were doing, that means you did a terrible job. Everything needs to be readable, now obviously someone may not initially understand what the code does, but that may just be a difference in experience, if someone at your skill level reads your code, they should be able to identify what each variable, method, class, ETC… does for the product and how they cant test it to make sure it all works.

Since I started learning more about code quality, making any sort of project for production has become way more optimized for myself. I’m thankful that I had friends there to help me understand where I was going wrong in the first place with poorly structured code. Instead of having to take time remembering how a project should look, its not basically ingrained in my head how to do, which I hope other developers do as well.

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

I’m very unfamiliar with REST API’s but throughout most of our classes I’ve learned that they are very important especially in moving forward with development as a career. Since I was not very familiar with the topic I wanted to look up the basics of the API’s functionality, this is the site that gave me that information https://www.redhat.com/en/topics/api/what-is-a-rest-api. This site is basically documentation describing an API, REST API and REST all in their own individual categories.

The documentation covers the basics of REST such as the client-server architecture and communication, the representation of the requester and endpoints and the format the data is actually transferred through and the guidelines of the REST functionality as well. This post also covers the topic of what an API has to include to be considered a RESTful API, disregarding the aforementioned topics it covers the specifics of how the resources that are used by the client and modified on the server should react. Cacheable data that is transferred between both the client and server is also a topic brought up which I think is actually the most important since any data lost between actions would result in a broken / useless API.

Since I’m very uninformed on the topic of REST and I haven’t setup any personal development environments to work with such a thing, so I won’t be putting much of this newly gained knowledge to use as of this moment, but learning about it for future reference will definitely help me in the long run. I’ll most likely setup the development environments needed and study up more on the internals and all of the languages that work best for this type of development since understanding server and client architecture does not only represent working with REST. It also represents working with pretty much any application that multiple of your clients will use depending on what they ask for. This also gets more into the request part of the communication which I have never really looked into in depth, so being able to see how it functions will also help my understanding of most other server-client / client-server communication.

Honestly when we first discussed REST in our classes I still didn’t really understand the entire process of what exactly was happening. Reading through this post again though, definitely clarified some of the topics we went over and more, especially more into the back-end side of the API. Going forward I will continue to research more into REST, it seems very interesting to me and again, will be very helpful in understanding more about architecture in bigger programs.

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

Github has probably been the most useful tool I’ve ever used when collaborating with other team members or co-workers on projects. Even though I have used it for quite some time now there are many resources out there on the basics that still help me in figuring out the tool. One of many that I found was actually on the Github blog itself under the developer skills section which has a guide to a good amount of the basics themselves. Here is a link to just one of the sections relating to pull requests https://github.blog/developer-skills/github/beginners-guide-to-github-creating-a-pull-request/. For anyone new to using Github these guides seem incredibly useful, they include videos, pictures and recaps for everything discussed.

Just recently we went through Github in our CS-348 course and I did end up referring back to this source to help me in getting a refresher and understanding the content better. These guides go through a step by step process in explaining how each of these functions such as pull requests and merging works. Each subsection of explanations also includes pictures and videos themselves to help the reader better understand what they should be seeing when following along with the process. One of the most recent posts in the beginners section also included the setting up and securing of the users profile as seen here https://github.blog/developer-skills/github/beginners-guide-to-github-setting-up-and-securing-your-profile/. This is one of the most basic of the basics that pretty much everyone that uses the internet should know about, but you would be surprised at how many actually do not take this part seriously. Thankfully in this post the author describes the use of 2FA and how to set it up, 2FA is one of the easiest ways to secure your account much better than just using a password. At the end of each of these lessons / posts, the author includes a “Your next steps” section that allows the reader the use of a repository to test with if the lesson declared the use of a repository, or it will point you in the next direction you should take.

Overall this blog is probably one of the most effective ways for someone who is just learning Github to get used to a bunch of the basics. I only found this blog just recently but I much prefer it over a youtube video itself since it guides you through each step with a good amount of detail and it is very easy to go back any time I need to and re-read specific steps or details. Since not all of the basics have been published yet I will most likely keep my eye on this blog because reinforcing the basics if you are not sure about something is always helpful.

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

Most of my time developing software so far has been with the back-end, I had to learn a decent amount about specific algorithms and because of the languages I worked with especially Java, learning about the Garbage Collection is something that’s been on my mind for a while. Overall, my time spent actually researching the Garbage Collector for Java has been very limited, all I knew was the baselines of the algorithms and the base of the functionality. While searching for some posts and information about the GC I came across a video from Inside Java that went over the Z Garbage Collector. Here is the link to said video, https://inside.java/2023/04/23/levelup-zgc/?utm_source=blog.quastor.org&utm_medium=referral&utm_campaign=scaling-microservices-at-doordash. For a quick summary of what is discussed in the video, there are multiple garbage collector types for Java, most of which are usually used in different scenarios. A quick description is given of these garbage collectors and some of their strengths in terms of throughput, memory footprint, latency and scalability. After discussing these, we learn more about ZGC which first released in a jdk11 development build for testing. Comparatively, ZGC is far better than pretty much every other GC in terms of scalability, heap allocation, latency and just overall performance. ZGC especially in terms of pause times is so much better that most other GC have a pause time in the terms of milliseconds, while ZGC has pause times in terms of microseconds. With accessibility in mind, when doing performance tuning for ZGC it is way easier, after jdk 17, it auto-adjusts itself to handle the amount of threads it will need for garbage collection, aside from that there is only the max heap allocation that the user should worry about tuning as well. The reason I am mostly interested in these types of algorithms and garbage collection systems in general is because many of the projects I’ve developed rely on them to be as efficient as possible, removing the unused data and keeping memory usage down. After listening to this I will most certainly either start using ZGC for my applications or do more research on the topic because for the most part I never paid too much attention to what GC my applications were using, it didn’t matter to me since I was uninformed on what exactly they did. Now that I know more about how specific GC’s function I’m most certainly going to start and try to apply ZGC to most of my projects as it seems it will be the most efficient for me.

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

I recently had a talk with one of my friends about certain ways that software should be constructed. One of the main points of discussion was the structure of classes in Object Oriented Programming, we also spoke about storage systems such as SQL and Flat File storage systems. I wanted to talk about this because it has actually had a huge impact on how I structure most of my projects made in java/C# now. For a while now the format of my code didn’t that visually appealing in the case of class structure and naming conventions. My naming conventions for the past few personal projects were very vague and once my friend gave me feedback on the code, it made me realize that when I re-read the code it came off as confusing, even though it was my project. Every project I’ve made so far after this discussion has come out to be exceptionally clean from my view point, the naming conventions are specific to their use case, the structure for classes interacting with each other is also very efficient now. I plan on continuing to use this methodology for more projects if it can fit into the scope of the project. The reason we discussed storage systems is because for a good amount of projects I’ve done terrible storage management, it was inefficient and quite ugly overall. With some projects needing a lot of data to be handled without anything being lost I would sometimes use YML, overall it is very easy to use but it was slower than other options such as JSON. Once I was shown how to implement JSON instead of YML I noticed significant changes in performance and the along with that process the code became much more readable. In regards to flat file storage, it seems to be very useful for smaller scale projects which is mostly what I work on, but in terms of larger data sets I was shown how to easily use SQL and a little bit of Prometheus to format the project even better. Since configuring and setting up flat files in a project takes a decent amount of code, setting up the database itself was way better. Using tables to grab information instead of having to manually create getters for each entry and key in a flat file was a very good quality of life update that was implemented into most of my other projects that had larger data. All I know now is that for any future projects depending on the data sets, I will be using JSON and SQL as their performance is a significant upgrade.

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