Category Archives: Week 11

Communication is Key

Over the past week, as we were talking about APIs and working on the backend to web applications, I was wondering about how the front end of these applications actually interacts with the backend software that we were working on. So I looked for something to help aid my understanding of frontend and backend interactions. In doing so, I found a post on vsupalov.com called How Does the Frontend Communicate with the Backend? that covers this area of web design.

While there is little discussion of APIs and their use in this process, I still think it is important to understand how the frontend and backend of a server interact in order to get a complete picture of how web applications work. The post starts off by explaining the basics of how the structure works and the definitions of terms, with the frontend being made of mostly HTML, CSS, and some JavaScript, and being run on the browser, which mostly interprets and renders data received from the backend. The backend receives HTTP requests from the frontend and compiles data to be sent and rendered in the frontend. The post then explains how these two components interact, through the packaging and sending of HTTP requests and responses. These generally are in JSON format, but could just be HTML, images, or any other files or codes. The final part of the post gives examples of how these systems work together to bring about the best possible user experience, by using the speed of the backend running on a host server to process how the user views a site, without having to use the much slower and choppier processing speed of the browser application. These examples include interacting with databases and how sites can render information server-side for SEO or performance reasons.

When I was working on websites, this kind of architecture would have saved me and the company a lot of time, I spent countless hours reducing the size of pictures to improve website performance, all of which could have been saved by using HTTP requests to dynamically load images when they were needed from a backend database. And the role of APIs in this process cannot be understated, facilitating this transfer of information between frontend and backend through properly formatted requests and responses. This gave me a much more clear understanding of how the interactions between the frontend and backend of web applications are processed, and why it is such an important part of proper web design. In the future, I feel that this information will help me have a better grasp of how these systems work, and how to properly utilize them to create better user experiences online.

Source: https://vsupalov.com/how-backend-and-frontend-communicate/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Software Construction Log #6 – Introducing APIs and Representational State Transfer APIs

When the topic of interfaces is brought up, the concept of User Interfaces tends to come to mind more times than not, given how we tend to utilize interfaces to exchange information between an end-user and a computer system by providing an input request and receiving data as an output result. Simply put, we often think of interfaces as the (often visual) medium of interaction between a user and an application. While this is true, such interactions are not limited between end users and applications, as it is possible for other applications to interact with other applications by sending or receiving information to each other to carry out a certain function. Such interface is an Application Programming Interface (API), which is a set of functions used by systems or applications to allow access to certain features of other systems or applications. One such case is the use of social media accounts to log-in to one’s Gitlab account, in this case Gitlab’s API will check if a certain user is logged into a specified social media account and has a valid connection first before allowing access to a Gitlab account. For this blog post, I want to focus on mostly web APIs.

There are, however, three different architecture styles, or protocols, used for writing APIs, therefore there is not once single way of writing the API that an application will use, and different advantages and trade-offs need to be considered when choosing a specific API protocol as the standard for an application. The styles used for writing APIs are the following:
1. Simple Object Access Protocol (SOAP)
2. Remote Procedural Call (RPC)
3. Representational State Transfer (REST)

Among the above protocols, REST seems to be the most widely used style for writing APIs. REST provides the standards constraints utilized for interactions and operations between internet-based computer systems. The APIs of applications that utilize REST are referred to as “RESTful APIs” and tend to utilize HTTP methods, XML for encoding, and JSON to store and transmit data used in an application. Although writing RESTful APIs cannot exactly be considered as programming in the same way writing an application in JAVA is, such APIs still utilize some level of scriptwriting and creating endpoints for an API still utilizes specific syntax when specifying parameters and what values they must contain. One article that I came across when researching tutorials is titled A Beginner’s Tutorial for Understanding RESTful API on MLSDev.Com uses an example in order to show how RESTful architecture design works for RESTful APIs. In this example, the author Vasyl Redka, proceeds to show an example of a response to a request, which HTTP methods and response codes are utilized, along with how Swagger documentation is utilized when writing APIs.

Though RESTful API may be somewhat confusing at first due to how the approach of writing APIs differs to the approach used for writing code, being able to effectively write APIs for web-based applications can be a rather significant skill for web-based application development.

Direct link to the resource referenced in the post: https://mlsdev.com/blog/81-a-beginner-s-tutorial-for-understanding-restful-api

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Data Science who?

What Is Data Science?
First of all, data science is an interdisciplinary field. In this article, we’ll cover the key aspects that you can expect to encounter in a data scientist role. Data science is, in fact, a very broad discipline, which continues to expand with new data-related needs.

Type of data used:
Activities performed on the job
Time allocation
Key skills
Frequently used data science methods

What Types of Data Do Data Scientists Use in Their Analysis?
The answer is: they use both structured and unstructured data. Structured data comes in the form of Excel spreadsheets and CSV files. Examples of such data are client tables and spreadsheets with transaction information. Unstructured data, on the other hand, is everything else: images, video, and audio files, all types of other data we can have. Reportedly, unstructured data represents more than 80% of all enterprise data, so every data scientist worth their salt should be able to take advantage of it.

What Are the Main Data Scientist Responsibilities?
It depends mostly on company size. In larger enterprises, there will be a higher degree of specialization as the company is able to afford more resources. The main activities that a data scientist can perform – but not necessarily does – in a business environment are:

Data collection and storage
Data preprocessing (also referred to as data cleaning)
Data organization
Data visualization and the creation of KPI dashboards
Experimentation and A/B testing
Statistical inference
Building ML models
Evaluating ML models
Deploying ML models
And Monitoring how ML models perform

Which Data Science Tasks Take Up the Most Time?
Ask anyone in the industry and you will hear the same answer. They’ll tell you they spend 80% of the time in an effort to make a hypothesis, find the necessary data, and clean it. Only 20% of the useful hours are dedicated to performing analysis and interpreting the findings.

What are the Key Data Scientist Skills?
There are many abilities that you should have in order to become a skilled data scientist. Some of the most frequently used data science techniques are:

Statistical inference.
Linear regression.
Logistic regression.
Machine Learning techniques such as decision trees, support vector machines, clustering, dimensionality reduction.
Deep Learning methods – supervised, unsupervised, and reinforcement learning.
Regardless of the method, a data scientist’s end goal would be to make a meaningful contribution to the business – to create value for the company.

How Does Data Science Make a Meaningful Contribution to the Business?
We can distinguish among two main ways to do that. First, help a company make better decisions when it comes to their customers and employees. We hope you enjoyed this article and learned something new. Now that you have a basic understanding of the field of data science, you might be wondering where to start your learning journey. Our Introduction to Data Science course offers a beginner-friendly overview of the entire field of data science and all its complexities.

https://365datascience.com/trending/data-science-explained-in-5-minutes/

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language (UML)

For this week’s blog post I have found a blog on Unified Modeling Language (UML). UML is an object-oriented modeling language. This has become a normal standard for documentation of a software system. It is a pictorial description of classes, objects, and relationships. It represents a plan that defines the working hardware or software system. For example, we can use a UML diagram to show what is going on in a three-class software system. For this example, the names of the three classes will be Student, Classroom, and Teacher. For each class, a box is used in UML to show the entire class with three lines separating class name, methods, and instance variables. Each variable is listed as the variable type and name separated by a colon (for example, String : Id). While the methods are listed as method name with parameters (if any) and the return variable type (if any) separated by a colon (for example, getId() : String) Now if we wanted to show that the class named Class borrows objects from the student class, we would draw a arrow pointing from student to Class. If we wanted to show that it extends the class, we would draw a dotted arrow instead.

UML was designed and created back in the 90’s. This was a period where object-oriented languages (OOL) such as C++ were being used to build complex but compelling systems. The issue during this time was that we had complex systems but no good way of showing on paper what the system is doing. This was until in 1994 when software engineers Grady Booch, Ivar Jacobson, and James Rumbaugh of Rational Software created the UML language. This development of the language was finished two years later in 1996. Each of the designers came together to find a language they will reduce the complexity. According to Study Section, the website with the blog, they say on their process of reducing this complexity, “Booch’s method was flexible to work with throughout the design and creation of objects. Jacobson’s method contributed a great way to work on use-cases. It further has a great approach for high-level design. Rumbaugh’s method turned out to be useful while handling sensitive systems. Behavioral models and state-charts were added in the UML by David Harel.” (Study Section) In 1997, the Object Management Group (OMG) acknowledged UML as a normal language. They now are responsible for maintaining the UML language and updating with new languages that come out.

History Of Unified Modeling Language (UML)

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Benefits of Recording What You Learn

Oftentimes when doing something repeatedly, whether that be some sort of skill or action which needs to be learned over time, it can become sort of “mindless” as you gain familiarity with the subject. So even as you become familiar with the idea or concept, you no longer think about doing it even as you practice or utilize it more and more often. Because of this, some ideas can feel like they are more “drilled” than actually understood and comprehended, losing the sort of comprehensive fundamental knowledge that would come from a more complete understanding. If you just learn something to use as part of a larger project or system, then it can be very easy to develop an incomplete perception of the concept, and this is an area where I found the pattern “Record What You Learn” to be relevant.

Discussed in chapter 5 of Apprenticeship Patterns, https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s06.html, the concept of “Record What You Learn” is concerned with the idea of writing down or ideas, techniques and technologies/skills which you might use throughout the course of projects or development periods. Relative to software development, sometimes an application can be made up of many smaller pieces or technologies (ie: a web-application consisting of Vue.js, Express.js, REST-API, MongoDB, running in Docker) which you might need to become familiar and competent with during development quickly. However, needing to learn about many different technologies at once can leave gaps in your overall understanding, and you might end up needing to reference manuals or guides often.

The benefit of writing these things down becomes apparent when you can look back to your own notes or documentation and reference them in the future, and as opposed to simply looking into the documentation written by the maintainers or developers of the tool in question, your own personal notes will likely contain useful context and explanation which could be lacking from standard syntax guides or official websites. Maybe you find a way to save time working in C++, when you write that time-saving measure down it becomes far easier to repeat in the future.

If you constantly reference your own notes it helps to reinforce those ideas more than referencing something written by an external source because you are rereading your own thoughts and ideas relative to the concept. I have recorded notes for things I have been learning in the past (HTML/CSS and web-development, Java, C#) and I think that it makes a difference to have your own notes with added context. The connection to your thought process and ideas helps the concepts sink-in, and writing them down makes you think about them more than you might otherwise.

Book Referenced:

https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s06.html

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

Sweep The Floor

“Sweep the Floor” is perhaps an Apprenticeship Pattern that I’ve seen most closely paralleled in the real world. The pattern proposes that the price of admission onto a team may be that the newly crested member start by doing the unglamorous jobs —hence the title of the pattern—, often this will be things such as differed maintenance or writing reports. This is manyfold: it proves capability, builds trust that you can work independently, allows for controlled and low-stakes contribution to the project, and will free up the more vested members’ time to teach you higher stakes tasks.

As I alluded to, this ritualistic humbling seems to be inevitable in any profession, particularly in what gets oft classified as skilled-work. When I was a mail processing mechanic, the first thing we new recruits were delegated was daily maintenance tasks such as changing rubber belts on a feeder assembly, or changing drive belts that were in the lower tiers of the mail processing machines; the latter considered the most uncomfortable —sometimes downright painful— task to work on. While I don’t suspect that updating documentation or eliminating technical debt will be nearly as dirty as being covered in paper shreddings and ink dust I felt this quote in particular was a very powerful way to bind the metaphor of back to software development:

“These sorts of fringe tasks benefit the team, but they will also benefit you as an apprentice, because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. This experience will serve you well as a journeyman too, because any master who takes you on will understand how valuable it is to have someone to do the unglamorous work. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.”

The authors made sure to mention my primary criticism of this learning style which is what they have called becoming the team’s gopher. If it were not apparent, a quick definition of a gopher is one who has become known to absorb the menial or painful work and thus gets typecast into that roll permanently, condemned to the strictly utility work which creates a lag on your understanding of current developments in the code base and hurt your chances of upward mobility. The authors’ prescription is relentlessly advocate for yourself, Nurture Your Passion, and Unleash Your Enthusiasm.

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.

The Tortoise Always Wins

“How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

—George Leonard, Mastery

While reading chapter 3 of Apprenticeship Patterns, I stumbled upon the preceding quote. It resonated with me because I often get so caught up in aiming for perfection that progress becomes halted. Anything worth doing is worth doing poorly. I have heard it said that perfection is the enemy of progress.

This chapter focuses on the long road we all must travel to master our craft. The author talks about how we have all grown to desire immediate gratification, whether that be in notoriety, wealth, or the development of our skill. If we desire to become true craftsmen we must focus our attention on delayed gratification. Our skills will take time to develop, and the journey will be a test in endurance and patience. The problem presented in the text is of being stuck in a “golden lock” where our aim for further crafting our skill is at odds with our desire for a higher paying job. By taking the path less traveled “Robert frost” we can make all the difference in our development as craftsmen.

We must be patient and compassionate with ourselves along our journey. It is easy to get discouraged when we see how little we know in comparison to veteran developers or even peers. So long as we strive to continuously hone our craft, we can become the masters that future generations of craftsmen look up to. The long road means we do not grow into incredible craftsmen overnight. It takes long hours and is a slow process.

When we take our time to mindfully develop code, asking questions about why and how code behaves the way it does, or why we approach problems a certain way, we deepen our understanding of not only the development process but our strategies for everyday living. We learn better problem-solving skills, we become more inquisitive into ways to efficiently meet the needs of ourselves, our families, and our communities. This is something I have struggled with as a CS major, trying to balance out good grades with deeper comprehension. Many students fall into the trap of just learning the information required to pass the class with a good grade, putting ourselves at a disadvantage. Our lives have only a finite amount of time, and sometimes we need to decide whether we should slow down and take time to comprehend the deeper truths of software development, even though it may take away from time available for studying the class materials.

If we desire to become true craftsmen rather than just working a 9-5 grind we need to recognize that the path we chose is neither easy nor short. Our field is growing exponentially with the constantly changing technological advances we are experiencing and will continue to experience. This path is not as straight and narrow as other fields, due to the continuous changing of technology. However, if we slow down and dig deeper asking the questions that lead to deeper understanding, we will see the commonalities that all software share, making it easy to adapt to the changing of software development. Traveling “The Long Road” can allow us to bring meaning and pride to our work rather than being another nameless cog in the machine for a corporation.

The tortoise always wins the race.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Record What You Learn

For this week’s blog post, I read the section “Record What You Learn” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section started with a quote by Atul Gawnde in which it states: “You should not also underestimate the power of writing itself….You can lose your larger sense of purpose. But writing lets you step back and think through a problem” This reminds me a lot of myself because I am usually the one that never writes anything down, Instead I will believe that I can remember it. However, later I forget it. As I get older, I realize that recording something is useful, for example, if we are doing a project sometimes it is a good idea to draw diagrams and analyze through writing which helps to organize and plan it out. The section mainly talked about the practice of keeping a diary or a journal that will be useful throughout your career. The author also mentioned avoiding falling into the trap of just writing down your lesson and forgetting them, which I have done several times.

Keeping a journal of what you learned and going back to read it regularly will help you review the materials and give you a vital resource to draw upon. I read in an article that Psychology research and learning experts suggest writing things down leads to better learning. When I think about it, it is quite true at least for me I learned better by writing the materials down. Another interesting insight I read on the section was “By reviewing your journal, you can switch your past and your present around to generate your future” This is such an amazing quote and I hope that from now on I can keep a journal and look back at the things I have recorded. This pattern changed the way I think, it has given me new insights and inspires me to start jotting down my thoughts. I hope Over time these entries help to write an article or even a book regarding the journey of my life.

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

Expose Your Ignorance – Apprenticeship Pattern

This apprenticeship pattern is called expose your ignorance and the name for it is kind of straight forward but it is an important matter for a software craftsman. Often times there are many things that a software craftsman does not know and the goal is to find out the things they don’t know and learn about. They need to gain more experience with the new technology and not be shy about learning. Exposing your ignorance means being able to put your ego aside and write down things that you currently aren’t capable of doing so you can move forward and learn about them. Also when working with teams, it is important to communicate to your client or product owner that the work you are doing requires a learning process and don’t just tell them you know what the technology is already. This way you will build stronger relationships over time. The goal is to find a balance between not knowing a certain thing and being able to learn it.

I think this pattern is important for software craftsmen because often times people will become certain and expert with a certain technology and want to only stay on that path. They aren’t willing to navigate in other directions but become more experts in that field. However, for craftsmen we need to keep on being interested in the journey and learn more things that we are ignorant about. The goal is to be able to learn things and as the journey goes along, you will be able to master things but it shouldn’t be the end goal. The people who are experts are aiming to be masters at the technology and learn the most they can about it because that’s their end goal and it is not about overall learning for them. This is why craftsmen need to expose their ignorance and find out things that they aren’t currently able to do. Then the next step is to figure out how to learn it and create a learning guide that will work for them. Overall, this is an important pattern for craftsmen to improve their knowledge.

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.

Apprenticeship Pattern – Nurture Your Passion

The key focus of this pattern is founded in the all too familiar scenario where you fundamentally enjoy the subject matter you are surrounded by at your work; however, the work itself gets in the way of your passion for the subject. An example of this would be suppose you are really passionate about software design and you enjoy taking your time making a solid product using good code. While that is your passion, and rightfully so, you may find your job is more concerned about functionality and speed. They might prefer you create shoddy code in a quick amount of time that works, rather than doing the job properly. As you might imagine, if your goal was to be employed to create solid code the way you always have, this might hurt your motivation.

The proposed solution to this predicament is to search around at your work and find something that properly interests you. Involve yourself in it and put in as much time towards it as possible. Outside of work, do the same. Find and work on interesting things that satiate your passion. I would continue the prior example to demonstrate how the solution works, except that its a pretty good example for why it doesn’t. I’m sure that in the right situation, the proposed solutions are good options. In situations such as above, however, it isn’t really possible to change what you do at work to better suit your passion. If you already work in software for the company, and the software isn’t up to your standard, where in the company can you go that is up to your standard?

Many companies have a fixed structure. Often, if you attempt to either move yourself around or change the structure itself, it is easier for the company to simply let you go and find someone else. That’s one of many problems that come from jobs being rare and workers being abundant. If jobs had to compete with one another for workers, overall conditions for workers would improve. As a quick aside: in my opinion, if the government weren’t trying its hardest to support major corporations (due to being bought out by them) and got rid of regulation that solely hurts small businesses, maybe in a more free-market economy where almost anyone can start up a company jobs could be abundant and would have to compete for workers. Speaking of idealistic views that might not actually stand up in real life, a second component to the proposed solution is to work on personal projects in your free time.

This is similarly not a valid option for many situations. Often, people simply do not have the time to work a full-time job and fulfill other responsibilities. Bringing up my example once again, you can work on quality software all week long in your free time, but writing code you know is bad and that you know could be better with just a little bit more time will always drain on you. Sometimes and for some people, it can be pretty easy to work on something you don’t enjoy. It can be easy to create something worthless and bad, but it depends on the situation and, more so, the person in particular. I personally find it extremely hard to work on things I don’t care about; even if I just have to do it badly.

It can be hard to have a strong passion for something and then have other people not allow you to do it. It isn’t even a matter of them letting you do it; it would be enough for them to do nothing. But often times, they directly work to oppose what your soul wants you to do. That said, you can’t just vilify them for it. You ended up in a bad situation but in the previous example, for instance, you wouldn’t be stuck. Maybe you misunderstood what they want or maybe they misled you. But if it’s a matter of your soul, so to speak, you can always leave the job. It isn’t always that simple; we have responsibilities and bills to pay. That’s why I personally believe that if you have the opportunity, build up your savings and investments. Sacrifice some of your standard of living now so you can afford to make a change like this in the future. Do your best to prevent yourself from getting trapped in life.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: