The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.
In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.
Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.
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.
As we have been Progressing through the weeks and we work on the pogils as well as the homework I find myself slowly getting the hang of the work flow as well as utilizing VSCode, I for once understand what is going on in the classes and am eager to continue to learn as it finally is being pieced together in my head. the biggest part would probably have to be the feedback that I receive and probably mostly everyone else gets as well its not some random jargon about how something is wrong but it seems like a guiding hand to get you to the solution that you aren’t to far from. the biggest take away I have gotten as organizing the UML diagrams on the Homework really connected the dots on how these classes and models work together better than it ever has , I can understand paths a little better than I did before.
I only hope I continue to understand the work I continue to do, and im eager to see what work I can get done.