Category Archives: Programming

Week 11

Deciding on a topic this week I decided to delve into Test Driven Development (TDD). I found an article with an engaging title “Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software” by Ferdinando Santacroce. This would be very useful for me and the whole class because it’s fresh in our minds and we will continue to work with this concept. Getting a firmer grasp on this topic will help me with future assignments and homework. It’s always great to get an insider view with experience inside the field connecting it to what we learn in class.

This article begins with the history of TDD giving credit to Kent Beck one of the first “extreme programmers”. At the time nobody had ever reversed the idea of testing starting with a test instead of the actual code. The purpose of writing a test before the code would help programmers put them in the perspective of the maker making it easier to create the software. This would make more tunnel-focused code with much more simplicity because of just focusing on the test. Plus the codes get rapid feedback because all the tests have been made. TDD has the fastest feedback loop only surpassed by pair programing. Currently, TDD is widespread inside the field and several teams utilize it day to day. It’s hard to adapt to this type of coding scheme but with time it is proven to be a key to success. Minor grievances may also come up because this type of process can be too rigid or the lack of tools.  

After reading this article getting a glimpse into the history of how this came to be. It didn’t specifically specify when it started but I assume it was around the 90s because it mentions how common it is now. Understanding the benefits of doing this test answers my question why would you decide to do your coding process in reverse? What we have been learning is that it will be conventional to have code and then write the test connected to the already processed code. The benefits of cutting down time because of the faster feedback times and leading to less complicated code, I now understand its purpose. That is a recurring theme with code the simpler the better because you are never working alone. Maybe it is a self-contained project but your future self may not understand your complex code and updates to the code should be easy to do not a headache. 

https://semaphoreci.com/blog/test-driven-development

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

A Look at Test-Driven Development & Benefits

Since just before Spring Break, in CS443 – Software Quality Assurance and Testing we have transitioned on from boundary/equivalence class analysis and onto Test-Driven Development as a strategy as well as implementation. For me, this is a huge relief and joy to get back to working on actual code rather than theoretical comp. sci. work, though it also helped me recognize the importance of non-coding exercises. 

I’ve also been really enjoying TDD as I find it aligns with my general coding habits and builds off them to help me identify new coding practices and strategies for addressing challenges. So I decided to look at some blog posts discussing it and how it’s impacted software projects versus other methods used. Test Driven Development Is the Best Thing to Happen to Software Design instantly jumped out to me.

The post discusses the significant influence of Test Driven Development (TDD) on software design. It explains TDD as an iterative approach shaping an idea into implementation through a cyclical process of ‘fail-pass-refactor’. The author illustrates the two approaches to writing code and tests: one driven by code and the other driven by tests, emphasizing the benefits of TDD in terms of mindset and code quality.

This post also considers TDD in real-world scenarios, highlighting its capacity to provide fast strategic approaches to software challenges that may seem to have no place to start (by creating tests). It addresses challenges in testing and offers solutions such as spying or mocking, managing variable test data, avoiding bloated setup, and preventing “Mocking Hell.”

Additionally, the post discusses the tendency to add unnecessary features in code and how TDD, by its nature, prevents such occurrences, thus aligning with the principle of “You Ain’t Gonna Need it” (YAGNI). This is definitely a fault that I fall victim to at times as I try to plan ahead too far in a project and add unnecessary code so I appreciate strategies to address it. Finally, it suggests that TDD not only aids in requirements meeting implementation but also serves as a technique for gathering feedback about software design, thereby advocating for Test Driven Design (TDD).

My typical strategy for developing code begins with creating a skeleton of basic components I expect to be easy to implement and then fill out the boundaries and remainders by developing minor unit tests (like print lines) to make sure it is working as intended. I sometimes do them at the same time, but I have been doing TDD sometimes without knowing it and am now better prepared to hone in on its benefits.

Source:

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.   

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking. 

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

View at Medium.com
https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

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

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Software Engineer vs Game Developer – Which one is for you?

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Suggested Standards for (basic) REST API Calls

In the past few weeks, we’ve finished the CS-343 semester focusing on designing/implementing REST API calls and interacting with back- and front-ends. During one of our classes, I recall a discussion about the fact that there are no unified across-industry “best practices” for writing API’s. Specific API structures and rules are common within teams but can vary from organization to organization, however there are some general habits and strategies. So I decided to do some searching and focused on a blog post on the website for Swagger, the REST API view/interaction software we’ve been using in class: Best Practices in API Design.

The post discusses some general best practices on creating consistent, well-designed API’s by focusing on three key characteristics: 

  1. Being easy to read, understand and work with
  2. Being hard to misuse, and in turn more intuitive for users
  3. Completeness and Conciseness – something which the post acknowledges frequently happens over time as developers build on top of existing APIs

Alongside some other basics on CRUD operations and how they correlate to standard REST API calls (get, post etc.), the post also dives into practices for writing effective call response messages. The codes for responses should follow the HTTP standards, where client-side errors return 400-level (4xx) codes versus server-side errors return 500-level and successful calls return 200-level. 

Arguably most important is providing thorough and clear explanations in response messages. For error responses, this entails providing detailed messages describing the error that occurred and suggestions/tips to address and debug it. As a part of this, it’s worth considering putting an example of a successful call to show proper syntax and passed parameters – handholding users will pay off with smoother API interactions long term. To reinforce this, the blog post recommends providing examples for all possible GET responses to demonstrate successful data access calls.

While specific implementations will vary by project/system, these are some good strategies and habits to keep in mind. The importance of providing examples for each individual GET response really sticks out and hits home for me. I can imagine with more complex systems and calls that may contain various request, query or other parameters it could quickly become confusing for users to navigate and access information they need. It seems worthwhile to also provide an example of a successful call in the error response for some specific situations, such as an Error 400 – Malformed Requested → providing an example successful request. 

Below, you’ll also find a link to a “glossary” of REST API parameters with explanations on their purpose and uses – a resource I also recently came across and have been finding valuable. If you have any other suggested “best practices” to keep in mind when designing REST API calls, please let me know in a reply or E-Mail.

  1. Blog Post: https://swagger.io/resources/articles/best-practices-in-api-design/
  2. Parameter Glossary: https://rapidapi.com/blog/api-glossary/parameters/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Welcome!

Hi, I’m Josh! I’m currently a 20 year old college student who’s studying Computer Science and this is the first blog I’ve ever had. I was never much into blogs, however I can see the benefits of consistently updating a log of your progress, thoughts, or ideas. Whether people read it or not, it’s a great way to express yourself!

With this blog, I hope to track my learning, personal projects, and the ever evolving world of technology we live in today. It’s easy to get lost in all the news and different technologies, so this might be my way of navigating through the ocean of programming/tech and keeping up.

That’s all I have for now. Have a great day!

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

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

The Software Craftsman: Chapters 5 & 6

Cahpter 5 resembled Chapter 2 from Robert C. Martin’s book The Clean Coder which has many of the same themes as this book. This chapter mostly covers the fact that as a professional you occasionally need to say no. If you don’t say no when you should say no, things can get ugly quick. I won’t talk too much on the reasons why here because I talked about it in more detail here.

I do want to talk briefly about one thing that was said in this chapter. With good managers, there should never be a “us and them” attitude. This could never be more true and I recently experienced the downside to an “us and them” attitude. I was on a job with the the VP of Stack Testing in Bridgeport, CT. We were working as contractors for a fairly large power generation company, we’ll call them “Big Guys”. So Big Guys have so many power plants that instead of contracting companies like us to do their stack testing, they have an entire team of internal stack testers. However, an issue came up where Bug Guys’ stack testing team didn’t have some special analyzers that my company has. This equipment is very expensive and very complicated to use. So we arrived on site and immediately the upper management of Big Guys made us feel threatened. The upper management made multiple comments about how if we screwed up even the slightest bit that they were going to throw us off site and hire a different contractor. That was the first sign this was going to be a rough few days. Anyways, we ended up meeting Big Guys stack testing team, we’ll call them “Little guys”. All of the stack testers from Little guys were incredibly nice and welcoming to us. They were excited to have us on site and really excited to see our equipment in action.

After a 16 hour day of testing along side Little guys, we started seeing some trends. Big Guys management kept referring to the testing that was happening as “Your tests”(Directed towards Little Guys), like somehow Little Guys are requiring them to test when the reality it that the State of Connecticut was the one requiring THEM (Notice the beggining of the Us and Them mentality). Then we noticed that Big Guys were not giving Little guys any information until the very last second. Each time they did this the sent Little guys into a frenzy getting ready for the next test. Same things like this kept happening throughout the day.

We arrive on site the next day to find out that after the previous day, Little guys were upset and disgruntled about the previous days happenings. They began venting to myself and my boss. The “Us and them” mentality become so apparent when they started go against what Big guys were telling them to do. Towards the end of the second day, Big guys told little guys on their last hour of tests to pause their tests. Big guys eventually told us why they paused the test and the reason was completely strange. They had us pause for reason that were 100% unrelated to what we were doing at that moment. Little guys made a unilateral decision to continue testing so they could leave before 7 pm. Obviously Big guys were furious when they found out and there was a yelling match (Thankfully neither my boss nor I were present for) between Big guys and Little guys. The moral of the story is if they had not had this us vs. them mentality I am almost positive the days would have been smoother and we there definitely would have been less contention.

 

Chapter 6 talks about Craftsmen as gardeners. I really appreciate this visual. There certainly is a difference between someone who plants and someone who gardens. Someone who plants prepares their base, digs their holes and plants their plants and then moves on. If you do this as a gardener then you will quickly find your plants getting choked out by weeds or overgrowing other plants. This is not okay. One of the most interesting points made was the mindset of developers thinking the didn’t have enough time. I never realized it, but I have done this. Multiple times. Working on small projects I could have saved my self countless hours if I had simply taken the time to create unit tests. I see that now. I know that now. But I still don’t always do it. Why? “CAUSE I THERE’S NO TIME FOR THAT!!”. Really? Really, Tyler? Don’t you remember last time you said that? You spent hours debugging a simple logical error that could have been found in seconds using unit tests. ….Yeah, I still skipped unit testing to push features “faster”. This is something I am trying to break for sure and this chapter was a good reminder that it’s a time saver for everyone if I simply write unit tests and take the time.

Guess what, Tyler. There. Is. Time. Write Unit Tests!

I have the written on a sticky note on my monitor at home.

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