Author Archives: Seth Boudreau

Development Environments

For this blog, I decided to do some research about development environments. When looking for sources to reference, I came across the article: “Comparison of Development Environments” on Coder’s blog. This blog post goes from simple development environments to more complicated ones.

The article starts off by going into depth about what development environments are. Integrated development environments or IDEs are the center of where developers navigate and edit code. However, the IDE are just one of the components in the development environment. There are the build tools, package managers, system dependencies, and configurations. There are also many development environment architectures as well.

  • Pure local environments: used for single developers or small development teams since it is purely local. Low cost since everything is stored locally
  • Virtual Desktop Infrastructures: the development environment is on a separate remote virtual desktop. Allows better storage across bigger teams and saving in a separate place.
  • Dev Containers: The development environment is packaged into a container . Provides a way to precisely specify the development environment once so everyone can have the same versions and controls on launch every time. I know in class we were able to build our own dev containers and such to match java version and java compiler version.
  • Cloud Development Environment: dedicates, manages, and monitors dev environments.

This blog really helped me to better dive into the deeper areas of development environments. Often when it comes to where code is stored and not just writing it, I get lost and tend to get confused. Seeing the images the article used helped to show what does what and where things are held. Also, as with most things, there are pro and cons to the usages of these environments. An example being Pure local environments being used for single developers or small development teams since it is purely local. This is good because it is low cost but it is hard to work in big development teams since everything is stored locally.

I haven’t had much experience with using different environments and instead have mostly focus on coding itself, but knowing these aspects is crucial when working on projects and software. Knowing to use cloud development environments for big groups and setting up dev containers is very important in proper workflow and to make sure everyone in the team is on the same page. I hope to understand these things pushing forward into my career.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Rest API Design

One of the topics we have been looking at in class have been rest APIs. Since we were working with APIs for some time I wanted to dive deeper into what they are and what makes a good one. The blog that I saw seemed perfect for this : “Everything I know about good API design” on SeanGoedecke.com.

One of the major topics that the post touched upon was that a good API design should be familiar and flexible. This mean that for developers who make them, APIs are complex products where lots of effort is put into designing them and polishing them. However, for the people who use them, the API should be familiar so that they know how to use it without lots of documentation. Even reading this makes it seem complicated. I guess I haven’t yet broken into this world of API creation. Basically, it seems like to me it would be a mix of building a simple API design but also make it be as useful as possible. Keeping it simple is not always the best solution but also making things too complicated will make things hard for the team to use.

Another Key topic the article goes over is changing APIs without breaking userspace. Basically what this is saying is that once an API is released and public, making any small change could break everything. Instead the article suggests to use versioning. I know I have working with versioning in class and looking at the different types of changes based on version numbers. For example, we used version with three different numbers as such: 2.4.0 from left to right being more breaking changes to smaller patches. Versioning is a useful way of updating APIs while also maintaining backwards compatibility. Now I really take notice in versions of applications I use and understand what kind of change has been implemented.

These aspects really helped me understand what makes a good API design. Building an API is not only making it functional but also flexible for developers and users. Being able to design APIs in two completely different ways and finding a happy medium is the key to making a good one. Also, being able to and understand versioning and how to not completely destroy your system when making changes. Going forward i hope ill be able to keep these things in mind to make thing predictable while also making the functions complex and useful.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Refactoring Code

When looking for some ideas with what to write about for this blog post, I settled in on refactoring code. For starters I know what it is and why we do it, but I wanted to go more in depth by looking at other resources and what they have to say about it. One of the first sources I came across was a blog post called “How to create a culture of continuously refactoring code?” by Stas Wishnevetsky. This post from Medium revealed something that for some reasons wasn’t so obvious to me and this was that refactoring isn’t a one and done kind of thing. Instead, it is more of a routine and should be done as one to keep code maintained properly and to make sure it remains easy to use.

The first thing that really struck me when reading this article was talking about code like it is something physical and biological. This comparison was made to show how code can “decay” and “rot”. While the code itself doesn’t break down and fall apart with time, there are multiple reasons that make it seem like it does. These reasons include: coding abilities improving over time, business needs and scale fluctuating, and deliberate tech debt. The article then goes on to explain why we should refactor and the end goal of maintaining stability and creating improvement.

I guess I have never had the need to deal with refactoring my code since most the time I program one time assignments and never had the need to upkeep some kind of program. I have, however experience my abilities improving while creating a project and have had some parts be sloppy while later improvements are better done. I suppose I should have gone back and refactored those early parts but the bottom line is that I’ve never had the need to. I would also run into problems trying to make small changes which would be risky in my program. This is one of the many pains explained in the article I read and makes lots of sense.

I know going forward in my career refactoring will become very prominent in my work and understanding it more now makes me feel better about it. This also really shows the amount of effort that is put into big programs we use on a day to day basis. Starting the practice of constantly and consistently refactoring my code, even simple projects, will be super beneficial for me going forward.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

The Importance of Keeping Code Clean.

After reviewing its meaning and apply the practice in my class, I wanted to search for a good source on clean code principles and some more reasons why it is important. i came across and read an article from the Codacy blog called “What is Clean Code? A Guide to Principles and Best Practices.” This article really went into depth on what it means to have your code be clean and have it makes to not only you, but other people as well. The link to the original post is right here: https://blog.codacy.com/what-is-clean-code

One of the first things this blog states is “writing code is like giving a speech. If you use too many big words, you confuse your audience. Define every word, and you end up putting your audience to sleep.” This very starting statement is what drew me to this post. Thinking about it like this makes so much sense. I believe I am pretty decent at public speaking myself so relating code it really helps define clean code to me. This post contains nine different methods on how to do this such as following code-writing standards and refactoring continuously. The article also explains how clean code helps development teams: teamwork is way easier, debugging becomes more straightforward, and overall it helps prevent many mistakes.

In class we’ve gone over many concepts this post explains, such as DRY(don’ repeat yourself), using comments sparingly, and writing short, straight forward functions. The most backwards concept for me is the comments. In past classes many professors have told me to write lots of comments explaining what certain things do. Now I’m being told to try not to use any? It does make sense, focus on making your code readable so you don’t need any comments.

Going forward for myself, making code simply and understandable will be a main focus for me. Keeping things simple and understandable makes way more sense than making code I need comments in. Another big thing for me is eliminating repetition. Using functions and calls instead of writing the same code over and over again will one hundred percent make my computer science life way easier and save me tons of time as well. I’ve only just started writing code in teams so I’ve only ever written code for my professors or just for myself. I know that keeping this readable will prevent meetings with teammates and hours explaining what the code I’ve created does.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Behavioral Design Patterns

Design patterns provide many benefits when it comes to coding and software development. They are essentially blueprints to help guide and solve problems through the process of designing software. While there are three types of design patterns, the one I will be focusing on here is behavioral patterns. Behavioral design patterns mostly focus on the assignment of responsibilities between objects and help with communications between those objects.

There are many different types of behavioral design patterns. Some of these patterns include:

  • Chain pf Responsibility
  • Command
  • Interpreter
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

All of these of different uses along with different pros and cons. For example, command patterns turns request into stand-alone objects called a command. This pattern allows you to capture each component of a request allowing the undo and redo of operations. However, this may cause overcomplications of code because of the layer between senders and receivers. Design patterns are easily customizable to help you approach any problem and provide solutions to many problems you may be having within development.

We’ve begun to touch on design patterns within class using UML diagrams and showing different ways to solve problems. We used the example of a duck class and different types of ducks. More duck types were added that were unusual types of ducks that had different behavior types. We used a couple different methods to help make the program work including overriding, interfaces, and behavior types. Each of these solutions had different pros and cons depending on what the user wanted out of the program.

All-in-all, each different type of design pattern has their own uses and downfalls. When working with design patterns, understand what a client or users want out of a program is key to really determining what design pattern to actually use.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

CS Introduction

My name is Seth Boudreau and I am a computer science student attending Worcester State University. I am going into my fourth year now as a student here and I am mainly making this blog to go along with my studies. Most of the information that I will type here will be for my two courses this semester: CS-343 and CS-348 and topics will vary based on information within the two courses.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.