DEV Community: Allen Reinmeyer

Getting Started with Deno

Allen Reinmeyer — Sat, 18 Jul 2020 19:41:22 +0000

This will be the first in a series of posts looking at Deno, the new runtime environment written in Rust. These posts will introduce what Deno is, and why it might be of interest to developers. We'll explore getting a server up and running too with Deno.

Future posts in the series hope to cover these topics:

Explore a more complex example and using TypeScript
Dig into the standard modules for Deno
show what external code is available for Deno and how to use it
Explore how Rust and Javascript interact together in Deno
Explore creating executables for replacements to bash scripts

What is Deno?

Deno is a new runtime environment for JavaScript. One of its main creators is Ryan Dahl, who previously created NodeJS and sees this as a new approach to JavaScript running outside the browser. There's a lot to like now that version 1.0 has just been released on May 13, 2020. Deno is written in Rust giving it a statically-typed base on which to build from. Applications using Deno can be written in either Typescript or JavaScript.

Deno itself is a single executable file. It acts as both a runtime and a package manager. There are different API's included in this one executable. If the API is already a web or JavaScript standard (fetch, setTimeout), the intention is it should interface and behave exactly the way it does in the browser. Any API's that don't match to a web standard, like the file access functions, sit under a Deno namespace. That separation of functionality frees developers from confusing API's in Deno versus a standard, or confusing developers whether a package is overriding common behavior. Additionally, there's a standard library that you can import methods from to extend the functionality.

You can install Deno by following the instructions here. The overhead to installation seems small and light which is a great way to onboard developers quickly and easily without a list of dependencies, weird errors that have to be Googled. It seems to just work.

Deno is not a fork of NodeJS or NPM

Deno is very much a re-interpretation of NodeJS. NPM packages are not supported. Apparently, there is a compatibility layer effort underway, but one of the principals of Deno is how modules and third-party code is handled. For starters, Deno has a binding layer called ops that map to JavaScript promises so async/await is supported with the first release. These promises are actually built with Rust's Futures and behavior is mapped to a JavaScript promise.

Did you catch the sentence above that NPM packages are not supported? Deno uses URLs to import external code into a project. Those external URLs are locations for ES Modules. Deno does not ask you to install an external library as Node does into node_modules folders. It does have a local caching system so the modules are not externally sourced every time they are referenced. But the caching is system-based, so each project does not store its own dependencies. There's no package.json either or a central configuration file.

Deno tools

A complaint might be that missing configuration files like package.json makes it harder to view at a glance what dependencies are used in a project. Deno provides a command-line option deno info that generates a dependency graph for a file inspects all standard and third-party modules. Since imports are URL-based, this works for local files as well as remote files. Try it by executing the following after you install deno.

deno info https://deno.land/std@0.50.0/http/server.ts

Deno has an opinionated formatter too that you can use by invoking deno fmt on a file or project folder. Since the code is TypeScript/JavaScript you can use your own formatter, but this is a nice addition for completeness.

A bundler and installer are included as well that compile a larger set of files into either a single JavaScript bundle or executable. The installer is especially intriguing as the documentation suggests this might be a way to write command-line interfaces in JavaScript instead of bash or python. This is perhaps one of the more intriguing aspects of Deno for me. I may write something in bash (or modify more likely) once every six months or so. I seldom remember the syntax for the if statements, so doing real work in bash is slow for me. If I could do it in either JS or TS, I'd be more productive and likely to actually script some things that I do repetitively because I won't feel like I have to always reference docs or Stack Overflow on bash scripting.

Stay outta my sandbox!

Your Deno project runs in its own sandbox. By default, the sandbox is extremely limited on permissions. So beyond import statements for external module loading, you must specify that your Deno code can create network connections. You must specify that your Deno project can access the filesystem. Further to that, you can even specify read-only or write-only access and even list out the files or directories that can be read or written. That means no longer wondering what nested npm packages might be trying to do. Mining bitcoin, stealing passwords, downloading malware can't happen in Deno unless you allow it. This intentional security design is a huge boost to developers wanting to write secure code. As it stands, there are probably consultants out there that can specialize in securing NodeJS or Docker projects given all the nasty ways that malicious agents can sneak into either running Docker containers or NodeJS projects that get built from basic tutorials and shipped out to production. While some may see this as extremely limiting and cumbersome to specify every permission needed, as a developer who's built NodeJS apps for a large company concerned with security, having a secure-by-design application running saves a lot of heartache down the road when your app is ready to go to production and has to pass security scans and reviews.

A simple web server in Deno

As many developers will explore Deno as a comparison to NodeJS, let's take a look at how to start up a simple web server.

import { listenAndServe } from "https://deno.land/std@0.50.0/http/server.ts";

function stripLeadingSlash(url: string): string {
  return url.startsWith("/") ? url.slice(1) : url;
}

function router(url: string): string {
    switch (url) {
        case "hello":
            return "Hello World!";
        case "":
            return `Hi! Try adding paths to the url to see different messages!\n`;

        default:
            return "Sorry, I can't help you!";
    }
}

listenAndServe({ port: 9000 }, (req) => {
  let { url } = req;
  url = stripLeadingSlash(url);
  const body = router(url);
  req.respond({ body });
})

While this is a simple example, you can see it's not complex to get a server up and running. Let's walk through this to explain better.

import { listenAndServe } from "https://deno.land/std@0.50.0/http/server.ts";

This is how Deno's standard library functions get imported. If we left off the @0.50.0 part of the url, we'd be pulling from whatever is in the default branch (probably master). That doesn't matter for our purposes, but it's a good practice to version your url references so breaking changes aren't introduced once you are building and deploying applications.

listenAndServe({ port: 9000 }, (req) => {
  let { url } = req;
  url = stripLeadingSlash(url);
  const body = router(url);
  req.respond({ body });
})

The function listenAndServe opens a connection on the port passed in and any requests that arrive on that port then get handled by the callback defined with that function. Deno has options already to handle TLS (https) traffic, but in our simple case, we just pass the function a port value and then the callback to tell Deno what to do with each request that comes in. In our case, we strip the url of it's leading slash and then pass that value to a function to determine what the body of the response will be. There's nothing Deno-specific about those helper functions. In fact, you may have noticed that although Deno is written in Typescript, in this case, the code is just plain old JavaScript. Deno supports either TypeScript or JavaScript so I have the freedom to test out quick prototypes in JavaScript and then change my extension to .ts and define types as I need to.

How do I run this?

You should have Deno installed locally via one of these methods. Then assuming the above code is saved in a file called server.ts (Or you cloned my repo here and are in the root folder) you execute the following command in your shell of choice:

deno run server.ts

Did you get an error? Remember back to me mentioning that Deno runs in a very protective sandbox? We are telling Deno to set up a network connection and starting a server. So we need to explicitly tell Deno that we allow it to access network commands by using the flag --allow-net.

deno run --allow-net=0.0.0.0 server.ts

That means that Deno can only access localhost (0.0.0.0). If it tries to go to https://my.bitcoin.miner all outgoing requests will fail. This works for local file access as well, where you may want to allow a temp or limited set of folders read/write access and no more.

Summary

Deno has a lot of promise. There's some confusion on my part how the third-party modules, standard library, and deno executable will all stay in sync and versioning between the three will work. While the deno executable is now version 1.1,2, the standard library is still on version 0.59. There are several pieces too that are hidden and only accessible under an --unstable flag.

The interplay between Rust, wasm, and JavaScript will be interesting to watch too. The core pieces of deno are Rust-based, so will there be a time that we can refer to Rust crates directly? That time may be now, as Deno publishes a few Rust crates but I'm not familiar with Rust enough to know if other Rust programs could use those and benefit from them. That would be a big help as many npm modules currently aren't usable as they use the CommonJS module format. Will that dampen development as users get frustrated with re-implementing working npm modules into a Deno-friendly format?

Deno should be a big contender in the developer landscape in the coming months. The attention to security, stability, and performance are always good goals to have. Developers have embraced the ideals it has, so as more and more features are turned on and interest grows, it will likely be a good-to-know toolkit for developers looking to build either API's or CLI's.

JavaScript Sets

Allen Reinmeyer — Tue, 31 Mar 2020 00:00:00 +0000

Photo by Chris Lawton on Unsplash
This post originally appeared on areinmeyer.dev

A goal this year has been to explore more nooks and crannies of JavaScript. I had never been exposed to Sets until I worked on the Advent of Code 2019 and came across some solutions that used them effectively. So now that I've explored Maps I want to take a deeper dive into Sets to see if they can be useful to me in my daily programming.

Sets are collections of unique values. Sets share a lot of similarities with Maps as they were introduced at the same time. The values in a Set can be any primitive or Object, and a mix of any type.

const mixed = new Set()
mixed.add("1")
mixed.add(1)
mixed.add([1,2])
mixed.add({"one": 1})
console.log(mixed)
//Set { '1', 1, [ 1, 2 ], { one: 1 }

Creating Sets

Sets have many of the same properties that Maps do and are created similarly.

const s = new Set() //An empty Set
const a = new Set([1,2,3]) //A Set populated from an Array
const b = [...a] //An Array from a Set
console.log(a)
// Set { 1,2,3 }
console.log(b)
//[ 1,2,3 ]

Manipulating Sets

You can add and delete elements from a Set. The add() method returns the new Set with the added element. The Set is also mutated so the return value need not be captured. The delete() however, returns whether the Set contained the element requested to be deleted as true or false as well as mutating the Set. Be careful with these differences! I might expect that the mutated Set is always returned and try to capture that in a new variable, but that would lead to a nasty bug in your code.

The has() method checks whether the element is present in the Set or not and returns true or false. There's a clear() method as well, that removes all the elements from the Set. Using clear() does not seem too useful? I cannot think of a good example in which I would want to keep using the same Set over and over but instead of creating a new object would want to clear it instead. Maybe there are performance considerations?

Adding

const s = new Set([1,2,3])
const duplicateOfS = s.add(4)
console.log(s) //Set { 1, 2, 3, 4}
console.log(duplicateOfS) //Set { 1, 2, 3, 4}
const itHas4 = s.has(4)
console.log(itHas4)//true

Deleting

let is4Deleted = s.delete(4)
console.log(is4Deleted) //true because the Set contained 4
is4Deleted = s.delete(4)
console.log(is4Deleted) //false because 4 was previously deleted from the Set
console.log(s)
// Set { 1,2,3 }

The number of items in a Set are easily determined by using the size property. This returns an Integer relating to the number of elements in the Set.

const s = new Set([1,2,3])
s.size //3
s.clear()
s.size //0

Iterating through a Set

Like Maps, Sets have a plethora of ways to iterate over the values. The keys() and values() methods are both present, though, for Sets, they are equivalent since Sets don't store key/value pairs. There is the entries() method that exposes a 2 element array to be consistent with Map.entries() though both elements in the array are the same value. The default iterator returns the next item in the Set. The order of insertion is preserved in any of the iterator methods.

Default iterator

const s = new Set([1,2,3,4,5])
for (let item of s) {
    console.log(item * 2)
}
//2
//4
//6
//8
//10

This appears to be the simplest and cleanest method for iterating. It's intuitive with the other iterators for Arrays, Objects, and Maps.

Iterating with keys()

const s = new Set([1,2,3,4,5])
//values() could replace keys() here without changes to the output
for (let item of s.keys()) {
    console.log(item * 2)
}
//2
//4
//6
//8
//10

I think the keys() and values() methods here are just present for consistency with Maps. I do not see any benefit in using this way to iterate over the other ways. The keys() method is really just syntactic sugar to convert the Set into an Array.

Iterating with entries()

const s = new Set([1,2,3,4,5])
for (let [item] of s.entries()) {
    console.log(item * 2)
}
//2
//4
//6
//8
//10

This is fine, but could be confusing syntax because you have to wrap the current element (in the example, item) in an array because entries() returns 2 values in an Array. You also have to call the method explicitly, whereas the default iterator mentioned earlier doesn't have either the array or the method call. The Array methods of map() and filter() are not available, though converting to an Array is possible to gain those methods.

Sets killer feature

The killer feature for Sets is that it is comprised only of unique elements. I will discuss some quirks with equality shortly, but first, let us look at how we can take an Array and turn it into a Set that contains only the unique elements.

const fullArray = [1,1,1,2,2,2,3,3,3,4,4,4,5,5,5]
console.log(fullArray) //15
const s = new Set(fullArray)
console.log(s.size) //5
console.log(s) //Set {1,2,3,4,5}
s.add(1)
s.size //5

That's it. Creating a new Set with an Array will remove all the duplicates. Any subsequent adds of an existing value will not change the size of the Set. Even if you would prefer to not use Sets in your project often, you could create a simplistic utility function like the following:

function dedupe(array) {
    return [...new Set(array)]
}

This function converts an existing Array into a Set, removing any duplicates and then converts the Set back into an array using the spread operator. The example is stripped down for simplicity. Likely any production level code would want to validate that the parameter is actually an Array.

Equality limitations with Sets

Let's discuss some possible limitations though with assuming Sets will always dedupe any types of Arrays. For the most part, the triple equality test (===) is used, so Objects that contain the exact same properties won't be considered equal. But NaN in this case does equal NaN. Usually, that is not the case, as you can easily see yourself if you type NaN !== NaN into a node or browser console. But Sets will only contain 1 element set to NaN. So our dedupe function above will not create an Array of only unique objects unless those objects actually point to the same Object references.

Tidbits

An interesting note about Sets is that unlike Maps, Sets have no accessor method. No find, index or other similar methods exist for Sets. The only way to access values once they are added is to either iterate over the Set or, more likely, to convert the Set back into an Array and use one of the Array built-in methods.

There's also a lot of examples I found that talk up the mathematical benefits of using Sets, like finding unions, intersections, etc. between multiple Sets. A Set in mathematical terms does not contain duplicates, so if you're working in a field that adheres to those principles, Sets could be a good data structure.

Use

As noted previously, Sets are a really nice way to get a unique list of primitives like Integer or String. They become less useful when dealing with a list of Arrays or Objects since equality in Objects is not about the Object properties but the reference itself. In a prior project, we had issues with users creating widgets with the same name. There was no referential integrity issue (The widget name was not a key as a UUID was created instead), but it became confusing if multiple users created a widget with the same name over and over. Using Sets, we could have done a validation check on the library by gathering up all the name properties and creating a Set, validating that the new widget name wasn't already taken. Conversion to Arrays and back into Sets is simple to do, so there's a lot of benefit to switching back and forth depending on the use case in the code between Arrays and Sets. This seems to be a great addition to the JavaScript landscape and one that I will reach for now more frequently now that I know more about them!

JavaScript Maps

Allen Reinmeyer — Thu, 19 Mar 2020 13:51:51 +0000

Photo by NASA on Unsplash

This post originally appeared on https://areinmeyer.dev

A goal this year has been to explore more nooks and crannies of JavaScript. I've never used Maps in production code and had not really come across them much until recently. Maps may not seem very useful above and beyond Objects, but there are a few key features that can make Maps useful in some circumstances. Maps were introduced in ES6 and have support in most recent browsers.

Creating a Map

Maps can be created in 2 different ways. Either call the empty constructor

const thisIsEmpty = new Map()
console.log(thisIsEmpty.size) // 0

Or you can pre-populate the Map from another Map or Array.

const fromArray = new Map([["a","foo"], ["b","foo"], ["c","foo"]])
console.log(fromArray)
// Map { 'a' => 'foo', 'b' => 'foo', 'c' => 'foo' }

Map contents

Maps get and set values with a get or a set method on the Map instance.

let list = new Map();
list.set("foo", 123); // Map { 'foo' => 123 }
list.size; //1
list.get("foo"); //123

A nice feature is the has method. The has allows the code to check if a property exists in the Map and returns undefined if it's not present. This can be useful when you have a Map that may not always have keys present. The syntax seems easier to understand then chaining checks on an Object.

let list = new Map();
list.set("foo", 123);
list.has("foo") //true
list.has("bar") //false

let obj = { "foo": 123}
if (obj && obj.foo) {
  console.log(obj.foo)
}
console.log(obj.bar) //undefined

Maps can use any value for a key like a function, object or any primitive, unlike Objects that only allow a String or Symbol.
That means that the keys of a Map could look like this:

const myFunc = () => {
  return 42;
}
let list = new Map();
list.set(myFunc, "This is a function!");
list.get(myFunc) //"This is a function!"

How useful is this? To be honest, having functions or Objects as keys do not seem like a terribly common use case. There are some interesting applications of storing counts or some cached values as the value of a Map where an Object is a key. Then you can store information about the Object and associate the data but not have to store the data in the Object itself. That allows the data to be loosely associated with the actual Object. If the data being associated with the Object becomes unnecessary it can be easily deleted without trying to modify the object.

But in that case, there's a WeakMap that is likely the better option for the previous case. Objects get garbage-collected after they are out of scope and cannot be referenced anymore. But Maps hold onto their references of Objects and so Objects that are a key of a Map aren't garbage collected. WeakMaps behave the same as Maps, except their hold onto Objects that are used as keys are weak (hence the name!) and so allow the garbage collection to remove the reference to the Object from the WeakMap as well. That means the size of your WeakMap could unexpectedly change if your Object key suddenly gets garbage-collected.

A good example of the above scenario would be keeping track of a list of users engaged in a chat and displaying the count of users somewhere on the screen. As users come into the chat room, you might add the user object as the key and maybe a temporary nickname to a WeakMap, using the size property to display the active users in chat. As the user leaves the chat, assuming they leave the app, the WeakMap would allow the user object to be released and the size would update automatically. That may not be the best implementation, but it is an example of how one might use Maps/WeakMaps with Objects as keys.

Map Size

Maps have a property size that will report the number of keys in the Map. So determining the number of items in the Map is always just one line of code.

let mapsize = new Map([['a',1], ['b',2],['c', 3]])
console.log(mapsize.size) //3

This is a great feature of Maps. Arrays have the length property, which is also a one-liner. But Objects don't have a built-in method for determining the length or size of the Object and has to be calculated manually. It still can be one-line, but it involves first getting the keys from the object and then determining the length of the keys array.

let objsize = {'a': 1, 'b': 2, 'c': 3}
console.log(Object.keys(objsize).length) //3

Order Retention and iteration

Maps retain their order of insertion, so retrieving the list of keys, values or entries is always deterministic. Objects can largely behave the same way the last few years, depending on the JS engine you are using, but that's only if you have the same types of keys in your Object. If the Object contains a mix of strings and symbols, there's no guarantee of order preservation, and in fact, you have 2 separate methods to return the keys.

const obj = {}
let sym = Symbol('sym')
let bol = Symbol('bol')
obj[sym] = 'first'
obj[bol] = 'second'
obj.foo = 'third'
obj.bar = 'fourth'
let stringKeys = Object.keys(obj) //[ 'foo', 'bar' ]
let symKeys = Object.getOwnPropertySymbols(obj) //[ Symbol(sym), Symbol(bol) ]

//But with Maps...
const mixedMap = new Map()
mixedMap.set(sym, 'first')
mixedMap.set("foo", "second")
mixedMap.set(bol, "third")
mixedMap.set("bar", "fourth")
mixedMap.forEach((value, key) => console.log(key, value))
//Output
//Symbol(sym) first
//foo second
//Symbol(bol) third
//bar fourth

As seen in the preceding example, you can iterate over entries with the forEach method, which takes a callback function as an argument, allowing both key and value as parameters. Note that value is the first parameter in the callback. forEach returns void, so sadly it can't be chained with any other functions. The keys() and values() methods are also present and behave much in the same manner as the related Object methods.

Another way to iterate is to use the entries method. Using the preceding mixedMap again we could use entries like this:

for( const entry of mixedMap.entries()) {
  console.log(entry)
}
//Output
//Symbol(sym) first
//foo second
//Symbol(bol) third
//bar fourth

Another(!) way to iterate is using the default iterator.

for( const [key, value] of mixedMap) {
  console.log(key, value)
}

My personal preference is in either the forEach or default iterator with a for loop. I think they balance terseness as well as patterns that are recognizable based on other Object and Array methods. Reliable order may not always be a concern, but when it is, Maps seem to provide the only way to have confidence in that order of insertion being preserved, especially if there is a chance that keys will have different data types.

Objects can only be iterated on by first retrieving the keys (or possibly values) of the Object and iterating on those. If your data structure is an Array of Objects or a nested Array, you also have the option of using the map method that is built-in with Arrays.

Performance

MDN mentions that Maps have better performance over Objects in insertion and deletion. In a naive but simple test, this proved out. Running 1,000,000 insertions and deletions in the same Map and Object, I saw these times reported.

Action	Map Time (ms)	Object Time (ms)
Insertion	149	150
Deletion	167	486

Here's the code I used. Feel free to point out any shortcomings! While there are some differences in time on insertion, the deletion can't be accounted for by timer of my machine or insignificant differences. I ran it several times, and each run reported roughly the same times, within a few milliseconds of each. The insertion times often were negligible, but the deletion was always a significant difference.

Drawbacks

You can't map or filter a Map. To do that, you would have to convert the Map into an Array or Object first, then use the built-in functions. The resulting Array or Object could then be turned back into a Map if so desired. Whatever gains noted above though likely are lost in doing a conversion back and forth from Map to Object or Array. Maps have an overhead of learning too most likely as it is a newer feature of the language that may not be widely adopted by teams.

Why use Maps over Objects?

The biggest draw to using Maps over an Object is the benefit of using something like an Object or Date as the key instead of resorting to a string or Symbol. Being able to quickly and easily see the size of the Map without calling a function is also useful. The has method associated with a Map is a nice interface for checking if the key is present in the Map. If you are doing a fair amount of deletions in Objects, Maps might also be more performant.

The reality is Maps are probably not something that is going to be used every day by most developers, so there is definitely a mental overhead of introducing it into a shared environment. Built-in iterables for Map and a property checking of has is beneficial in many uses though, so I definitely will be reaching for Maps now that I know more about them. It's also a great way to share knowledge with a team and introduce them to this new data structure.

JavaScript's tricky Object mutation

Allen Reinmeyer — Thu, 20 Feb 2020 01:32:25 +0000

This post originally appeared on areinmeyer.dev

One "trick" to JavaScript that used to produce a lot of errors for me was the difference in assigning primitives to variables versus assigning Objects to variables. But, like a magician's sleight of hand, the "trick" disappears when you understand the sleight-of-hand.

Let's explain the problem with a couple of examples.

When you declare a variable and assign it a primitive value, you do something like this:

let a = 1;
let b = a;
b = b + 1 //b is 2, a still is 1

But when you do the same thing with Objects, this happens:

const a = { "foo": 1, "bar": 2 }
const b = a
b.foo = 20 //b is { "foo": 20, "bar": 2 }, a ALSO is { "foo": 20, "bar": 2 }

Wait, what!?

Assigning primitives to variables

In most cases, when you assign what's considered a primitive value (numbers, strings, symbols, booleans) to a variable, you are assigning the value. Unless you're using the const keyword in declaring the variable, you can change the value of the variable like this:

let a = 1;
a = "one";
console.log(a) //"one"

You can't though do this:

let a = "one"
a[1] = "l"
console.log(a) //"one"

But you can do this:

let a = 1
a = a + 1 //alternatively, a++
console.log(a) //2

The distinction may be subtle. The variable a points to a primitive, and that primitive value can be reassigned (since we used let). The primitive itself can't be changed. The second example above is trying to do that. In the first and third examples, we are changing the value of what a is pointing at. Don't think of the third example as incrementing a, instead think of it as changing a to be the result of a + 1.

Assigning Objects to variables

The magic appears when assigning Objects to variables. Changing an element in an Object or an Array is valid syntax and common.

Let's look at a few Object assignment examples:

const array = ["a", "b"]
array[0] = "c"
console.log(array) //"c", "b"

let array = ["a", "b"]
array = ["A", "B"]
console.log(array) //"A", "B"

const array = ["a", "b"]
const newArray = array
newArray[0] = "A"
console.log(newArray) //"A", "b"
console.log(array) //"A", "b"

Note that the contents of Arrays (which are a specific type of Object) can be mutated. Using const in the second example results in a "TypeError: Assignment to constant variable", as that replaces what array is assigned. That violates the concept of const, which prevents a re-assignment of values (or Objects) to another value or Object.

So what's happening in the third example? Are we creating pointers to Objects? Are Objects created and passed around by-reference?

Sharing is caring confusing

We won't dive into memory management, whether variables are passed by reference or value, because I don't feel confident to explain it that well yet. 😜 My limited understanding at this point is that Objects get created on the heap in memory, and then a pointer to that location is stored on the memory stack, the place where JavaScript wants to get variables. There's a lot of nuances, and the distinction of Call-by-Reference and Call-by-Share is not one I can articulate.

When Objects are created and then referenced by multiple variables like in the examples previously, what occurs is the variables point to the same Object in memory. That's why this first example below returns true, while the second example returns false. The Objects in the first example point to the same Object, while the second example has created two separate Objects. Doing a simple assignment of a variable that is pointing to an Object makes both variables point to the same Object and does not create a second, separate Object.

//Both a and b point to the same Object
const a = { "foo": 1, "bar": 2 }
const b = a
console.log(a === b) //true

//Both a and b point to different Objects
const a = { "foo": 1, "bar": 2 }
const b = { "foo": 1, "bar": 2 }
console.log(a === b) //false

So what's a dev gotta do?

There are several avenues your code can take, depending on the type of Objects you are using. We can copy the Object into another Object. A new way that's been added in TC39 Stage 4 is the Object Rest/Spread Properties. It uses the ... spread syntax that's become common in recent years with destructuring and retrieving nested values from Objects. Our above example becomes:

let a = {"foo": 1, "bar": 2}
let b = {...a}
b.foo = 20 //b is { "foo": 20, "bar": 2 }, a REMAINS { "foo": 1, "bar": 2 }

The same outcome can be achieved by using Object.assign. That creates a new Object.

let a = {"foo": 1, "bar": 2}
let b = Object.assign({}, a)
b.foo = 20 //b is { "foo": 20, "bar": 2 }, a REMAINS { "foo": 1, "bar": 2 }

Note here that assign takes an empty Object. Object.assign mutates the first parameter as well as returning an Object. You can pass as many Objects as you want to assign, but as you add Objects to the right of the list, those take precedence over the Objects to the left.

Hang on, more problems ahead!

There's some problems with the spread operator or the Object.assign that you need to be aware of. Are you working with an Object that has nested Objects? Well, get ready, those aren't copied fully by either of the above methods! Nested Objects are still shared by the original Object. Only the top-level (or shallow) keys are truly copied to the new Object.

let a = {"foo": 1, "bar": 2, "baz": {"foo": 3 } }
let b = Object.assign({}, a)
b.foo = 2 
console.log(b.foo) //2
console.log(a.foo) //1
b.baz.foo = 20 //b is { "foo": 20, "bar": 2, {"foo": 20 } }, a is also { "foo": 1, "bar": 2 , {"foo": 20 } }

To avoid the problem in the previous example, you would have to do this:
let b = JSON.parse(JSON.stringify(a))
But that works if you are using very simple data types. Dates, functions, Maps, Sets, all would not be copied over as you would expect them to be copied over.

The best bet is to examine or use the lodash method cloneDeep. If you don't want lodash, you can do something similar, but make sure you traverse your Object all the way. In other words, don't go it alone, use a tried and tested external library if possible.

The non-simple answer

What I've started doing now when I am thinking about data structures is to try and avoid nesting Objects inside of Objects to prevent some of these accidental mutations on the original Objects. If I can keep state as local to React components or functions/classes that tends to avoids the need to have complex data structures. If I have to have complex data structures, I try to make sure that in passing parameters to functions I'm slicing out what I need only for that function.

It is easy to fall into the trap of passing large data structures around to functions to avoid listing out 5 or 6 parameters, but when that occurs or I find myself wanting to pass large structures I stop and try to understand how I got to this point and refactor away the need to have large structures passed around or passing a long list of parameters to a function.

It's much easier to spot the "magic" now that I understand better how Objects get created and stored. The magical errors have started to vanish and because of it, my code appears to be simpler.

References

In researching this problem, I stumbled upon several good articles and resources. The original inspiration for this article was from Dan Abramov's JustJavaScript as I came across this very problem in old code I had written and this is my clumsy attempt to write about it and better understand it.

MDN JavaScript Docs Simply a great resource for all things JavaScript
Dr. Axel Rauschmayer's JavaScript for Impatient Programmers
Call by Sharing

My 2020 Goals

Allen Reinmeyer — Mon, 20 Jan 2020 03:35:09 +0000

Learning Javascript for reals

This post originally appeared at areinmeyer.dev

I attempted to complete the wonderful Advent of Code this past year and got to Day 10.

Well, I got to Day 8 and then used a lot of help from Reddit and Github searches to get to Day 10. 😭

What did I learn? I have relied on frameworks or libraries these past 4 years as a bit of a crutch to tell myself I really knew Javascript.

Is that a bad thing? Not really. I started a greenfield project at that point and knew some JS via jQuery and small bits and pieces doing some basic websites. We were under a tight but do-able schedule at work and needed to show continued progress to keep things running. A React/NodeJS set-up was the right solution (in part because our front-end UI was all moving to React anyway!). But it required me to really level up fast not only on Javascript but also React, NodeJS, webpack, ES6 features, Docker and eventually Redux to tie into helper libraries our core team was providing as some internal scaffolding.

Lots of tutorials, blog posts and heavy use of lodash, we shipped. It's still running in production today. I learned GraphQL as well during the process, as we were so successful in showing progress that we decided to roll some of our own solutions instead of relying on third-party vendors for some parts of the puzzle. It's easy to reach for npm and Google to get past certain hurdles. But as I went through Advent of Code I tried to keep my solutions basic and use Vanilla JS as much as possible without adding libraries or overhead. I tried to do functional programming and I quickly learned I didn't have enough comfort to do that either. I'd limit myself to trying to reference Mozilla MDN too and realized I hadn't ever used Maps, Sets, or understood the number of methods that Array or Object have built-in.

Does that make me a bad developer? No, I'd argue a lot of developers don't really use Maps or Sets too often either. But as I thought about what I wanted to level up on in 2020, it occurred to me that instead of trying out a new language like Rust or Reason, which are both really cool time investments, I should go back to basics to focus on the area that I say I really know. This year, I intend to do that by continuing the Advent of Code or maybe some other code katas or lessons in a similar vein. I'll probably dive into some of Axel Rauschsmayer's books (https://exploringjs.com/) as well as Dan Abramov's https://justjavascript.com that he just announced.

All the Functions!

My other goal is to really get a good understanding of Functional programming. I've read different articles and blog posts, conference talks, and even have a book sitting on my virtual shelf (Functional Programming in Javascript by Dan Mantyla). But can I explain what a monad is? Probably not. There are several resources that I'll use for that:

Functional Programming in Javascript The afore-mentioned book that's been sitting on my shelf for far too long
James Sinclair's blog There's so much good content here. And he references another good series from ...
Tom Harding explaining the Fantasyland spec
Professor Frisby's Mostly Adequate Guide to Functional Programming Brian Lonsdorf's Javascript guide to functional programming. It's available on Github and PR's are welcome.

Several of these I've read before or started, but I think it'll be a good exercise to re-read and really try to apply the lessons learned here. Currently, I'm not writing a lot of code during my day job, so having examples and lessons to try and apply will be helpful. My goal is to try and really document my process as well. I think doing both simultaneously won't be too challenging (i.e., a chapter a week on general Javascript and another chapter on Functional Programming). I've read that to truly understand Functional Programming you need to learn a language like Haskell which really only allows you to use Algebraic structures and functional concepts.

Feel free to send me any additional references that would be helpful. So maybe I'll be taking a detour as I go during the year to learn a new language. Wish me luck here's to a great 2020!

Docker commands I can't live without

Allen Reinmeyer — Tue, 13 Aug 2019 01:31:20 +0000

This post originally appeared on areinmeyer.dev

I have used Docker since late 2015 when I started our greenfield React/NodeJS project. Like many developers, I tried to grok enough of it to get the project up and running. And then as we spun off new micro-services, I copied and pasted the previous implementation to the new project.

But over the last year, I've had to dig into the guts of Docker more and more. This is the first part of two posts about what I've learned. There are several commands or settings that I've picked up on that I think are incredibly useful. These commands have helped increase my understanding and productivity when working with docker containers locally.

Docker Preferences

Save a running container as an image

docker commit container image2

Docker builds layers or images for each command that you specify in the Dockerfile. This is a great way to "save" a working copy for further experimentation or other local changes. When you run the command, the existing container and all of the changes you have made to it are stored as a new image. This has saved me a couple of times when I started the container but maybe forgot to open a port.

There is no clean way to open a port on a running container, and if you are trying to get something working without this command you would have to start a new container with the port open and redo any changes.

Don't use this command to save an image that you want to publish. The associated Dockerfile isn't updated so you would never be able to recreate the new image that you are creating.

Get a summary of all images/containers in Docker

docker system df

Want to see how much memory all of your containers and images are using? This command gives a nice summary of the space used by images, containers, and volumes. Usually, when a docker container complains that it is out of memory, the likely true problem is that whatever you have allocated overall for Docker to consume has filled up. Seeing what images and containers are using then can be a good starting point for freeing up space. Though remember, you can't delete images that are being used by a container, either stopped or running!

See ALL images on your machine

docker ps -a

Without the -a parameter, this shows you all of the running containers. Add the parameter though, and you see all of the stopped containers. These could be stopped containers or failed builds. Use either the name or the container ID to then docker rm <name> to remove the container. Or docker start <name> to restart a container. Often this can be a treasure hunt of past attempts or tests that are no longer needed.

Remove all unused images

docker rmi $(docker images -q -f "dangling=true")

If I was smarter about setting up cron jobs, I would have this command run about every 2 weeks. Every time you build a docker image locally, each step in your dockerfile creates an image. Most of the time the intermediate layers are removed but untagged images can remain with errors or interrupted builds. Docker doesn't do a great job of cleaning up those images and they persist until either your disk fills up or you remove them.

This command gets a list of all your image ids in docker locally (docker images -q) and displays only the untagged leaves (-f "dangling=treu"). Those are then removed with the docker rmi command. The nice part of this is that docker will warn and skip deleting any images that are in use from a container. So it's a relatively safe command to run.

See all processes running in a container without logging into the container

docker top <name>

Don't want to exec into a container just to see what's running? Open up a tmux window or a new terminal window and run this command. Much like UNIX's top, it'll take over your window (hence my new window suggestion!) and show you processes running on the container you've specified. Really handy for seeing what processes get spawned (or not) in the container. Also handy to see why my Macbook's fan suddenly kicked in. This helped start me on the path to tuning a container that was running out of memory and getting OOMKilled in kubernetes. I could recreate locally and troubleshoot the issue.

None of these commands are revolutionary or dreamed up by me. Most I found by googling and reading the docker docs. Maybe though I've helped you, dear reader, save a few hours by compiling them together in one shot? Some came with little explanation, so my hope is I've now provided a better understanding of what these do.