Forem: Daniel Warren

#6 Subgrid, Threads, Clouds Aren't Real, and Intl.Segmenter

Daniel Warren — Fri, 06 Oct 2023 20:06:33 +0000

In today’s episode we take a look at css subgrid, why the BBC is leaving Threads, how there is no such thing as the cloud; it’s just someone else’s computer, and then we talk a little bit about the segmenter API.

Substack
Spotify

Show notes:

Tech tweet of the week

Non-tech

Motoball - soccer on motorbikes in Europe. I watched a match live once and it was one of the wildest sports I’ve ever witnessed.

Console.Warren(), a New Podcast

Daniel Warren — Mon, 25 Sep 2023 01:44:44 +0000

I started a podcast called Console.Warren() where each week I highlight what's new and noteworthy in software engineering. The episodes are short, five to six minutes each.

In the latest episode, #4, we talk about Bun 1.0, career, ActivityPub, and zod-mock.

Please consider subscribing and if there is anything you'd like to see featured on the podcast, let me know!

Substack
Spotify
Apple Podcasts

A Lightweight Package to Generate CSS and JS Variables

Daniel Warren — Fri, 26 May 2023 03:26:51 +0000

Developers love new projects. The blank canvas.

One of my favorite things to do in a new project is setup the theming, thinking about the look and feel of the new application. But the work becomes tedious, and I end up copying and pasting a lot of css and js variables from old projects.

To solve my problem, I created a lightweight, probably too simple, package called varbq, pronounced like barbeque, because, hey, Memorial Day is coming up.

I tend to use the same theme format over and over again, which is very similar to what the amazing book, Refactoring UI, lays out.

Theses projects generally have primary, secondary, accent, and grey colors, each having between five and nine shades, for example, primary200 or accent900. They'll also include spacing sizes to keep the app uniform, like spacing100: 4px, spacing200: 8px, etc. The same goes with typography, shadows, and occasionally screen size.

This is where varbq comes in handy.

After installing, run the command npx varbq build to create the varbq.json file. Passing in optional flags --js or --css only creates those files (for example if it's a React Native project), otherwise both get generated. This command will create a varbq.json file if one doesn't exist.

Each key in the file will create variables based on the array of values, incrementing by 100. So...

{
  "primary": ["hsl(216, 99%, 98%)", "hsl(216, 98%, 92%)", "hsl(216, 95%, 86%)"],
  "spacing": ["4px", "8px", "12px"]
}

becomes...

export const varbq = {
  primary100: "hsl(216, 99%, 98%)",
  primary200: "hsl(216, 98%, 92%)",
  primary300: "hsl(216, 95%, 86%)",
  spacing100: "4px",
  spacing200: "8px",
  spacing300: "12px"
}

and...

:root {
  --primary100: hsl(216, 99%, 98%);
  --primary200: hsl(216, 98%, 92%);
  --primary300: hsl(216, 95%, 86%);
  --spacing100: 4px;
  --spacing200: 8px;
  --spacing300: 12px;
}

The variable files live in varbq/ at the root of the project.

Check out the docs for more information and let me know any features you'd like to see in the future.

Dark to Midnight Mode

Daniel Warren — Wed, 30 Nov 2022 04:41:35 +0000

Without software engineers, instead of yachting around the globe, the titans of industry would be on their third slice of pizza in their parents’ basement, reading a newspaper because online news wouldn’t exist.

Software engineers built the world. Now it’s time we save the planet, starting with the energy grid. Because who better to fix the problem than the very people who caused it in the first place, with all of our app development and Bitcoin mining.

The first place to start would be dark mode. Studies show that dark mode can save an average of three to nine percent of battery life. But we can do better.

I’m ready to introduce the next big thing in design and development: Midnight Mode.

In Midnight Mode, everything is black: the images, the text, the sidebars, the headers. Every element. The sidebar, for example, still exists, but will only be slightly visible when hovered. This saves at least an additional 15% of battery life. Essentially, it’s like the screen is turned off, until it’s not.

Advertisers will love Midnight Mode, too. Users spend an additional 50 to 70 percent more time exploring the site. Engagement is off the charts as users aimlessly search for what they’re looking for.

With Midnight Mode, we no longer have to worry about pesky designers with their UI/UX and fancy color schemes that are destroying the planet. Imagine saving the planet AND not having to look at another Corporate Memphis noodle person playfully showing you all the fun you’re going to have on their devastatingly mundane app. This alone could save the planet.

No fluffs. No frills. Midnight Mode will be driven by pure functionality, just as the internet was originally intended.

We hope all engineers and designers will embrace this new movement before it’s too late. See below for a demo. Let’s change the world.

Demo

Dear JavaScript, I Hope this Email Finds You Well...

Daniel Warren — Wed, 12 Jan 2022 22:54:11 +0000

Dear JavaScript,

I hope this email finds you well. I feel like I owe you an explanation about what went down between us a few months ago. Everything happened so fast and now that the dust has settled, I’ve had a chance to look back and unpack a lot of the emotions involved. At the very least, I owe you an apology. So, JavaScript (JS), I’m sorry.

I remember when I first met you, I was nobody. I didn’t even exist. At the time, I think I was dating PHP. She was good for me, but we never had that spark. When you walked into the room at that party in the East Village, I felt my heart drop. Yes, you were a little out there, a bit all over the map, but you were stunning; a beautiful mess that I couldn’t take my eyes off.

We got to chatting and we had a lot in common. We could both be spontaneous, and to our detriment, a little unpredictable. You could be a number, a string, or an object; it didn’t fucking matter. And it turned me on. After the party, you came back to my apartment for the night. I’ve never been with someone so flexible.

We’ve had our ups and downs. I guess lately, we’ve been fighting a lot. Sometimes I just don’t get your indecisiveness. Like that night at dinner when you suddenly changed into an array without warning. I was so angry, but I still loved you. And I know, I know - I’m not perfect either. Especially in the early days of our relationship when I thought class components were the future. But you stuck with me because you knew, like yourself, I was a free spirit. We embraced our chaos together.

Then I met someone else.

I didn’t mean to fall in love with TypeScript (TS), it just sort of happened.

Honestly, when I first met TS, I couldn’t stand her. We met at a party. I remember her repeatedly complaining about the exits at the bar not being up to code. I found her incredibly off-putting. She kept yelling at me about the exit situation, but the messages out of her mouth made little sense.

Here’s the thing, JS. I’ve been floating around aimlessly now for a while. My life is a bit of mess. I don’t really care about much anymore. Sometimes I pass props into components and I don’t even use them because nobody checks anyways. I don’t even bother removing console logs anymore. I’m not blaming you. But sometimes I think our being together only exacerbated the problem for us both. I needed someone more stable. Someone with a plan.

I have to get this off my chest. Yes, I was with TS at the end of our relationship. After that party, I went back to her place. I don’t really know why. She was such a know-it-all. But nothing really happened. We just held hands, that's all. The rest of the time she asked me about my goals in life and if I wanted children. We talked about our families. She went to private school on the East Coast and her father is in banking. They’re Duke fans.

Things are good now with TS. She makes me a better man. But, and I have to be honest here, I still think about you. TS never wants to experiment or try new things. If we don’t go to our favorite Italian place on Friday nights, she loses her mind. I think she has OCD. She’s not… you. Sometimes when I’m with her, I think about you. I know that’s wrong, but, I’d be lying if I said I didn’t still love you.

So for what it’s worth, I’m truly sorry.

Anyway, next month I’ll be in your neck of the woods. If you’re not busy, maybe we can catch up and grab a drink?  

Yours truly,

React

Ten Tips for Becoming an Elite Developer

Daniel Warren — Wed, 02 Sep 2020 03:11:38 +0000

Experienced developers will tell you after graduating from boot camp your first job will most likely be as a junior developer.

This is utter nonsense. Bologna.

Trust me, I’ve built several todo apps and I taught myself Typescript in only a few months so I know what I’m talking about.

Today I’d like to share with you ten tips to take your deving to the next level, whether you are a junior or a seasoned professional in the field.

1. Always edit your node_modules

Let's start off with the most obvious tip. Many of you are probably rolling your eyes at this one because it's the first good piece of advice you get when you're a junior. But why does it matter? NPM packages are updated all the time but sometimes we as devs don't have the time wait around for the next update or bug fix in the source code. Any competent dev worth their salt should be able to go in and make the necessary changes to keep their project on the right track.

2. Functions

Functions should be big. According to Merrium-Webster, a function means “an official or formal ceremony or social gathering.” Social gatherings encompass many people, all who do different jobs. A function in coding is no different. They should contain a plethora of functionality. In my React projects, I have one or two giant functions for the entire project. Don’t buy into the hype of smaller functions doing one thing each. It’s garbage. Keep all your functionality together in one giant function. It’s easier to read too.

3. Indentation

Two or four spaces? I prefer five. When people look at my code, I want them to think, that’s Daniel’s code. What’s one of the first things they tell new writers or artists? To find your own unique voice or style. Coding is no different. Find a unique style. Grab your voice by the brackets. Experiment with different indents and layouts. Linters are creativity killers. Don’t use them. Your code is art. You are Rembrandt, your keyboard your brush.

4. Documentation

Documentation is for the weak-minded. If you’re a good coder, you should know how your code works just by looking at the code. READMEs are for amateurs. Your code is the README. If another developer joins the project and asks for a README, they probably aren’t very good at their job. Recommend their position at the company be revoked back to junior.

5. Staying ahead of the trends

Brush up on XML because I predict it’s going to make a serious comeback over JSON.

6. Git smart

This one drives me mad. Stop committing so much. I commit once a day. Sometimes I don’t commit for weeks. Doing anymore only confuses and clogs up your flow. You want clean code, Uncle Bob? Look at my commits. Ideally, a project should only have two commits - initial commit and deploy.

Start pushing directly to the main/master/develop branch. Pull requests are for the gutless. If you believe in your code, dammit, push it directly to master. Branches only make things more confusing. As a team, we should all be on the same page, but how can you do that if everyone creates their own branches? What is this, the Wild West? Your team needs unity, one branch. One team.

7. Agile vs. waterfall

I have to say, I’m flabbergasted with agile development taking over many businesses. Imagine building a house using agile. The foundation is poured and suddenly the owners want that second bathroom moved to the other side of the basement. Then they want the fireplace on another wall. Now the blueprints have to be thrown out and you have to drag the architect off of another project so he can fix the plans. This is why you lock the blueprints. Building software is no different. If your vision has to pivot halfway through the project, you’re doing something wrong.

8. Designers

If the designer gives you designs for the app and you think they look like crap, overrule them. You have the most important job in the world. You are a software engineer. A God, really. You have an ego? Damn right, you should. Heart surgeons have nothing on you. Somebody has to do the really important work in this world. Show that designer a thing or two about designing.

9. Dress code

Push for stricter dress codes - suits, lab coats, scrubs - something in that vein. We’re the smartest and most sophisticated profession out there - time we start dressing like it. I wore a tux to work on my second day as a junior dev and my colleagues were so impressed, they didn’t say a word.

10. Finally…

Do the opposite of everything I just said.

Comfortable Tube Sockets

Daniel Warren — Sun, 21 Jan 2018 05:09:45 +0000

According to their website, "Socket.io enables real-time bidirectional event-based communication.” Unpacking this description, it essentially means a browser and server can have live information sent back and forth instantaneously to multiple users. In a chat application, when one user types a message and presses enter, the message travels to the server, and from the server, it’s sent out to all of the other users connected to the socket. I like to think about a socket as a tube from your browser to the server. You shoot information up the tube where it hits the server. At the server, it’s processed and copied, and sent back down all of the other open tubes and handled by the client.

Beyond chatting, sockets are used for all sorts of applications including document collaboration and multiplayer video games. In this tutorial, I’ll go over the basic concepts of a chat application. Because Socket.io can be used with almost any framework, I won’t go into any setup details, instead focusing on the main concepts. In addition, I won't cover setting up a package.json file or using npm install for dependencies. If you need more information on these subjects, see here for npm and here for package.json.

First we’ll start with server.js which will live in the root of your project. Start by adding the following dependencies and create a new Express app:

const express = require('express')
const socket = require('socket.io')
// open is for convenience
const open = require('open')
const app = express()

Next, we need to specify where to serve up our static files. This may change depending on the framework you use, but in my case, I'm serving up files from the public directory. Then we need to setup the server to listen on, in this case, port 8000, or whatever port you like:

const express = require('express')
const socket = require('socket.io')
const open = require('open')
const app = express()
const port = 8000  

app.use(express.static('/public'))

const server = app.listen(port, function(err) {  
  if (err) {
    console.log(err)
  } else {
    open(`http://localhost:${port}`)
  }
})

Now that we have our Express server running, we need to listen for user connecting to a socket using io.on. A user connects, and the function says, oh, we have a new user.

const express = require('express')
const socket = require('socket.io')
const open = require('open')
const app = express()
const port = 8000  

app.use(express.static('/public'))

const server = app.listen(port, function(err) {  
  if (err) {
    console.log(err)
  } else {
    open(`http://localhost:${port}`)
  }
})

const io = require('socket.io')(server); 

// Sets up the connection
io.on('connection', (socket) => {  
  console.log('a user connected');
})

With this function, we can place different listeners inside that we will link up with the client side later. The first one will listen when the user sends a new message. We'll use socket.on which takes any name, but in our case, we'll simply call it 'chat', and a callback function. When our user presses send on a new message, the message is sent through the tube to where it is caught by our socket.on function.

Once we catch the message from the client, we use io.sockets.emit. This function takes the message and sends it down the tubes to all of the other open sockets:

const express = require('express')
const socket = require('socket.io')
const open = require('open')
const app = express()
const port = 8000  

app.use(express.static('/public'))

const server = app.listen(port, function(err) {  
  if (err) {
    console.log(err)
  } else {
    open(`http://localhost:${port}`)
  }
})

const io = require('socket.io')(server); 

io.on('connection', (socket) => {  
  console.log('a user connected')

  socket.on('chat', (data) => {
    // Emits chat message to all open sockets
        io.sockets.emit('chat', data)
        console.log("Chat emitted from server")
    })
})

You can add as many listeners as you'd like, but for this tutorial, we'll keep it simple and add one more that sends a message to the console when a user disconnects:

const express = require('express')
const socket = require('socket.io')
const open = require('open')
const app = express()
const port = 8000  

app.use(express.static('/public'))

const server = app.listen(port, function(err) {  
  if (err) {
    console.log(err)
  } else {
    open(`http://localhost:${port}`)
  }
})

const io = require('socket.io')(server); 

io.on('connection', (socket) => {  
    console.log('a user connected')

    socket.on('chat', (data) => {
        io.sockets.emit('chat', data)
        console.log("Chat emitted from server")
    })

    // Disconnects
    socket.on('disconnect', () => {
      console.log('user disconnected');
    })
})

Now it's time to move to our client side which, in our case, will run in the public folder as client.js.

First, let's wire up our client side and server by using socket.io-client:

const io = require('socket.io-client')  
const socket = io('http://localhost:8000')

Then we'll set up an event listener for the send button click. I will leave this code vague since it depends on how you wire this up in your own project. You may simply have an event listener on the button in vanilla JS or you may be using something like React. Beyond what you choose, you'll want to have the following code inside that sends the message up the tubes with any other relevant information (like username, date, etc.):

// Inside your event listener
    socket.emit('chat', {
        message: message,
        username: username
    })

Once the send button is clicked, Socket.io emits the chat to the server where it's caught and sent to every open socket. The next step is to setup the 'catcher' of that data being sent back from the server. We do this using socket.on which listens for any chats being sent back down all the tubes:

socket.on('chat', (data) => {
    console.log("Received from server: " + data)
    // Do something with the data
})

You can decide how to handle the data once received. You may want to populate a div using something like document.getElementById('messages').innerHTML = "<p>" + data.message + "</p>" or if you're using something like React, you can update the state with the new message.

We have barely scratched the surface on Socket.io, but understanding the basics allowed me to learn more about sockets as the concept was hard to grasp at first.

Auld Lang Refactoring

Daniel Warren — Sun, 31 Dec 2017 19:01:18 +0000

New Year’s is filled with resolutions to work out, diet, exercise, and get more organized. This year, I’d like to get my knee in order so I can run again, continue on my vegan endeavors, and keep our apartment decluttered now that we have an infant.

Tidying up got me thinking about code and refactoring. Frameworks like React and Rails offer structures to encourage code to stay clean and tight with their uses of modules and components. But sometimes when writing JavaScript from scratch, refactoring and keeping clean code can quickly get out of hand. I wanted to create a before and after example using plain JavaScript as an exercise in refactoring.

The program is simple: use an input to add an item to an array and show the results on the page.

Here is the “before” starter code:

HTML:

 <div class="container">
  <h1>Add Item to Array</h1>
  <form id="form">
    <input type="text" id="item">
    <input type="submit">
  </form>

  <pre id="output">Ouput here...</pre>
</div>

JS:

let list = []
let form = document.getElementById('form')
let output = document.getElementById('output')

form.addEventListener('submit', (e) => {
  e.preventDefault()
  let item = document.getElementById('item')
  list.push(item.value)
  output.innerHTML = list
  item.value = ''
})

First I created an empty array named list. I grabbed the form and output using getElementById() then setup an event listener on the form. When submit is detected, I grabbed the input id (item) and pushed the value onto the list array. Once the list was updated, I populated the pre tag with the array. Finally, I cleared the input.

The code works! But much like the Cleveland Browns, just because they have uniforms, a team name, and a quarterback, doesn’t mean the organization is streamlined and firing on all cylinders.

The problem with our code is that we have three variables floating around in the global scope, which could have implications in the future if we add new variables. All of our functionality, adding the item to the list, clearing the input, and outputting the array, is packed inside our event listener, making it confusing to understand and hard to read. And if we want to add more features in the future, we’re going to have lots of cluttered code to sift through.

I learned to always write the code I wish I had, then work backwards. So in this case, I’d like to have a function to call like this to start things off:

const formListener = (form) => {}

formListener(form)

This function nicely wraps our code so we don’t have any stray variables outside roaming around like a lost Browns receiver running the wrong route.

I added our list array inside and created our event listener on our form:

const formListener = (form) => {
  let list = []
  form.addEventListener('submit', (e) => {
    e.preventDefault()
  })
}

formListener(form)

I wanted my event listener to only deal with grabbing the input value and clearing:

const formListener = (form) => {
  let list = []
  form.addEventListener('submit', (e) => {
    e.preventDefault()
    let item = document.getElementById('item')
    item.value = ''
  })
}

formListener(form)

Next, I wanted a function to add our input value to our array. Something like addItem():

const addItem = (item, list) => list.push(item)

const formListener = (form) => {
  let list = []
  form.addEventListener('submit', (e) => {
    e.preventDefault()
    let item = document.getElementById('item')
    addItem(item.value, list)
    item.value = ''
  })
}

formListener(form)

Finally, I created another function to show the array on the page, show(), and then called our formListener() function with our form:

const addItem = (item, list) => list.push(item)
const show = (list) => document.getElementById('output').innerHTML = list

const formListener = (form) => {
  let list = []
  form.addEventListener('submit', (e) => {
    e.preventDefault()
    let item = document.getElementById('item')
    addItem(item.value, list)
    show(list)
    item.value = ''
  })
}

formListener(document.getElementById('form'))

While this may be a silly example, I hope it sheds some light on the thought process that goes into refactoring, even if the un-refactored code is simple. Refactoring is a lot like writing — you write a horrible first draft, then go back and rewrite, rewrite, and rewrite until it’s clean and streamlined. Unless you’re the Browns, of course.

Frameworkless Events

Daniel Warren — Mon, 25 Dec 2017 21:52:25 +0000

In fifty years when self-driving cars rule the road, what happens when someone needs to manually drive? The autopilot malfunctions and my great-grandson, Weston, must get home to watch the Cavs play the Warriors in game seven of the NBA Finals, because modern medicine has figured out a way to keep LeBron and Curry playing at top performance well into their 80s.

But Weston has only manually driven a car once or twice in his life, the first time on a dare from a friend that resulted in the partial mangling of his parents’ garage bay.

Despite the incredible capabilities of modern JS frameworks, like React, Angular, and Vue, we probably all feel a little bit like Weston when it comes to writing plain old JS without the crutch of a framework.

I’m working on a chat application in React/Socket.io/Express where users can click on a message, respond, and the response will appear directly under the selected message. In an effort to manually drive this car, I wanted to recreate the click events in plain old JS.

I want to be able to click on and select a list item with only one item selected at a time. If I click on the same item, it will toggle the class between active and inactive. Here is what we will be building:

For this example, I will use an unordered list of the top five NBA 3-pt leaders (you can use whatever list you like, whether books or a list of movies).

<div class="container"> 
  <ul id="list">
    <p class="title">Choose a 3-Pt Leader</p>
    <li class="inactive" data-id="0">Ray Allen | <span>2973</span></li>
    <li class="inactive" data-id="1">Reggie Miller | <span>2560</span></li>
    <li class="inactive" data-id="2">Jason Terry | <span>2242</span></li>
    <li class="inactive" data-id="3">Paul Pierce | <span>2143</span></li>
    <li class="inactive" data-id="4">Kyle Korver | <span>2097</span></li>
  </ul>
</div>

I have an unordered list of five items with a class of inactive. In addition, each item has a data-id which we’ll use later. In our CSS we have two classes, active and inactive. The rest of the CSS is purely decorative:

.active {
  background: #cc0000;
  color: #fff;
  transition: .15s;
}

.inactive {
  background: #efefef;
}

For the JS, we first want to grab the unordered list:

const listOfThings = document.getElementById('list')

Next we want to add an event listener on the ul:

const listOfThings = document.getElementById('list')
listOfThings.addEventListener("click", function(event) {})

Inside of the event listener, we want to loop through all of the list items:

const listOfThings = document.getElementById('list')
listOfThings.addEventListener("click", function(event) {
  let list = document.querySelectorAll('li')
  for (let i = 0; i < list.length; i++) {
  // loop through all the list items…
  }
})

First in the loop, for the selected item, we want to toggle the class name between active and inactive. We do this by comparing the data-id on the target to the data-id on the current iteration.

const listOfThings = document.getElementById('list')

listOfThings.addEventListener("click", function(event) {
  let list = document.querySelectorAll('li')
  for (let i = 0; i < list.length; i++) {
    if (event.target.dataset.id === list[i].dataset.id) {
      if (event.target.className === 'inactive') {
        event.target.className = 'active'
      } else {
        event.target.className = 'inactive'
      }
    } 
  }
})

If we leave this as is, we would be able to select more than one item at a time. In order to prevent this, we add an else condition (if it’s not the target of the click) we set it to inactive. This ensures any item not selected doesn’t have a red background.

const listOfThings = document.getElementById('list')

listOfThings.addEventListener("click", function(event) {
  let list = document.querySelectorAll('li')
  for (let i = 0; i < list.length; i++) {
    if (event.target.dataset.id === list[i].dataset.id) {
      if (event.target.className === 'inactive') {
        event.target.className = 'active'
      } else {
        event.target.className = 'inactive'
      }
    } else {
      list[i].className = 'inactive'
    }
  }
})

The logic gets pretty confusing and there are a number of ways to write this but the above gets the job done. Originally, I had the opposite logic with two ternary operators smashed together but this felt like too much:

event.target.dataset.id !== list[i].dataset.id ? 
list[i].className = 'inactive' : 
(event.target.className === 'inactive' ? event.target.className = 'active' : event.target.className = 'inactive')

In conclusion, a good exercise is to rewrite high level framework code into simple plain JS. Not only is it good practice but it gives us an appreciation for the frameworks we use everyday.

View the final product here
http://danielwarren.io/2017/11/26/frameworkless-events

Fs-tivus for the Rest of Us

Daniel Warren — Mon, 25 Dec 2017 21:41:17 +0000

What better way to bring in the holidays than by taking a look at Node’s File System (fs) module!

At a high level, Node fs lets us read, write, create, update, and remove files from our computer using JavaScript on the back end, similar to how you would use Ruby or Python.

To use File System, I imported the module:

const fs = require(‘fs’)

For this example, let’s say we have a JSON file named data.json with a list of Christmas movies. We want to add a new movie to the file and save it to a new file called updated.json that doesn’t exist yet.

Our data.json file looks like this:

{
  "movies": [
    {
      "name": "Christmas Vacation",
      "director": "Jeremiah Chechik",
      "year": "1989"
    },
    {
      "name": "Die Hard",
      "director": "John McTiernan",
      "year": "1988"
    }
  ]
}

And the object we want to add to the JSON looks like this:

let christmasStory = {
  "title": "A Christmas Story", 
  "director": "Bob Clark",
  "year": "1983"
}

First, I read the contents of the data.json file and saved it into a variable:

fs.readFile('data.json', 'utf8', (err, data) => {
  if (err) throw err
  let obj = JSON.parse(data)
})

I used fs to access the File System module. The first argument readFile() takes is the file we want to read followed by ‘utf8’ which we add otherwise we’ll get a bunch of strange numbers that aren’t converted into characters. Since readFile() is asynchronous, I added a callback function that fires once it’s finished grabbing the data. I added in some minimal error checking, and tapped into data which holds our JSON file data. Finally, since the data read from the file comes to us a string, I converted it to JSON using JSON.parse().

Next, I pushed the new movie, A Christmas Story, into the movies array in the JSON.

fs.readFile('data.json', 'utf8', (err, data) => {
  if (err) throw err
  let obj = JSON.parse(data)
  obj.movies.push(christmasStory)
})

When writing JSON to a file, we have to turn it into a big string, the way it came to us, otherwise the file doesn’t know what to do with the data. To do this, I used JSON.stringify() and saved it into a variable named updated:

fs.readFile('data.json', 'utf8', (err, data) => {
  if (err) throw err
  let obj = JSON.parse(data)
  obj.movies.push(christmasStory)
  let updated = JSON.stringify(obj, null, 2)
})

To finish, I used fs.writeFile() which takes the file to write to and then the data you want to write. WriteFile() will create the file if it doesn’t exist.

fs.readFile('data.json', 'utf8', (err, data) => {
  if (err) throw err
  let obj = JSON.parse(data)
  obj.movies.push(christmasStory)
  let updated = JSON.stringify(obj, null, 2)
  fs.writeFile('updated.json', updated)
})

The finished code looks like this. To run the code, go to the root of your folder and run node yourFileName. Once run, you'll see the new updated.json file appear in the project's root:

const fs = require('fs')

let christmasStory = {
  "title": "A Christmas Story", 
  "director": "Bob Clark",
  "year": "1983"
}

fs.readFile('data.json', 'utf8', (err, data) => {
  if (err) throw err;
  let obj = JSON.parse(data)
  obj.movies.push(christmasStory)
  let updated = JSON.stringify(obj, null, 2)
  fs.writeFile('updated.json', updated)
})

We only scratched the surface of fs, but as you can see, the module gives us endless possibilities for creating and adding data files in our applications.

No More Foo, Bar, and Baz

Daniel Warren — Mon, 25 Dec 2017 21:24:24 +0000

When I was a kid, my best friend’s dad owned a computer company and told us he knew the secret to Fubar. He said he was sworn to secrecy and to this day has never divulged the secret. If you’re not familiar with Fubar, he was a 1980s robot whose name stood for Futuristic Uranium Bio-Atomic Robot. He seemed so life-like and I dreamed of owning one as a kid. Of course, now that I look back at old Fubar videos, it’s pretty clear Fubar was nothing but a big remote control car with a walkie-talkie strapped to his head, probably operated by a guy in a nearby room.

This brings me to my next point. Maybe they’re not related, but I’d like to talk about the use of “foo, bar, baz” in coding tutorials. I’m not quite sure if foo/bar/baz comes from Fubar, but they sound similar enough to make my point.

For those of you who write tutorials, you do such great work and we are appreciative. Without tutorials, the world of coders would be lost. But, for the love of God, please stop using foo, bar, and baz in your tutorials.

Unfortunately this disease has reached epidemic proportions. I recently ran into a tutorial where the writer explained the concept of associations in ActiveRecord using a similar example to below (I’m code-paraphrasing here):

class Foo < ActiveRecord::Base
  has_many :bazzes
  has_many :bars, through: :bazzes
end 

class Bar < ActiveRecord::Base
  has_many :bazzes
  has_many :foos, through: buzzes
end 

class Baz < ActiveRecord::Base
  belongs_to :foo
  belongs_to :bar
end

First of all, what the hell is a foo and a baz? We know what a bar is but are we talking about a bar/pub or a parallel bar? And how does it relate to a foo? In what capacity does a foo have many bazzes? For me, so many of these concepts take time to grasp, but make it almost impossible when the examples don’t have concrete meaning grounded in reality. Tutorial writers are much better off using real world examples, like how a tweet belongs to a user, or how a dog has many bones.

So please, keep writing tutorials, but do not use foo, bar, or baz!

Clarifying Async and Promises

Daniel Warren — Mon, 25 Dec 2017 21:18:35 +0000

I wanted to clearly present async and promises since the concepts were hard for me to understand at first. Here’s my attempt:

Synchronous javascript means to wait for one action to complete before moving onto the next. For example, imagine a line of five small tables. On all of the tables is a coin, with the exception of the second table, which contains a spinning top. Your job is to go along to each table, flip the coins and spin the top. If you’re doing this synchronously, you would go to the first table, flip the coin and move to the next table. But at the second table, you spin the top but you can’t move to the next table until the top stops spinning. In the real world, this can lead to a bad user experience if you have to wait for something to finish before the rest of the page loads.

Asynchronous requests solve this problem. Instead of waiting for each function to finish, the action is passed to a thread outside of JS. When the request is fulfilled, it’s added to the end of the thread and the callback function will fire. So in our table example, once you spin the top, you can move onto the next table and flip the coin. When the top stops spinning, the table will get shifted to the end of the queue and be ready once you reach the end of the tables.

This ties into promises. A promise is essentially an object that represents an action that hasn’t finished yet but will finish at some point down the road. This makes it easier to handle multiple async requests. When the promise has resolved, we can use the .then function to do something with the returned data. This also makes it easier to chain .then requests together. For example, if we make a request to a server for a token, we want to wait for the token to come back. Once we receive the token, we parse it, and finally do something with that data.

Another example would be if we had an application that is making three separate API requests. Say one API request is for an image, another for the comments, and another for the user data. But we want to wait for all the data to come back before we update the UI so we can use a promise to wait for all the data to finish and then display it to the user. We can use .all to accomplish this with promises.

As a final example below to illustrate promises, we see that A will fire first. Then a fetch request is fired where we wait for a promise from C and then for D. In the meantime, B is fired while we wait. Once C resolves, it fires, then finally D resolves and it fires.

apiCall = () => {
    console.log(‘A')
    fetch('http://someAPI/data')
        .then(res => {
            console.log(‘C’)
            return res.json()
    })
        .then(theData => console.log(‘D’, theData))
        console.log(‘B‘)
}