Category Archives: Week 6

REST and RESTful

The article, “REST vs. RESTful: The Difference and Why the Difference Doesn’t Matter,” examines the Representational State Transfer pattern, or REST, and its implementations, RESTful services. The author, Eric Goebelbecker, mentions REST pattern’s creator Roy Fielding, and provides a link to Fielding’s dissertation.

 The article then
defines REST’s architectural constraints. Client-server architectural style,
separating responsibilities between client-side and server-side. Client-side
will handle user interaction while server-side will handle data and state. This
allows for the two sides to evolve independently of each other. Stateless, the
server is not responsible for a client’s session state and instead, the client
keeps the session state. Cacheable, the server must classify their responses as
cacheable or not. This improves performance by allowing the client to store
cacheable responses for later, equal requests. Uniform Interface, possibly the
most important constraint, requires the use of a uniform interface for
components. This simplifies the architecture by taking advantage of the
software principle of generality. The final constraint mentioned in the article
is a layered system. A layered system is a hierarchical system that
encapsulates components to layers that can be independent of each other. This
can be used for security and performance such as load-balancing. These five architecture
constraints are what defines the REST pattern.

The article then gives an example between remote procedures
calls (RPC) and REST. The difference being that RPC manipulate data by remote
calling the server functions and REST, instead, shares the data between
client-server. Put simply, in REST the URIs work with data and not remote
methods.

The article then mentions the Richardson Maturity Model.
Richardson’s model classifies RESTful services into four levels of compliance. Level
0, the use of RPCs. Level 1, sharing resources between server and client. Level
2, the proper use of HTTP verbs. And level 3, exporting hypertext with objects
to aid with API discoverability. The author of the article brings up that Fielding
would only consider level 3 to be true REST.

Before I read through this article, I had only a rudimentary
understanding of the REST pattern (I had missed the class that introduced it).
I now understand REST and RESTful, the architectural pattern and its
implementations. REST focuses on data sharing and a uniform interface to make its
data the emphasis of the pattern and not its specific implementations. This
allows for easier understanding with generality and assists with scalability.

 I read some of
Fielding’s dissertation and highly recommend it to anybody who is learning REST.
The descriptions of the architectural constraints are clear and provide simple
examples.

LINKS:
Article: https://blog.ndepend.com/rest-vs-restful/
Fielding’s Dissertation: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Path of Most Resistance

In my last blog, I sought
to cover Integration Testing and in doing so we covered the two distinct types
outlined by Mr. Fowler. Of these, Broad Integration Testing (BIT to save time)
is most relevant to the next subject I wish to cover: Path Testing. BIT covers
the interactions between all ‘services’ within a program – meaning a program’s
completed modules are tested to ensure that their interactions match
expectations and do not fail some tests created for them. In this way, Path
Testing is very similar but with a focus on how paths through various aspects/modules
of a program, hopefully, work or do not.

           As
opposed to BIT, Path Testing (PT) seeks to identify not just the interactions
between modules, but instead any and all possible paths through an application
– and discover those parts of the application that have no path. The ultimate
goal is to find and test all “linearly independent paths”, which is defined as
a path that covers a partition that has yet to be covered. PT is made up of,
and can integrate, other testing techniques as well, including what we’ve
covered most recently: equivalence testing. Using this technique, paths can be
grouped by their shared functionality into classes, in order to eliminate
repetition in testing.

           When
determining which paths to take, one could be mistaken for wanting to avoid the
same module more than once; as stated previously, we are seeking paths we have
yet to take. However, it is very often that the same path must be taken, at
least initially, which leads to several modules. In fact, a path might be near
or actually identical to one that has come before it, but if it is required
that several values be tested along this path then it as well is considered
distinct as well. An excellent example of this made by the article I chose
states that loops or recursive calls are very often dictated by data, and
necessarily will require multiple test values.

           However, after this point the author begins to move away from the purely conceptual to actual graphs representing these paths, specifically directed graphs. While it was painful to see these again after thinking I had long escaped discrete math, they provide a perfect illustration for the individual modules you expect a path to trace through, as well as possible breaking points. Directed graphs represent tightly coupled conditions, and in this way they express how a program’s run in order and the cause and effect of certain commands upon execution. In this way, it offers a much more concise visual presentation of the testing process as opposed to something like equivalence testing. As well, these graphs are quite self-explanatory but I look forward to applying these concepts in class to actual code.

Sources

Path Testing: The Theory

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Finishing Initial Workflow Testing and Another Story Mapping Session

I began last week on Tuesday by preparing for the workflow story mapping session that would be held the next day. I did this by first quickly exporting all of the VMs I had created to an external SSD that way we could have them on our laptops at the meeting if we wanted to use any of the test accounts in their own environments. I quickly tested importing one of them on my laptop just to make sure this worked which it did very easily. I then finished the GitHub workflow testing as I wanted this done before the next day’s meeting. I ran into another error when I was trying to push commits to the feature branch with a shop developer account. I figured out that this issue was caused by the shop developers accounts’ not having permissions for the test shop repository. By adding the two shop developer accounts to the repository as collaborators and giving them write permissions this fixed the push issues and last week’s issue of not being able to create new branches in the repository. The reason for this problem was because when creating the GitLab group it automatically takes permissions from the group level and automatically applies them to the repositories, so I didn’t realize I needed to do this separately in GitHub. I tested this again in GitLab by creating a new repository to be sure and it does copy the permissions over for individual repositories. GitHub has separate permissions for repositories than organizations (Unlike GitLab) and it needs to be manually set, something that I didn’t do initially. After doing this I could successfully implement the rest of the workflow in GitHub Free and found it worked the same way as GitLab Gold. 

Wednesday was the story mapping meeting. During that meeting Dr. Wurst and Dr. Jackson created the entire story map for the shop-level workflow. I found this to be very helpful as it shows the complete sequence of events from applying to be a shop through developing stories to closing the shop. Even better is that the user roles for each step is marked clearly above each step in the story map. I am sure this will help me immensely in future testing and alleviate the issue of asking which users are responsible for performing which steps of the workflows when I am testing them. I found it was great to observe and participate in another story mapping session and to see how these workflows are developed. After developing this we briefly discussed any remaining questions I had and I was assigned new tasks including how to migrate issues from GitHub to GitLab when importing projects along with moving on to creating documentation for setting up shops and the processes involved. 

Friday I decided to test the original workflow on GitLab Free just to be consistent and make sure it worked on all 3 of the platforms before continuing. I found that it worked exactly like the GitLab Gold testing did and there were no issues with it. Dr. Jackson asked if I had any notes on testing so I then went through my old testing notes for GitLab Gold and GitHub Free and formatted it to be consistent and show which user was performing which step. I posted a link to the Docs file with these onto the issue card on the LFP GitHub. Dr. Wurst invited me to a LFP Discord server he created so I joined this and helped him setup his microphone. Once we got this working we briefly discussed project boards and moving cards and further testing that I would need to do on this going forward with the project / issue boards on the 3 platforms. Finally I figured out how to import issues from GitHub to GitLab. The reason it wasn’t done for the BEAR-Necessities-Market repository earlier was because forking the project first on GitHub removes the issues from the project. I found that if you directly import a GitHub project into GitLab from your own account it copies all of the issues over.

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.

Expose Your Ignorance

Hello my readers and welcome back to my blog. Today I am going to write about another Apprenticeship Pattern called Expose Your Ignorance. I totally agree that it might sounds weird when you hear it but you will change your mind by the end of this blog post.

You have just started working for a company, its your first job and everyone expects a lot from you. You are now a Software Developer and its time to show your skills. Too much pressure I know!!

This chapter of the book talks about how you should not hide what you don’t know as that will make you more ignorant. Everyday of the job and everyday of our life is a learning process for everyone and you don’t make an exception. The authors strongly encourage every software developer out there (especially the inexperienced ones) to expose their ignorance by asking questions. By asking questions you are letting your team know that you want to learn and lower the level of ignorance.

Pride! Ahh pride, this is what holds most of the people back. I totally get it that it’s easier said than done, but you should really leave your pride aside when learning. Yes its true, you can go and do your own research about the matter but that it going to take you a bigger amount of time compared to the situation where you can just ask your teammate or your manager.

If my close friends were to read this blog post would say: “Look who’s talking!”. Yep I got the same issue, I am very afraid to the idea that my teammates will think how inexperienced or ignorant I am so I just keep going on my own and stress myself until I find the answers of my questions. However I have realized that working in a team with a great environment makes it way easier to address to your teammates or manager for questions you might have.

So yeah..long story short: Ask questions about what you don’t know or need to know! But keep in mind to try to shorten the list of the things you don’t know soon. There will be times where the list will get longer than usual and sometimes shorter but as you choose the shortest path to expose your ignorance, you will notice that by the end on the trip you will be an expert. Don’t get discouraged, ASK!

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

Find Mentors

I feel as though this apprenticeship pattern will apply to most of us who is nearing their graduation date. Most of us only have classroom experience when it comes to developing and soon we will be part of something bigger than just us. We will be joining an organization that has big ambitions and aspiration to see those goals to the end. What should we expect? How do we learn to work through our problems? How do we learn at all?

The author suggests seeking out someone who has been in this position before and strive to learn from them. Eventually someone will accept you as an apprentice and you would remain under their supervision throughout the apprenticeship while working towards becoming a master craftsman. Now this ‘master craftsman’ who will accept you as their apprentice does not have to physically be available. It could be someone in an online community; anyone in the field that knows more than you do. The way to do this may be to pick a community that is active and learn from the individuals there.

I actually like this pattern because I feel as though all of us need a mentor when we are in the field to help us progress through our development. I hope to apply this to myself and learn as much as possible.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Sweep The Floor

Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.

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

Learn the basic

Hi everyone and welcome to another CS 448 blog. Today blog is going about study the classics which is one of the apprenticeship patterns by Adewale Oshineye, Dave Hoover. This blog is a simple pattern which helps me understand the importance of learning the basic. This pattern is about constantly updating your knowledge about the field and making sure you have a strong foundation on the field. After reading this apprenticeship patterns I realize that I should ask where the sources of information are coming from when trying to understand a subject from a person. Most of the time when I don’t understand something that is being talked about, I usually just ask the individual to explain the details in more depth but now I understand I should ask the person where they had discovered the information so I can learn it. I think the biggest problem I have with advancing my skills in programming is that I don’t read enough. After reading this pattern I decided I going to make a reading list to further my knowledge in programming. I like how the pattern points out that there a reason why the classic books are kept and are important to learn. This change the way I judge classic textbooks and now I more interested in them. Most of my books are updated so I haven’t look at any old books yet but I disagree with this pattern a little because some of the books like programming books always have to be updated so the classics wouldn’t apply but I can see other books like theory having classic book that can still relate even in today times. All in all, I think this apprenticeship pattern study the classics is important to the pattern because it explains the importance of understanding the classics while using modern tools. After reading this article I learn to read more, and I change my view on reading. I always feel like watching videos and doing projects was enough, but I now realize that you have read more of both classics and modern book to further my knowledge in the programming field.

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

Reflecting on “Apprenticeship Patterns” – The Deep End

Overall, I consider myself a person who tends to enjoy my comfort zone. I appreciate settling into a routine, whether this routine appears in my part-time job or is reflected in my academic projects. But is remaining stagnant the best decision for me, going forward into my career? Probably not, considering that I want to grow in knowledge as I gain more experience in the field. This week’s apprenticeship pattern, called “The Deep End,” provides more insight about how I can nip stagnancy in the bud, so that I can break away from a more comfortable routine and challenge myself further, becoming more confident in myself and my skills at the same time.

The problem that The Deep End aims to solve is one that I’ve started to already describe. As I spend more time in my career, I may become concerned that establishing a more mundane routine (like sticking to familiar projects which keep me in my comfort zone of work) is not the ideal choice if I want to continue to improve my skills.

In order to fix this issue, I need to jump into the deep end. To do this, I should seek out projects or other opportunities that are challenging enough that they are straying away from my comfort zone. I need to also understand that this sudden change to more difficult work can come with risks, including the possibility of failure. This balance of striving to test myself with different, tough tasks, while keeping an eye on my progress so that I am not in over my head, must always be maintained. If the likelihood of “drowning” continues to increase, it is also essential that I have the capability of reeling myself back in and find help if needed.

I completely agree with everything this pattern encompasses. Even though it would be nice for me to remain comfortable with the work I am doing, I know that it is imperative for me to continue tackling difficult problems and projects so that I can remain at the top of my game and keep my skills fresh.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Diving Deep

This series explores Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This week, I decided to read the apprenticeship pattern “The Deep End.” 
To be completely honest, most career opportunities that are on the horizon are somewhat intimidating. I wonder if I have the ability to do a lot of the work they require. The chapter talks about getting into a rut, but my rut is working fast food. Making a transition to a career-oriented position is a big step, and it is a bit out of my comfort zone.
Instead of reluctantly accepting a task that I am not confident about, I should have the self-assurance to jump in at the deep end. This gives me permission to take on a task that might seem daunting when it presents itself. This is easier said than done, and I find it hard to entirely  abandon my initial timidness.
It is important to note that they also warn about getting too far out of your depth. It is okay to jump in the deep end, but “you still need to remember that if the water level is above your head it means you’re drowning.” This is key. They offer two other patterns for helping with this, which is “Finding Mentors” and “Kindred Spirits.” The titles seem descriptive enough to give a general sense of what you might need to look for. Perhaps one of these will be the topic of a future blog post to dive in more in depth.
The action it suggests is to measure the biggest projects I’ve accomplished based on a few factors of complexity. When the next project comes along, see how it compares. It claims this is a good indicator of where my career is heading, and it might be the basis of choices I make.
Already, when thinking of mapping my projects like this, I think to myself, “I need to do more independent projects.” I’ve done quite a bit for school, but I haven’t done anything incredibly ambitious on my own. I have vague goals of what I want to do, but I have done few concrete steps to fulfill them.
Most of my goals for independent projects are somewhat formidable at this point in the game. For example, I would like to make some sort of a web app that I would have to develop full stack. I have a few ideas in mind for what to do.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

MINIX3: Scheduler Research II

I’ve had to change my approach the past week or so with this independent study. When confronted with the source code, I think I began to feel overwhelmed by the amount of concepts I had to dive into. As a result, I attempted to take it from square one and relearn many systems concepts while also working on understanding the scheduler. As it turned out, this was a bit stressful for me. So I have decided to instead look at the relevant source code and, line by line, take notes learn things as they come. Perhaps this is the traditional way to handle diving into a large system of work, but since I don’t have a large amount of experience in large-scale work this is a learning process for me. It seems that this new direction is working a bit better for me.

Let’s start with /minix/servers/sched/main.c. The main() function is the primary function of the scheduler. When a message is passed into the scheduler, the main() function defines variables for the message, system call number, the caller’s number, and the result of the system call. Then, it enters an infinite loop. This loop saves the message’s info in the variables that were defined for it, and then checks for special situations such as system notifications, etc. (I’m not totally positive on the function of that, but it says that the balance_queues() function is called in this event.) Then, based on the call_nr (the system call number), a switch statement determines what call from /sched/schedule.c should be executed next, with functions like do_noquantum() (which executes when a process is out of quantum) and do_start_scheduling() (which seems to start the scheduling of the process). So long as the process is executed correctly, a reply is sent back that communicates success, and the loop continues on to the next kernel message.

So hopefully soon, I’m actually going to start tinkering with the scheduling policy and see what I can come up with. In the scheduling report I discussed in my previous post, it was suggested that with the current interface a Round Robin, Priority Scheduling, Staircase Scheduler, or Rotating Staircase Deadline algorithm can be easily implemented, so I’ll learn one of those and aim for that. I’m sure it’s going to take me longer than just a week to fully implement, but we’ll see what kind of magic I can work. I’m also sure I’m going to have to write a couple more of these research-related blog posts before I fully understand the workings and can proceed forward, but having changed my plan of attack, I’d like to finish those this week. Ready to move forward once again!

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