In this first apprenticeship pattern, it talks about how a person may have realized they have gaps in their skill set and walks us through ways we can resolve this issue. I decided to do this apprenticeship pattern as my first one because I feel like I relate to this topic. Throughout my undergraduate career, I bounced around from major to major mostly because I am an indecisive person, but also because I am a person who has very diverse interests. I wanted to learn and do everything despite how unrealistic that may all seem. I often took classes out of order so that they would all fit in my schedule. As a result, for some of my classes, I felt like I was always playing catch up because I did not take the previous class that the class was built off or was either taking that class concurrently or at a later date. Because I was taking the classes out of order, I was always trying to learn things that I already should have known before taking the class. This left gaps in my knowledge because I wasn’t always sure that I learned everything that I needed to learn for the class.

One of the topics that the author talks about in this apprenticeship pattern is that often times when a person identifies the fact that they have gaps in their knowledge they don’t know where to start. This was how I felt sometimes when I realized I had a gap in class. In the book, it talks about how everyone learns differently and how we just need to find a way that works best for ourselves. For others it may be going online and reading a lot of articles and working through problems. For me, when I get stuck, I find myself staying late after class or going to my professor’s office hours and working through problems step-by-step with others. One thing that I found really interesting about this section is the topic of finding a balance between trying to hone your skills to confront your ignorance and fulfilling the needs of the team. I found this topic to be interesting because it was something that I never really thought about before. It is important for a person to confront their ignorance and hone their skills because that will make them a better programmer, but it is also just as important that you are mindful of others that you work with because in whilst in the process of honing your skills, you may inadvertently drag your team down. This made me realize this is something I need to think more about and work on in the future.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

As a big fan of LaTeX, I really enjoyed learning and using PlantUML in class. For those of you who do not know what UML is, UML stands for the Unified Modeling Language which is a language that allows us to create models/diagrams. It is commonly used to create some sort of visual to convey information to an audience. In class, we used PlantUML to show the relationship between classes but there are still a lot of things you can do with the language that we did not have time to cover in class.

In this first blog post by Rachel Appel, she goes over most of what we covered in class at a slightly slower pace.

In addition to covering what was covered in class, in her blog post, Ms. Appel also shows another way of using PlantUML diagrams. She shows us how to create USE diagrams. USE diagrams allow us to describe the relationship between users (or actors in Ms. Appel’s USE diagram) and the software and its components. I find this especially useful when describing to others the principle of user privilege or even from a managerial standpoint describing to your employees what information or resources, they have access to.

In the previous blog post, it talked about what kinds of diagrams you can make using PlantUML, and in this blog post, it talks about some style choices you can make in your diagrams and informs you about some features in PlantUML to organize your diagram.

https://www.codit.eu/blog/plantuml-tips-and-tricks/?country_sel=be

The blog post talks about many different features you can find in PlantUML. It talks about how to change the direction of the arrows, changing the box shape, changing the arrow color, and even adding a legend at the end of the diagram. The next topic that the post talks about text alignment and adding a background to your diagram. The post also talks about a couple of other really cool features you can do in PlantUML so be sure to give the post a quick read!

I picked this topic to do this week because it was in fresh in my mind after talking about it with one of my professors. It is also a topic that I found really interesting when we covered it in class at the beginning of the semester and is something I always wanted to learn more about. In the past, whenever I had to create a model for another class I used LaTeX, Excel and/or MatLab to generate the diagram and sometimes I had to jump through so many hoops to get the diagram to look the way that I wanted to. With PlantUML, there are a lot of built-in features that I can choose from and use so I can see myself using this knowledge in another class.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Considering how far along we are now in the semester, I decided to revisit a much earlier topic, design patterns. For this week’s blog post, I am going to look at a post by Ravi Kiran, a research analyst at Edureka. In class, we covered what are design patterns and what are some examples of design patterns and in this blog post, Mr. Kiran starts off the same way by introducing the audience to what are design patterns and why we use them. Then he begins to talk about what are the four categories of design patterns which are creational, structural, behavioral, and JEE (Java EE-based). The blog then proceeds to list examples of design patterns, what categories the design pattern falls under, and explains a little bit about why that design pattern falls under that specific design pattern category. The blog post does not explain all of the examples but instead for the ones that it does explain, it explains it very well in the form of a UML diagram and snippets of Java code. In addition to all of the technical information, this blog post gives us, it also gives real-world examples where that design pattern can be applied.

I chose this topic because when we were learning about this topic in class and when we did a homework assignment, I found the topic to be very interesting. I really wished we had spent more time on this topic in class. It was only after reading this post that I realized in class and on the homework, most of the design patterns that we covered in class fall under the creational or structural categories. After learning about the Singleton pattern in class and working on it on the homework, I think conceptually I understood the topic, but after not working on it for some time and revisiting the topic, I think I understand it better now than I did back then. One of my regrets early on in the semester was not doing the Advanced Assignment working with the Factory design pattern. When I was reading about that design pattern for the assignment, I found it interesting and thought I understood the topic, but I did not do the assignment because I was not sure if I understood the topic well enough to do the assignment. After reading more about the topic and seeing the UML diagram, it validated my thinking about the topic. I am the kind of person who second guesses themselves a lot and after reading this blog post, it makes me want to just go for it the next time I don’t quite understand something or understand it completely. I feel like if I just did the assignment back then I probably could have done it but I second-guessed myself.  

https://www.edureka.co/blog/java-design-patterns/

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

This week I am going to over a post from the CodeGuru. The post starts by talking about the importance of refactoring, what it is and why we refactor. They define refactoring as the process of restructuring or improving the internal structure of code while keeping the functionality of the code and not changing its external behavior. The article then goes on to talk about when the pros and cons of refactoring and why sometimes it is not best to refactor.

Refactoring code can help prevent bugs but if done improperly, refactoring code can also create bugs in your code so that is why it is important to be careful when refactoring code. In the article, it talks about how it is a good habit to analyze your code before refactoring code. If after analyzing your code, you find that you have to refactor most of your code, they caution you against refactoring the program because you may end up creating more work for yourself. Instead, they recommend that it may be better to start over from scratch. Another practice they implore coders to follow is you should not refactor code if you don’t have the tests or plan to create the tests for that code. This is because, without the tests, you may not have sufficient information about whether or not your code has changed the behavior of the program. Another good practice they recommend is you should wait until you deliver the product and use the time in between tasks to refactor code. Software development can be a very time-sensitive industry so some good practices that we should have as programmers are we should be mindful of the time we have before deadlines and be able to analyze whether a task can reasonably be done in the allotted amount of time. We should also establish clear and achievable goals and refactor code in between tasks and before adding new features to the program so that we can avoid technical debt.

I chose this post to review this week because I think it is a very important topic not just in this class but in programming in general. One of the reasons why I chose this topic, in particular, is because in class we often toss the term around in class, we know what it is and how to do it, but we never really talk about how to do it well or what are some good practices that we should follow. Personally, I have been following some of these practices all along such as gauging my time before deadlines and making objectives along the way, but I also have a really bad habit of deviating from those objectives. There were so many times in my undergraduate career where right before an assignment is due, I ended up refactoring the program from start to finish or redoing the entire assignment from scratch. Now that I know good refactoring habits, I can avoid this in the future.

https://www.codeguru.com/csharp/best-practices-for-code-refactoring/

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

This is a topic that I have been wanting for a while to write about but never really got around to doing so until now. For this week, I am going to review a post made by Martin Fowler. In the first part of the blog post, Mr. Fowler explains what the acronym stands for and where the term comes from. Mr. Fowler than walks the reader through an example of when we could apply YAGNI. In the blog post, the example that he uses is a company having two teams work on two different components of a program (one for sales and the other one for pricing). The pricing team then predicts that in six months’ time, they will need to create software that handles pricing for piracy risks and Mr. Fowler argues that this violates the principle of YAGNI. He argues that because the team is making assumptions based on something that has not happened yet, the feature the team builds might be wrong or worse not needed or used at all. In which case, this will mean that the team wasted a lot of time, energy, and effort analyzing programming and testing something that may or may be useless. In the amount of time the team spent developing the precaution for piracy, they could have used that time working on a different required feature of the program. Furthermore, the feature they build could handle the problem incorrectly which means they might have to refactor this feature later down the line. It also adds an extra layer of complexity to the program and adds more items for the team to repair and maintain. In addition, Mr. Fowler argues this is a bad habit for people to get into. The habit of making precautions in advance because it is impossible to predict all possible outcomes and as he put it even if we tried, we would still end up getting “blindsided”.

I wanted to write about this topic now because when I was doing the intermediate assignment for Homework 4, I was thinking about how my approach was violating the single-responsibility principle because one of the methods was doing three different things. When realizing this, I started thinking about my other bad programming habits. One of which was I tended to think ahead and code things that I think the program would need and how it violates YAGNI. So, I decided to read and review a post on YAGNI because I wanted to learn more about why you shouldn’t code things in advance so that the next time that I code, I can avoid those mental pitfalls. I think reading about this blog post would help me a lot because sometimes I have a hard time making these realizations on my own unless someone brings it to my attention in discussion.

https://martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Let me just begin by saying I really like how this blog post was organized and written. It starts off very formally by giving definitions for the terminology that they would use throughout the post and then transitions to explain those same terms in layman terms. With the way the post is written, the author makes it so even a person without a Computer Science background can semi follow what is going on in the post because the author explains the concepts using things that everyone sees and uses on a day-by-day basis.

The post starts with an example of a web URL and how the statement after the web extension is actually a query string. Then the article goes on to talk about how you can format your search to look for a specific pattern, and max or minimum string length. After going over the basics of how to format query strings, they go to talk about how you can combine multiple criteria to further down your search.

For example:

Somedictonary.com/words/?letter=5&partOfSpeech=noun

This finds you all of the five-letter nouns in the dictionary.

The reason why I chose this particular blog post to read and talk about this week is because it is relevant to what we are learning in class. It is a topic we are going to go over in class and have already talked a little bit about this topic in class. In addition, we are using also using it this week for the homework. I chose this post because I think it does a great job explaining the topic. The post is short and worded in a way that I think is easy to understand. It also uses a lot of images and examples, so it was also easy to follow along with what the author was saying about the topic.

In class when we started talking about this topic, I did not think it was particularly difficult to understand, but another reason I chose this blog post is that I have always been the kind of person where I either “use or lose it”. I have always been the kind of person where whenever I learn something new, I need to apply that information or forget about it.

In class, I immediately made the connection that you can use query strings to refine searches in databases but after reading this blog post, I learned you can also apply it to websites. In a way, I think I have always known this because often times when I am navigating a website and want to go from one page to the next, I may just change the page number or page entry in the URL. I don’t think I would have put two and two together and realized on my own that what I was doing was modifying the query string or that I was switching from one endpoint to another.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I am reviewing a blog post made by Gabriel Tanner. Mr. Tanner is a software engineer at Dynatrace and in this blog post, he talks about the characteristics of Docker Compose, why we should use Docker compose. Mr. Tanner starts the blog post about why we have/use Docker.

“With applications getting larger and larger as time goes by it gets harder to manage them in a simple and reliable way.”

The first feature about Docker compose that Mr. Tanner talks about is its portability and how it can construct and destruct a development environment using the docker-compose up and docker compose down commands respectively. The blog post also goes common uses of Docker compose and common reasons why people use Docker compose. Some examples of common uses of Docker are its ability to run several containers on a single host and to run your program in an isolated environment. An example of a common reason why people use Docker compose is people might want to run their program in an environment similar to the one used in the production stage. The post also goes on to talk about volumes and the different types of volumes and their syntax, networking so that our containers can communicate with one another and many other different topics.

The entire blog post is basically one big tutorial about Docker compose. It defines the features of Docker compose, gives examples of its uses, and explains why we should use it. I think this is a blog post that is worth reviewing for this class because I think it could be a really good resource to have in the class. The post is a little long, but it is very thorough. I think it would be a good way to review Docker compose before a midterm or final. In addition, the blog post also covers a lot of information that we have not done over in class, so it also provides a way for us to investigate and learn more deeply about the topic. For the first half of the blog post, it covers material that we have already covered in class but in the second half of the blog post, it covers a lot of features about Docker that we have not yet covered in class such as using multiple Docker compose files by passing an optional override file. This is a feature of Docker that I can see myself using in the future and is a feature that I wish I had learned sooner. A couple semesters ago, I was doing a project in MatLab and Java and was running several large programs on one computer. This made the project very time-consuming and difficult because it took a long time to run all of the programs, generate and collect all of the results. Had I known what I know now about Docker, I would have done a lot of things differently.  

https://gabrieltanner.org/blog/docker-compose

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.