farskid

// Test tree with contrived data
let testTree = {
  value: 1,
  child: [
  {value: 2, child: [
    {value: 7, child: []},
    {value: 8, child: []},
    {value: 9, child: []},
  ]},
  {value: 3, child: []},

farskid

import { createMachine, assign } from "xstate"
import {
  zipCodeRegex,
  verifyZipcode,
  formatPhoneNumber,
  validatePhoneNumber,
} from "../../utils/quiz_form_validation"

//
export const stepMachine = createMachine(

farskid

#...

function gitzip() { 
	git archive -o $@.zip HEAD
}

#... gitzip ZIPPED_FILE_NAME

farskid

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

farskid

user-package-stats

I was poking around trying to figure out all the packages I have access to publish and got curious. So I write this little script to determine the download stats for all the packages I have publish access to.

Feel free to try it yourself. Just change the username passed to getUserDownloadStats.

By default, the stats are sorted by their average daily downloads (descending). That should give you an idea of the most "popular" package of a given user relative to how long that package has been around.

You can use it with npx like so:

farskid

/**
 * Takes arguments in the form of --arg-name value and puts them into an object (argMap).
 * Argument keys begin with double hyphens and additional hyphens are converted to camelCase.
 * 
 * E.g. `node quick-argument-parser.js --test-arg1 'value1' --test-arg2 'value2'` will create argMap with the value:
 * ```
 * {
 * 	testArg1: 'value1',
 * 	testArg2: 'value2'
 * }

farskid

# Pass the env-vars to MYCOMMAND
eval $(egrep -v '^#' .env | xargs) MYCOMMAND
# … or ...
# Export the vars in .env into your shell:
export $(egrep -v '^#' .env | xargs)

farskid

I bundled these up into groups and wrote some thoughts about why I ask them!

If these helped you, I'd love to hear about it!! I'm on twitter @vcarl_ or send me an email carl.vitullo@gmail.com

Onboarding and the workplace

https://blog.vcarl.com/interview-questions-onboarding-workplace/

• How long will it take to deploy my first change? To become productive? To understand the codebase?
• What kind of equipment will I be provided? Will the company pay/reimburse me if I want something specific?

farskid

sudo rm -rf /Applications/Tuxera\ Disk\ Manager.app
sudo rm -rf /Library/Application\ Support/Tuxera\ NTFS
sudo rm -rf /Library/Filesystems/fusefs_txantfs.fs
sudo rm -rf /Library/Filesystems/tuxera_ntfs.fs

farskid

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

If it's not fun anymore, you get literally nothing from maintaining a popular package.

One time, I was working as a dishwasher in a restu