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.

I am combining these two patterns because I think that one without the other will make for an improper balance of skills. This quote [1] by Carl Rogers in his book, on Becoming a Person [2] is very inspirational to me. I have made a career habit out of trying to be unique, self-directed, and perform self-directed learning.

I am also aware of the importance of being able to admit gaps in my knowledge to others. I will be the first to admit that I don’t understand something, or that someone else has a better idea than I do, especially when I think I can leverage this knowledge to improving my skills, and my personal development efforts.

Throughout my career, I have always had home-based software projects in play. The two most noticeable were Guitar Companion, (a Windows C++/MFC turned C#.NET utility program for guitarists which contained components for a notation editor, metronome, tuning fork, band manager, and video guitar lessons), and Guitar Chords, an Android app using MIDI, speech recognition, and swiping techniques to display an intuitive, pleasant looking, and efficient way to show and play any chord.

Although these efforts didn’t make huge sums of money, they did have the intended benefit of ramping up my skills in different areas, allowing me to learn from my home office, and then use this knowledge when needed at companies I worked for. The reverse effect also occurred. I was able to learn techniques at client sites, and then parlay this knowledge back to my personal efforts.

If I had not been willing to “expose my ignorance”, I would not have been able to learn many techniques from other developers. If I had been too focused on “confronting my ignorance”, I would not have done well at sharing back the knowledge I had attained on my own. This process was truly a win-win experience.

It is beneficial that as one grows in their career, they become progressively less concerned about others thinking they are not adequately qualified, because they have gained enough information to both learn and teach. This will lead to salary increases, better projects, better interviews, better companies, and ultimately to a happier career.

References:

1.“If we value independence, if we are disturbed by the growing conformity of knowledge, of values, of attitudes, which our present system induces, then we may wish to set up conditions of learning which make for uniqueness, for self-direction, and for self-initiated learning.”

2. Chicago. Rogers, Carl R. 1995. On Becoming a Person. 2nd ed. Boston, MA: Houghton Mifflin (Trade).

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

For this week’s pattern, I decided to read ‘The Long Road’ from Chapter 3: Walking the Long Road. The context of this pattern is that today’s society values quick success and overnight celebrities more than long term goals and success. Due to this, software developers are much different compared to veteran software developers and make the same mistakes they had made when they were inexperienced software developers. The problem of this pattern is that I, the reader, aspire to be a master software craftsman but my aspiration conflicts with what people expect from me, quick success. My guts tell me to take the highest paying job and first promotion I’m given and ignore slowly building up my skills. I thought this was pretty spot on of how society is today. Social media makes it so anyone can become an overnight celebrity which is probably one of the root causes as to why society is this way. Too much do we value quick cash and success, some people even expect it which is weird considering how hard it is to become an overnight celebrity. People need to take a step back and learn to have a long term goal and work towards your success instead of trying to get rich quick.

As for the solution of this pattern, it was basically the same as I wrote above. I should accept that I may be considered weird for thinking long term but I should accept it. I should also keep focusing on my long term goal, which is to become a software craftsman. By following the long term goal of a software craftsman, I’m able to become more skilled at learning, problem solving, and developing strong relationships with my customers. This is a good thing because, as mentioned before, people are too focused on getting rich quick and not focusing on building themselves up. By sticking to this, I won’t get rich quick like some of these people but I will be much more experienced, having built myself up long term and sticking to a goal. This is a long journey I’m not ready for but this will help me much more later in my life.

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

For this blog post, I have chosen the “Nurture Your Passion” pattern in which this pattern talks about how one should keep their passion for whatever they are doing secure from the inevitable draining activities that will harm your passion. When one progresses into their career, the circumstances will change and the activities you used to do for enjoyment will soon turn annoyances or be in such a crunch that there is no time for blank. It is up to yourself to mitigate these issues and to help preserve your passion.

The time of coding and working with all these programs and getting a fully functioning product is quite fulfilling to see. The work needed to get there and the problems that life will throw at your way will make you want to reconsider your decisions however such as trying to sift through countless bugs or being in a less than optimal working environment. There a number of different options to consider when trying to mitigate this issue, such as exploring different forms of media that contain information that you would like to look at or interacting with different people with the same passion to help bolster your own. The book goes into different patterns that describe these solutions such as breakable toys and kindred spirits where you have these different resources to use to help keep you going.

This pattern does indeed resonate with me as while coding has started out as a side hobby, quick and enjoyable with no commitments to it whatsoever is slowly changing to me more intensive and time consuming leading to generally less enjoyment. This makes me think of the eventual future of potential crunch times and unenjoyable meeting that will take place in which I will have to start picking up new skills to help mitigate these issues such as improving my communication skills incase any situations such as bad interactions with other people in the workplace could be solved by talking myself out of it. There is the chance of a new hot idea in the future that I could latch onto to help keep my interest up and going.

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

This week I decided to take a look at ‘The Deep End’ pattern, which covers the next step on your knowledge gaining journey. The main message of this pattern is to not be afraid and take that next big leap, whatever it may be. The pattern certainly doesn’t suggest taking a risk that jeopardizes your career, but rather taking on new challenges. Software apprentices can apply this pattern to scenarios such as taking on bigger projects, more complex tasks, working with larger teams, or in new places. While these opportunities may seem daunting, learning is all about stepping out of your comfort zone, even if it means failing at times. 

I am surprised that the pattern suggests diving straight into the deep end as opposed to starting shallow and gradually growing deeper. But I suppose if you were doing the same type of work day in and day out, your biggest break would come from a new challenge. Looking forward, when such an opportunity arises, I think the best way to face a new challenge would be to go into it prepared. This is certainly easier said than done. There is of course the mental hurdle of overcoming the fear of failure and the risk of actual failure. But again, as mentioned in this and previous patterns, you should be able to reach out to mentors and kindred spirits to help. I think that is one thing I should keep trying to recognize, that I should not be afraid to take on difficult projects if I know there is a network of people that can help guide me. 

This pattern is a good reminder to step outside of your comfort zone and it reassures you that it is okay to take risks in your professional career. Given that you have the preparation and a supportive work environment, taking on challenges will only help you gain more experience. I would think that currently, I am in the middle of one of these challenges. Up until now, I have only worked on smaller-scale projects with at most two other people. And for this capstone course, I am working with a team of 6, attempting to develop a fully functional inventory system from backend to frontend. So through this process, I have only been gaining experience and I look forward to what else I can learn.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern discusses how software developers should read classic books regarding the craft of software development. Being an apprentice means that you are inexperienced and are still learning what means to be a successful software developer. You should expose your ignorance and ask about any concepts that seem unknown to you, and then try to find the books where these concepts came from. An apprentice should have a list of these books on their reading list.

However, you cannot read every book. There is just way too many and there is too little time. So instead of reading every book, you should invest your time reading the good books. The good books are ones that are useful regardless of time. If you find yourself asking if a book is outdated, then you are reading the wrong type of book. Good books hold timeless information and concepts. Being able to determine which book is good and which book is not a skill that you will be able to pick over time. By reading constantly and reflecting on your work, you will be able to distinguish the “long lived” books.

While reading the good books is certainly beneficial, there is such a thing as taking things too far. If you focus too much on the classics, you might end up abandoning or forgetting pragmatic knowledge and information. This is the knowledge and information that enables software developers to improve on their day to day craftsmanship. Therefore, it is important to strike a balance in your reading list between the classic “long lived” books with modern, pragmatic books.

I personally think reading the classics is one of the most important things that an apprentice can do. An apprentice’s job is to learn as many skills, techniques, and concepts as they can about their trade. As apprentices, our inexperience and ignorance means that we still lack core concepts and skills. Reading classic books could help us attain such concepts and skills. It is from these classic books that we can expand our list of concrete skills and build a foundation for our craft.

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