Hello again and welcome back to this week’s update. Today, I want to discuss something very critical in software development but perhaps many find it quite intimidating (me included) – Software Technical Review. For any developer, whether they are a professional coder or just a beginner, getting familiar with this process will completely change the game. So, grab your coffee or another favorite brew, and let’s break STR down.

Firstly, what is it?

To describe it in simple terms, a Software Technical Review is a sort of code brainstorming. This procedure requires a team of developers – sometimes, other stakeholders, too, – to meet and look through the code and design of the project, as well as any other technical part. It is a kind of peer review of your code, where every team member, checks each other’s homework to make sure everything is on course before proceeding further.

Secondly, why is it important?

Well, STR helps identify bugs immediately, ensures software complies with quality requirements, and helps consultants stay up-to-date with a project’s aims. All in all, it’s like double-checking an essay before sending it: it would be quite irritating to receive a failing grade for a paper due to small mistakes that could have been rectified. Imagine the irritation when even small details can have a severe aftermath.

What actually happens in the review?

The team analyzes the code to detect blunders, potential security risks, and quality as a whole.
They examine the design document to see if the planned architecture makes sense, and if it is achievable.
The team also looks at the performance of the development and its ability to satisfy the requirements of the proposed user.
The members always come up with their ideas of what to upgrade or alter.
Who is involved, and not just developers?

Finally, here is the STR’s cast:

Project managers, who ensure the project is on the right path to its goals and timeline.
Quality assurance engineers are responsible for the quality and ensuring that no rough edges of under-functionality come out.
Other developers may see an error that was made in the code-reviewing phase by the coder.

Some review suggestions?

You should know what you have done without stammering, have an open mind to revision, know it is for everyone’s best, and try to avoid subjective opinions – stick to points on making your code better, not yourself worse.

As they say, two minds are better than one so try to take advantage of the other minds worrying about the same project as you in order to better yourself and your programming skills.

Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Hello, and welcome back to your least favorite corner of the internet. I want to talk about something that I found to be pretty cool, Programming Katas. To all my OG Karate Kid fans out there, programing katas are basically the “Wax-on, wax-off”‘s of the programing field.

Translating this to our world, programming katas are small, manageable coding exercises that challenge you to solve problems repeatedly, often in different ways. Each kata is designed to be tackled in one coding session, making them the perfect daily workout for your brain.

Just like playing scales can make you a better musician, regularly working through katas can make you a sharper coder. They force you to wrestle with new problems, reminding you of syntax you might have forgotten or introducing you to new methods and functions. Katas aren’t just about finding any solution; they’re about finding the best solution and then making it better. This iterative process of refining your code teaches you about the art of clean, efficient programming. It’s all about writing code that not only works but works beautifully. As you progress through different katas, you’ll find yourself picking up new programming concepts and deepening your understanding of the languages you use. Many katas come from community platforms like CodeWars, HackerRank, or LeetCode, where coders from around the world share their solutions and insights. Imagine solving a puzzle and then seeing a dozen different ways others have solved it. Boom, you’ve just struck learning gold.

Starting with programming katas is as easy as signing up for a platform that hosts them. Pick one that suits your taste and start with challenges that match your skill level. Personally I like the katas from CodeWars, the community problems and challenges push me forward to try and be better than what I was yesterday, or I just solve some problems just for bragging rights with my fellow programmer friends. Sites like CodeKata.com have good starting exercises for people who just got in Kata’s so you might find that to be your particular cup of tea. Either way if you just find an exercise you fancy and work on that, it’s enough.
Don’t be afraid to struggle—that’s part of the learning process.

Incorporating katas into your daily or weekly routine can transform the way you code. They keep your skills fresh, introduce you to new ideas, and deepen your problem-solving abilities. Plus, they’re a lot of fun! Whether you’re a newbie looking to get better or an experienced dev wanting to stay on top of your game, give katas a try. You might just find yourself hooked, coding better, faster, and more creatively than ever before. Just remember that while Kata’s are fun and have several profits, do not fall behind on your school work or personal portfolio projects. The reason why you’re even grinding Katas in the first place is to become a better programmer for your main line of work.

Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Here’s the thing, having the right workstation isn’t just about keeping up with the cool kids anymore, it’s about finding the right blend of power, ergonomics, and style to run through coding marathons, debug sessions, and endless project nights. Let me guide you through what, in my opinion, is the best (somewhat cheap?) setup you could have as a CS student.

First off, the centerpiece of your digital dominion: the Laptop. You know that for CS students the laptop is not just some tool you use, it’s your best friend, your main weapon, your Excalibur and as such It needs to be powerful enough to compile the code faster than you can say “runtime error”. Try to find a laptop that has:

• Powerful CPU: Intel Core i7 or i9, or AMD Ryzen 7 or 9. If you’re into Macs, Apple’s Silicon chips have proven their efficiency these past years so if you can afford it, go for it.
• Plenty of RAM: 16GB should be your starting point. If you’re into machine learning or running multiple Virtual Machines, 32GB should be your sweet spot.
• SSD Storage: Waiting for your IDE to load is so, 2010’s. Most laptops now come with 256GB SSD, if you juggle multiple projects you can upgrade to 1TB.
• Graphics Card: Look into a graphics card that is affordable but also new, It will be useful not only for GPU programming and A.I. work but also for winding down by running some of your favorite AAA studio games.

Some people might be content with only a laptop as their workstation and I can’t say they are wrong as some of you living in dorms might not have the space for your workstation, but trust me when I say that setting up peripherals is a game changer.

• Hi-Res Monitors: A single 27-inch, 4K monitor can drastically change your coding experience by reducing eye strain and improving readability. It works great for having your code on one screen and your reference material on your laptop. I’m running a 34-inch ultra-wide + 15.6-inch laptop on the side. Maximum real estate.
• Mechanical Keyboard: Once you go clack, you never go back. The tactile feedback is not only satisfying but also reduces typing fatigue. Plus, it makes you feel like a hacker from a 90s movie.
• Ergonomic Mouse: Your wrist will thank you if you get a mouse that is fit for your hand, try to find something that feels right for you.
• Quality Headphones with Noise Cancellation: For when you need to zone out and focus, or just vibe to some tunes while debugging.

Don’t be afraid to express yourselves whether it’s with LED lights, action figures, or posters of your favorite GitHub repos, make it yours. You’ll be spending a lot of time here, so make sure it’s a place that inspires you.

By now you should have what is essentially a perfect workstation. You have your laptop around campus, your station to hook it up and unleash its potential.

This is my personal working space,I hope it inspires you. Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

You know that heartbeat you skip when you press ‘run’ and pray everything works? Well, today I shall exhibit a certain method that has been around for some time that will have you save those skipped heartbeats for when your favorite TV show character nearly dies. Enter Test-Driven Development (TDD) – it’s kind of like having a buddy checking your work as you go, making sure you’re on track

Imagine you start cooking a new recipe you found. Would you start cooking without checking if you’ve got all the ingredients? You write a small test for a feature you’re about to whip up, see it fail (because it doesn’t exist yet), and then write just enough code to pass the test. It’s a cycle: write a test, code a bit, make it pass, and clean up your code without changing how it works. Rinse and repeat.

Yes, I’m not a telepath but I know what you are thinking right now, why even bother?

One benefit of TDD is that it nearly eradicates most of the bugs in your code, making you less likely to spend hours hunting down bugs. You’re checking your steps as you go, so you know exactly where things might have gone sideways.
Your code design is going to be more professional because when you write your tests first you can make your code more modular and easier to read, kind of like organizing your closet so that you can find your favorite shirt even in the dark.
Once you have a couple of tests, guess what? You can go update or refactor your code however you like, your tests will let you know if you broke something.
Apparently, the word online is that after getting used to it you’re actually going to code faster. The backtracking time to fix bugs adds a lot to your programming timer even if it doesn’t feel like it.

Okay, It’s not all Sunshine and Rainbows. I personally feel like Test-Driven Development feels like a drag at most times, especially for people who are not used to writing tests before you code, and from what I have experienced so far, writing good tests is an art form on its own. Still, once you start, you might just want to stick with it. The payoff in reducing headaches (I promise I’ll stop using this word in the future) and quality code will be worth it.

I really want to think of TDD as my coding companion, helping to keep my code clean and bug-free. It is somewhat of a mindset shift, more frontloaded work for sure but I feel like it will result in fewer late-night coding sessions and better-quality projects. Whether you are a solo developer or a team player, giving TDD a shot could be a game-changer. So try leading the way with tests next time you sit down to code and see how that goes.

Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Hello, It’s me, your favorite computer science student ready to once again complain about the career path I chose myself.

Today’s menu of minor headaches (I’ve got to stop using this) consists of Path Testing, which is the same as checking every corner of your room for monsters before going to bed to ensure your beauty sleep doesn’t get interrupted.

Imagine you’re playing a video game where you choose paths to reach the exit of a maze. Some paths are straightforward, others are mazes with obstacles. Path testing is the same principle but with your code. You need to check every route your code can take to catch bugs hidden off the beaten path.

Think of your code as a map, with each part representing a stop or a crossroad. The goal is to explore all the stops and paths without an endless journey. We use a Control Flow Graph as a map for your code to ensure that we are not missing any hidden detours.

To implement Path Testing you only need to follow a few key steps:

1. Create the Control Flow Graphs: This graph maps out all the possible routes through the program.
2. Calculate Cyclomatic Complexity: This metric is the guide for the number of test cases needed for adequate coverage.
3. Identify Independent Paths: Determine the set of paths that cover all the edges and nodes in the graph.
4. Design Test Cases: Create test cases that will traverse each identified path.

That’s pretty much it.

Now you may say “But Ano why even bother with Path testing?”. Well, Path Testing is your code’s ultimate test drive. It uncovers sneaky bugs that hide in specific conditions and gives you a deep understanding of your code, making it easier to add features without issues.

And yet there is a catch. While Path Testing may be great, it can also be tricky for complex apps. Trying to test every path can feel like planning a road trip to Mars. The key is to smartly select which paths to test, covering as much ground as possible without getting lost in the details.

Just like our previous entry on software testing, Path Testing is another secret weapon for robust code. It’s meant to bring you peace of mind, ensuring your app or program performs without any flaws. So, before you deliver or push your code, be sure to take it on this essential road trip that guarantees your code does what it is supposed to.

Till next time,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

As we start the Spring 24 Semester we turn a new page and focus on new courses and topics which will be closely followed during the upcoming months.

 Before I go deeper into what we are focusing on this semester, let me remind everyone of you who continues to read my blog entries of who I am.

My Name is Anairdo Duri or Ano if it’s easier for any of you. I am a Junior Computer Science student at Worcester State University hoping to graduate next year.
Now that we got that out of the way let’s continue.

 The main focus of my blog entries this semester will be focusing on Software Quality Assurance & Testing. I will be looking into various topics related to Software Testing which will include Test cases and evaluation, levels of testing, unit testing, system testing, test automation, code reviews, and so on.

 Software Quality Assurance (SQA) and testing are crucial components of the software development life cycle, aimed at ensuring the delivery of high-quality software products. SQA is a systematic and comprehensive process that ensures the development and maintenance of software meet established quality standards and customer requirements.

  Testing is the process of executing a software application or system with the intent of finding defects and ensuring that it behaves as expected. Its main objectives are to identify defects and ensure they are fixed before software release, to verify that the software meets specified requirements, and to ensure the software functions correctly in different scenarios.

 My goal this semester is to obtain a greater understanding of these two important concepts in the large spectrum of computer science concepts as I already know that it will be useful in my desired career as a computer scientist.

Let’s hope that this semester is as successful as the past ones have been and as always,

Ano out.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

In the everyday life of a computer science enthusiast we are caught up in complex stuff like algorithms and coding languages, but there is a crucial aspect that we cannot overlook, writing clean code. In this blog post, I will show you some coding principles that make your code look good and make life easier for you and whoever reads your code.

1. Clean Code is not just a fancy choice, it’s a must. Robert C. Martin says, “Clean code is simple and direct. It reads like well-written prose.” This basically means writing a clean code isn’t just for others, it’s a great help to you as well.
2. Naming things by what they are supposed to do makes total sense. Dont aim for cryptic names, go for clarity. Think of good names as a map, it tells you what is what without a guide.

   Python Example:
   <<
   #Confusing variable name
   x = 5
   #Clear variable name
   total_items = 5
   >>

3. Consistent formatting is your code’s best friend. Follow a set of indenting and formatting rules and stick by it till the end. Most IDE’s or coding tools make your code look neat automatically but putting some effort yourself goes a long way.

   Java example:
   <<
   // Messy formatting
   public void exampleMethod(){
   if(condition){
   statement();
   }
   }
   // Clean formatting
   public void exampleMethod() {
   if (condition) {
   statement();
   }
   >>

4. Break things down and chop your code into smaller bits (this part exists in all of my blog posts by now). Each bit needs to have one main job or function. This makes your code easier to understand and saves you from later headaches.
5. A little comment goes a long way. Try to think of comments as salt, a pinch is just right, and a lot ruins the dish (and gives you high blood pressure). Use your comments for tricky parts and remember to keep them updated.
6. A lot of us are familiar with Legos which makes Test-Driven Development somewhat easier to grasp. Before building a great pyramid, try to plan it out with smaller bricks (tests). Not only does it ensure your code works but it helps in keeping things organized.

To conclude: Diving deeper into the coding world the smartest move you can make is writing clean code. Not only to impress the others but to make your life smoother. To put this in other words my generation understands writing clean code is the “ultimate flex”. Until next time keep it clean.

Ano out.

References: 
“The Clean Code Blog

From the blog CS@Worcester – Anairdo&#039;s WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

As final’s week approaches I find myself coding through the night more and more accompanied by my two best friends, my IDE, and the lo-fi girl(if you know you know). Late-night coding sessions are practically a rite of passage in the computer science world as the thrill of solving problems and watching your code come to life is extremely rewarding. However, the toll it takes on your physical and mental health is also extremely undeniable. This semester I have had the privilege of sleeping most mornings as my classes and part-time jobs are in the afternoon or past that, so sleeping late at night has not bothered me as much as it would have if I had early-morning obligations. Even though I’m getting around 5-7 hours of sleep, the irregular sleep patterns and long hours in front of my computer bring challenges that are worthy of discussion.

1. Irregular Sleep Patterns:
   Late-night coding more than often leads to irregular sleep patterns which disrupt the circadian rhythm, this results in fatigue and creates difficulties in concentrating let alone long-term health issues.
2. Sedentary Lifestyle:
   Long periods of coding mean long periods of sitting. The sedentary lifestyle created as a result can contribute to health problems like obesity(my excuse for getting a beer belly at 20), back pain, and even cardiovascular issues. This can also decrease your stamina to the point that even going through 2 flights of stairs can cause you to have short breath.
3. Mental Burnout:
   When you keep pushing yourself too hard for extended periods of time the only thing you’re gonna end up with is having mental burnout. Have you ever gone to class and could not remember how to write a for loop? That’s exactly what mental burnout is. The lack of motivation, increased stress, and plunged creativity are just a couple of the symptoms that can throw all your hours of coding into the trash bin.

Even though these challenges might seem harsh at first, there are some practices you could follow that ease the strain on your body during this hard work.
Creating a consistent sleep routine will lead to better health. You can sleep even during “unconventional” hours, it just matters that it remains consistent and your body will thank you for the predictability.
Taking regular breaks can combat the negative effects of prolonged work sessions. The most popular practice is the 20-20-20 rule in which every 20 minutes you look at something 20 feet away for 20 seconds to reduce eye strain. Personally, I have never liked this rule as getting away from work every 20 minutes really disrupts my workflow and most of the time it distracts me from solving particular problems that I may have been working on, so I came up with my own method. Every 50 minutes, I give myself 20 minutes of break time dedicated to anything else besides sitting in front of the computer. Stand up, do some stretching, grab a bottle of water, grab a snack, open up a window, and just stare outside. If you’re at the 50-minute mark but don’t feel like disrupting your workflow? Continue working but when the time to take the breaks comes again give yourself 5 extra minutes for every 10 minutes you kept working.
Doing something physical during the break time is even better. You can do simple exercises that do not require much room or any equipment. My personal favorites:Toe touches, that thing you do where you pretend you’re a sea lion(I forget the name of the stretch), and push-ups.

In one of my previous blog entries “Scruming through the semester”, I mentioned that breaking the work into smaller more manageable tasks helps in productivity, that advice is valuable here again as this not only makes your work more achievable but it also prevents burnouts.

What’s more important is to know when to stop. Start recognizing the burnout signs and know when to step away. Good work comes from a healthy mind and more than often the best solution to a hard problem is some good quality sleep. It’s easy to prioritize code over your well-being in the fast-paced world of computer science. However, keeping your mental well-being and physical health is a crucial step to sustain success in this field. Incorporating good and healthy habits into your coding routines can ensure that your overnight sessions are productive and sustainable in the long run. As one of my good professors has said: “You can save your code and work on it later, you can’t save your health and load it when you get sick.”.

Ano out.

From the blog CS@Worcester – Anairdo&#039;s WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.