Miscellaneous December Flashcards

1
Q

strongly typed vs

static type vs

A

What is Strongly typed VS Weakly typed?
Strongly Typed: Does not allow “type coercion”.

Weakly (loosely) Typed: Weakly typed languages like JavaScript or Perl won’t throw an error and adding string and number in JavaScript will results ‘28’.

What is Static VS Dynamic type?
Static typed languages are those in which type checking is done at compile-time, whereas dynamic typed languages are those in which type checking is done at run-time.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

deep vs shallow copy

example methods of both

A

shallow copy methods only work with shallow arrays
don’t work on deep arrays or deep objects
if you change something in one of them, it’ll change in both because they are pointers to same obj

shallow copy methods

arr.slice(0)
array.concat(array2)
spread operator
Object.create({}, obj)
Object.assign({}, obj)
Array.from(arr1)

deep copy methods

JSON.parse(JSON.stringify())
Service Workers postMessage() onmessage
History API history.pushState(obj, title) history.state
Notification API new Notification(“title”, {data: obj}).data
Build a custom recursive function

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Engine vs Runtime

A

Engine:

Memory Heap
Heap is the place (memory) where objects are stored when we define variables.

Call Stack
Stacks holds our function calls. On each new function call, it’s pushed on top of the stack. You can see your stack when you have an exception on JavaScript by stack trace.

Runtime:

Web APIs:
Browsers have defined API’s which developers can be used to make complex processes such as to get location of visitor, GeoLocation is defined.

List of APIs
https://developer.mozilla.org/en-US/docs/Web/API
DOM(document)
AJAX(html http request)
Timeout(setTimeout)

Event Loop
A process which is responsible to check our stack and then trigger our callback queue continuously.

Callback Queue
When a process finished its job, such as a xhr call, it’s dropped in a callback queue. Callback queue is triggered by event loop process after our stack is empty which means the process waits in that queue until our stack is empty. Once our stack has no function call, then a process is popped-out from callback queue and pushed in to stack.

Learn example here:
https://medium.com/javascript-in-plain-english/understanding-javascript-heap-stack-event-loops-and-callback-queue-6fdec3cfe32e

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

classical vs prototypical inheritance

A
Classical Object-Oriented Programming
In classical object-oriented programming we have two types of abstractions: classes and objects. An object, as mentioned before, is an abstraction of a real world entity. A class on the other hand is an abstraction of an object or another class (i.e. it's a generalization). For example, consider:

+———————-+—————-+—————————————+
| Level of Abstraction | Name of Entity | Comments |
+———————-+—————-+—————————————+
| 0 | John Doe | Real World Entity. |
| 1 | johnDoe | Variable holding object. |
| 2 | Man | Class of object johnDoe. |
| 3 | Human | Superclass of class Man. |
+———————-+—————-+—————————————+
As you can see in classical object-oriented programming languages objects are only abstractions (i.e. all objects have an abstraction level of 1) and classes are only generalizations (i.e. all classes have an abstraction level greater than 1).

Objects in classical object-oriented programming languages can only be created by instantiating classes:

class Human {
    // ...
}
class Man extends Human {
    // ...
}
Man johnDoe = new Man();
In summation in classical object-oriented programming languages objects are abstractions of real world entities and classes are generalizations (i.e. abstractions of either objects or other classes).

Hence as the level of abstraction increases entities become more general and as the level of abstraction decreases entities become more specific. In this sense the level of abstraction is analogous to a scale ranging from more specific entities to more general entities.

Prototypal Object-Oriented Programming
Prototypal object-oriented programming languages are much simpler than classical object-oriented programming languages because in prototypal object-oriented programming we only have one type of abstraction (i.e. objects). For example, consider:

+———————-+—————-+—————————————+
| Level of Abstraction | Name of Entity | Comments |
+———————-+—————-+—————————————+
| 0 | John Doe | Real World Entity. |
| 1 | johnDoe | Variable holding object. |
| 2 | man | Prototype of object johnDoe. |
| 3 | human | Prototype of object man. |
+———————-+—————-+—————————————+
As you can see in prototypal object-oriented programming languages objects are abstractions of either real world entities (in which case they are simply called objects) or other objects (in which case they are called prototypes of those objects that they abstract). Hence a prototype is a generalization.

Objects in prototypal object-oriented programming languages may be created either ex-nihilo (i.e. out of nothing) or from another object (which becomes the prototype of the newly created object):

var human = {};
var man = Object.create(human);
var johnDoe = Object.create(man);
In my humble opinion prototypal object-oriented programming languages are more powerful than classical object-oriented programming languages because:

There is only one type of abstraction.
Generalizations are simply objects.
By now you must have realized the difference between classical inheritance and prototypal inheritance. Classical inheritance is limited to classes inheriting from other classes. However prototypal inheritance includes not only prototypes inheriting from other prototypes but also objects inheriting from prototypes.

https://stackoverflow.com/questions/19633762/classical-inheritance-vs-prototypal-inheritance-in-javascript

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Rest API versioning

A

When to Version
APIs only need to be up-versioned when a breaking change is made. Breaking changes include:

a change in the format of the response data for one or more calls
a change in the request or response type (i.e. changing an integer to a float)
removing any part of the API.
Breaking changes should always result in a change to the major version number for an API or content response type.

Non-breaking changes, such as adding new endpoints or new response parameters, do not require a change to the major version number. However, it can be helpful to track the minor versions of APIs when changes are made to support customers who may be receiving cached versions of data or may be experiencing other API issues.

How to Version
REST doesn’t provide for any specific versioning guidelines but the more commonly used approaches fall into three categories:

https://restfulapi.net/versioning/#:~:text=Versioning%20helps%20you%20iterate%20faster,to%20break%20existing%20client%20integration.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

why is graphql less likely to be versioned

A

https://symfony.fi/entry/versioning-an-api-in-graphql-vs-rest#:~:text=In%20REST%20any%20self%2Drespecting,versioning%20in%20the%20same%20sense.&text=The%20header%20approach%20achieves%20similar,URL%20method%20is%20often%20favoured.

When do you need to version your API?

Breaking changes primarily fit into the following categories:

Changing the request/response format (e.g. from XML to JSON)
Changing a property name (e.g. from name to productName) or data type on a property (e.g. from an integer to a float)
Adding a required field on the request (e.g. a new required header or property in a request body)
Removing a property on the response (e.g. removing description from a product)

In GraphQL you introduce and deprecate fields

GraphQL is different from REST in quite a few ways. One of the key thing is that instead of the server dictating what a response will look like, the query itself defines the shape of the response. Instead of sending all the data over the wire, the request specifies exactly what is needed and only that data is sent.

So essentially a GraphQL entity will always remain in the same exact address and represent the same version. Existing data attributes should obviously not be changed to maintain backwards compatibility, as the GraphQL standard itself is unable to enforce this. Discipline and communication is still needed to maintain

Take an example where a company search API has the field for a logo in it. Over the years the API needs to update the type to keep up with the latest file formats:

  • Logo in 2015: Bitmap (PNG)
  • Logo in 2017: Vector (SVG)
  • Logo in 2019: Animated (GIF)
    With REST to get the specific version of the logo to maintain compatibility with clients you would end up with three URLs in the year 2020:
https://example.com/api/v1/companies
https://example.com/api/v2/companies
https://example.com/api/v3/companies

Alternatively you you could also keep the older versions of fields around in later versions. That would be feasible with the example case, but if your payload is documents or something else then you’ll be sending over a lot of redundant data.

With GraphQL you would simply add completely new fields at each time, but the resource URL will remain the same. Clients that don’t request a Bitmap/PNG in 2020 will not even know that it’s available.

If we were to add new fields to GraphQL for the new formats over time for a total of three fields (logo,logo_vector,logo_animated) by 2020, then a GraphQL client built in 2015 can continue to make queries like this to get the Bitmap/PNG version:

query Query {
  companies {
    id,
    title,
    logo
  }
}

Instead a bleeding edge client built in 2020 could target the same endpoint with this request to get an animated logo:

query Query {
  companies {
    id,
    title,
    logo_animated
  }
}

This would result in a response with only the animated version of the field. In theory a client could request all of the different fields with a query such as:

query Query {
  companies {
    id,
    title,
    logo,
    logo_vector,
    logo_animated
  }
}
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

polyfill

A

A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it. … The polyfill uses non-standard features in a certain browser to give JavaScript a standards-compliant way to access the feature

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

babel

A

is a JavaScript compiler

Babel is a toolchain that is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript in current and older browsers or environments.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

what is functional programming, functional vs object oriented

A

These three approaches will be shown at the example of JavaScript but they apply for most programming languages (some languages push you towards a certain paradigm though - JavaScript doesn’t).https://academind.com/learn/javascript/functional-vs-oop-vs-procedural/

  • paradigm - how you structure your code; organize and reason about
  • Procedural Programming
    • Procedural programming is all about writing “procedures”. You could kind of translate this with: “Write down the steps your program should execute in order”.
    • we don’t group any logic in any special way

Functional programming mainly supports abstraction over data and abstraction over behavior. Object-oriented programming mainly supports abstraction over data only. Functional programming provides high performance in processing large data for the applications.

the code is easier to write, runs faster, and uses less memory.

Functional - First-Class Citizen Functions
Higher-Order Functions
Function Composition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

methods of code reuse

inheritance vs composition

implementation

A

inheritance

  • very fragile,
  • if you need to use it, only create one level, avoid using hierarchies

composition or mixin

  • favor composition over inheritance;
  • various features as independent objects

implementation
create const canEat and canWalk
if you’re using a constructor method to create person
Object.assign(Person.prototype, canEat, canWalk)
const person = new Person()
* to copy methods and properties from object to another

  • to make it more readable we can extract this into a function mixing

function mixin(target, …sources){
Object.assign(target, …sources)
}
(…spread to accept any number of arguments)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Object.assign()

A

The Object.assign() method copies all enumerable own properties from one or more source objects to a target object. It returns the target object.

const returnedTarget = Object.assign(target, source);

Applications:

Object.assign() is used for cloning an object.
Object.assign() is used to merge object with same properties.

https://stackoverflow.com/questions/43074256/changes-to-object-made-with-object-assign-mutates-source-object

Object.assign creates a shallow clone

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Javascript design patterns

A

Module Design Pattern in JavaScript

JavaScript modules are the most prevalently used design patterns for keeping particular pieces of code independent of other components. This provides loose coupling to support well-structured code.

https://jsmanifest.com/power-of-the-module-pattern-in-javascript/#:~:text=Arguably%20the%20most%20popular%20variation,which%20then%20becomes%20the%20module.

As you may have guessed, the module pattern lets you create modules. In the end, modules are basically just objects. But there are a couple of ways to create modules.

For those that are familiar with object-oriented languages, modules are JavaScript “classes”. One of the many advantages of classes isencapsulation- protecting states and behaviors from being accessed from other classes. The module pattern allows for public and private (plus the lesser-know protected and privileged) access levels.

Modules should be Immediately-Invoked-Function-Expressions (IIFE) to allow for private scopes - that is, a closure that protect variables and methods (however, it will return an object instead of a function).

Observer Design Pattern in JavaScript

There are many times when one part of the application changes, other parts needs to be updated.

Another prime example is the model-view-controller (MVC) architecture; The view updates when the model changes. One benefit is decoupling the view from the model to reduce dependencies.

Prototype Design Pattern in JavaScript

Any JavaScript developer has either seen the keywordprototype, confused by the prototypical inheritance, or implemented prototypes in their code. The Prototype design pattern relies on theJavaScript prototypical inheritance. The prototype model is used mainly for creating objects in performance-intensive situations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly