KHTDR – khtdr home page

css-vars-design-token

Mon, 28 Oct 2024 00:00:00 +0000

CSS Variables as Design Tokens: A Simple Approach to Design Systems

Design systems are essential in modern web development. They help maintain consistency, speed up development, and ensure a cohesive user experience across applications. For small teams or even solo developers, a design system can really make things easier. It cuts down on repeated design decisions by providing reusable components and design guidelines and allowing developers to focus on building features instead of worrying about inconsistencies. This leads to faster iterations, easier onboarding for new team members, and a more unified product.

CSS variables, or custom properties, are entities defined by CSS that let you store values for reuse throughout a document. They enable dynamic styling and can be updated at runtime, making them a powerful tool for creating flexible and maintainable design systems.

Why CSS Variables Are Good Enough

While there are many sophisticated design token solutions available, native CSS variables have evolved to be remarkably capable:

They're built into the platform
They cascade naturally through the DOM
They can be updated dynamically
They work with any framework (or no framework)
They're performant
Browser support is excellent

Introducing css-vars-design-token

The css-vars-design-token package offers a lightweight approach to design tokens using CSS variables. It provides:

Simple theme switching
TypeScript support
React integration
Zero dependencies beyond React itself

Basic Usage

Here's a simple example:

// Create the `light` and `dark` themes.
const themes = {
 light: {
 color: {
 primary: '#0066cc',
 background: '#ffffff',
 text: '#333333'
 }
 },
 dark: {
 color: {
 primary: '#66b3ff',
 background: '#1a1a1a',
 text: '#ffffff'
 }
 }
};

// Wrap your components in a provider
function App() {
 return (
 <CssVarsDesignTokenProvider themes={themes}>
 <MyComponents />
 </CssVarsDesignTokenProvider>
 );
}

Your CSS can then use these tokens:

.button {
 background-color: var(--color-primary);
 color: var(--color-text);
}

.card {
 background-color: var(--color-background);
 border: 1px solid var(--color-primary);
}

Advanced Features

Deep Tokens

The library automatically flattens deep token structures:

const themes = {
 light: {
 spacing: {
 small: '0.5rem',
 medium: '1rem',
 large: {
 default: '2rem',
 mobile: '1.5rem'
 }
 }
 }
};

This creates CSS variables like --spacing-small, --spacing-medium, --spacing-large-default, and --spacing-large-mobile.

Theme Switching

The library provides a hook for easy theme switching:

function ThemeToggle() {
 const { theme, toggle } = useCssVarsDesignTokenContext();
 return (
 <button onClick={toggle}>
 Current theme: {theme}
 </button>
 );
}

Real-World Applications

Responsive Design

CSS variables work seamlessly with media queries:

:root {
 --sidebar-width: var(--layout-sidebar-default);
}

@media (max-width: 768px) {
 :root {
 --sidebar-width: var(--layout-sidebar-compact);
 }
}

Component Libraries

Design tokens can help create consistent component libraries:

function Button({ variant = 'primary', children }) {
 return (
 <button
 style={{
 backgroundColor: `var(--color-${variant})`,
 padding: 'var(--spacing-medium)',
 borderRadius: 'var(--border-radius-medium)'
 }}
 >
 {children}
 </button>
 );
}

You even have access to the current token values themselves, if needed:

function ({ children }) {
 const { token } = useCssVarsDesignTokenContext()
 const newColor = desaturate(token.color.backgroundColor)
 return (
 <div style={{ backgroundColor: newColor }}>
 {children}
 </div>
 );
}

Benefits Over Alternative Approaches

Simplicity: No build tools or preprocessors required
Performance: CSS variables are highly optimized in modern browsers
Developer Experience: Easy to debug using browser dev tools
Framework Agnostic: The underlying CSS variables work everywhere
Progressive Enhancement: Falls back gracefully if JavaScript fails

Getting Started

Install the package:

npm install css-vars-design-token

The library weighs less than 1KB gzipped and has zero dependencies beyond React.

Check out the GitHub repository for more examples and documentation.

Additional Links

]]>

opts.js

Fri, 02 Aug 2019 00:00:00 +0000

opts.js is a Javascript helper library for command-line applications, for accepting and parsing command-line arguments, flags and options, and automatically generating a useful help message.

Introduction to Opts.js

Why choose opts.js over something bigger and better?

Small : Under 10kb, uncompressed.
Stable : Relatively unchanged since 2010. See changelog.
Standalone : No package manager necessary, no compiling needed. See src/opts.js.
Tested : Millions of downloads per year. See npm/opts.

Quick-Start example

The following example set up a custom "version" function, and opts in to the automatic help message. No pun intended.

opts/examples/example1.js

var opts = require('opts');

var options = [
 { short : 'v'
 , long : 'version'
 , description : 'Show version and exit'
 , callback : function () { console.log('v1.0'); process.exit(1); }
 }
];

opts.parse(options, true);
console.log('Example 1');
process.exit(0);

node ./example1

Example 1

node ./example1 --help

Usage: node ./example1 [options]
Show this help message
--help
Show version and exit
-v, --version

node ./example1 -v

v1.0

See more examples below.

Installation

No NPM dependencies are required

To use opts.js, you do not need to use NPM or any package manager. It is written in plain-old Javascript, and can be downloaded and included in your Node.js project as-is. All of the examples use this approach.

cd /path/to/your/project
curl -o opts.js https://raw.githubusercontent.com/khtdr/opts/master/src/opts.js

Typescript and NPM packages for convenience

If you are using NPM in your project, you can install it using the name opts.

npm install opts

Basic usage and setup

To use, import the library and call opts.parse with your configurations. The various types of configurations are covered further down.

var opts = require('opts');
opts.parse(options, arguments, help);

or with the more modern syntax

import * as opts from 'opts';
opts.parse(options, arguments, help);

If you installed opts with NPM, the typescript definitions should automatically be available in your editor. Otherwise you can download the definition (.d.ts) file here.

API configurations

opts.parse(options, arguments, help)

Options are flag-arguments. Arguments are everything else. Consider the following hypothetical command for starting a server that listens on http://0.0.0.0:4000

node ./my-app start --host 0.0.0.0 -p 4000

In this example, the options are --host 0.0.0.0 and -p 4000. The argument is start. The arguments can be after, before, or among the options.

Options

options is an array of option objects. Each option in the array can have the following fields. None are required, but you should at least provide a short or long name.

let options = [
 { short : 'l',
 long : 'list',
 description : 'Show a list',
 value : false, // default false
 required : true, // default false
 callback : function (value) { ... },
 }, // ... followed by more options
];

Arguments

arguments require less configuration. This is an optional argument to opts.parse:

let arguments = [
 { name : 'script',
 required : true, // not required by default
 callback : function (value) { ... },
 }
];

Help auto-generator

Finally, you can add an automatically generated help message by passing a last parameter of true. This is also an optional argument to opts.parse.

opts.parse(options, true);
// or if you want more control, you can do:
/*
 options.push({
 long : 'help',
 description : 'Show this help message',
 callback : require('opts').help,
 }
 opts.parse(options);
*/

More examples

Showcase of features and options

opts/examples/example2.js

/**
 * More complex example.
 *
 * Run:
 * node example2.js --help
 * and play with the options to see the behavior.
 *
 * This example shows different ways of using the library. It is deliberately
 * inconsistent. Choose the style that suits you best.
 */

var opts = require('opts')
 , host = 'localhost'; // default host value

var options = [
 { short : 'v'
 , long : 'version'
 , description : 'Show version and exit'
 , callback : function () { console.log('v1.0'); process.exit(1); }
 },
 { short : 'l'
 , long : 'list'
 , description : 'List all files'
 },
 { short : 'f'
 , long : 'file'
 , description : 'Load a file'
 , value : true
 , required : true
 },
 { short : 'd'
 , long : 'debug'
 , description : 'Set a debug level'
 , value : true
 },
 { short : 'h'
 , long : 'host'
 , description : 'The hostname to connect to'
 , value : true
 , callback : function (value) { host = value; } // override host value
 },
 { short : 'p'
 , long : 'port'
 , description : 'The port to connect to'
 , value : true
 },
];

opts.parse(options, true);

var port = opts.get('port') || 8000 // default port value
 , debug = opts.get('d') || 'info' // default debug value
 , file = opts.get('f')
 , list = opts.get('list');

var arg1 = opts.args()[0]
 , arg2 = opts.args()[1];


if (list) console.log('List arg was set');
if (file) console.log('File arg was set: ' + file);
console.log('Debug level is: ' + debug);
console.log('Host is: ' + host);
console.log('Port is: ' + port);

if (arg1) console.log('Extra arg 1: ' + arg1);
if (arg2) console.log('Extra arg 2: ' + arg2);

process.exit(0);

Conflict detection

opts/examples/example3.js

/**
 * Simple example that is broken by design (conflicting options)
 *
 * Examples:
 * $ node example3.js
 * > Conflicting flags: -v
 */

var opts = require('opts');

var options = [
 { short : 'v'
 , description : 'Show version and exit'
 },
 { short : 'v'
 , description : 'Be verbose'
 },
];

opts.parse(options);
console.log('Example 3');
process.exit(0);

Using named arguments and from within a library

opts/examples/example4.js

/**
 * Advanced example using namespaces for a library and named arguments
 *
 * Run:
 * node example4.js --help
 * and play with the options to see the behavior.
 */

var opts = require('opts')
 , host = 'localhost'; // default host value

// Example of using some library in the same app
var libOpts = [
 { short : 'l'
 , long : 'list'
 , description : 'Show the library list'
 , callback : function () { console.log('mylib list!'); },
 },
];
opts.add(libOpts, 'mylib');

var options = [
 { short : 'l' // deliberately conflicting with 'mylib' option
 , long : 'list'
 , description : 'List all files'
 },
 { short : 'd'
 , long : 'debug'
 , description : 'Set a debug level'
 , value : true
 },
];

var arguments = [ { name : 'script' , required : true }
 , { name : 'timeout' }
 ];

opts.parse(options, arguments, true);

var debug = opts.get('d') || 'info' // default debug value
 , list = opts.get('list');

var script = opts.arg('script')
 , timeout = opts.arg('timeout') || 30;


if (list) console.log('List arg was set');
console.log('Debug level is: ' + debug);
console.log('Script is: ' + script);
console.log('Timeout is: ' + timeout);

process.exit(0);

You can find the source code and all examples at Github, github.com/khtdr/opts.

]]>

Resume

Fri, 02 Aug 2019 00:00:00 +0000

Resume for Jose Mazzarelli

Summary

With 20+ years of experience building reliable software across various industries, I am skilled in full-stack development and team leadership focusing on secure web application development.

Contact Information

Professional Experience

Private Consulting `2024 - Present`

AI Consultant

Part of a small team providing AI consulting and services.

Postgres Typescript LLM RAG Vector Search
Financial document store and semantic search with LLM answer completion.
Typescript React Chat App Document Viewing
Chat app for interacting with backend RAG API.

– -

VZBL `2023 - Present`

Co-founder Lead Developer

Leads the application development, focusing on application architecture and data exploration.
Designs and builds key features including onboarding flows, dashboards, and data visualizations.
Built features including user management, multi-tenant security, and customizable interfaces.

– -

SocialChorus/FirstUp `2018 - 2023`

Senior Software Engineer Team Lead
Typescript Ruby Rails React Redux Node.js Redis Postgres Puppeteer NPM MJML Cypress RSpec

Interviewed several hundred candidates as part of the core hiring team.
Managed teams in publishing and analytics/reporting in Agile and Kanban processes.
Led the transition to modern front-end tools, improving app performance and user experience.
Designed and built custom publishing tools used to create content for millions of users.
Integrated Metabase and Tableau into the product for analytics and reporting.

– -

Kount `2007 - 2018`

Software Engineer UX Architect Software Architect
jQuery Javascript CoffeeScript PHP Oracle (PLSQL) React Redux Node.js OWASP JWT PHPUnit

One of the original engineers at Kount, contributing to its growth and eventual acquisition by Equifax.
Focused on speed and security, working on authentication, dependency injection, and theming frameworks.
Responsible for software security training and best practice implementations.
Developed various customer facing and internal tools.

– -

Boise State University `2014 - 2018`

Adjunct Lecturer

Taught Intro to Web Development course.
Taught Programming Languages course.

– -

YourList `2011`

Lead Developer Software Architect

Python MySQL MQ
Developed a distributed scraping algorithm.
Javascript jQuery PHP MySQL
Clone of popular sell-it-yourself website.

– -

Keynetics `2006 - 2007`

Full Stack Developer

Javascript jQuery PHP Perl Python
Worked on financial processing code and prototyped security tools.

– -

PersonalShopper `2005 - 2006`

Full Stack Developer)

Javascript jQuery Java Oracle

– -

Idaho Transportation Department `2002 - 2004`

Intern Web Developer

Javascript ASP.NET MS SQL
Worked with many departments to develop intranet and website applications.
Project News Announcement

Education

BS Computer Science Boise State University 2004

]]>

A Developer's Design Implementation Checklist

Fri, 24 Jan 2025 00:00:00 +0000

Mockups never tell the whole story

After nearly 25 years of leading UI/UX development, I've learned that the difference between a successful project and a death march often comes down to one thing: understanding the full scope of work - especially the parts that aren't in the mockups.

I love working with designers. Their creativity and vision are essential to creating great products. But even the most talented designers don't always think in terms of application state and edge cases. That's where we developers come in.

A design checklist for developers

The key to delivering smiles instead of stress is realistic estimation. You need to account for everything - not just what's visible in those perfectly crafted Figma files. Without this knowledge, you'll find yourself days before delivery, discovering whole new categories of work nobody planned for.

I've seen this play out countless times: the mockup shows a beautifully designed dashboard with sample data perfectly laid out. But what happens when: An admin accidentally deletes a critical record

The user has 10x more items than the design shows
Someone's name is in Korean and breaks the layout
The data is empty, slow to arrive, or malformed
The user is on a slow mobile connection
Someone needs to navigate the interface with a screen reader

These aren't edge cases - they're the reality of how people will use your application. And accounting for them up front is the difference between a smooth delivery and a last-minute scramble.

Over the years, I've developed a systematic approach to reviewing designs. Here's my battle-tested checklist that helps surface these requirements early. I've organized it by major concern areas, but feel free to adapt it to your workflow.

The Checklist

Layout Structure — The foundation of any interface is its layout structure. Getting this right early is crucial because it affects everything else. Layout decisions impact both the visual hierarchy and the technical implementation approach. Here's what to clarify:

Base layout composition and hierarchy	What are the major layout regions/sections?
	How do sections relate spatially to each other?
	What grid system or layout technique should be used?
Responsive behavior	At what pixel widths do layouts change?
	Which elements reflow vs hide on mobile?
	How do navigation elements transform at breakpoints?
Panel sizing/interactions	Are panels resizable?
	What are min/max dimensions?
	How do panels behave when content overflows?
Overflow handling	Which containers should scroll?
	Is scroll behavior smooth or standard?
	Are there sticky elements during scroll?
Loading states	Which regions show loading indicators?
	Are there placeholder layouts while loading?
	How do loading states affect layout stability?

Input Elements — Forms and input elements are where users directly interact with your application. They're also notorious for having complex state management and validation requirements. Every input needs careful consideration of its various states and behaviors:

Visual states	What color/style changes on hover?
	How is focus indicated visually?
	What visual feedback shows disabled state?
Validation states	Where do error messages appear?
	How are required fields indicated?
	What triggers validation checks?
Label/text sourcing	Are there placeholder values?
	Do any labels update dynamically?
	Where are text strings stored/managed?

Text Content — Text content is deceptively complex. It's not just about displaying strings - it's about handling dynamic content that can vary wildly in length, language, and format. These requirements help prevent layout breaks and poor user experience:

Content source	What API endpoints provide text?
	How often does content update?
	Is content cached client-side?
Loading states	Should skeleton layouts match content shape?
	What placeholder width/heights to use?
	When do loading indicators appear/disappear?
Truncation handling	At what width/height does text truncate?
	Is there a "show more" mechanism?
	How are long words handled?
Empty states	What message appears when no content exists?
	Are there suggested actions shown?
	How does empty state affect layout?

Transient Elements — Tooltips, modals, popovers, and other temporary UI elements need special attention. They often have complex triggering logic and need to play nice with other elements on the page. Here's what to nail down:

Trigger conditions	What user actions show/hide the element?
	Is there a delay before showing/hiding?
	Can system events trigger the element?
Animation specs	What properties are animated?
	What timing functions are used?
	How do animations change on mobile?
Coexistence rules	Which elements can show simultaneously?
	Do elements affect each other's position?
	How is z-index managed?

Data Tables/Lists — Tables and lists are where complex data interactions happen. They often need to handle sorting, filtering, and pagination while maintaining performance with large datasets. These questions help define the complete behavior:

Sorting behavior	Is initial sort order specified?
	Can multiple columns be sorted?
	How is sort direction indicated?
Filtering mechanisms	How do multiple filters combine?
	Is filter state preserved?
Empty/loading states	What appears during initial load?
	How is "no results" handled?

Implied CRUD Features — Almost every data-driven interface needs more than just the "happy path" shown in mockups. Create, Read, Update, Delete operations often come with a host of implied requirements that aren't visible in the design but are essential for real-world usage:

Record management	How are new records created?
	Can records be archived instead of deleted?
	Is record cloning/duplication needed?
	What confirmation is required for destructive actions?
Edit workflows	Is inline editing supported?
	How are unsaved changes handled?
	What validation occurs before save?
	Can edits be reverted/cancelled?
Audit requirements	Are changes tracked with timestamps?
	Do we show who made changes?
	Is version history needed?
	How long is history retained?
Batch operations	Can multiple items be selected?
	What bulk actions are available?
	How is batch operation progress shown?
	How are partial failures handled?

Using This Checklist

Grab this checklist and run through it during your first design handoff meeting. It's way better to figure this stuff out upfront than to discover halfway through development that nobody thought about what happens when the API times out.

These are the things that work for me, but feel free to adapt it to your needs.

]]>

A Tailwind-CSS development server

Mon, 07 Jan 2019 00:00:00 +0000

Simple quick way to get started learning and playing with Tailwind CSS

Example output while running dev-server, shown here:

Features

No "transpiling" configuration is needed (or used).
No build tools need to be set up.
Tiny reactive web server: ~115 lines of code with lots of comments.
Minimal dependencies:
- chalk for color,
- socket.io for server <—> browser communication,
- and tailwindcss of course.

Installation

Clone the GIT repository, and install the dependencies.

git clone https://github.com/khtdr/tailwind-dev-server.git
cd tailwind-dev-server
yarn

Running

yarn start

Then open your browser to: http://localhost:8080

Development

Edit any of the following entry point files:

Changes will be recompiled and automatically refreshed in your browser. Errors will be displayed in the server output.

Create any additional HTML files as needed, using ./index.html as a starting-point reference.

Building

If you like what you see and want to save it and use it, run:

yarn build

And now you can use your newly-built ./tailwind-bundle.css stylesheet however you like.

]]>

Dark-Mode Light-Mode Css

Sun, 16 Aug 2020 18:53:52 -0600

Use a media query to set different values for variables in dark-mode.

:root {
 --background-color: #eee;
 --text-color: #222;
}

@media (prefers-color-scheme: dark) {
 :root {
 --background-color: #222;
 --text-color: #eee;
 }
}

body {
 background-color: var(--background-color);
 color: var(--text-color);
}

]]>

pageboy

Fri, 14 Aug 2020 18:46:11 -0600

pageboy

Write your shell scripts in any combination of scripting languages.

Example Script example.pb

#!/usr/bin/env pageboy
echo in Bash
$PAGE php
echo back to Bash

#!/usr/bin/env php
<?php echo "in PHP\n";

Running the following, produces:

chmod +x ./example.pb
./example.pb

in Bash
in PHP
back to Bash

You can mix and match all you want. If your script uses valid shebangs, it will work. If it doesn’t, it’s a bug and please let me know. It also supports the (not quite right) awk shebang: #!/usr/bin/env awk.

Test suite status

./run-tests.sh

pageboy-v2.1.3
./pageboy-test # runs as pageboy script
./pageboy-test -r <page> # runs requested page
./pageboy-test -p <page> # prints requested page
./pageboy-test -c # compiles to bash script
./pageboy-test -d # dumps page table
./pageboy-test -h # shows this message
https://github.com/khtdr/pageboy
./tests/aliased.pb ... passed
./tests/args.pb ... passed
./tests/awk.pb ... passed
./tests/confusing.pb ... passed
./tests/dump.pb ... passed
./tests/lots.pb ... passed
./tests/named.pb ... passed
./tests/pageboy.pb ... passed
./tests/paths.pb ... passed
./tests/plain-bash.pb ... passed
./tests/print-php.pb ... passed
./tests/pwd.pb ... passed
./tests/run-php.pb ... passed
./tests/version.pb ... passed

Installation & quickstart

Current version: 2.1.3
Download the pageboy bash script and put into your $PATH (ie. ~/bin/).
Start using #!/usr/bin/env pageboy as your shebang line in your bash scripts.
Call other “pages” of your script by using the pre-defined $PAGE command in your scripts.

#!/usr/bin/env pageboy
$PAGE php | wc

#!/usr/bin/env php
<?php
phpinfo();

 934 3524 29671

If you want multiple pages of the same language, append an index, starting at 1, to the pagename.

#!/usr/bin/env pageboy
cat <($PAGE php1) <($PAGE php2)

#!/usr/bin/env php
<?php echo "one";

#!/usr/bin/env php
<?php echo "two";

onetwo

You can distribute a version of your script without the dependency on pageboy by compiling it:

# copy above into `onetwo.pb`
onetwo.pb -c > onetwo.sh
chmod +x ./onetwo.sh
./onetwo.sh

onetwo

Big Example

#!/usr/bin/env pageboy
cat <($PAGE php) <($PAGE ruby) <($PAGE bash1) <($PAGE bash2) <($PAGE php2)

#!/usr/bin/env php
<?php
for ($i=10; $i<=20; $i++) {
 echo $i . "\n";
}

#!/usr/bin/env ruby
5.times do
 puts "Hello, World! ~ruby1"
end

#!/bin/bash
echo "Hello, World! ~bash2"
whoami

#!/usr/bin/env bash
env | grep TERM

#!/usr/bin/env php
<?php
echo __DIR__;

10
11
12
13
14
15
16
17
18
19
20
Hello, World! ~ruby1
Hello, World! ~ruby1
Hello, World! ~ruby1
Hello, World! ~ruby1
Hello, World! ~ruby1
Hello, World! ~bash2
khtdr
TERM_PROGRAM=iTerm.app
TERM=xterm-256color
ITERM_PROFILE=Default
ITERM_SESSION_ID=w0t0p0
/home/khtdr/

Standard features

pageboy -h

pageboy-v2.1.3
pageboy # runs as pageboy script
pageboy -r <page> # runs requested page
pageboy -p <page> # prints requested page
pageboy -c # compiles to bash script
pageboy -d # dumps page table
pageboy -h # shows this message
https://github.com/khtdr/pageboy

More examples can be found in the tests directory.

Advanced features

Pages can be named, see pageboy/tests/named.pb
Args can be passed in, see pageboy/tests/args.pb

The full source code and examples are available at: khtdr/pageboy

]]>

treeify-paths

Fri, 14 Aug 2020 18:46:11 -0600

Introduction

Useful when converting a list of file names into a nested UL/LI tree. Perfect for site maps, and directory listings.

Provide a list of file names:

blog/all.html
blog/2036/overflows.html

And recieve a directory-like tree:

blog
- all.html
- 2036
  - overflows.html

Installation

Install it with NPM:

npm install --save treeify-paths

Import with modern syntax:

import treeifyPaths from "treeify-paths";

Or if you are not using NPM, install the library by downloading the source file directly and including it in your project:

curl -o treeify-paths.js "https://raw.githubusercontent.com/khtdr/treeify-paths/blob/master/dist/treeify-paths.js"

Load with classic syntax:

let treeify_paths = require("./treeify-paths").default;

The library itself is written in a few lines of typescript.

Example Usage

This module provides a function treeifyPaths that takes a list of file names and returns a directory-like tree.

type Tree :{
 path :string // full path to this node
 name :string // name of this leaf
 children :Tree[] // sub tree of trees and leaves
}
treeifyPaths(paths :string[]) => :Tree

This example produces prints the following output:

import treeifyPaths from 'treeify-paths';
console.log(JSON.stringify(treeifyPaths([
 'about.html',
 'careers',
 'careers/job-1.html',
 'careers/job-2.html',
 'to/some/page.aspx',
]), null, 3);

{
"path": "",
"name": "",
"children": [
{
"path": "about.html",
"name": "about.html",
"children": []
},
{
"path": "careers",
"name": "careers",
"children": [
{
"path": "careers/job-1.html",
"name": "job-1.html",
"children": []
},
{
"path": "careers/job-2.html",
"name": "job-2.html",
"children": []
}
]
},
{
"path": "to",
"name": "",
"children": [
{
"path": "to/some",
"name": "",
"children": [
{
"path": "to/some/page.aspx",
"name": "page.aspx",
"children": []
}
]
}
]
}
]
}

Online Interactive Examples

Testing

The mocha tests have many examples

> treeify-paths@1.0.2 pretest khtdr/treeify-paths
> tsc lib.ts && mv lib.js treeify-paths.js

> treeify-paths@1.0.2 test khtdr/treeify-paths
> mocha tests.js

 treeifyPaths([...arguments])
 arguments: none
 ✓ should return an empty object
 arguments: empty list
 ✓ should return an empty object
 arguments: list with a single file
 ✓ should return a single file
 ✓ should return with nested children
 arguments: multiple file names
 ✓ should return with nested children
 ✓ should alphabetize
 ✓ should ignore duplicates

 7 passing (8ms)

The full source code and examples are available at: khtdr/treeify-paths

]]>

react-zondicons

Fri, 14 Aug 2020 17:17:45 -0600

A dependency-free, small, fast, good-looking React SVG icon set.

See: http://khtdr.com/react-zondicons/ for installation, usage, documentation, and examples.

Source Code at https://github.com/khtdr/react-zondicons

]]>

Simple live-reloading Nodejs web server

Fri, 01 Jan 2016 00:00:00 +0000

Building your own live-reloading web server

Follow along and build your own automatically-refreshing web server, as shown here:

This setup assumes you know and use Node and NPM

You are editing HTML, CSS, and Javascript by hand, because you like it. You've had some of that hot-reloading goodness before, and you want it now, too.

You don't feel like spending the weekend reading Webpack docs, so you decide that it should only take a few dozen lines of Javascript, at most, to roll your own.

You already have node and npm installed. So you go for it.

Planning a solution

You will want to be able to:

serve static files
refresh the page whenever a file changes

For serving static files, there are many options to choose. The best choice will be the one that allows you to solve the "refresh" problem easiest.

But how can you refresh the page when a file changes? Your browser will not have direct access to the files you are editing, so it will rely on a smart web-server that has access to your file system.

You will need to:

detect when a file changes
send a signal from the server to the web browser
trigger a refresh on the page

Simple enough :)

Putting the solution together

Building the web server

Express.js has a built-in solution for serving static files. And Node.js already has the http server. Start by creating a project directory and installing the first dependency.

mkdir ./live-reload-server
cd ./live-reload-server
npm init -y
npm install express

This HTTP server will listen on port 8080 and serves files found in the same directory.

var express = require('express');
var app = express();
app.use(express.static(__dirname));

var http = require('http').Server(app);
http.listen(8080);

Save the code above to a file named ./server.js and run it:

node server.js

You can verify it is working by opening a browser and going to https://localhost:8080/server.js. You will see your code that is running. Now, create a minimal webpage with a reference to a stylesheet.

Create the HTML and save it to ./index.html

<!DOCTYPE html>
<html>
 <head>
 <link rel='stylesheet' href='/theme.css' />
 </head>
 <body>
 Greetings!
 </body>
</html>

and the CSS…

echo "body { background-color:yellow }" > ./theme.css

Make sure the server is running, and go to https://localhost:8080. You will see a yellow page with your greeting. So far, so good!

Implementing the "live-reload" feature

Node.js provides a file-watcher you can use to monitor the directory for changes. But the docs also have something to say about using this feature.

The fs.watch API is not 100% consistent across platforms, and is unavailable in some situations.

The recursive option is only supported on OS X and Windows.

Luckily(?) for you, this is good enough to get started. You will still need to signal to the browser when a change is detected, and for that you can use Socket.io.

npm install socket.io socket.io-client

The code is straight forward: watch the working directory for changes and emit an event with Socket.io.

var fs = require('fs');
var io = require('socket.io')(http);
fs.watch(__dirname, { recursive:true }, function () {
 io.emit('file-change-event');
});

The Socket.io server can be started various ways. Here it is given the HTTP server from the previous step.

Finally, a puzzle to solve. Something needs to listen for the file-change-event emitted by the server. Upon receiving the event, the page also needs refreshed. So it makes sense to put the "listening code" on the webpage itself.

For obviously obvious reasons, you don't want to add the javascript to every page you fiddle with. Better to have the server inject it automatically for you!

So what is this "listening code" that needs to be on every HTML page?

<script src="/node_modules/socket.io-client/dist/socket.io.js"></script>
<script>
 var socket = io();
 socket.on("file-change-event", function () {
 window.location.reload();
 });
</script>

The snippet above includes the client library that we installed with NPM earlier. It creates a new Socket.io client, and upon receiving the file-change-event from the server, reloads the page.

Now you need to serve that snippet of javascript along with every HTML page. Back to Express.

Write a GET handler that intercepts requests for HTML pages and appends the "listening code" to the page.

app.get('/index.html', function (_, res) {
 fs.readFile(__dirname + '/index.html', function (_, data) {
 res.send(data
 + '<script src="/node_modules/socket.io-client/dist/socket.io.js"></script>'
 + '<script>'
 + ' var socket = io();'
 + ' socket.on("file-change-event", function () {'
 + ' window.location.reload();'
 + ' });'
 + '</script>'
 );
 });
});

That solves the problem for the index.html page, but what about the rest of the HTML pages? Instead of hard-coding the path, you can use a regular expression to intercept requests for HTML pages and directories.

When a request ends in a slash, take care to append index.html to the requested path.

Change:

app.get('/index.html', function (_, res) {
 fs.readFile(__dirname + '/index.html', function (_, data) {
 //...
 });
});

to:

app.get([/\/$/, /.*\.html$/], function (req, res) {
 var filename = __dirname + req.path;
 filename += filename.endsWith('/')? 'index.html': '';
 fs.readFile(filename, function (_, data) {
 //...
 });
});

Final result, copy+paste and start hacking

Now, putting it all together!

var express = require('express');
var app = express();
app.get([/\/$/, /.*\.html$/], function (req, res) {
 var filename = __dirname + req.path;
 filename += filename.endsWith('/')? 'index.html': '';
 fs.readFile(filename, function (_, data) {
 res.send(data
 + '&lt;script src="/node_modules/socket.io-client/dist/socket.io.js"&gt;&lt;/script&gt;'
 + '&lt;script&gt;'
 + ' var socket = io();'
 + ' socket.on("file-change-event", function () {'
 + ' window.location.reload();'
 + ' });'
 + '&lt;/script&gt;'
 );
 });
});
app.use(express.static(__dirname));

var http = require('http').Server(app);
http.listen(8080);

var fs = require('fs');
var io = require('socket.io')(http);
fs.watch(__dirname, { recursive:true }, function () {
 io.emit('file-change-event');
});

That's it!

Start the server with node server.js, go to https://localhost:8080 in your browser, and take a good look at your yellow page. Open up the css file you created earlier, and change yellow to orange. Save, but don't refresh your page. Just observe. The page will automatically update.

The files in this tutorial can be found at:

github.com/khtdr/live-reload-web-server

]]>

KHTDR – khtdr home page

css-vars-design-token

CSS Variables as Design Tokens: A Simple Approach to Design Systems

Why CSS Variables Are Good Enough

Introducing css-vars-design-token

Basic Usage

Advanced Features

Deep Tokens

Theme Switching

Real-World Applications

Responsive Design

Component Libraries

Benefits Over Alternative Approaches

Getting Started

Additional Links

opts.js

Introduction to Opts.js

Quick-Start example

Installation

No NPM dependencies are required

Typescript and NPM packages for convenience

Basic usage and setup

API configurations

Options

Arguments

Help auto-generator

More examples

Showcase of features and options

Conflict detection

Using named arguments and from within a library

Resume

Resume for Jose Mazzarelli

Summary

Contact Information

Professional Experience

Private Consulting 2024 - Present

VZBL 2023 - Present

SocialChorus/FirstUp 2018 - 2023

Kount 2007 - 2018

Boise State University 2014 - 2018

YourList 2011

Keynetics 2006 - 2007

PersonalShopper 2005 - 2006

Idaho Transportation Department 2002 - 2004

Education

A Developer's Design Implementation Checklist

Mockups never tell the whole story

A design checklist for developers

The Checklist

Using This Checklist

A Tailwind-CSS development server

Features

Installation

Running

Development

Building

Dark-Mode Light-Mode Css

pageboy

pageboy

Test suite status

Installation & quickstart

Standard features

Advanced features

treeify-paths

Installation

Example Usage

Testing

react-zondicons

Simple live-reloading Nodejs web server

Building your own live-reloading web server

This setup assumes you know and use Node and NPM

Planning a solution

Putting the solution together

Building the web server

Implementing the "live-reload" feature

Final result, copy+paste and start hacking

Private Consulting `2024 - Present`

VZBL `2023 - Present`

SocialChorus/FirstUp `2018 - 2023`

Kount `2007 - 2018`

Boise State University `2014 - 2018`

YourList `2011`

Keynetics `2006 - 2007`

PersonalShopper `2005 - 2006`

Idaho Transportation Department `2002 - 2004`