On StackOverflow, Ben Butterworth succintly solved this Vitest predicament in an answer to a question about Jest.
// a-local-file.js -----------------------------------------------
import {dependency} from './deps'
export function aFunction() {
setTimeout(() => {
dependency()
}, 2000)
}
// test.js -------------------------------------------------------
import {test, vi} from 'vitest'
import {aFunction} from './a-local-file'
import {dependency} from './deps'
vi.mock('./deps')
describe('when it returns true', () => {
beforeEach(() => {
vi.mocked(dependency).mockResolvedValue(true)
})
test('...', () => {/* ... */})
})
describe('when it returns false', () => {
beforeEach(() => {
vi.mocked(dependency).mockResolvedValue(true)
})
test('...', () => {/* ... */})
})
I was adding tests to a proof-of-concept TypeScript function running on AWS Lambda.
The main function is in the file index.ts.
It uses import to pull in a helper login function, in the file login-helper.ts.
I wanted to test the behavior of the index.ts function when the login fails, as well as when it works.
With this ability to conditionally mock the extracted login function, I can have one describe block where I test the failing-login behavior…
import {describe, test, vi} from 'vitest'
import {login} from './login-helper'
import {handlePayload} from './index'
vi.mock('./login-helper')
describe('handlePayload', () => {
// ...
describe('with invalid login', () => {
beforeEach(() => {
vi.mocked(login).mockRejectedValue('mocked login fails')
})
test('throws', async () => {
await expect(() => handlePayload(payload)).rejects.toThrow('mocked login fails')
})
})
})
…as well as the “happy path” logic when the login succeeds…
import {describe, test, vi} from 'vitest'
import {login} from './login-helper'
import {handlePayload} from './index'
vi.mock('./login-helper')
describe('handlePayload', () => {
// ...
describe('with valid login', () => {
let mockedPost
beforeEach(() => {
mockedPost = vi.fn()
vi.mocked(login).mockResolvedValue({
post: mockedPost,
})
})
test('attempts to post', async () => {
await handlePayload(payload)
expect(mockedPost).toHaveBeenCalledWith({/* ... */})
})
})
})
We detected that you have versions of dependencies that are not officially supported:
- `svelte`. Expected ^3.0.0 || ^4.0.0, found 5.0.0-next.262.
If you're experiencing problems, downgrade dependencies and restart Cypress.
To set the stage, here’s the problem I saw: a headless run would throw an error and hang (first it would show some <svelte:component> deprecation warnings and then spit out SvelteKitError: Not found: /__cypress/src/index.html), and a headed run would show “Your tests are loading…” and then nothing else would happen.
First, as recommended by GitHub user @lmiller1990, I added this viteConfig function to my cypress.config.ts’s component.devServer so that Cypress’s Vite server will know that we’re bootstrapping a Svelte project:
import {svelte} from '@sveltejs/vite-plugin-svelte'
export default defineConfig({
component: {
// ...
devServer: {
// ...
viteConfig: () => {
return {
plugins: [svelte()]
}
},
},
},
})
With this change, a headless run (npx cypress run --component) starts up the Cypress reporter properly!
However it throws a new error when trying to mount the component:
Svelte error: component_api_invalid_new
Attempted to instantiate src/components/TopNav.svelte with `new TopNav`, which is no longer valid in Svelte 5. If this component is not under your control, set the `compatibility.componentApi` compiler option to `4` to keep it working. See https://svelte-5-preview.vercel.app/docs/breaking-changes#components-are-no-longer-classes for more information
As the message notes, Svelte 5 has changed how components are mounted, so we’ll need to convince Cypress to mount them the new way.
Looking in the cypress/support/component.ts file, I notice that the mount command comes from the ‘cypress/svelte’ dependency:
import {mount} from 'cypress/svelte'
…then I poked around the Cypress repo on GitHub until I found the svelte package, and within its mount.ts file I see where it instantiates the component-under-test using new.
So let’s try to change what it does!
First I opened up the cypress/support/component.ts file and removed the import {mount} that was there. Then I copied over the function mount implementation from Cypress’s mount.ts, renamed it to mountV5, and used it as the implementation function where Cypress.Command.add is called with 'mount'. Then I also brought over the functions and values that it depends on: componentInstance, cleanup, getComponentDisplayName (which needs DEFAULT_COMP_NAME), and finally checkForRemovedStyleOptions, getContainerEl, and ROOT_SELECTOR from the mount-utils package. (I also removed all the types, just to have fewer in-editor errors to wade through right now.)
Finally I modified the function mount from Cypress’s mount.ts so that instead of constructing a new ComponentConstructor({target, ...options}), it calls mount(Component, {target, ...options}) as the Breaking Changes doc suggests — including bringing over the mount function from the svelte package, with import { mount } from 'svelte'.
Oh but it turns out that Svelte v4 swapped out .$destroy() for calling unmount, so let’s change the import to also pull in unmount and use that in the cleanup function.
Here’s the juicy bit of my component.ts now:
import {mount, unmount} from 'svelte'
function checkForRemovedStyleOptions(mountingOptions) {
for (const key of ['cssFile', 'cssFiles', 'style', 'styles', 'stylesheet', 'stylesheets']) {
if (mountingOptions[key]) {
Cypress.utils.throwErrByPath('mount.removed_style_mounting_options', key)
}
}
}
const ROOT_SELECTOR = '[data-cy-root]'
const getContainerEl = () => {
const el = document.querySelector(ROOT_SELECTOR)
if (el) {
return el
}
throw Error(`No element found that matches selector ${ROOT_SELECTOR}. Please add a root element with data-cy-root attribute to your "component-index.html" file so that Cypress can attach your component to the DOM.`)
}
let componentInstance
const cleanup = () => {
if (componentInstance)
unmount(componentInstance)
}
const DEFAULT_COMP_NAME = 'unknown'
const getComponentDisplayName = (Component) => {
if (Component.name) {
const [, match] = /Proxy\<(\w+)\>/.exec(Component.name) || []
return match || Component.name
}
return DEFAULT_COMP_NAME
}
function mountV5(Component, options={}) {
checkForRemovedStyleOptions(options)
return cy.then(() => {
// Remove last mounted component if cy.mount is called more than once in a test
cleanup()
const target = getContainerEl()
const ComponentConstructor = (Component.default || Component)
componentInstance = mount(ComponentConstructor, {
target,
...options,
})
// by waiting, we are delaying test execution for the next tick of event loop
// and letting hooks and component lifecycle methods to execute mount
return cy.wait(0, {log: false}).then(() => {
if (options.log !== false) {
const mountMessage = `<${getComponentDisplayName(Component)} ... />`
Cypress.log({
name: 'mount',
message: [mountMessage],
})
}
})
.wrap({component: componentInstance}, {log: false})
})
}
// Augment the Cypress namespace to include type definitions for your custom command.
// Alternatively, can be defined in cypress/support/component.d.ts with a <reference path="./component" /> at the top of your spec.
declare global {
namespace Cypress {
interface Chainable {
mount: typeof mountV5
}
}
}
Cypress.Commands.add('mount', mountV5)
And with that, my Cypress component test is passing! 🙌
Here’s a link to my full cypress/support/component.ts file, and here’s the first commit with the other changes to get a bare-bones component test working.
npm init vite and picked a SvelteKit project (using TypeScript).
First change-up you’ve gotta make is to use the @sveltejs/adapter-static adapter. For Svelte(Kit?) reasons it needs to be one of the devDependencies:
$ npm install -D @sveltejs/adapter-static
…then use it in the svelte.config.js to set strict: false and specify the public directory as the source for pages and assets:
import adapter from '@sveltejs/adapter-static'
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte'
export default {
preprocess: [vitePreprocess()],
kit: {
adapter: adapter({
pages: 'public',
assets: 'public',
fallback: undefined,
precompress: false,
strict: false, // https://kit.svelte.dev/docs/adapter-static#options-strict
}),
},
}
Here’s how I initially got the static site prerendering on GitLab pipeline…
# .gitlab-ci.yml
image: node:latest
pages:
stage: deploy
script:
- npm ci
- npm run build # even though this appears to create things in `.svelte-kit/output/{client,server}/*`, @sveltejs/adapter-static puts things into the `public/` dir...
artifacts:
paths:
- public
publish: public # this might be the default
only:
- main
Okay so at this point GitLab is building the static site and hosting it on GitLab Pages; now for adding SQLite…
First install better-sqlite3 as one of the devDependencies (and if you’re using TypeScript, @types/better-sqlite3 too)…
$ npm install -D better-sqlite3 @types/better-sqlite3
Then pick a +page.svelte file which you want to get some data from the database, and open (or create) its corresponding +page.server.ts file.
In this file you’re gonna import better-sqlite3, use it to read the .db SQLite file, and run a query to extract some data…
import {error} from '@sveltejs/kit'
import type {ReqestHandler} from './$types'
import Database from 'better-sqlite3'
import fs from 'node:fs'
const db = new Database(fs.readFileSync('src/path-to-sqlite-data.db'))
export const load: RequestHandler = ({ params }) => {
const showNum = Number(params.slug)
const stmt = db.prepare('select * from shows where id like ? limit 1')
const result = stmt.all(`%${showNum}%`)
if (result?.length) {
const [showData] = result
return showData
}
error(404, 'Not found')
}
Now the +page.svelte will be passed that showData object as the PageLoad data!
<script lang="ts">
import type { PageLoad } from './$types'
export let data: PageLoad
</script>
<h1 class="show__title">
Show #{data.id}: {data.tagline}
</h1>
{#if data.notes}
<p class="show__notes">{data.notes}</p>
{/if}
Ta-daa! It works! 🙌 🥂
I have lots of experience with Cypress, so to try something (else) new I decided to check out Playwright.
To add Playwright to my existing app, I used the create-playwright CLI tool: pnpm dlx create-playwright
It scaffolds a test subdirectory, a (GitHub) CI actions yaml file, and installs browsers to test with (chromium, firefox, webkit). Once it’s done, it recommends running pnpm exec playwright test to set up some starter tests, and then pnpm exec playwright show-report to start a local webserver showing the results of the test.
The Playwright site has suggestions on setup for GitLab CI, namely to use their mcr.microsoft.com/playwright:v1.45.1-jammy Docker image:
tests:
stage: test
image: mcr.microsoft.com/playwright:v1.45.1-jammy
script:
# ...
I added that to my existing gitlab-ci.yml file and the default example tests are passing on GitLab CI! (Note that I used the stages section to specify that the test stage runs first, and if it succeeds then the deploy stage runs. I’ll work on a build stage after I write some tests…)
To start testing my app, I’ve gotta tell Playwright what URL to visit to find the app. In Playwright >=1.13.x, the playwright.config.ts file has a use section wherein we can specify the baseURL to use what npm run dev defaults to:
export default defineConfig({
// ...
use: {
/* Base URL to use in actions like `await page.goto('/')`. */
baseURL: 'http://localhost:5173',
},
// ...
})
To get this working on GitLab, traditionally I’d look for a way to override the baseURL in the CI environment… However the bottom of playwright.config.ts has a webServer section which lets us specify a command for starting the server plus the URL to look for it — and we can use the $CI environment variable to modify this behavior for running on CI vs local/dev:
export default defineConfig({
// ...
webServer: {
command: process.env.CI
? 'npm run build && npm run preview -- --port 5173 --strictPort'
: 'npm run dev -- --port 5173 --strictPort',
url: 'http://localhost:5173',
reuseExistingServer: !process.env.CI,
},
// ...
})
…and with that, on GitLab it will build and then preview the built files, wait for the url to be responsive, but on local/dev it will hit the url and only run the command if there is not something running there!
Once I got more of my site built, I found that linking from a +page.svelte template with slug A to the same template with slug B would result in the URL being changed, but some of the content on the page is not changing… I initially assumed this was due to me breaking Svelte’s reactivity in some way, but it turns out to be a common SvelteKit footgun:
…so it’s both “a feature not a bug” and also due to me not declaring the template’s input as “this needs to be reactive”. Great.
The Svelte 4 solution is something like this:
export let data: PageLoad
$: tracksData = data.tracksData
$: setlistData = tracksData.reduce(/*...*/)
…but I’m trying to stick with Svelte 5, which means doing the same thing with $props() and $derived() instead:
let {data} = $props<PageLoad>()
let setlistData = $derived(data.tracksData.reduce(/* ... */)
Note that because this data is coming from the +page.server.ts file’s load function, it ends up at $props().data and not within the top-level props.
I’m slightly tweaking the URLs for things in this rebuild, so I want to add some redirects from the old formats to the new ones. I’ve followed this guide to support redirects with the SvelteKit static adapter, but had to tweak it slightly (perhaps for Svelte v5??)… but it’s still worth reading because it explains more fully what is going on here:
set up a mapping of old-URLs-to-new-URLs in a JS object, and save as src/redirects.js (can’t use TypeScript for this apparently?)
modify/create src/routes/+layout.server.ts (note: this belongs in +layout.server.ts and not +layout.ts as the above blog post says! otherwise you’ll break HMR in dev) to import that new redirects.js object along with the redirect function from SvelteKit, and export a function which checks whether the incoming URL matches one of the keys in the redirect object:
import {redirect} from '@sveltejs/kit'
import {REDIRECTS} from '../redirects'
export async function load({url}) {
const pathname = url.pathname
if (REDIRECTS.hasOwnProperty(pathname))
return redirect(301, REDIRECTS[pathname])
}
Tie the two together by modifying svelte.config.js to import the redirects.js object and add its keys to the list of routes to prerender:
export default {
// ...
kit: {
// ...
prerender: {
entries: ['*', ...Object.keys(REDIRECTS)],
},
},
}
Flexsearch makes a lot of claims about how fast it is on the client-side. That sounds pretty nice, so let’s integrate it!
I used this guide on integrating Flexsearch with SvelteKit which (despite being aimed at Svelte v4) was quite helpful in pointing the way. The guide mentions adding search match markers to the search response, but I skipped that to start with. Here’s what I ended up doing…
src/lib/search.ts — contains logic for building and searching the indexsrc/routes/search.json/+server.ts — server-side (in dev; what about when building for static site?) endpoint to “serve prerendered content as JSON”+page.svelte where the UX for the search will be (I’m using my home page, i.e. src/routes/+page.svelte)
$state( /*...*/ ) to wrap the initial values of searchTerm, results, and the ready flagonMount(() => { /*...*/ }) to retrieve search.json and set up the index$effect(() => { /*...*/ }) to wrap the call to searchSongsIndex(searchTerm)…and it works!
At one point I was happily hacking away and running the site locally with npm run dev, but when I pushed up to GitLab the Pipeline failed with this:
$ npm ci
npm warn deprecated rimraf@2.7.1: Rimraf versions prior to v4 are no longer supported
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm error Exit handler never called!
npm error This is an error with npm itself. Please report this error at:
npm error <https://github.com/npm/cli/issues>
npm error A complete log of this run can be found in: /root/.npm/_logs/2024-07-18T22_10_54_897Z-debug-0.log
$ npm run build
> almost-dead-dot-net@0.0.1 build
> vite build
sh: 1: vite: not found
Ruh roh. First I enabled debug logging with the CI_DEBUG_TRACE variable, but that seems to be like the shell setopt -o VERBOSE and was not helpful with the actual error…
Instead, change up the CI script to npm install --cache=.npm so that error logs will be saved in the current working directory, and then have GitLab capture them as artifacts:
pages:
stage: deploy
script:
- npm install --cache=.npm && npm run build
artifacts:
paths:
- public
- .npm/_logs/*
when: always
publish: public
only:
- main
Then even if the job fails, any npm logs will be made available as artifacts and can be downloaded and inspected.
In my case, there was no new info about why the Exit handler is never called…
Noticing that I specified the node:latest image to build, I tried setting it to use the version of Node I’m using locally: node:20.9.0. This changed the error message shown in the Pipeline, giving me a proper stack trace! 🎉
npm ERR! code 1
npm ERR! path /builds/alxndr/almost-dead-dot-net/node_modules/@sveltejs/kit
npm ERR! command failed
npm ERR! command sh -c node postinstall.js
npm ERR! Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
Dutifully I locally removed the package-lock.json and node_modules/ and reinstalled and committed, and happily GitLab CI was able to build the app!
Yep I’m one of those weirdos who doesn’t use VSCode.
Instead I am a big fan of NeoVim, and lately I’ve been using Mason to manage language linters/checkers/etc. Helpfully there is a svelte-language-server! (make sure you’re using the one from the official SvelteJS project and not the now-deprecated initial project by James Birtles)
I’d noticed that TypeScript checking was working as expected in .ts files, however it’s not working in .svelte files even with <script type="ts">…
Luckily there is a Discord community for Svelte where folks are pretty quick to respond to questions, and @TGlide pointed me in the right direction. I needed to configure the TypeScript LSP client to look for .svelte files (of course 🤦) and also tweak the Svelte LSP client with something about watched files:
local lsp_capabilities = vim.lsp.protocol.make_client_capabilities()
lsp_capabilities.workspace.didChangeWatchedFiles = false
lspc.svelte.setup {
capabilities = lsp_capabilities
}
Now NeoVim shows me TypeScript errors/warnings within .svelte files, and updates when I edit (not just on save)!
npm init vite does a lot of the backend-for-frontend setup, without which I’d be totally unable to do any of this. Chapeau, Vite!
The SvelteKit docs are quite nice, helpful for a brand-new-beginner like me. Thanks Svelters!
Kisaragi Hiu’s blog shepherded me gently through all of the SQLite stuff! Thank you!
https://www.okupter.com/blog/e2e-testing-with-sveltekit-and-playwright
Here’s what it might look like to write Toki Pona using Ogham letters…
jan ale li kama lon nasin ni:
ona li ken tawa li ken pali.
jan ale li kama lon sama.
jan ale li jo e ken pi pilin suli.
jan ale li ken pali e wile pona ona.
jan ale li wile pali kepeken nasin ni:
ona li jan pona tawa jan ante.
| Latin | Ogham |
|---|---|
| a | ᚐ |
| e | ᚓ |
| i | ᚔ |
| j | ᚆ |
| k | ᚉ |
| l | ᚂ |
| m | ᚋ |
| Latin | Ogham |
|---|---|
| n | ᚅ |
| o | ᚑ |
| p | ᚁ |
| s | ᚄ |
| t | ᚈ |
| u | ᚒ |
| w | ᚃ |
I made a Vim syntax file for Toki Pona text!
Load it up and :set filetype=tokipona, then it will highlight headnouns-with-capitalized-names, “la”-phrases, “X ala X”, as well as preverbs and particles and pronouns:
(I recommend also using /dev/urandom’s Toki Pona vim spellcheck.)
]]>Below I’ve created an interactive tool to let you enter amounts of starter, water, and flour (and optionally yeast and salt too), and then receive a set of numbers describing the ratios you’d entered.
(Trial and error has landed me around 1 part starter, 4 parts room-temp water, 5 parts high-protein flour, 0.1 part salt… I built this tool in order to help me fine-tune that ratio, and determine ratios for using yeast.)
]]>(I’d come up with this a few months ago and only posted it on Mastodon, but also it had some errors, so here it is with a more permanent place and with corrections…)
The classic pangram:
.o’i mu xagji sofybakni cu zvati le purdi
.i ro remna cu se jinzi co zifre je simdu’i be le ry. nilselsi’a .elei ry. selcru .i ry. se menli gi’e se sezmarde .i .ei jeseki’ubo ry. simyzu’e ta’i le tunba
| Latin | Ogham | IPA |
|---|---|---|
| delimiters | ᚛ ᚜ | (pause) |
| . | ᚖ | [ʔ] |
| ’ | ᚕ | [h] / [θ] |
| a | ᚐ | [a] / [ɑ] |
| b | ᚁ | [b] |
| c | ᚊ | [ʃ] / [ʂ] |
| d | ᚇ | [d] |
| e | ᚓ | [ɛ] / [e] |
| f | ᚃ | [f] / [ɸ] |
| g | ᚌ | [ɡ] |
| i | ᚔ | [i] |
| j | ᚗ | [ʒ] / [ʐ] |
| k | ᚉ | [k] |
| Latin | Ogham | IPA |
|---|---|---|
| l | ᚂ | [l] |
| m | ᚋ | [m] |
| n | ᚅ | [n] |
| o | ᚑ | [o] / [ɔ] |
| p | ᚘ | [p] |
| r | ᚏ | [r] |
| s | ᚄ | [s] |
| t | ᚈ | [t] |
| u | ᚒ | [u] |
| v | ᚍ | [v] / [β] |
| x | ᚙ | [x] |
| y | ᚆ | [ə] |
| z | ᚎ | [z] |
Here’s an exploration: nasin sitelen tawa lipu pi nimi ale
sitelen sitelen is one of the many orthographies of toki pona.
It is a beautiful and creative writing system! But its inherent flexibility can be challenging to navigate, and can make it difficult to recall the definition of a glyph.
As a beginner to toki pona who was fascinated by sitelen sitelen, I was looking for many source documents to see how different people drew the glyphs. I then found myself wanting a method of defining a glyph based on its visual appearance, not knowing its pronunciation, and with only a rough understanding of sitelen sitelen (or even the language’s vocabulary).
This reminded me of studying Mandarin, and using Chinese dictionaries organized by radical and stroke count — and I wondered if something similar (but also pona!) were possible for sitelen sitelen…
There are 26 “roots” (visual components);
The roots are in a particular order.
Each glyph has a unique set of roots associated with it;
The dictionary lists each glyph in order according to the order of the roots.
This allows a dictionary user to quickly locate an unrecognized glyph within an arbitrarily-sized list of otherwise “difficult-to-order” glyphs, with only a rough understanding of the roots and ordering necessary, and without depending on any knowledge of pronunciation (of either the glyph or the patterns/motifs common to sitelen sitelen glyhs).
My goal is to have the “roots” be roughly from simple-to-complex, and to use the established sitelen sitelen phoneme glyphs as a starting point.
The five vowel “infixes” are prominent in many of the full glyphs, so I’ve chosen to use them as the very beginning. The order is roughly: mouth; basic eye; complex eye/s; full face.
The nine consonant “bases” are next, in this rough order: dots; wrinkles; bumps; different structures.
The above fourteen phoneme glyphs don’t quite cover all the existing full glyphs, so I’ve identified some more shapes (drawing from existing sitelen pona glyphs) as common roots. These are ordered from simple/geometric to complex/anatomical.
Last but not least, two “meta” roots, notable for how they’re placed in relation to other self-contained glyphs: the “cartouche” container shape; and the “plinth” supportive-base shape.
The specific roots and order are still subject to change.
| root | visual description |
|---|---|
 |
tongue — a long/tall bump with a line; a tongue with septum |
 |
eye — a circle (perhaps with dot in center); a basic eye |
 |
eye & brow — a dotted circle with supporting line; an eye with eyeball and orbital cavity |
 |
closed eye — two perpendicular lines intersecting; a plus, X, crossed lines |
 |
anterior face — a line with dots on either site; a nose and two eyes facing the reader |
 |
crease? — two/three short roughly-parallel lines, adjacent to a larger feature |
 |
dots — two or more dots, perhaps with a nearby line/crease |
 |
lips? — a line intersecting (not crossing) another line |
 |
bucktooth? — multiple bumps with one in front of the rest |
 |
downward buds — multiple bumps at the bottom, with a crease |
 |
upward buds — multiple bumps at the top, with a crease |
 |
tailfan — multiple bumps at the top or side, without a crease |
 |
cob — a tall / narrow shape |
 |
stack — three stacked circles / shapes |
| linja | a long line, perhaps slightly curved |
| Ƨ | a backwards “S” or curvy “Z”; a swirly reversing (but not closed) line |
| sama | two (or more) parallel lines |
| weka | three (or more) short non-parallel lines emanating from a shared vanishing point |
| nena | a bump / curved protrusion |
| leko | a square / right-angled shape |
| monsuta | a sharp point / acute angle |
| ◎ | a hole; depth (along the dimension perpendicular to the plane containing text) |
| uta | a mouth |
| ☞ | a hand with fingers / a foot with toes; an extremity with digits |
| poki | (meta) containing structure; shape which contains / surrounds full glyphs; cartouche / quotation |
| _ | (meta) supporting structure; wide-and-short shape which often appears under full glyphs; plinth |
Try it out at: alxndr.github.io/nasin-pi-lipu-nimi
The first row of glyphs are the roots. Pick one or more of them, and the big list of glyphs below will update to filter and show only the glyphs which include the root(s) you’ve selected.
Then you can click on a glyph to get more info about it: pronunciation, definition, sitelen Emosi!
Definitions in the dictionary are from linku.la.
Unicode characters were identified using Shapecatcher.
Fonts / glyphs:
The dictionary (and this blog) are hosted on GitHub Pages.
Here is a way to be able to account for necessary-but-ineffable software maintenance in a management style which demands prioritization, thereby allowing the tech team to gradually and regularly pay down tech debt:
The ticket is titled “Upgrade or refactor some dependencies”, or something intentionally slightly vague — This is to allow the developer some leeway in deciding what sorts of dependency work they’ll tackle, each time the ticket rolls around.
The ticket is scheduled for a regularly-occurring specific time period — sprint, month, whatever the team is already using — This time period should be regular enough that the ticket doesn’t feel unusual, but not so frequent that it gets in the way of other work.
This ticket is actually many tickets, which are created recursively — part of the Acceptance Criteria is to create a new ticket, ready to be scheduled/refined — This ensures that the pattern continues!
After seeing several dependency-laden codebases (using e.g. NodeJS, or Ruby on Rails) become brittle as their developers are not able to upgrade the scaffolding of the application, and witnessing the same pattern happen with different leaders and team members and management styles and team structures, I was looking for a way to have the Product team(s) recognize the notion of “expected maintenance”. In order for it to be useful in a variety of situations, the form of this expected maintenance has to fit however the Product team wants to manage, so in my case it took the form of a never-ending series of Jira tickets.
Normally a developer would hate the idea of an infinite sequence of tickets, but this is essentially free time for the developer to tackle whatever tech debt they see fit to tackle. I like to have these tickets rotate between the developers, so that everyone gets a chance to scratch whatever itch was bothering them lately.
Really, this dripping tap of work is an accurate reflection of maintenance costs and should scare the Product team more than anyone else! It’s the cost of doing business with any codebase, no matter how many dependencies there are — there should always be periodic maintenance, to clear out the cobwebs and grease the wheels and upgrade the latches.
This pattern has been successful for two years and counting, on a high-importance internal project which therefore has lots of Product and Leadership attention (and therefore is more likely to have techdebt de-prioritized!), allowing the team to keep all but two (!) dependencies on the major version (in a modern NodeJS project with extensive unit and integration tests).
]]>👈 ✊ ⏩ 💬 👈 🔼 ➗️ 👤 🔣 ❄️ ⚖️ 💧 🔣 ➖️
👆 🔼 ➗️ 👉 💗 👍 🤷 ❓
🗣 👍 🔼 📄 🌐 👇 ▶️ ✅ 👇 ➖️
⏰ ⏮️ 🔼 ➗️ 👋 🗣 ❗️
o jan-ale, toki a!
tenpo ni la mi kama sona toki e toki-pona a!mi pali e nimi-mi la jan [lete e sama a telo e].
ona la sina pilin-pona anu seme?toki-pona la lipu [ma a tomo o tonsi o ni] mi li lon ni.
tenpo kama la o toki a!
o jan ale, toki a! tenpo ni la, mi kama sona toki e toki pona a!
mi pali e nimi mi la, jan Lesate. ona la, sina pilin pona anu seme?
toki pona la lipu linluwi Matoton mi li lon ni.
tenpo kama la o toki a!
]]>