Category Archives: Week-15

REST API Design Practices

What is REST API? - Seobility Wiki

For many assignments in a recent class, I had the opportunity to use and learn about REST (Representational State Transfer) API in relation to simple web applications. In working with REST, I was unsure about some of the syntax and conventions used with the API, namely the difference between different response types (JSON vs String response for instance).

I looked into finding some more information on good practices for REST API projects, and according to a helpful blog post I found on Stack Overflow (https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/), REST APIs should generally both request and send responses with JSON (JavaScript Object Notation). I had a number of issues with sending and receiving data which was not in this format (needed to send/receive strings in POST methods within an endpoint). This was causing problems such as information not being sent and received properly (name field of an item not being sent or received in the right places) as well as issues with the functioning of the web application itself (endpoints belonging to unrelated services would cease to function properly if the requests and responses were not JSON.

Furthermore, according to the author, JavaScript has baked-in methods to handle interacting with JSON entities, which makes it easier to use overall especially if there are other JavaScript based technologies being used within the structure of the project, so it makes sense to use JSON within requests/responses. So in future projects involving REST, I will attempt to primarily use JSON objects for responses and requests to ensure compatibility and easy access through JavaScript.

Another point which was discussed was the importance of using nouns in naming conventions, rather than verbs (specifically nouns which are highly representative of the destination or object being affected) when naming endpoint paths. IE: instead of POST: /orderPizza/, use POST /order/ when trying to create a new order. This makes sense, as the HTTP methods typically describe the action or verb being enacted on an object, so you needn’t describe that within the endpoint path.

Finally, I want to discuss the topic of HTTP status codes; the author of this article describes the meaning of many common error codes and why you might return them as a response. This was especially helpful for me as I had been using these codes within a REST project, but had no idea what the majority of them actually meant. According to the article, a code of 400 indicates a client-side validation error, 401 represents an authorization or permissions error, and 404 represents an inability to find a particular resource. Out of all of these errors, 404 is definitely the most common from my experience. I have frequently seen this while using the internet whenever a page would couldn’t be found on a website/web application, it was pretty neat to learn more about.

What is a 404 Page? - Learn to code in 30 Days
Example of a common 404 not found error page

Overall, after reading this article I feel more informed about the way REST API services work, and will be more prepared for the next project I work which makes use of the framework.

Post Referenced: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

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

AngularJS

This post today is about AngularJS based off of the article AngularJS-Overview by TutorialPoint. AngularJS is a structural framework for dynamic web applications that was developed in 2009 by Misko Hevery and Adam Abrons. Its latest version 1.2.21 is now maintained by Google. AngularJS lets you use HTML as a template language and then allows you extend the the syntax to express application components. It is a framework used to build large scale and high performing applications that are easy to maintain. General features include that it is open source and licensed under Apache license version 2.0, it is an efficient framework able to create Rich Internet Applications (Web apps that are able to perform the normal features and functions of normal applications), provides an option to write client side applications using Javascript under an efficient Model View Controller method, and AngularJS is cross-browser compliant so that it automatically handles JavaScript for each browser. The advantages of AngularJS are that it has the ability to make single page applications in a clean way, provides data binding capabilities to HTML giving it a responsive experience, it is unit testable, uses dependency injection, gives the ability to provide more functionality with less code, and it can run on all major browsers and smartphones. The disadvantages are that it is not secure and not degradable. Since it is a framework that is JavaScript only, it is not safe so server side authentication is a must. Also since it is all JavaScript, if the user disables it, the webpage would show nothing but the basic page.

This relates to class because we were looking at the process and components that go into web applications. I selected TutorialsPoint because I have used it before for overviews, tutorials, and references. It has proven to be a reliable source to me so I do not have to worry about getting the wrong information. Their reviews online are typically very well rated with key words such as reliable, useful and helpful. I have found those three keywords to be true with this article. I had learned many things since I did not know much about AngularJS prior to reading the article. Some of these things include that it is very useful for single page applications and that it is not very secure. This is very useful for me to learn about because I am currently planning a single page web application project so it is an option for me to utilize.

Source: https://www.tutorialspoint.com/angularjs/angularjs_overview.htm

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Maven Overview

Today I will be writing about Maven using information from the article Maven-Overview by TutorialsPoint. Maven is a project management tool giving a complete build process framework. Mavens objective is to provide a comprehensive, reusable and maintainable model for projects and to provide plugins and tools to interact with this model. Since Maven uses a standard directory layout and default build lifecycle, development teams can quickly set up their project builds. When you have multiple development teams Maven can create a standard build structure for all teams to use. This promotes consistency across the project while developers create reports, builds and testing automation setups. Maven gives a way for developers to manage builds, documentation, reporting, dependencies, SCMs, releases, distribution and mailing lists. Mavens project structure is declared in in the pom.xml file. POM stands for Project Object Model and contains the fundamentals of the entire Maven system. This pom.xml file is similar to the build.gradle file we have seen/used in class. Some features of Maven include its ability to generate a website or PDF including complete documentation, backwards compatibility, automatic parent versioning so that there is no need to specify in the sub module, parallel builds achieving performance improvements of up to 50%, and improved error reporting.

This topic relates to class because it is a software project management tool, which can be very useful to developers. We often used Gradle in class which is a similar concept. I selected this article from TutorialsPoint because it is a useful website for quick references, overviews and tutorials. It is similar to w3schools which is another website I use often for quick tutorials, references, etc.. I would say that the information is reliable, just more shallow as it does not dive deep into topics. I would not use it as the only source when trying to learn a certain subject in depth as you will not get a deep understanding of the material. As an overview though, I would say it is perfect. I personally had an okay understanding of Maven as I had used it a couple of times but never knew the finer details as to how it is different from other project management tools. Some things I had learned from this article are its many features including its use for reporting and documentation. I plan to use project management tools for future projects, so it is good to know the differences and know which one is the right one to use.

Source: https://www.tutorialspoint.com/maven/maven_overview.htm

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Blog #6: Design Patterns

The class that I am taking right now goes over database design patterns, so it is only right that I research even more about them for this most recent blog post. I found an incredible website that discusses all sorts of designs, some which that I have never heard of before this. I will attach the link to the website but it was from sourcemaking.com. The examples that the website describes all fall under three different categories: creational, structural, and behavioral design patterns. The creational design patterns are defined as being all about instantiation. There are other subclasses of this design pattern group like class-creational and object-creational patterns. Some examples from the website of patterns in this larger group are builder, singleton, factory method, and more. In contrast, the structural group of patterns are all about class and object composition. Some examples of patterns from this group are adaptor, composite, bridge, decorator method, and more. The last group, behavioral, is defined as patterns for Class’s objects communication. These patterns are mostly concerned with communicating with objects. Some examples of this design pattern group are command, iterator, observer, visitor method, and more. I am very happy that I went back and revisited this topic from my class, especially since I am about to take the final in this class. I recommend taking a look at the same website that I used to research for this blog post, and I genuinely wish I found it earlier in this semester!

https://sourcemaking.com/design_patterns

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.

Blog #5: Database Design

As I near graduation, many of my courses become more specialized towards my actual major and concentration. This semester, I have been enrolled in two computer science classes that, despite being very different, have help emphasize each other with their abstract similarities. Software Construction, Design, and Architecture repeatedly proved the value and worth of Database Design and Applications time and time again. The same could be easily claimed with the roles reversed. The reason I want to share this in my blog is not to say they are similar classes, but to express how important it is to me that my courses relate. If a class I take relates to something I do in real life or something I want to do later in life, it is easier for me to put effort into getting the most out of the class as I possibly can. Furthermore, I have already stated in previous posts that knowing that something I am learning is usable in real life is very motivating, while not being sure if I will ever use the information I study can be the opposite. So why does this all relate back to my two separate courses in this semester? It is because both classes are for different concentrations of my major but still share conceptual similarities. I chose to be a software development student which relates to Software Construction, Design, and Architecture directly, while Database Design and Applications is geared more toward Big Data Analytics. Seeing the similarities between these two classes helped show me that what I am studying is very worth it and can be used regularly in my life. I was able to use what I learned in one class directly on something I would practice in the other… at similar time periods in the semester no less. I definitely believe that this was somewhat intentional by my school to have classes like these be on similar timeframes, and I am glad to say that it does actually motivate me a bit and validates the concepts in each course. I do not have a source or link for this post, but I did feel like sharing this because of how adamant I am about this being a great and useful tactic of teaching/learning.

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.

Sprint 3 – Retrospective

Sprint 3: 04/08/2020 – 05/04/2020

Sprint 3 preparation started on 04-08-2020. Since Sprint 3 was the final Sprint we were planning to get work done as much as possible. We proposed too many issues that were all appropriate, but we wouldn’t be able to finish them all on time, so we all agreed to keep the most important ones. Our top goal for this Sprint was to have the UpdateGuest service work as a whole.

These are the issues we came up within our Sprint 3 planning (we had more in our backlog):

  • Create MongoDB database for UpdateGuestService
  • Implement WebUI in Angular App
  • Decided which type of Angular form to use for Web UI
  • Learn about Angular Testing
  • Create endpoints in backend
  • Learn how to create tests for backend endpoints
  • Learn Docker
  • UpdateGuestWebUI: Create Docker Configuration
  • UpdateGuestService: Create Docker Configuration
  • Implement requested endpoints from registrar team
  • Decide what needs to be tested in the frontend
  • Implement endpoints in Frontend
  • Implement Angular form in WebUI.

 During Sprint 3 I worked in multiple issues and supported the team with issues discussions and merge requests’ review:

1 – This issue was part of Sprint 2, but we had some minor changes that needed to be done before we merged the merge request.

2 – We had to decide which Angular Form we were going to use, and as a team, we decided to use Reactive Forms.

3 – This is issue was more about learning. The first thing learned was that the latest version of Docker cannot be installed in a Windows Home edition unless you are using it as an enterprise. Docker in Action was a great resource to learn Docker.

4 – I have reviewed, approved, and merged the merge request for this issue.

5 – I created the Docker configuration of the UpdateGuestWebUI using the NGINX proxy server, which by default will run at PORT 8080, using the Docker container IP.

6 – We had a couple of merge requests for this issue. I have reviewed the merge requests of my teammates and implemented the Age&Employment component.

What we needed to do less

We should not focus only on the issues we get ourselves assigned to. Reviewing each other’s work is very important.

What worked for us as a team:

  • Reviewing each other’s work helped a lot with our progress because of the feedback we gave and received.
  • Helping each other through Gitlab Discussions and during our class meetings.
  • Checking GitLab constantly as we decided on our working policy helped us be on the same page.

What we need to improve 

There is always something that needs to be improved, especially when the team is determined to constantly make progress and succeed. In our case, we should improve the way we manage our time. 

Conclusion

I think we finished Sprint 3 successfully. We managed to work together even better than Sprint 1 & 2. The reason for that is because we were able to communicate, discuss, share, and collaborate with each other the whole time. In the end, we all feel satisfied and accomplished with the progress our team had.  

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

A Different Road

Many times the plan that people have laid out for their lives are almost never the same as what actually happens. In this pattern, A Different Road, the author discusses that sometimes it is okay to step away from The Long Road that you were taking to becoming a software developer. This simply means that its okay to step way from this, whether it be permanent or temporary, you should always carry the skills that you learned with you into whatever it is you do next. Then expanding from that, if you do return, you should keep those unique experiences and bring them back into your next job.

This pattern speaks to me personally because I have had many different jobs ranging from warehouses, Dunkin Donuts, meat shops, landscaping etc. The point being is that I have had the privilege to be able to experience this firsthand. Many of these jobs were basic minimum wage jobs that left me desiring for more, and to be able to actually use my brain. However, these jobs all were able to give me something back that I have been able to carry with me throughout my life. For example, most of these jobs gave me the motivation to constantly be trying to reach a better place in life and work. I know how it feels to be sitting in a job and feel like my brain is melting from boredom. Going through these times grants me the motivation to not have to return to them.

The pattern also discusses that often times with a desired job in the software field, HR will see the other jobs as simply lack of experience. However, through the many jobs that I have had it is very obvious to me that this does not constitute for lack of experience because all jobs tie together in different ways. Because I simply was not doing software strictly at the time, does not mean I am not capable of a software job. This is where it all ties back to the pattern. If you are able to take away good, beneficial lessons from where ever you are, you simply have to be able to prove these “skills” to whoever is doubting you.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Draw Your Own Map

The final Apprenticeship pattern I would like to discuss is titled “Draw Your Own Map.” This pattern is written for developers who feel that none of the career paths their employer provides is a good fit for them. It reminds us that it is up to ourselves, not our employers or anyone else, to determine what the next step in our careers should be. The pattern recommends that we develop possible career maps made up of small, specific steps we want to achieve. If our maps conflict with our employers’ expectations, we should simply seek out other opportunities that better fit. These maps are never set and can be altered as our circumstances change, but they will always help guide us towards the career we want.

As I’ve gotten closer to finishing college, I’ve become increasingly worried about my future. I don’t have any definite goals or plans for my career, and I don’t know how to create these plans or put them into action. I chose to read this pattern because it seemed like it might help me figure out a plan for myself. After reading the pattern, I at least think it provides some useful advice. I like that the pattern emphasizes the importance of achievable steps and advises against high-level goals. This makes me think differently about my lack of long-term goals, as I now understand that it is easier to succeed by planning short-term steps. Additionally, the pattern helped me realize the importance of following my own plan instead of one set by my employer. I have had miserable jobs in the past which I felt trapped in due to a sense of obligation towards my employer, but reading the pattern pattern assured me that I do not have this obligation.

One problem I had with this pattern, which also applies to the other patterns I read, is that it assumes the reader is already employed as a developer. For this reason, the pattern doesn’t quite provide the help with actually creating goals that I was hoping for. Despite this, I think the pattern gives a crucial piece of advice in the second paragraph, where it emphasizes the importance of taking a first step. Even without a clear plan, taking a step is crucial for building momentum that can lead to success. Despite not having clear goals for my future, I already know I want to work on regaining my passion for programming in the short-term. After finishing college, I should focus on pushing myself to take this step. Hopefully, I will develop the motivation to keep programming and eventually be able to draw a map for myself to follow.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Finishing Up The Patterns

The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.

The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.

I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.

The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.

I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.

I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.

I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Improving as a Developer

Today’s first pattern in Apprenticeship Patterns is “The Deep End”.

“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.

As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.

The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.

I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.

The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.

Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.

I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.