These weeks, I’ve been learning about APIs and back-ends. I also had the opportunity to practice with an API in my current homework. However, I am very confused about the relationship between API and back-end. I don’t understand how the API is related to the back-end, what the API and back-end are used for.

To answer those questions, I tried to search for some information about API and back-end. Back-end API development introduction, written by Cesare Ferrari, is a resource that I have found useful. The website has clear definitions of back-end and API; and their relationship is also described in detail, which helps me get better understanding of the two new terms. From the website, I know that back-end is a service that will send data to the front-end which interacts with the end users. On the other hand, API, Application Programing Interface, is a set of definitions and protocols for building and integrating application software. API can be also considered a back-end component, which is typically used by front-end applications to communicate with back-end applications. In other words, the API is used to outline all the requirements or functions that will interact with the end user. The back-end will rely on the API to create endpoints that fulfill all the requirements designed in the API. There are different types of APIs, but the REST APIs, which stands for Representational State Transfer, is one of the most popular. It communicates via HTTP requests to perform four basic functions known as CRUD. These are creating data (post), reading data (get), updating data (put), and deleting data (delete).

Moreover, the website also provides a general information of Node.js and Express to explain more how to create and use back-end applications. Node.js is used to execute a Javascript on the back-end without the browser. Express is a library or a Node.js application is used to create and send HTTP requests.

All in all, I think the website is a good resource because it’s short, concise, and provides the essential information I need. It gives me a general idea of what the back-end and API are, and how the back-end and API relate to each other. By understanding the two new definitions, I was also able to understand what I was supposed to do in each one. Based on what I read from the site and what I did with my API homework, I can envision the API as an interface class and the back-end as my concrete class that will implement all abstract methods from the interface class.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

REST APIs have become increasingly popular over the last few years, and for good reason. REST has less of a learning curve than other API models, has a smaller footprint, and parsing of JSON is less intensive than traditional XML parsing. There are a few key standards to REST, including utilizing certain requests like GET, POST, PUT, and DELETE, for example.

When a call is made using REST API, there are a few things that go on within the call itself. First are the endpoints, which is a unique URL that is used to represent objects or groups of objects of data. Every API request has its own endpoint. In addition, there are also the methods used for the request. These include those I listed above, like GET, POST, and PUT. A header contains the information that represents the metadata associated with the REST API request. The header also indicates the format of the request and the response, and provides information about the status of the request. Lastly, the request also consists of data, which is also referred to as the body, that is usually used with the POST and PUT commands and contains the information that will be updated or created.

Another important part of REST APIs are parameters. When someone is sending a REST API request, they can use parameters to narrow or further specify their search request. These are valuable tools, since it allows you to filter the data being received in a response. Some parameter types include path, header, cookie, and the most common, query. Query parameters are located at the end of a URL path and can either be required or optional. This can be useful if, for example, you are using a base GET command to get all of the objects in the database, and you can have an optional parameter to specify which of all those objects you want, using something like ID or name, depending on your implementation.

Source

I chose the above source because it gave good additional information on REST APIs, compared to other websites I visited. This helped me further understand how REST APIs differ from other web APIs, and what helps make REST different and usually better. REST APIs definitely have their many uses, and allows ease of use with their standards of requests, using easy to understand methods like GET, POST, and PUT, to name a few.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Resource Link: https://www.linode.com/docs/guides/when-and-why-to-use-docker/

For this week I decided to research and write about what exactly docker is and what it’s used for in commercial applications or projects. With how much we use docker in class, I was curious as to what its other applications were and how it was used it other settings. I was curious about this because I had never heard of docker or used docker before this class, and it seems like such a useful and important piece of software. Even with just what we’ve covered so far in class, it appears to be very versatile and suitable to a variety of different applications.

This article summarizes what docker is, when and how it originated, the benefits of docker, and when and when not to use docker. I chose this article because it provides all the necessary information in a clean and concise way. While many other resources about docker were bloated and included lots of unnecessary information, this one has just the right amount of information to inform a user about what docker is, how to learn more about it, and how to get started using it. This makes it a great resource for someone new to docker, who maybe just heard about it and doesn’t know exactly what it is.

First, the article provides details about what docker is and when it was released. Docker was released in 2012, and since has become an important technology in web development. This was surprising to me because I figured I would have heard about such a big and important technology in web development, at least in one of my other classes. I figured that since I hadn’t heard of it, it must be a newer technology, but it’s already 9 years old. However, it does make sense that it would be a fast growing piece of software because of its versatility and ease of use. It makes the process of setting up and configuring a web server much simpler than it would be otherwise, and it makes monitoring those web servers easy through the docker application.

Next, the article delves into some of the benefits of docker. The benefits include reproducibility, isolation, security, docker hub, environment management, and continuous integration. Docker is reproducible in a similar way to a java application, because whereas a java application runs on a java virtual machine that is the same across all operating systems, a docker container runs in docker and is the same across all operating systems. This is very useful because it means that the container doesn’t have to be changed across different operating systems, meaning that setup time is reduced. Then, isolation is the property of a docker container where it can have instillations independent of the operating system it’s on, and independent of other docker containers. This helps to avoid conflicts between docker containers that may require different dependencies or installations. Next, with the different parts of an applications separated into different docker containers, security is increased. This is because if a single docker container is compromised, other docker containers won’t be affected. Also, different containers means that different versions of a project can be maintained independently, for example for testing. The docker hub makes it easy to find and use certain images, also leading to ease of setting up a docker container. Finally, docker can be used as a part of tools like Jenkins, meaning that when an update is made, it can automatically be saved and pushed to docker hub as an image, and put right into deployment. This cuts down on development time, and increases the ease of use by reducing the amount of work that must be done manually.

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

The “Draw Your Own Map Pattern” is chiefly about assessing your current role in an organization and looking forward to your next professional endeavor, be it within that organization, or externally. The Problem section explicitly defines the situation such that your current employer does not have the position you’re looking for in your organization. The proposed solution, in summary, is to put careful thought into your future external position and then create a plan with micro steps to get you there; these steps will help keep your sights on the potential position.

The pattern seems to coincide very much with the steps I’ve taken in life. I’ve personally undergone a very windy path to get where I am now and will certainly be considered having an unconventional path in any career I manage to land outside of college. While I don’t always have scheduled periods of reflection in my career, I find that periodically discussing with coworkers what they want to make of their careers inspires them to pursue their goals and also forces me to look inward and re-evaluate if I’m happy with my career at that point.

Perhaps my favorite takeaway from this pattern was the activity provided in the Action section at the bottom. For the unacquainted, the activity requests the reader to make a map of three jobs that could be logically pursued beyond their current one. The authors then insist that the reader do this with the web of three jobs for each of the previous branches and assess if any of these roles would satisfy them. The exercise implores that the branching is done one more time and this final iteration should be roughly representative of your total career prospects. I found that engaging with this exercise left me feeling hopeful and optimistic about my potential career paths —which is to be expected as a student— and would specifically recommend it to others looking to make a change who may be a bit more pessimistic about their prospects. As someone who has hopped careers, the hesitancy to reconsider one’s career comes from a fear of needing to take drastic action but by using this exercise I think those in a similar situation to my own would realize that they’re not as far from their destination as they may seem.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

What this apprenticeship pattern starts off talking about is how you have been developing extraordinary code for years, meeting the standard for the company, but all of a sudden you are offered a management position which will in fact take you away from coding into another direction. Now the pattern states that this may be tempting and show that you are leveling up, but it is actually sort of an illusion in a way. You may feel that a promotion will help you out, but in this case it is taking away from the journey you have took so far and the motivation to be a good programmer. When you take the promotion, then you will start deteriorating in the skill of programming slowly as time passes by. What staying in the trenches means is to stay true to your passion, and try to find rewards for you exemplary work in some other sort of way by negotiating with the company.

I think the main message of this pattern is important and how it is talking about staying true to your passion. One thing that I don’t agree with is just because you may come across a different path in life that may be outside of programming, does not mean that you should not take. There are a lot of people that won’t be able to be in the position of manager and although a person has a passion for programming, there are times when someone needs to go to the uncomfortable side to level up. It may be time to start learning more about the bigger picture of software development and managing a team of programmers, then just doing programming yourself. It will be a different change and the only way to find out whether you like it or not, is to try it out. In the future, if you believe that the role isn’t for you, then you can always go back to some role of programming at a different level. The goal however shouldn’t just be to give up programming all together, but to try some different path while also staying up to date with the programming aspect. I personally believe that this will help you out more with experience of leading a team and not only focusing on the developing aspect. The more variance experiences a person has, then in the future it can help apply in all sorts of different aspects.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I read the section  “A Different Road ” from chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how taking a different road could be a risky or life-changing event.  Despite this risk, I believe that one should be not afraid to do something different with your life. A change no matter whether they seem good or bad at the time will teach you something new or a new experience that can drive you to push forward. The author started the section by talking about explaining how saying goodbye to the craft can be risky, but  “Even if you leave the road permanently, the values and principles you have developed along the way will always be with you” I think this is very true, no matter the change, the principles you have acquired so far in the career will always be there for you.

Currently, I want to talk about the sad reality and risk one may face when one changes a craft. The author talked about how a person switched from an IT job to be a teacher and afterward it was hard for the person to get back to the industry because “most HR people in big companies didn’t like it.” Sadly, most software companies nowadays see the gaps in a person’s career, and you must justify within their value system why you left and why you are coming back now. Also, as technology is evolving daily, companies want individuals that are willing to learn quickly and adapt to the environment rapidly. The solution suggested in this section I found quite helpful, which was to Write down some of the other jobs you think you would enjoy doing, find people who are doing those jobs and ask them questions regarding them. This interaction will help an individual to decide if they are making the right decision to choose a different path. Reading this section made me think of what my life will be if I choose a different road, it is risky, but is it worth it. Sometimes you must risk It for a greater reward.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern I chose this week is “Kindred Spirits”. According to this pattern, you may find yourself in a workplace that does not encourage software craftsmanship. In the absence of a mentor, you should find like-minded people who are also looking to become software craftsmen. Unlike mentors who are people you aspire to be like, peers are people you can feel more comfortable with. You can exchange ideas without feeling pressured like you might with a mentor. It is important to remember though that you should not just follow the crowd. It is important to think for yourself.

As a computer science student, I have the good fortune of being surrounded by kindred spirits. Most of my peers are of a similar experience level to me. Because we are all in the same classes, we are all learning the same language and doing the same assignments. It gives me so many other people I can bounce ideas off.

The author also discussed the difference between mentors and kindred spirits, and I think that difference is really highlighted when you are a student. It is often intimidating to ask professors for help or ask for their opinion. Sometimes when a professor tells you something or gives you a suggestion, you feel like that is the only way you can do something. With other students you are not as afraid to ask questions, especially if you are friends with each other. You are also able to take advice from them without feeling like that is the only way a problem can be solved.

Under the “Action” section the author discusses finding communities to join based on the languages you know or the tools you use. This is another benefit of being a student. Groups like the computer science club offer an in-person community to be a member of. It might be a bit harder to find a group after graduating but it is still do-able – especially with social media. If you cannot find an in-person group to join there will always be a discord server to join. You could even organize your own group easily using social media like the author says to do.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

For my final blog post pertaining to the apprenticeship patterns in the textbook, I decided to review the pattern entitled “Rubbing Elbows.” The situation that this pattern pertains to when the apprentice has almost plateaued and has been working on their own for projects. In this situation, the book explains that the apprentice will sometimes feel like they are missing things (like better ways of solving problems), but that they are not able to find these things on their own during their plateau. The reason I chose to review this specific pattern is because I can relate to it. On my free time outside of school, I have worked on projects on my own, and I know there are better ways to program what I am making but because I work on my own, I find it difficult to find those new and possibly better ways or working. The book’s solution to this problem is to find someone else to work with in order to learn more and have a different perspective on your projects/work. “Find ways to sit with another software developer and accomplish a hands-on task together, side-by-side. There are some things that can only be learned while you are sitting with another software developer to accomplish a shared objective.” I have actually done this before with a classmate while working on making iOS applications for fun, and it was an enormous help. Even if the person you are working closely with does not have a different solution to your problems, the added outside perspective proves to be not only helpful, but also necessary. I was especially excited when reviewing this pattern because I feel like I already am great at working with others, and the fact that that skill could be a good thing for my career is reassuring. The book describes how working with someone else could have many benefits even if it is only once a week. It helps keep you motivated and helps keep the other person motivated as well. If working with a certain person becomes not so motivating, the book explains that this does not mean you should give up, but perhaps you should think about working with someone else who could be even more motivating to collaborate with.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

This week I read the section “Learn How You Fail” in chapter five of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This section focuses on the concept of learning from your mistakes by understanding your shortcomings. An example the authors use to illustrate this is writing an implementation of binary search and its tests in one sitting without compiling the code or running tests once. Once finished, compile the code and run the tests in order to find any mistakes you’ve made. Repeat this process until the code compiles and passes all the tests while also writing down notes on each iteration. These notes will act as an identifier to your personal shortcomings which will certainly be useful into the self-assessment that allows one to set realistic expectations and a direction to aim towards in self-development.

The concept of “Learn How You Fail” has a lot in common with “Expose Your Ignorance” like how they both promote self-improvement and emphasize examining one’s shortcomings. But the most important similarities among these is that they’re both concepts that center around learning from your failures. However, the key difference is that EYI is opening up yourself to failure while LHYF is learning from that failure. It’s just that both concepts complement each other in that one naturally leads to the other. Take for example that exposing your ignorance could very easily act as the direction needed for self-development similar to the notes in the “Learn How You Fail” example.

The idea of “Learn How You Fail” is also one that applies to many different contexts outside of software development. For example, before someone learns how to ride a bicycle, they’re likely to fall dozens of times. A saying I’ve encountered in everyday life is that mindlessly failing again and again will only get you so far, improving muscle memory and the like. A key aspect in learning effectively and quickly is knowing exactly what to improve on. That’s why I personally believe that a direction or a goal is incredibly important not only to this concept, but to learning as a whole.

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