Category Archives: Week-14

REST API Design

Hello everyone and welcome to week 14 of the coding journey blog. In this week’s post I will be talking about REST API and it is an important topic when it comes to the web. REST API stands for representational state transfer and the main purpose of is that is is designed to take advantage of existing protocols. REST has the option to be used on practically any protocol, the main advantage it takes is over HTTP which is used for Web APIs. The main benefit for REST API design is that software developers don’t need to use any additional software or make downloads to take advantage of the protocols. It has a lot of versatility as it allows you to build an API that accustoms your vision and as well as the needs of any clients. There are six key constraints to REST API design that people need to be aware of when deciding to use the API and if it fits your needs. These constraints include client-server, stateless, cache, uniform interface, layered system and code on demand.

The constraint on client server revolves around the idea that the client and the server need to be independent of each other and need to be separate. In essence, developers should be able to make changes to their applications without impacting the data structure or the database design of the server. This goes vice-versa as the developer should also be able to make changes to the data structure or database design server without effecting the application for the client. Next constraint is that REST APIs are stateless and so calls should be independent of one another and that it contains enough data required to complete itself with no errors. It should not rely on data that is stored in the server and should do with the data it is provided in the call. Next constraint is that a REST API should be designed to allow the storage of cacheable data. Essentially, the response needs to indicate that the data can be stored up to certain time limit or in real time it should not be cached by the client.

Uniform interface is the next constraint and it should allow independent upgrades of the application without having the application’s services attached to the API layer itself. This is essential to separate client from sever. A layered system, which is another constraint, is a system composed layers as each layers serves a different purpose or function. This design principle is important in most software as different layers of architecture allows an application that is more scalable. The last constraint is code on demand which allows for code to be transmitted through the API to use within the application. It creates an evolving application that doesn’t only depend on the structure of its own code. Overall, REST APIs are important for web projects and I will certainly use them going forward.

For more information on the topic:

https://www.mulesoft.com/resources/api/what-is-rest-api-design#:~:text=REST%20or%20RESTful%20API%20design,when%20used%20for%20Web%20APIs.&text=REST%20API%20Design%20was%20defined,in%20his%202000%20doctorate%20dissertation.

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.

Blog #4: Rest APIs

For the last month, including the our class’s most recent homework assignment, we have been working on Rest APIs. In the last assignment, we had to construct different Rest API Endpoints. For this blog, I wanted to learn a lot more about Rest APIs and try to master them better. I found a great blog about it all on stackoverflow.blog, and I will attach a link to that blog at the bottom of this post. I definitely recommend checking it out to learn more on this subject like I did. Rest APIs are among some of the most popular available web services that is used to allow clients and browser applications to communicate with a server. These APIs must be designed in a way that keep in mind account security, performance, and easy usability. An important thing for Rest APIs is JSON. Almost all networked technologies can use JSON as it is the standard for transferring data, and it is accepted by Rest APIs for request payloads. A lot of what the blog I read goes over is how to write Rest API Endpoints and coding. It explains the importance of including error handling, filtering, sorting, and nesting resources. It shows even more specifics like how collections should be named using plural nouns rather than verbs. This blog is super great for helping with every single specific when writing these endpoints, even down to the exact code to use for all the different common HTTP errors. It later goes on to explain using cache data to improve performance as well as specifics for versioning APIs. Overall, this blog taught me a lot more about writing these API Endpoints, and the best part is it helped show how it all is done with clear examples of actual code. It even came in helpful during my homework assignment earlier this week. Anyone looking to learn about or brush up on this topic should follow the link to see the blog that I used to research for Rest APIs, and I guarantee it will be extremely educational!

Best practices for REST API design

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 #3: UML Diagrams Cont.

In a previous blog post, I did a little research on UML and ER diagrams, and tried to express how valuable I believe they are in the real world. Today, I plan to dig deeper into the specifics of these diagrams like their formatting and meanings (if one were to look at a finished diagram. There are many specifics for a great UML Class Diagram that help to make it even more useful than simply drawing it out to represent different programs or databases. The example I discussed in my previous post when I referenced this was how the difference between a plus or minus sign before variable names shows how the variable can be public or private (plus being public and minus being private). The next thing I would like to attempt to explain is the importance of how the lines between boxes on the diagram are drawn. Each is specific enough to show exactly what type of relationship is being made between the boxes using arrows, triangles, dashes, strikethroughs, and more. If there is a full line between two boxes then it is a relationship and having a triangle at one or more of the boxes demonstrates that that box or those boxes are providing many things to the relationship. If it has a strikethrough instead, then it is providing one thing (two strikethroughs means one and only one). The boxes can have one-to-one, one-to-many, and many-to-many relationships depending on how the line between them is drawn. These rules apply more toward ER diagrams, but there are many similarities to common UML diagrams. For UML diagrams, we often use open or closed arrows or diamonds at the end of our lines that help indicate the hierarchal relationship between the boxes. Using these symbols, along with changing whether the line is dashed or solid, we can demonstrate inheritance, association, and much more. So we already can see that the format of these diagrams can show more than just the basics, but let me continue to explain even more. Before I continue though, I would like to say that visual-paradigm.com is an extremely useful website that describes all of this even better than I can. I accessed it to help me research these diagrams for two different blog posts now, and I definitely recommend giving it a look. I will leave the link to it at the bottom of this post as usual. Anyways, I want to describe the formatting of the boxes themselves next. This is for UML Class diagrams more than it is for ER diagrams, but it could be applied to both. In general, each box will represent a class in some program (or a table in a SQL database), and they are often separated into three rows. The first row is the name of the class, the second row is for the variables, and the third row is for methods (or functions, operations, etc.). Each variable and method can be public or private as I already discussed, and the methods can include the parameters in the parentheses as well as the return type at the end of the line. There is much more that can be explained, but I would like to end this post by expressing that these diagrams can be made however seems most fit for us. If we do not need to know all of the details of methods and variables, we can simply make our diagram as straight forward as we want by just putting names for the boxes. This is for looking at the diagrams conceptually rather than getting stuck in the details of each class. If we want to show a lot of the class, but not all the nitty-gritty details, we can use the specification approach, which shows details of the classes, but not all. Lastly, if we want our diagram to include all parts of the classes, we can do that as well, and it is called implementation. These are all valuable methods and designs, and it is up to the user to decide what is the best for them.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

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.

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is like climbing a mountain taller than you may have climbed before. It seems so difficult and intimidating but once you are at the top, you realize how the hard part is over and it will now be easier moving forward. You may feel great pressure if your team has a task and they all seem to understand while you have some questions or are unfamiliar with the material. It seems as though exposing to them your ignorance will ruin their confidence in you or hurt your pride. However, exposing your ignorance does just the opposite! Your team members will see that your ability to learn is your strong suit and their confidence in you will be even greater. You will not be a master in one specific field but a master at obtaining skill and knowledge in any field you are presented with.

In my own experience, exposing your ignorance can be a great ice breaker at the beginning of a project. Just because your whole team may seem more knowledgeable than you on the material does not mean that they don’t need a refresher or are just putting on an act of confidence before they do research on their own to catch up. The most direct and fastest route to the knowledge is to ask your team member who has immediate knowledge. Perhaps the situation is vice versa and you have more knowledge than your team, asking revealing questions even if they are just for review can open the conversation for people to expose their ignorance and then learn the fastest way possible. It can be hard to swallow pride and fear judgment but if you remember that the most important thing is the project then your own pride becomes secondary. It is also better to have someone ask the questions they need than to put on an act and slow things down by learning as they go when the time could have been taken to spread knowledge amongst the whole team simultaneously. Now while you still may have to learn as you go after having exposed your ignorance, at least your team is aware and can now take proper steps to aid you until you have obtained the necessary knowledge.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Jumping Off the Deep End

The pattern “The Deep End” is all about taking on challenges and hard tasks to further your progress in learning and avoid plateauing. The pattern also talks about how it will help build your portfolio and give you more experience in different areas and fields of computer science. There is also a risk for this pattern which is that you may feel like you are drowning when you are unable to complete or work on the task because it is too difficult. According to the pattern, you should write down the biggest project you worked on was and the biggest code base you have made and look for projects of similar dimensions and attempt to work on those as well. The best way to grow is to challenge yourself and take on bigger and bigger tasks to both show your progress and what you can achieve. I relate to this pattern since I believe that its the best way to grow and learn when it comes to everything else so it makes sense that it applies here as well. There will always be a ability to fail, but it takes a strong person to look at that possibility and still push forward. I feel that this pattern made me think of how I will be doing a fair amount of work outside of any job that I employed to do because I will want to and need to learn and experience more to grow.
I feel that this pattern is helpful and useful information for anyone in any profession since it can be applied in different ways. The pattern talks about keeping your head above water, but I feel that at times you need to really go down under water to get stronger. I think it’s important to be reasonable with what you can handle, but I don’t think that means you need to be afraid of being really challenged by a task or project that pushes you “under water”. By taking calculated risks and challenges, we can achieve greater heights of what we are able to do. I feel like this pattern pushed me to want to take on greater challenges and work on larger projects to build up my portfolio and learn new things that I will be able to use in future professions/projects.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Find Mentors

For this week “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye I have chosen “Find Mentors”. It talks about finding someone to help you along the journey as a Software Developer, a mentor – a person who can teach or show you the ropes of the profession. The general state of the computer science field is young and therefore there is not many masters present, especially those that can teach us everything so one might have a lot of masters, each for a different part of the field they want to pursue. Important thing is to remember that we are all still learning about this and being a mentor does not mean they know everything.

This particular pattern is something I was a truly fortunate to have gone through in my own career. In my years of work, I have found a person who was willing to help me learn the ropes of the Motion Control field and be patient with me and my constant questions and mistakes. He is an exceptionally good teacher who will always take his time to explain concepts and work required to get things done. What I have found rather useful (and I will probably use this method in the future) is that this pattern does give us some way of potentially finding a mentor or many. It also somewhat prepares us for the possible rejection form potential mentor as unlikely it is and how the benefits can be huge.

What I have found particularly useful in this Pattern is how it tells us to “be tenacious about finding mentors to guide you”. After my own experience with this I think this is a very good advice, I for one know for sure I would not be where I am today in terms of my skills and understanding of the subject if it wasn’t for the help of my mentor. Everyone should find such a person to help them develop their skills, unless one is a genius and does not need any help, it is impossible to know things about a field without someone already experienced helping along the way. I think this cannot be stressed enough: FIND MENTORS!

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Use Your Title

For this week “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye I have chosen “Use Your Title”. It is a pattern, like the title says, about job titles and their meaning and possible impact at your work and professional life. Titles at work are very often paid attention more than they should be or the opposite, not enough. The can very misleading and make someone look more impressive than they are or the again the opposite, they can make someone experienced and impressive look like they are not worth your time. Directly quoting the book: “When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description.”

This pattern is something I have been struggling with most of my professional career. I always have been stuck with titles that are so much less then what I am actually doing or capable of, all simply because I did not have a college degree, even though my experience and track record were exemplary. Again, the book states this perfectly: “the frustration that comes from a lack of recognition should remind you that our industry has a problem.” This pattern is a great showing of how something trivial as a title at work can mean so little in certain circles or it can mean everything on others. I could see this at my work a lot where I was skipped over in an email when my coworkers who had a slightly different title were not. I am sure that this is happening everywhere in the current culture of computer science and software development.

At the same time, I know and so should others that title doesn’t mean much and all that matters are skills and a fair compensation for performed services but very often it is hard to look past the title one has. It can be demanding or just scary to have a title that sounds more impressive than the work one is performing and constantly living with others expecting more from you than you are supposed to do. Titles are the most important useless things one will need at work in my opinion. Problem is many people put more attention on those then they should and that will not change any time soon.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

How to Learn about New Tools

The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.

This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.

The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.

I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.

If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.

I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.

I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.

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.

The Value of Asking Questions

This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.

This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.

To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.

I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.

Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.

I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.

I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.

This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.

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.

Reflection on Independent Study

With this year’s independent study presentation complete and the semester’s coming to a close, I have a project that is working. Naturally, there’s a lot more I wish I could have done. But I’ve learned a lot not only about individual technologies, but also how to plan a large project and schedule tasks.

Setting deadlines for certain portions of the project was helpful, but I did deviate from the schedule a bit in order to get more-important parts done, or prerequisite issues that were unexpectedly necessary. Some flexibility is certainly required when entering into a project without a working knowledge of the technologies at hand.

I love throwing myself into things that I know will be difficult, and that’s kind of what I was going for in this project. Turning big problems into smaller, manageable problems is one of the main reasons I enjoy software. But it’s a balancing act, because I was essentially throwing myself into 3 big problems: Learn signal processing; learn machine learning; implement a mobile application. There were a few weeks of struggling with new technologies for more hours than I had planned, and knowing that I was barely scratching the surface of only one of these big problems caused considerable stress. At times, I thought there would be no way I could get a single portion done, let alone all three.

But somehow each week I got over a new learning hump just in time to implement my goal for the week, while concurrently doing the same for my capstone sprints. Deadlines are a beautiful thing. I did a speech in my public speaking class in my first year that discussed Parkinson’s law, which says work will expand to fill the time available for its completion. This idea has followed me ever since and has proven to be true.

In preparing my presentation in the last couple of weeks, I found a couple of issues and had a couple realizations on how I could do things differently (read: better). I added some of them as I went along, and I was tempted to completely revamp the machine learning model before my presentation. Instead of the inevitable all-nighter it would have required, I managed to restrain myself and save it for the future. But this shows the importance of presenting your work as you go along, as one does in a Scrum work environment. Writing about and reflecting on issues and solutions in a simple way forced me to re-conceptualize things, both in my blog posts as I went through the semester, and in my final presentation.

While I had guidance from my advisor on how to approach and complete the project, planning and implementation was on me. There were definitely pros compared to my capstone’s team project. For example, I knew every change that was made and I had to understand all the working parts. Getting things done was mostly efficient because I only had to coordinate my own tasks. However, in my capstone I was able to bounce ideas off of team members who could provide a different perspective when we both understood the language or framework at hand. Delegating tasks also made it easier to completely understand the subtle details that allows for efficient use of a technology. Both of these experiences taught me transferable skills which I’ll be able to use in the future in solo and team projects.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.