Category Archives: Week 13

A Very Small Introduction to JavaScript

Since we’ve been using JavaScript for the past several weeks in class and in homework, I thought it would be beneficial to help run through some elements of JavaScript I found weird or difficult at first. I’ve noticed some people have a harder time understanding JavaScript’s syntax or how its variables work, so I wanted to make this as a sort of reference.

Types

JavaScript contains primitive and non-primitive types. A variable can be declared with “var”, “let”, or “const”, more on const later. The main primitive types are1:

  • Boolean: true, false
  • Null: null
  • Undefined
  • Number: 72, -174.21
  • String: “Hello, ”, ‘world’

For an object type, objects are very loose and can for the most part be defined with relative ease. 

Let’s take a simple object, named “car”.

This object has three properties, wheels, year, and color. When declaring or assigning properties, the syntax shifts from the typical use of “var num =”, to “num: ”. These properties in an object are pairs: “wheels” and “4” are a pair, specifically a key-value pair as well as an object. This means that there is more than one way to access an object’s properties. 

The second one looks suspiciously similar to a map, specifically one in C++. Objects may be iterated through using a for-loop directly.

Functions

Functions may be defined in a few ways. If inside of an object, the function would be defined as:

Else, it may be defined as the following:

The bottom function declaration is known as arrow notation. A function with arrow notation is not bound to an inherited constructor or the keyword “this”, and its usage with scopes may be troublesome. Its parentheses may be dropped if there does not exist any parameters, such as “getProps => {}”2.

JSDoc

JSDoc is a markup language used to comment JavaScript code, and is similar to JSDoc in many ways. JSDoc may be created by typing “/**”, then pressing enter upon this pop up:

JSDoc is, in my opinion, very useful in declaring classes, functions, objects, types, or declaring types. This is especially important with JavaScript, since types are handled dynamically.

JSDocs can use the following my pressing “@” inside of the comment, revealing a large list of descriptors, with users being able to make any and anytime3:

Upon creating a simple JSDoc annotation:

Hovering over the object “car” will read:

For our function getValue:

This is rendered as: 

Hopefully, this post can be helpful. JavaScript was odd for me when I first started, with these topics being some of the things that took me a while to get used to. The sources contain a wealth of information that I have and will continue to refer to and learn from, and hopefully they can help you too.

Links:

  1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures (Types)
  2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions (Arrow Functions)
  3. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html (JSDoc)

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

DRY PRINCIPLES

The DRY meaning “Don’t repeat yourself” principle is a best practice in software development that recommends software engineers to do something once, and only once. The concept, which is often credited to Andrew Hunt and David Thomas, authors of “The Pragmatic Programmer”, is the tongue-in-cheek opposite of the WET principle, which stands for “write everything twice”.

According to the DRY principle, every discrete chunk of knowledge should have one, unambiguous, authoritative within a system. The goal of the DRY principles is to lower technical best by eliminating redundancies in process and logic whenever possible.

Redundancies in logic

To prevent redundancies in logic (code), followers of the DRY principle use abstraction to minimize repetition. Abstraction is the process of removing characteristics until only the most essential characteristics remain.

Redundancies in process

To prevent redundancies in processes (actions required to achieve a result), followers of the DRY principle seek to ensure that there is only one way to complete a particular process. Automating the steps wherever possible also reduces redundancy, as well as the number of actions required to complete a task.

An important goal of the DRY principle is to improve the maintainability of code during all phases of its lifecycle. When the DRY principle is followed, for example, a software developer should be able to change code in one place and have the change automatically applied to every instance of the code in question.

As programmers, we collect, organize, maintain, and harness knowledge. We document knowledge in specifications, we make it come alive in running code, and we use it to provide the checks needed during testing.

Violations of DRY

“We enjoy typing” (or, “Wasting everyone’s time”.): “We enjoy typing”, means writing the same code or logic again and again. It will be difficult to manage the code and if the logic changes, then we have to make changes in all the places where we have written the code, thereby wasting everyone’s time.

How to Avoid DRY

To avoid violating the DRY principle, divide your system into pieces. Divide your code and logic into smaller reusable units and use that code by calling it where you want. Don’t write lengthy methods, but divide logic and try to use the existing piece in your method.

DRY Benefits

Less code is good: It saves time and effort, is easy to maintain, and also reduces the chances of bugs. One good example of the DRY principle is the helper class in enterprise libraries, in which every piece of code is unique in the libraries and helper classes. I chose this topic because as a programmer, it is always important to know why design principles are useful for us, what and how to implement them in our programming.

Software Design Principles DRY and KISS – DZone Java

The DRY Principle: Benefits and Costs with Examples (thevaluable.dev)

What is DRY principle? – Definition from WhatIs.com (techtarget.com)

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Week 13: Why You Need a CSS Developer

https://www.toptal.com/css/why-you-need-a-css-developer

Keeping in line with my front-end blog posts, I wanted to read another blog post on front-end stuff so I decided to pick this blog post from toptal.com on CSS developers. I also decided to choose this blog post because I think CSS is the first programming language I was aware of, I only knew that it was part of web design but I was always confused looking at it’s syntax. In this blog post from Silvestar Bistrović, he runs over what CSS developers do and why we need one.

He introduces the reader with CSS developers and what they are. They’re web professionals whose primary responsibility is to deliver a polished and styled product to the visitor’s browser. Practically every website uses CSS, but CSS is often not considered an “equal” in the modern web development stack. This has led to CSS being taken for granted, sometimes even overlooked. He then goes on to explain why CSS developers are a necessary good and to have a dedicated CSS developer instead of someone who isn’t.

The blog post is sectioned into 3 sections: What Do CSS Developers Do, Why Do You Need a CSS Developer, and Wrapping Up with every section having subsections explaining further on the section. What Do CSS Developers Do covers what they do, CSS tools, techniques, and principles, CSS, the fact Javascript is everywhere, and that writing tidy HTML always matters. Why Do You Need a CSS Developer covers CSS coding standards, CSS design implementation, organizing your CSS code, CSS code in production, and what CSS developers can do for you. Wrapping Up is self explanatory, it’s a conclusion.

As mentioned earlier, CSS was the first programming language I stumbled upon. I stumbled upon it as a kid playing online games and trying to customize my profiles for sites. I didn’t know what it was at the time and just took CSS code from others and used that to format my profile for those online games. It wasn’t until now that I would stumble upon it again in class during In-class activity 15-16 and realize how important it actually is. CSS is one of the forefronts of frontend design and that was something I didn’t know until now because I haven’t dipped my toes in web dev stuff yet. At first I thought front-end web developers were supposed to be jack of all trades for front-end development but after reading this I think having someone who specializes in CSS is essential to your team and as the author says, “do you want to leave your product in the hands of a specialized professional that could polish it to perfection, or would you settle for good enough?”

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

API Design – Getting Started—Alen Pokos

The speaker in this podcast is Alen Pokos, a deputy chief technology officer at Trikodor, a software development company specializing in UX (user experience) and natural language processing for computers, think Siri/Cortana. He spends this hour discussing API design and ideas on how to approach designing web APIs as well as giving personal accounts of his time in the industry and the solutions for common problems he’s encountered.

He begins the presentation defining API as something that enables applications to communicate with one another, it should reflect the goals of the business it is designed to serve, as well as giving a brief description of REST. Pokos goes on to explain common scenarios where Web APIs are usually built; being for other web servers or client consumers such as a web browser or mobile application.

The topic covered in the video that I found most compelling, and really where a lot of the value I gleaned was, was API design. This is primarily what his company presents itself as being experts in. He very poignantly states that “When people disagree on design, it is often they do not agree on the goals.” I’ve run into this situation when designing other things, be it in woodworking, Information Security, Hardware deployment, you name it. It’s something that should really be agreed upon before a project begins which is why software process management strategies all have some form of a task list where goals of development are clearly stated and agreed upon prior to actual development. It is important that before you decide on how a project accomplishes its task, you know what the task is.

I chose this episode because we are currently studying API, frontend, and backend development for the Libre Food Pantry. Understanding the context of what we’re doing and how it may relate to the industry is important for maintaining a firm perspective of how I could potentially translate the skills I’m cultivating into a professional workplace.

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

To-may-to : To-mah-to; Po-tay-to : Po-tah-to ; Framework : Library?

At the end of my previous blog post, I incorrectly referred to React.js as a framework. It is actually a JavaScript library. Although the two can be used to achieve a common goal, the two terms are not exactly interchangeable. Allow me to use the following analogy to explain my understanding of the two.

The main difference is when you’re using a library, you’re asking for it to assist you with completing your code. Frameworks on the other hand can be used to write your code but require you to “relinquish ownership” and abide by its rules. To discern the two, let’s look at the code to be written in terms of sharing information with one another. 

Scenario A.

You’re browsing StackOverflow and you come across a user who is asking a question about how to use various functions/methods in a particular programming language. You, being a well-seasoned programmer and active user in the StackOverflow community, wish to give this user a bit of assistance. So you decide to do some research on said programming language and functions/methods. Once you’ve gotten a firm understanding of the concepts, you give a friendly and in-depth response to the user, which helps to solve their problem. 

Scenario B. 

You’ve been assigned to write a paper explaining how to use various functions/methods in a particular programming language by your professor. They require the paper to be written in an accepted formatting style (MLA/APA) of your choosing. You, being a top student of your class, do some research to produce a high quality paper that reflects your standing. As you write your paper, to adhere with formatting guidelines, you use in-text citations. Once your paper has been completed you also cite your sources on your works cited page. Your professor gives you perfect marks on your paper due to the accuracy and proper formatting of your paper. 

In both of these scenarios, we were able to relay the information (write our code) in different ways. While the method of finding the information was roughly the same the end product is what differed. 

In scenario A the user was able to answer the question in any manner that suited their needs with no restriction. In scenario B, however, the student was not granted the same leisure and was required to structure their response according to a specific set of guidelines. Scenario A represents the usage of a library in your code, while scenario B represents the use of a framework. While the tools used were essentially the same, the control over the end product was not. The correlation to be made here is the control over the code that highlights one of the main differences between how libraries and frameworks operate.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Week 13: 9 Best Practices for Optimizing Frontend Performance

https://blog.bitsrc.io/9-best-practices-for-optimizing-frontend-loading-time-763211621061

So last week I wrote a blog post on good practices for REST API design so naturally I had to follow it up with a blog post on good practices to follow on optimizing frontend performance since we’re working with frontend stuff this week.

This week’s blog post is about a blog post from bitsrc.io from Nethmi Wijesinghe titled “9 Best Practices for Optimizing Frontend Performance.” In this blog post, she writes about 9 best practices that will be useful to the reader to optimize frontend data loading. The 9 best practices she lists are: minify resources, reduce the number of server calls, remove unnecessary custom fonts, compress files, optimize images, apply lazy loading, caching, enable prefetching, and use a content delivery network.

To summarize the 9 practices:

  1. Minify Resources: remove unnecessary, redundant data from your HTML, CSS, and JavaScript that are not required to load, such as code comments and formatting, etc.
  2. Reduce the Number of Server Calls: More calls to server, more time to load. 3 ways to reduce the number of server calls include: using CSS sprites, reducing third party plugins, and preventing broken links.
  3. Remove Unnecessary Custom Fonts: Self explanatory, but also you can take these 3 actions when using fonts on your website like, converting fonts to most efficient format, subset fonts to remove unused characters, and preloading fonts explicitly required.
  4. Compress Files: Compress files to save loading time since larger files = longer loading time.
  5. Optimize the Images: Images improve user engagement but make sure they are optimized to save loading time.
  6. Apply Lazy Loading: Lazy loading allows web page to load required content first and then remaining content if needed
  7. Caching: Allow caching so browsers can store the files from your website in their local cache and avoid loading same assets when revisiting
  8. Enable Prefetching: Prefetching loads the resource in anticipation of their need to reduce the waiting time of the resource.
  9. Use a Content Delivery Network: Using a CDN (group of servers distributed across several geographical locations that store a cached version of the content to deliver fast to the end-user) allows you to optimize loading time as well.

I picked out this blog post because we were using frontend in class during Activity 15-16 and I wanted to follow up with practices to optimize your frontend. This was one I found that was interesting but also introduced new terminology to me. Things like lazy loading, prefetching, and CDNs I didn’t know about until this reading this post. Also, I haven’t had any web dev experience prior to this class and doing the in class activities made me more interested because it was something new to me I had never touched. I knew web dev things existed I just never knew how complex it can actually get and it’s actually made me more interested in possibly pursuing a web dev position instead.

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

Refactoring

Hello everyone, hope you are all doing well. As this is the final week, I would like to wish you all Goodluck with your finals. In this week’s blog, I would like to talk about Refactoring as it is one of the important parts of programming. Refactoring is a process of restructuring code while making sure it does not change the original functionality of the code. The main goal of refactoring is to improve internal code by making small changes without altering the code’s external behavior.

Computer programmers and software developers refactor codes to improve the design, structure, and implementation of software. Refactoring improves code readability and reduces complexities. It also helps software developers find bugs or vulnerabilities hidden in their software. Refactoring improves codes by making them more efficient by addressing dependencies and complexities, becomes more maintainable and reusable by increasing efficiency, makes the code cleaner which then makes the whole code easier to read and understand, these are a few purposes of refactoring.

Refactoring can be performed after a product has been released, this should be done before adding updates and new features to the existing code or it should be done as a part of day-to-day programming. There are several benefits of refactoring like it makes the code easier to read, encourages a more in-depth understanding of code, improves maintainability. It also comes with various challenges like this process will take extra time if the development team is in the rush to finish the product and refactoring is not planned for, without clear objectives refactoring can lead to delays and extra work, Refactoring cannot address software flaws by itself, as it is made to clean code and make it less complex. There is various technique to refactor the code some of the examples include moving features between objects, Extracting, refactoring by abstraction, and composing. The best practices to follow for refactoring include Planning for refactoring when a project starts, Developers should refactor first before adding updates, refactor in small steps, Test often while refactoring, fix software defects separately, Understand the code before refactoring, focus on code deduplication, use of Automation tools make refactoring easier and faster.

I choose this article because it has a clear definition of refactoring and purpose of refactoring, benefits of it, explains different techniques to perform code refactoring, and gives best practices to follow for refactoring and since it is very helpful for software engineers, in the future these practices will help me do my job easier and help me do my job in an effective way.

Article: https://searchapparchitecture.techtarget.com/definition/refactoring

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

Solo Project Management Using Government-Grade Advice

https://derisking-guide.18f.gov/state-field-guide/basic-principles/

Something I struggle with quite a bit is directing my personal software projects. Staying committed, composing large pieces of code with each other correctly, and even figuring out what I want to do in the first place are all things that I just sort of play by ear, with limited success. In an attempt to gain some insight, I found this article published by a technology and design consultancy for the US government, directed at non-technical project managers. The gist of it is that these managers must understand six concepts: user-centered design, Agile software development, DevOps, building with loosely coupled parts, modular contracting, and product ownership. I won’t go into all of these, since some are still more technical than others, but I want to highlight a few.

One of my favorite points in the article is something that I’ve believed for a long time, which is that all development should be centered on the needs of the end user, rather than stakeholders. Project risk is reduced by ensuring the software is solving actual problems for actual people, and the problems are identified via research tactics like interviews and testing for usability. It would be kind of silly to interview myself, but I think this is a good mindset to have. It kind of sounds meaningless when stated so directly, but if you want a product you have to focus on creating the product, rather than daydreaming about every possible feature it could have.

Another point I liked was the discussion of Agile software development. Without getting too into the weeds on details, the basic problem it seeks to solve is that detailed, long term plans for major custom software projects generally become incorrect as the project proceeds and new technical considerations are discovered. To combat this, agile developers plan in broad strokes, filling in details only as necessary. In a way, it kind of reminds me of an analogy I heard once to describe Turing machines – an artist at their desk, first drawing a broad outline and then focusing on specific sections and filling in details (it may or may not be obvious how this is related to Turing machines but that’s not relevant). The primary metric is how fast documented and tested functionality is delivered.

I found two other somewhat related points useful as well, both of which deal with modularity. The first is the idea of “building with loosely coupled parts”, which essentially boils down to the idea that if one agile team is in over their head, they should split the work into two or more distinct products each with its own dedicated team. Modular contracting is just applying this concept before even beginning a project. Together, I think this a helpful way of possibly connecting all the small fleeting app ideas I have – rather than one unfocused monolith, I could work on a small ecosystem with a shared API that I add and remove things from as needed.

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

API calls

We know api but how are they called?

The Uniform Resource Identifier (URI) of the server or external software whose data you desire is the first thing you need to know when making an API request.
This is essentially a digital version of a street address.
You won’t know where to send your request if you don’t have this. For example, the HubSpot API’s URI is https://api.wordpress.com. It’s worth noting that most APIs have several endpoints, each with its own set of end routes. Consider the case when you want to stream public tweets in real time. Then you could utilize the filtered stream endpoint on Twitter. The base path is https://api.twitter.com, which is shared by all endpoints.
/2/tweets/search/stream is the filtered stream endpoint. You can either add that to the end of the base path, or just list the endpoint in your request.

Add an http verb

Once you’ve got the URI, you’ll need to figure out how to make the request. The first thing you must include is a verb that expresses a request. The following are the four most fundamental request verbs: To retrieve a resource, use the GET command. To make a new resource, use the POST command. To alter or update an existing resource, use the PUT command. TO DELETE A RESOURCE, USE THE DELETE KEY. Let’s say you want to see a list of the nearest alternative fuel stations in Denver, Colorado, and you use NREL’s Alternative Fuel Station API. Then you’d make a GET request that looked something like this:

GET https://developer.nrel.gov/api/alt-fuel-stations/v1/nearest.json?api key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This instructs the server to look for a list of alternative fuel stations in Denver in the database. If that list exists, the server will return an XML or JSON copy of the resource along with a 200 HTTP response code (OK). If that list doesn’t, then it will send back the HTTP response code 404 (not found).

Test API calls

Making API calls to various endpoints, receiving responses, and validating the status codes, response times, and data in those answers are all part of API testing. ReqBin, for example, is a software tool or web service that does this type of testing. Although the processes are similar, they will differ depending on whatever tool or service you use. The steps for utilizing ReqBin to test an API are listed below. Enter the URL of the API endpoint. Select the appropriate HTTP method like GET POST etc., Enter your credentials in the Authorization tab, Click Send to submit your API request.

Why this topic?

I chose this topic since it was the subject of a school assignment.
I followed the directions in the readme file you provided, but I wanted to learn more about why we use the GET method and why we use the POST method in which situations.
Overall, this topic piqued my interest, and I believe it is critical knowledge for all students aspiring to be software developers.

Link: https://blog.hubspot.com/website/api-calls

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Encapsulate What Varies

When we write code, we try to think ahead to what possible changes we may need to implement in the future. There are many ways that we can implement these changes, ranging from slapping together a quick patch, methodically going through the code and changing all the affected parts, or writing the code in such a way that anticipated changes can be added in with just one or two small adjustments. This last method is what “encapsulate what varies” means. Writing code will often cause us to think about what future changes we need, and by isolating those parts of the code we can save ourselves time in the future. I found an article that does a good job explaining this concept, and while reading through it I was reminded of a recent project where using encapsulation ended up saving me a lot of time and headaches in the future.

The specific event that the article caused me to remember occurred during my most recent internship. One of the projects I worked on was a script that would automatically assemble 3D CAD models of of any of the systems the company was working on at the time. This script needed to read the system specifications from a database and then organize that data, identify key parts of the system, and figure out how it is assembled so that it can then send those instructions to the CAD software and create the 3D model. It was a big project, and I and the other intern working on it were daunted by the amount of ever changing data that would need to be accounted for. Many systems were of a unique design, and as such we couldnt use the same exact code for all systems. The engineers we were attatched to for this internship introduced us to something called python dataclasses. These essentially allowed us to structure parts of our code that we knew were going to be subject to change in such a way that adding or removing certain data points from the database doesn’t break the overall program. If any changes arise, we only need to alter the related dataclasses for the rest of the code to be able to work with the new change. Without these we would have had to create new methods/classes for each unique change every time it came up; which is not something anyone wanted. I am glad I found out a way of “encapsulating what varies” since I can now write better and more future-proof code by isolating the parts that I believe will be changed the most often.

https://alexkondov.com/encapsulate-what-varies/

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