Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello!

Welcome back to the blog. This week I am discussing the Craft Over Art pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that you are being paid to make something to solve a problem for a customer. The problem is that there is already a solution for how to fix that problem, but you would be able to come up with something creative to address the problem that would impress your coworkers. 

The pattern discusses that being a craftsman is impacted by relationships we build with others–we should work to build strong connections with customers, making sure we deliver to them something of quality. We shouldn’t aim to focus on our own interests. You should be working to the best of your ability but also keeping the customer’s best interests in mind. Part of our growth is being able to give up the opportunity to make something beautiful and instead create something useful when needed.

The pattern advises that in the next 24 hours you work on something to be useful rather than beautiful, and to think about what you should be focusing on while you make the decision on making something useful. You should also reflect on your past experiences where you tried to do something creative rather than follow an already-made path for solving a problem and the result of it, and what would have happened if you chose to use a previously established solution.

I thought that this pattern was an interesting read. Throughout the patterns, I’ve been seeing that we should work to hone our skills and not get too comfortable with certain activities–try to branch out some more or we may get stuck. And this pattern is saying that although we should exercise our skills, we need to find a balance between creating something ingenious and creating something based on an already existing solution. I think this is important to think about when doing work. Of course, I think it would be great if you could figure out new ways to do things. But it’s also important to deliver products to the customer in a timely manner, and it may be too resource consuming to create something from scratch as the pattern mentions. I don’t have any disagreements with this pattern. It would be great to develop the ability to know when to sacrifice utility vs beauty and it would definitely be on my mind when I need to solve a problem in the future. I usually tend to look for any known solutions and make slight adjustments to the solutions when necessary.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Programming is a skill that requires applying the right patterns to various scenarios. To become proficient in pattern applications, it’s helpful to analyze how other developers have used them. One great approach is to study open-source code published by experienced programmers. Carefully reviewing their work can spark ideas on how to enhance one’s own programming patterns and projects. This enables developers to expand their skill set and gain inspiration from the expertise of others.

I find it intriguing that as I read more code, I find it easier to comprehend. It’s fascinating to think that this improved comprehension reflects my mastery of the craft. Additionally, I discovered an interesting suggestion to track code changes over time using git. By reviewing the history of a codebase, I can gain insights into how the code has evolved and identify patterns that proved successful in the past. This knowledge can then be applied to the code I write in the future. Being able to observe and understand the evolution of code not only helps me identify errors that were initially overlooked but also provides me with an opportunity to continuously improve my programming skills. By incorporating successful patterns into my own work, I can strive to produce high-quality, efficient code.

When I use open-source packages, I sometimes face challenges where the documentation doesn’t fully explain how to use the package. It can be frustrating, but I’ve learned that diving deeper into the source code provides an excellent opportunity to learn from the author’s coding patterns and techniques.

I completely agree with the insights provided by the pattern, which suggests that going through open-source code or someone else’s code is an excellent way to learn from experts. I believe that studying experts’ codes is the best way which can help me with much more than just how to use a particular software package. By observing the patterns and techniques used by skilled programmers, I can improve my own way of programming and learn to write more and make code run efficiently. Inspecting open-source code is a crucial aspect of my development process, and I plan to continue doing so in the future. It’s a great opportunity to learn from the best and enhance my programming skills.

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

This weeks blog read of choice was a blog called “ Polymorphism in Programming” by Jonathan Johnson. This blog goes throught what is polymorphism, how to use them and also the different types that there are. One thing I thought was funny is that it compares ciderella after midnight m and before as polymorphism. Since polymorphism is when the object undergoes transformation. In programming the oject tranforms in compile time and dynamic and what does the transfmation is the method and object. Polymorphism is very essential to object oriented programming. Four different types of polymorphism are subtypes polymorphisms, parametric polymorphisms, and hoc polymorphisms and coercion polymorphisms. Subtype polymorphisms is the most common kind, it uses of class name to refrenece multiple kinds of subtypes at once. Parametric polymorphism which is also describe as overloading specially provides a way to use one of its functions to interact with multiple types. Ad hoc polymorphism also known as compile time the function with the same name acts differently for different types and lastly there is coescion polymorphism is the direct tranfomation of one type to another this happens when one type gets cast into another type. The reason why I picked this blog post was because we went over polymorphism in class a while back but I personally did not take the time to dig deeper into the subject so this was a good opportunity to dive a little deeper. Which is what I was able to achieve with this blog post. It refreshed what I learned about the different types of polymorphism and really helped me grasp the concept into a more deeper level. The reason why I picked this blog post is because I like the way it was formatted and how it is organized with its information. I also like the graphics that they used to explain it. It brought a simple and a more clear picture. Especially when they used Disney to connect to reader. I really appreciated that, it brought a sense of light weight to the read. There was a lot of information but it was easy to intake because of the organization. I hope to take a lot from this blog post, and use polymorphism to reuse code more effectively, to also use same variable for multiple date types. And also to reduce coupling with differently functionality types. Hopefully these clarification with different types help me excel in this so that when I do need to reuse code I can do it in the best format possible using all the architecture structures that I am learning. 

https://www.bmc.com/blogs/polymorphism-programming/

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

This article from InfoWars main goal is to explain the Law of Demeter, which is something that I have never heard about before this class. The basic premise of the Law Of Demeter is to ensure that classes and objects should never know the internal design and content of other classes. This promotes loose coupling and allowing code to be easily modified and changed in the future. First discussed in 1987 at Northeastern University, the law was developed to help software designers create code that can be understood and modified easily. This seems to be the main goal for most design laws. With more coupling, there is more confusion. The Law of Demeter will ensure that there is minimal complexity within code from restricting classes to have excess knowledge of the inner workings of other classes.

The main reason I selected this article for this weeks blog post was because it again showed some visual examples of code being used in the Law of Demeter, instead of just plain text. As I stated in another blog post, I enjoy seeing pieces of code that show the principle being used, and showing its violations. This article was also another free resource for many beginner coders to utilize to enhance and optimize their code. This is a concept I did not know about before taking this class. Reading the article, I connected the main points of the Law of Demeter to concepts we have learned in class, such as loose coupling. I’ve never realized that those small concepts we learned in class had much bigger implications in the world of software design, such as having a whole law dedicated to it.

In the future, knowing the Law of Demeter exists will help me make sure my code utilizes loose coupling, so that my code can be easily understood and ready by my co-workers on the project. Having code that is easy to read and understand is important when working in a team environment, as you can write something that you personally understand easily, but if a co-workers takes over your work, they are left in the dark as to what they are reading. This also promotes communication in the work environment, such as having standards for writing code so that everyone is on the same page when it comes to creating code, and allows for a more fluid and effective work environment.

Link: https://www.infoworld.com/article/3136224/demystifying-the-law-of-demeter-principle.html#:~:text=The%20Law%20of%20Demeter%20principle%20states%20that%20a%20module%20should,of%20other%20objects%20or%20components.

From the blog CS@Worcester – Noelan Chabot's Blog by nchabot1 and used with permission of the author. All other rights reserved by the author.

This week in CS-343 I’ve been getting familiar with REST APIs. This is not the only time I’ve had to use a REST API; I had to use them in my project last year for operating systems. REST APIS as explained in the stack overflow blog “Best Practices for REST API design” are one of the most common kinds of web services available today. It allows various clients including browser apps to communicate with a server via REST API. It’s important to design the REST API so that the client can properly and effectively communicate with the server.

First, what is a REST API? A REST API is an application programming interface that conforms to specified architectural constraints, like stateless communication and cacheable data. It is not a protocol or standard. REST APIs should accept JSON for request payload and response to JSON. JSON is the standard for transferring data. On another note, while transferring dates, I didn’t use JSON in my project, instead, I ended up using Curl. A curl is a command-line tool for transferring data, and it supports about 22 protocols, including HTTP.  It’s very good when testing REST services, but the blog and most sources I would say would recommend JSON for requests/responses. I was familiar with JSON files, it’s common, but now I understand why using JSON is the more optimal.

Endpoint paths are used to grab/modify whatever information you might want from the REST service. The most common ones are GET, POST, PUT, and DELETE. GET retrieves resources, POST submits new data to the server, PUT updates existing data, and DELETE removes date.  Creating routes are how we can use these endpoints. For example, let’s say that we have a route called article, POST /articles/ is for adding a new article, PUT /articles/:id is for updating the article with given id, DELETE /articles/:id is for deleting an existing article with given ID.

To avoid any confusion when an error occurs, we have HTTP response codes so that we can figure out the root of a problem, the common HTTP status codes include 400 Bad Request This means that client-side input fails validation. 401 Unauthorized – This means the user isn’t not authorized to access a resource. It usually returns when the user isn’t authenticated. 403 Forbidden – This means the user is authenticated, but it’s not allowed to access a resource.404 Not Found – This indicates that a resource is not found. 500 Internal server error – This is a generic server error. It probably shouldn’t be thrown explicitly. 502 Bad Gateway – This indicates an invalid response from an upstream server. 503 Service Unavailable – This indicates that something unexpected happened on server side (It can be anything like server overload, some parts of the system failed, etc.).

This doesn’t cover all the details of REST API but for the most part, this will get you a decent understanding of how it all works.

Link To “Best Practices for REST API design” : https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

For this week I wanted to dive a little deeper on the APIs that we has begin to work with in the previous lab, it interested me how these systems work and wanted to see how different examples out in the world worked and how it related to how we interact with the systems themselves.

In the blog the author goes deep into how the API System are very apparent throughout the world and how they work, the best example I saw was a calendar system on google. The user would send a request to googles remote server and then the server would respond with the site to allow the user too book on the calendar, one the user set the date the request would be sent back to the server and a response would be sent back to the user. As someone who uses other systems like booksy to book haircuts with my barber its interesting how the API allows me to book it on my end while it does all of the work for me interacting with the server and changing my barbers calendar to integrate my appointment.

In the case of the work we did in the lab it is interesting to see how the API used for the pantry relates to some of the APIs discussed in the blog, when we worked we saw the all of the different actions in that API which led to either the collection as a whole or individual students when we looked to post new details or retrieve details. It is interesting to see how similarly the example we worked on works with the blogs APIs, where ours is more adding students taking food or putting food in the pantry, while also logging what is taken or what is put in, there examples is access to a Weather API to check weather in certain areas or the facebook API to give the user their profiles information.

One part that the Blog focuses on heavily is Object Oriented design, where there is a large list of objects and each object has an API which allows the objects to interact with one another, much of what is said leads back to our earlier lab seasons focusing on the different design models and which ones work better, the API aspect of it is now made relevant on how these objects interact with each-other on the users side.

Gazarov, Petr. “What Is an API? in English, Please.” Medium, We’ve Moved to FreeCodeCamp.org/News, 10 Oct. 2016, https://medium.com/free-code-camp/what-is-an-api-in-english-please-b880a3214a82.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

In 1980, I attended a 3-month course at the Center for Computer Education in Lynnfield and was taught “Structured COBOL programming”. I then worked for the Commonwealth of Massachusetts Department of Welfare for 4 years, using COBOL as my first programming language. I had no real mentors here but did make a number of long-term friends. The lack of a mentor made it hard for me to progress as much as I did later in my career, where I had the advantage of working with some really smart people, so it is good that I learned to love computers early on at this job. I was pretty self-directed. Towards the end of my time at this job, I was able to work with some PL/I consultants who showed me what a “real” programming language was like. With this new knowledge, I was able to change jobs, and to double my salary first at MGH, and then at SEI corporation.

Around this time, I attended a course in PASCAL at UMASS Boston, and a PL/I course at Boston University. These jobs had people who were able to teach me some new tricks, but I also was able to return the favor to them. This lack of mentorship in my early years I look back on as a benefit. I was really “thrown into the deep end” in many places, which really helped me to keep learning as much as I could on my own. If I hadn’t continued to love computing, I would have certainly left my career in its early years.

I really didn’t get “Mentored” until I became a consultant, taught myself C and the Windows 3.1 SDK, and went to work at MIT. Through my consulting years, I worked at 10 to 15 companies, doing Windows UI development and SQL database work. These positions were both enterprise-level and desktop-level. There were about a half dozen people I considered mentors at these assignments, and I also sometimes acted in a mentor role to more junior employees.

I think it was fortunate that I was able to work at so many diverse organizations, because I became familiar with many new programming languages and software products, as well as obtaining a broad view of many diverse industries.

So, starting with COBOL, which I look back on and realize was a terrible language, I entered a journey which would continue to get more and more interesting as time went on. I have programmed in C, C++, C#.NET, PL/I, SQL, and a few others, but didn’t really feel I had found “The Language” for me until I started developing with Java which allowed me to convert to mobile Android development.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.