Kasparas Anusauskas

Test driven development and reading on how to simplify my code

2021-01-01T00:00:00Z

Simple JS function

Today I've read a nice article about Test Driven Development by Lee Cheneler: https://medium.com/@lee_85949/from-fizzbuzz-to-react-practical-test-driven-development-in-javascript-9fd05a4d1ad6

Do read it, all examples in this post are taken from there. Remember these are my daily notes helping me to commit to learning something every day, not original content.

The thing with TDD is, I always feel like it's just one step away. You could have this beautiful, logical, clean, instantly refactorable flow, but the tasks are usually so complex that you have to reverse engineer some old code + API, and try to implement some stuff to understand how all these endpoints map together etc. Then you have done half of the work, and it's kind of too late for the "TDD" approach.

This has to change, thought. To help me commit, I've decided to restart with the basics from the article.

First example was developing fizzbuzz function using the test driven development flow, which, turns out, is a task frequently given by interviewers. The task is very simple but lend's itself well to testing:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

To do this, we'll need:

Node
Jest (our test runner)

Here's how simple it is, really:

# Install Jest
npm install --save-dev jest

# Inside package.json, add jest command to your scripts:
{
  "scripts": {
    "test": "jest"
  }
}

# Create test file
touch function.test.js

# Create file to test in a directory of your choice
touch function.js

# Write your first test in function.test.js (see Step 1 below) and run Jest to see it fail:
npm run test

Write a test with a small task (return number which was passed as argument)
Check that it fails
Write code and make sure the test no longer fails
Refactor if necessary, which is easy since we now have the test.

Here's the test:

const { fizzbuzz } = require("./_tdd-function");

// Step 1
it("should return the numbers passed in that are not divisable by 3 or 5", () => {
    expect(fizzbuzz(1)).toBe(1);
    expect(fizzbuzz(2)).toBe(2);
    expect(fizzbuzz(4)).toBe(4);
    expect(fizzbuzz(7)).toBe(7);
    expect(fizzbuzz(11)).toBe(11);
});

// Step 2
it("should return 'fizz' if the number passed in is divisable by 3 ", () => {
    expect(fizzbuzz(3)).toBe("fizz");
    expect(fizzbuzz(6)).toBe("fizz");
    expect(fizzbuzz(9)).toBe("fizz");
    expect(fizzbuzz(12)).toBe("fizz");
});

// Step 3
it("should return 'fuzz' if the number passed in is divisable by 5 ", () => {
    expect(fizzbuzz(5)).toBe("buzz");
    expect(fizzbuzz(10)).toBe("buzz");
    // expect(fizzbuzz(15)).toBe("buzz"); <-- Too early for that, 15 is divisable both by 3 and 5...
    expect(fizzbuzz(20)).toBe("buzz");
});

// Step 4
it("should return 'fizzbuzz' if the number passed in is divisable by 3 and 5 ", () => {
    expect(fizzbuzz(15)).toBe("fizzbuzz");
    expect(fizzbuzz(30)).toBe("fizzbuzz");
    expect(fizzbuzz(45)).toBe("fizzbuzz");
});

And here's the function:

const fizzbuzz = (num) => {
    // Could write (num % 15 === 0) which sounds clever but I think is less descriptive
    if (num % 3 === 0 && num % 5 === 0) return "fizzbuzz";
    if (num % 3 === 0) return "fizz";
    if (num % 5 === 0) return "buzz";

    return num;
};

module.exports = { fizzbuzz };

You write one test, and implement the functionality. Then move to another. It's super pleasant and simple.

A React component

Principle is the same with a react component. There's a lot more trouble in preparing the environment for it, though. Not only does one need Jest, but also some library to help selecting stuff, mocking clicks etc. But, the principle is largely the same. You write a test, make it fail, make it work, refactor until it's nice.

The test:

// http://localhost:8000/react-dev-demos/day1
import React, { useState } from "react"

// Refactored from class:
/* 
export class Counter extends React.Component {
  constructor() {
    super()
    this.increment = this.increment.bind(this)
    this.state = {
      count: 0,
    }
  }

  increment() {
    this.setState({
      count: this.state.count + 1,
    })
  }

  render() {
    return (
      <>
        <span data-testid="count">Count: {this.state.count}</span>
        <button type="button" onClick={this.increment}>
          Increment
        </button>
      </>
    )
  }
}
*/

// To functional component:

export const Counter = () => {
    const [count, setCount] = useState(0)

    const increment = () => {
        setCount(count + 1)
    }

    return (
        <>
            <span data-testid="count">Count: {count}</span>
            <button type="button" onClick={increment}>
                Increment
            </button>
        </>
    )
}

export default function Day1() {
    return Counter
}

The component:

import React from "react";
import { render, fireEvent } from "@testing-library/react";
import "@testing-library/jest-dom/extend-expect";
import { Counter } from "./_tdd-react-component";

it("should display the start count as 0", () => {
    const { getByTestId } = render(<Counter />);

    expect(getByTestId("count")).toHaveTextContent("Count: 0");
});

it("should increase the count by 1 when increase button is clicked", () => {
    const { getByTestId, getByText } = render(<Counter />);

    fireEvent.click(getByText("Increment"));
    expect(getByTestId("count")).toHaveTextContent("Count: 1");

    fireEvent.click(getByText("Increment"));
    expect(getByTestId("count")).toHaveTextContent("Count: 2");
});

The main benefit I see, is you have to really understand the task before doing this, and plan by writing the tests. And no one can argue it's not OK to do it properly. It's TDD, so it's cool, everyone knows that.

Learning to (kind of) enjoy test driven development in JS with simpler tests

2021-01-04T00:00:00Z

I have never really used test driven development. When I tried, it got too clumsy, messy, I tried testing methods of my classes. Didn't really know what I was doing.

The light came after attempting to TDD a functional component wish useState / useEffect hooks when they were released. No longer could I access state or internal methods of a class in my tests. Not without keeping them outside the component I then knew this is not how it was intended to be done.

Along came the (https://testing-library.com/)[https://testing-library.com/] with it's guildelines about how one should test components exactly the way a user would use them.

This means always rendering them to a virtual DOM, accessing elements by their DOM attributes, manipulating them and asserting based on DOM state. You just have no way to do more anymore. And that is pretty liberating in a sense that you can just focus on writing a decent test for the real use case.

An additonal benefit is the encouragment to drop the long standing "1 assert per 1 test" rule (it's in the FAQ). The tooling is capable to show you exactly on which line the test fails while also outputing color coded "Expected vs Reality" DOM state. So it's just no longer useful to go through the trouble of writing more tests. Test a success case, test a failure case and that might just do it.

The old and the new ways

If there is a component involving:

Show "Loading..." text
Fetch data A from endpoint a
Fetch data B from endpoint b
Process A using some Array.reduce + Array.filter etc.
Process B using some Array.reduce + Array.filter etc.
Merge processed data using some procedure only used in that component
Display (correctly) merged data in a list

How I used to test it

I write 7 or more tests for each step. If this was a functional component, I would moved the algorithms in 4, 5, 6 outside the component and test them separately.

This isn't ideal, because this is a component, not some helper library. If requirements change, algoriths processing the data will change. 4, 5, 6, 7 will all get broken. Or, what if we use new library which performs exactly what 4, 5 used to do. We can't refactor 4 and 5 out without breaking the tests.

However, as I mentioned, this is a component. All we care about is what the user sees is correct, as defined by the task, right?

How I'm learning to do it now

I write one longer test. In that test I check 1 and 7. Possibly, I also check if 2, 3 calls API only once, because are quite suitable for nasty bugs involving render loops.

Does this break TDD if I don't test each step?

Initially, I thought of it that way. How do I "write a small test and make it pass" If I don't write a test. I mean, we all know the mantra:

Split task into smallest logical parts
Write a test for that small part
Make it pass
Repeat

Then refactor to make it nice, make it fast. So how do I write the logic without testing it? Well, the key point for me was noticing that mostly, just as I said, the 'logic' is just a few 'reduce' + 'filter' statements. Perfectly acceptable to write using just one test checking the final result.

To tell you the truth, I didn't yet TDD a really big component (this is typically a large form with one input affecting value of others after calling API first). However I feel now I'll just be forced to split it further. And, if there's a lot of conditional logic, it's still always possible to move it to functions outside the component and test them separately.

Any way, it's the first time I'm actually looking forward to it.

Excercise

Here's the test:

import React, { useEffect, useReducer, useState } from "react";
import axios from "axios";

const initialState = {
    charCounts: null,
    error: null,
    isLoading: true,
};

const charSelectReducer = (state, action) => {
    switch (action.type) {
        case "SUCCESS":
            return {
                charCounts: action.charCounts,
                error: null,
                isLoading: false,
            };
        case "ERROR":
            return {
                charCounts: null,
                error: action.error,
                isLoading: false,
            };
        default:
            return state;
    }
};

const CharSelect = ({ lowercaseUrl, uppercaseUrl }) => {
    const [value, setValue] = useState("");
    const [{ charCounts, error, isLoading }, dispatch] = useReducer(
        charSelectReducer,
        initialState
    );

    useEffect(() => {
        const { token: cancelToken, cancel } = axios.CancelToken.source();
        (async () => {
            try {
                const [{ data: lowercase }, { data: uppercase }] = await Promise.all([
                    axios.get(lowercaseUrl, { cancelToken }),
                    axios.get(uppercaseUrl, { cancelToken }),
                ]);
                const charCounts = lowercase
                    .concat(uppercase)
                    .sort((a, b) => a > b)
                    .reduce((acc, char) => {
                        const lowChar = char.toLowerCase();
                        acc[lowChar] = ++acc[lowChar] || 1;
                        return acc;
                    }, {});
                dispatch({ type: "SUCCESS", charCounts });
            } catch (e) {
                dispatch({ type: "ERROR", error: "Unexpected error" });
            }
        })();

        return () => {
            cancel();
        };
    }, [axios]);

    if (isLoading) return "Loading...";
    if (error) return error;
    return (
        <>
            <select data-testid="select" onChange={(e) => setValue(e.target.value)} value={value}>
                <option value="" data-testid="char-select-option">
                    Select char
                </option>
                {Object.keys(charCounts).map((char) => (
                    <option key={char} value={char} data-testid="char-select-option">
                        {char}: {charCounts[char]}
                    </option>
                ))}
            </select>
            <button>Next</button>
        </>
    );
};

export default CharSelect;

And here's the function:

import React, { useEffect, useReducer, useState } from "react";
import axios from "axios";

const initialState = {
    charCounts: null,
    error: null,
    isLoading: true,
};

const charSelectReducer = (state, action) => {
    switch (action.type) {
        case "SUCCESS":
            return {
                charCounts: action.charCounts,
                error: null,
                isLoading: false,
            };
        case "ERROR":
            return {
                charCounts: null,
                error: action.error,
                isLoading: false,
            };
        default:
            return state;
    }
};

const CharSelect = ({ lowercaseUrl, uppercaseUrl }) => {
    const [value, setValue] = useState("");
    const [{ charCounts, error, isLoading }, dispatch] = useReducer(
        charSelectReducer,
        initialState
    );

    useEffect(() => {
        const { token: cancelToken, cancel } = axios.CancelToken.source();
        (async () => {
            try {
                const [{ data: lowercase }, { data: uppercase }] = await Promise.all([
                    axios.get(lowercaseUrl, { cancelToken }),
                    axios.get(uppercaseUrl, { cancelToken }),
                ]);
                const charCounts = lowercase
                    .concat(uppercase)
                    .sort((a, b) => a > b)
                    .reduce((acc, char) => {
                        const lowChar = char.toLowerCase();
                        acc[lowChar] = ++acc[lowChar] || 1;
                        return acc;
                    }, {});
                dispatch({ type: "SUCCESS", charCounts });
            } catch (e) {
                dispatch({ type: "ERROR", error: "Unexpected error" });
            }
        })();

        return () => {
            cancel();
        };
    }, [axios]);

    if (isLoading) return "Loading...";
    if (error) return error;
    return (
        <>
            <select data-testid="select" onChange={(e) => setValue(e.target.value)} value={value}>
                <option value="" data-testid="char-select-option">
                    Select char
                </option>
                {Object.keys(charCounts).map((char) => (
                    <option key={char} value={char} data-testid="char-select-option">
                        {char}: {charCounts[char]}
                    </option>
                ))}
            </select>
            <button>Next</button>
        </>
    );
};

export default CharSelect;

Track view duration of fake social network feed items using intersection observer. Part 1.

2021-08-11T00:00:00Z

What we're gonna Build

Weekly challenge is for experiments, I reserve up to 7 hours from my week for those, including writing the blog. This is not production grade stuff. You have been warned.

Social networks and websites often have feeds where you scroll through content items. It's then common sense they would measure the view duration of each piece. This would greatly help in serving even more "similarly engaging, intelligence-stimulating content", because that's what we like to see, right? I've recently seen a movie, The social dilemma which talks about this stuff a lot. I don't agree with the narrative it makes social networks "evil", but I still enjoyjed it.

Let's build a feed of nice images and measure ourselves to see how the whole tracking thing can be built easily, and how the results look, real time.

To begin with, feel free to watch this demo of the final app. Or just leave it to the end.

The app

Nothing takes away the fun better than a good, detailed plan. Let's use React, and build these components:

ViewDurationTracker - renders content, fires callback passed from parent with view duration when it changes;
Feed - assembles a categorized, pseudo-randomized list of nice photos, and passes them down using props to any component it is supplied;
Dashboard - displays list of most popular content, and view duration
Controller - listens for callbacks with view duration for all items, can pass data to another component (dashboard)

I will not present all the code here, as the stuff does get a bit lengthy. Feel free to check it on github or run it on codesandbox.

Let's discuss key parts and view the result.

ViewDurationTracker - the main element enabling us to very easily time the view

To build this stuff, first I had to put down some ground rules.

On Instagram, when looking at a photo, I sometimes scroll it out of the viewport so my fingers don't obstruct the view. So, I'll say that when 85% of an element is in the viewport, we'll consider it "being viewed".

Obviously this is greatly simplified, and there is probably a whole branch of analytics just for getting the various "in view" factors right - but 85% is gonna work fine for our 7 hours of alloted time :)

Let's explore the components responsibilities in more detail:

render children in a div;
when 85% enters viewport, save the lastEntryDate in state;
when 85% leaves the viewport, calculate view duration as difference between Date.now() and lastEntryDate;
call callback passed from parent as a prop with view view duration and some info about the element.

Simple stuff. Yet when I tried to test-driven-develop-it I found testing it is not possible using regular Jest / React testing library / jsdom setup, because jsdom does not support real layout, making us unable to test logic based on scroll position.

Fortunately, we now have Cypress which renders tests in a real browser. Lately, it can even render react components for unit testing without having any kind of "app". I'll make sure to write about it later.

// To run:
// npx cypress open-ct
import React from "react";
import { mount } from "@cypress/react";
import ViewDurationTracker from "./ViewDurationTracker";

beforeEach(() => {
  cy.viewport(320, 640);
});

it("renders children inside a div", () => {
  mount(<ViewDurationTracker>I am a single child</ViewDurationTracker>);
  cy.get("[data-cy=TimedViewContainer]").contains("I am a single child");
});

it("calls callback passing correct arguments", function () {
  // Let's use window and not worry about it for once.
  // cy.spy only accepst [object, property] so 
  // let's not complicate our own lives for now.  
  window.callback = ({ viewDuration, properties }) => {
    expect(viewDuration).to.be.greaterThan(100);
    // Expect 200ms view duration, but allow up to 250ms 
    // The programattic scrolling part consumes a few ms so we're adjusting for taht
    expect(viewDuration).to.be.lessThan(150);
    expect(properties.id).to.be.equal(1);
  };

  cy.spy(window, "callback").as("callback");
  mount(
    <div style={{ paddingTop: "10000px" }}>
      <ViewDurationTracker onViewDurationMsChange={callback} properties={{ id: 1 }}>
        I am a single child
      </ViewDurationTracker>
    </div>
  );

  // At this point we're in a real browser, on the top of the viewport
  cy.scrollTo("bottom");
  // We've now scrolled ±10000px down
  cy.wait(200);
  // After waiting a 200ms we scroll back up
  cy.scrollTo("top");
  // And we check that our callback was called.
  // Callback above contains more checks
  cy.get("@callback").should("have.been.called");

  // Possibly the more "Cypress'y" way to do this for reference:
  // (I don't like it):
  // cy.get("@callback").should(
  //  "have.been.calledWithMatch",
  //  Cypress.sinon.match.number
  //    .and(Cypress.sinon.match((x) => x > 100, "> 100"))
  //    .and(Cypress.sinon.match((x) => x < 150, "< 150"))
  // );
});

And that's the test. I was blown away by comparing:

my thoughts on how much trouble it is gonna be to write it
how little trouble it actually was

After having the test, the component itself was very easy too. We're building on the shoulder of giants people, and using the (Intersection Observer API)[https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API].

import React, { useEffect, useRef, useReducer } from "react";

const initialState = { lastEntryTime: 0, viewDuration: 0 };

// Using reducer because my 3 simple rules of determining "will you get f****d
// up by the functional component" say I indeed will:
// - Does it pass a callback to some function? // true
// - Does the callback modify state ? // true
// - Does the state modification relies on previous state? // true When all 3
//   are true, you will have stale state problems due to JS closures, just
//   manage the state in a reducer like this to avoid it. The callback only
//   dispatches actions, and does not need to know anything about the state,
//   avoiding problems entirely If in doubt, read the excellent article about it
//   here. Read it all, and read it at least 3 times:
//   https://overreacted.io/a-complete-guide-to-useeffect/
const reducer = (state, action) => {
  switch (action.type) {
    case "enterViewport": {
      return { ...state, lastEntryTime: Date.now() };
    }
    case "leaveViewport": {
      return {
        ...state,
        viewDuration: state.lastEntryTime
          ? state.viewDuration + (Date.now() - state.lastEntryTime)
          : 0
      };
    }
    default: {
      return state;
    }
  }
};

const ViewDurationTracker = ({
  children,
  properties,
  onViewDurationMsChange,
  ...props
}) => {
  const [state, dispatch] = useReducer(reducer, initialState);
  const elementRef = useRef();

  // This gets called when interesection observer says "85% of element has
  // entered or left the viewport"
  const intersectionCallback = (entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        dispatch({ type: "enterViewport" });
      } else {
        dispatch({ type: "leaveViewport" });
      }
    });
  };

  useEffect(() => {
    // On startup, setup the intersection observer for this component instance
    let observer = new IntersectionObserver(intersectionCallback, {
      threshold: 0.85
    });
    observer.observe(elementRef.current);
    return () => {
      // Don't forget to disconnect it when the instance says bye
      observer.disconnect();
    };
  }, []);

  useEffect(() => {
    if (state.viewDuration) {
      // when view duration of this instance changes, call callback from parent
      onViewDurationMsChange?.({
        viewDuration: state.viewDuration, 
        properties // might be an {id}, might be anything else...
      });
    }
  }, [state.viewDuration]);

  return (
    <div data-cy="TimedViewContainer" ref={elementRef} {...props}>
      {children}
    </div>
  );
};

export default ViewDurationTracker;

At this point, we can track the duration of a single item. We still need to deploy a swarm of these trackers on a fake "feed" of images, aggregate all their view durations as the user scrolls through and display the data.

Feed, Dashboard and Controller

Fetch photo data using unsplash.com API

For the experiment, we'll need something to track. Unsplash has a wonderful API allowing us to search fetch a list of image data based on many search criteria. I've assembled a list of such images fetched from multiple categories (see below). Then, transposed the json data a it as to avoid fiddling with the objects during run time.

Here's a node script I scribbled to use the API:

// To run, from script directory:
// node ./getPhotos.js

const fetch = require("node-fetch");
const fs = require("fs");
const unsplash = require("unsplash-js");

const ACCESS_KEY = "mfpNJ7dKkJlWHZ9NFd6fyBhVSLiFZKC90D0dVN48JIs";
const UTM_PARAMS = "utm_source=ScrollObserver2&utm_medium=referral";

const CATEGORIES = [
	"animals",
	"architecture",
	"cars",
	"fashion",
	"man",
	"motorbikes",
	"nature",
	"sports",
	"street",
	"underwater",
	"woman",
];

const api = unsplash.createApi({
	accessKey: ACCESS_KEY,
	fetch,
});

async function fetchPhotoData() {
	let promises;
	try {
		promises = CATEGORIES.map(async (category) => {
			console.info(`Will fetch category ${category}`);
			return await api.search.getPhotos({
				orientation: "portrait",
				featured: true,
				page: 1,
				perPage: 30, // Undocumented max seems to be 30.
				query: category,
			});
		});
	} catch (e) {
		console.error(e);
	}
	const responses = await Promise.all(promises);
	let idsByCategory = {};
	let dataByIds = {};
	CATEGORIES.forEach((category, index) => {
		let categoryPhotos = responses[index].response.results;
		idsByCategory[category] = categoryPhotos.map((result) => result.id);
		let categoryPhotoData = Object.values(categoryPhotos).reduce((acc, photo) => {
			let result = {
				acknowledgeUrl: photo.links.download_location,
				description: photo.description,
				id: photo.id,
				likes: photo.likes,
				src: photo.urls.regular,
				unsplashLink: `https://unsplash.com?${UTM_PARAMS}`,
				userLink: `${photo.user.links.html}?${UTM_PARAMS}`,
				username: photo.user.username,
				category,
			};
			acc[photo.id] = result;
			return acc;
		}, {});
		dataByIds = { ...dataByIds, ...categoryPhotoData };
	});
	let categories = Object.keys(idsByCategory);
	let result = {
		categories,
		idsByCategory,
		dataByIds,
	};
	fs.writeFileSync("photos.json", JSON.stringify(result));
	console.info("Result:", result);
	console.info("We're done.");
}

fetchPhotoData();

Feed

Using the photo data fetched, building a list is trivial. However, I wanted to add some additional functionality to ensure all categories have an equal chance to be displayed, with a certain level of randomization.

The algorithm should roughly:

randomize order of categories;
randomize order of images in each category;
take first image from first category, append to feed;
take first image from second category, append to feed;
...
when categories run out, repeat with the second image;
...
when images run out, stop.

This allows us to distribute categories through the list nicely. Later I've discovered a bug (ocassionaly one category is shown multiple times), but had no more time to fix it or to add a test for it, at least in this iteration.

See the code on:

(codesandbox)[https://codesandbox.io/s/in-browser-feed-item-view-duration-tracking-using-intersection-observer-zxgi7?file=/src/componentDemoViews/FeedDemoView.jsx]
(Github)[https://github.com/Gonusi/in-browser-view-duration-tracking-using-intersection-observer/blob/main/src/components/Feed/Feed.jsx]

Controller

This one accumulates the view duration of all elements and sorts them. It should be capable of accepting a minimum view duration to track - so that when user scrolls past the list very fast, these images don't get recorded. That, I've found, would only creates noise in our results - user does not actually view these images (unless user is a machine) anyway.

So, the plan is:

pass a onViewDurationChange callback / handler to the child Feed component;
when it's fired, take the {viewDuration, imageSrc} or similar;
put this data into an object containing list of viewed images;
if such imageSrc already exists in that list, add the viewDuration to the previous `viewDuration;
sort the results based on view duration to form a top 20 list.

See the code on:

Dashboard

Top 20 images images should be displayed with their respective view duration in seconds at the botttom of the screen. Clicking on an image should scroll the feed to that image so the user can see it better when browsing the results. So, it also should have controls for pausing the tracking.

See the code on:

Results

It works quite nicely. I've tested the thing multiple times, and yes, if you forget you're being tracked, you get some results you:

might not expect;
might expect but still be a bit ashamed of;
might be interested by.

The app quickly run into limitations due to the nature of how I selected the images, lack of any statistical methods implemented to actually present results.

The categories are very broad and non descriptive. For example, "nature" can range from a photo of a river valley, to stuff that is more like two color abstract painting. I prefered the latter, so to interpret results more meaningfully, I'd have to find better ways to categorise / describe the images.

I had these search terms / categories in the test:

	"categories": [
		"animals",
		"architecture",
		"cars",
		"fashion",
		"man",
		"motorbikes",
		"nature",
		"sports",
		"street",
		"underwater",
		"woman"
	]

Roughly, the top 5 images mostly tended to include a variation of [nature, motorbikes, underwater, woman, fashion].

I am a ±30 year old male, enjoying enduro motorcycling, so it's all very expected. However, this is still very interesting stuff, and for my next experiment I might update the tracker, build it into a chrome plugin so I could check the view duration of any web content. Then I could track facebook feeds etc.

Also, I noticed I start scrolling faster when I get bored, and "preferred images in the end of session" get less view time than they would have gotten if they were seen in the beginning of the session.

And these feeds are not only photos, it contains political stuff etc. For now, the results are best shown in a video, so enjoy:

Improvements to be made in next iteration, should there be one.

add categories below images in Dashboard;
save the data of each session in localStorage and build a statistical dashboard to better interpret results;
look for ways to adjust for increasing scroll speed as the session progresses.

Check the full code on Github orcodesandbox.

Bye for now, have a great day. Kasparas

Setting up a cronjob in a docker container running alpine linux node image container

2021-08-18T00:00:00Z

After finishing a NextJS app running in our docker service stack, I had to make it register to our service health dashboard. It accepts a POST request with some data, which is out of the scope of this article. Anyway, all the other services were using curl to post and report their health every other minute.

Here's the registration script. Nothing fancy, just using curl to make a POST request to an address defined in an environment variable:

# Docker prefils this with container ID, which can be used to access 
# this container in the network
hostname=$(cat /etc/hostname)
curl --header "Content-Type: application/json" \
     --request POST \
     --data '{"name": "some-service-name", "host": '"${hostname}"'}' \
     https://some-dashboard-url.com
echo "cronjob has just finished executing register-to-dashboard script"

Here's my Dockerfile:

# Dockerfile
FROM node:alpine AS runner
ENV NODE_ENV production
WORKDIR /
RUN apk add --no-cache curl
# move script to predefined 1min directory, change permissions, schedule it for running
# YES, script needs to NOT have .sh file extension
COPY  /register-to-dashboard.sh /etc/periodic/1min/register-to-dashboard
RUN chmod +x /etc/periodic/1min/register-to-dashboard
RUN echo "* * * * * run-parts /etc/periodic/1min" >> /etc/crontabs/root
ENTRYPOINT [ "startup.sh" ]

And here's the startup.sh file:

# startup.sh
# make sure errors stop execution
set -e
# start the cronjob
crond -f -l 8 &
# start nextjs using our own command from package.json...
npm run start:production

Alpine linux already comes set up to run cronjobs. It's directory /etc/periodic already contain directories 15min, daily, hourly, monthly, weekly.

Putting a shell script, with .sh extension removed (weird I know) into one of these directories, and starting the cronjobs using crond -f -l 8 will execute your script at the specified frequency.

You can run crontab -l to check the table specifying this behaviour:

crontab -l
# do daily/weekly/monthly maintenance
# min	hour	day	    month	weekday	command
*/15	*	    *	    *	    *	    run-parts /etc/periodic/15min
0	    *	    *	    *	    *	    run-parts /etc/periodic/hourly
0	    2	    *	    *	    *	    run-parts /etc/periodic/daily
0	    3	    *	    *	    6	    run-parts /etc/periodic/weekly
0	    5	    1	    *	    *	    run-parts /etc/periodic/monthly
# after our Dockerfile runs:
# RUN echo "* * * * * run-parts /etc/periodic/1min" >> /etc/crontabs/root
# we'll have a non-default line here:
*	    *	    *	    *	    *	    run-parts /etc/periodic/1min

From the Dockerfile we create create a new directory, 1min by COPY'ing a script there, and schedule the directories scripts to be ran every minute, expressed in the crontab syntax as seen above. See CronTabGuru about the syntax.

Running this stuff

When you have the Dockerfile, register-to-dashboard.sh files ready, from that same directory we can run this stuff and check out if all is working fine:

# build a docker image as instructed by the Dockerfile and tag it with "app"
docker build . -t app
# run a container using it
docker run app
# in a terminal, see a list of running containers
docker ps
# if you don't see it, you can check all containers, including stopped ones + get more info with --no-trunc
docker ps -a --no-trunc
# find the id or name of your running container, and open a shell on it
docker exec -it {your container id or name (without brackets)} /bin/sh
# when shell opens, we can check out if our Dockerfile has configured the cronjob:
crontab -l
# ... look for line like this, if you see it - great
# *	    *	    *	    *	    *	    run-parts /etc/periodic/1min
# simulate running of scripts from our folder, the output will tell you which scripts will be run exactly
run-parts --test /etc/periodic/1min
# if you wish, you can actually run the scripts yourself by issuing same command as the cronjob does
run-parts /etc/periodic/1min

Your cronjob should already be running every minute now. So, while we were checking all this stuff, some output should have appeared in the first terminal, started the docker container.

To see logs of a container anytime, even if you closed that terminal:

docker logs {container id or name}

If you need to stop the container

docker stop {container id or name}

So much fun, these cronjobs.

Make CRA dev server respond to CORS OPTIONS requests, as a gentleman should

2021-09-15T00:00:00Z

If you have ever wished to access the dev server of Create React App, your'e in luck. While working on a login page for a custom authorization server, I needed our OAuth client (SPA app) to return 204 OK response with correct CORS headers even in development mode. Essentially, I wanted two CRA apps running on different ports to be able to talk to each other using cross origin POST requests.

Development server (also based on CRA) with login page running @ https://login.app:3000:

POST `https://client.app:3001/login-callback?code=123?state=456`

Client App must respond:

204 OK
#CORS headers (regular ones ommited for briefness): 
{
    # allow login app to make cross origin POST request to me
    Access-Control-Allow-Origin: https://login.app:3000 
    # allow login app to send me cookies on a cross origin request
    Access-Control-Allow-Credentials: true 
    # allow login app to use these methods on a cross origin request
    Access-Control-Allow-Methods: GET, POST
}

Fortunately, if you put a file setupProxy.js in your src directory (as generated by CRA), you can configure a node express proxy server, modifying responses made by CRA dev server at your own will. Let's use a popular (CORS)[https://www.npmjs.com/package/cors] middleware npm module to set up cross origin responses automatically.

So, using Create React App gives you a similar directory structure (as of 2021). Create the file as shown below:

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg
    setupProxy.js <--- Create this file

File contents should be:

// src/setupProxy.js
// do npm install --save-dev cors to install the cors package

const cors = require('cors');

const corsOptions = {
	origin: 'https://login.app:3000',
	credentials: true,
    methods: "GET,POST"
};

module.exports = (app) => {
    app.use(cors(corsOptions));
	app.options('*', cors(corsOptions));
}

And that's it. You'll get the response you need. To recap what we have done:

configured node express server running (or proxying?) our CRA app on local domain https://client.app:3001;
when it receives OPTIONS request, it will respond with certain headers (specified above);
when browser running App https://login.app:3000 makes that OPTIONS request, specified response headers inform it it's OK to continue with the actual POST request;
everything works out nicely.

Actually, we could avoid using any imported package at all. We could just create a little middleware ourselves:

// src/setupProxy.js
module.exports = (app) => {
    app.use((req, res, next) => {
        res.append('Access-Control-Allow-Origin', ['https://login.app:3000']);
        res.append('Access-Control-Allow-Methods', 'GET,POST');
        res.append('Access-Control-Allow-Credentials', 'true');
        next();
    });
}

So that's it. This is great stuff, and you can definitely do more than set up CORS with it. FIY, I do not know if this is really a proxy server sitting in between CRA dev server and you, or are we actually configuring the instance of dev server. CRA says we indeed are configuring the dev server instance.

Access Express and CRA (Create React app) development server routes on same localhost port

2022-01-30T00:00:00Z

If you have a fullstack app where, say, landing routes are served using Express, and there's an inner "App" made using react, it's comfortable to develop both on the same port. Example scenario:

http://localhost:3000/app <- Create react app web development server configured with "homepage": "app" in package.json
http://localhost:4000/api <- Express based API routes
http://localhost:4000/landing <- Express based static landing pages

Create react app has a proxy feature allowing us to seamlessly work on http://localhost:3000/app and access the API without any CORS issues. To configure it, add "proxy" to the CRA project's package.json:

{
   ...,
   "homepage": "/app",
   "proxy": "http://localhost:4000" <-- add this
}

With this config, all requests made to https://localhost:3000/api, except those containing Accept: text/html header, will be proxied to https://localhost:4000 (our backend server).

However, by design this proxying will not work for landing pages (note the Accept: text/html header exception). The alternative way to configure "proxy" for CRA - the setupProxy.js will not help in this case too.

Instead, consider proxying the other way:

Don't proxy CRA -> Express backend
Proxy Express backend -> CRA

// Express code
const request = require('request');

app.get("/app/*", function (req, res) {
    req.pipe(request(`http://localhost:3000${req.path}`)).pipe(res);
});

We take the req object, pipe it to the request library with makes identical request to another URL. Then the result is piped back to response.

Our custom Express server has no limitations regarding any headers, so will successfully proxy the request.

Full example and use case

Let's create a basic fullstack app. Obviously (but not so obviously when I was first starting 10 years ago..), you'll need Node. Begin by creating an Express Hello world app.

Express server

From inside directory fullstack (any name will of course work), set up a basic Express app + add request http client package:

npm install express request

This will generate a package.json file similar to this:

// fullstack/package.json

{
  "dependencies": {
    "request": "^2.88.2",
    "express": "^4.17.2"
  }
}

Create a server.js file with the "Hello world" app contents:

// fullstack/server.js

const express = require('express')
const app = express()
const port = 4000

app.get('/', (req, res) => {
    res.send('Hello World!')
})

app.listen(port, () => {
    console.log(`Example app listening on port ${port}`)
})

Your directory structure should look like this:

To test your Express app, from fullstack directory run:

node server.js

Visit http://localhost:4000, you should see "Hello world" text content returned by the Express server. Close the server by pressing CTRL + C in the terminal for now.

Create react app "client" setup

From "fullstack" directory, create a React app called "client":

npx create-react-app client

Your directory "fullstack" should now look like this:

Configure CRA to have homepage of /app. This is not strictly required if you know what you're doing, but out of scope of this article.

// fullstack/client/package.json
{
  ...,
  "homepage": "/app"
}

Start the CRA dev server, from the fullstack/client directory:

npm run dev

Visit http://localhost:3000/app and you should see a basic react template app.

Configure Express proxy

Now we need to proxy http://localhost:4000/app/* to the CRA server running on port 3000. In fullstack/server.js containing the "Hello world" Express code, add some lines:

app.get("/app/*", function (req, res) {
    console.info(`Proxying to localhost:3000${req.path}`);
    req.pipe(request(`http://localhost:3000${req.path}`)).pipe(res);
});

Why /app/* with the wildcard, instead of just /app ? CRA will need to serve some static assets, like js files, stylesheets, favicons... Requests to all of them need to be proxied to the CRA dev server.

Testing it all out

The steps:

make sure your CRA dev server is still running by visiting http://localhost:3000/app (should open demo react app);
start the Express server again by running node server.js from the fullstack directory, check if http://localhost:4000 is still showing "Hello world" message;

access http://localhost:4000/app/hello.

In the 3rd step, what should happen is:

Express will get a request to http://localhost:4000/app/hello
get handler for http://localhost:4000/app/* will catch it and run our proxying logic
request library will make request to http://localhost:3000/app/hello
CRA dev server will return index.html contents
the html contents will be piped to Express response
you will get the proxied react page, on the port of Express server

Hope this makes sense.

Typescript - discriminated unions for more concise react component prop types

2022-06-17T00:00:00Z

I had a problem where a component providing our app graphql capabilities was returning one of those:

<ApolloProvider /> - real graphql provider to allow testing some legacy code
<MockedProvider /> - mocked graphql provider for testing with... mocks

const NetworkProvider = ({client, isMocked, mocks}) => {
    if (isMocked) return <MockedProvider mocks={mocks} />
    
    return <ApolloProvider client={client} />
}

Note the different returned providers accept different props. MockedProvider accepts mocks prop, while the ApolloProvider does not, instead it accepts an optional client prop. That's an excellen opportunity to mix up the props and pass something that makes no sense. In the old days I used to use a check in the component to warn user incorrect props were passed, something like this:

if (!props.isMocked && !!props.mocks) {
    throw new Error('Please only pass mocks if isMocked is true. ')
}
if (props.isMocked && !!props.client) {
    throw new Error('Please only pass client if isMocked is false. ')
}

Today, typescript can warn us if we pass incorrect props based on another prop, removing any need to do such checks. We just need to create 2 interfaces, one for each group of props, both having at least 1 common prop to help TS identify which of the 2 interfaces should be applied.

import {MockedRequest} from "msw";

interface MockedProviderProps {
    isMocked: true // the common prop
    mocks: MockedRequest[]
}

interface ApolloProviderProps {
    isMocked: false // the common prop
    client: ApolloClient<unknown>
}

type Props = MockedProviderProps

const NetworkProvider = ({client, isMocked, mocks}: Props) => {
    if (isMocked) return <MockedProvider mocks={mocks} />

    return <ApolloProvider client={client} />
}

Now if we try to do something stupid - like pass the mocks prop while isMocked === false, typescript will warn us.

Just to give another, even more contrived example, let's use an imaginary component Person. The Persons live in a really horrible world where you can only choose 2 jobs, and if you don't have a hobby as an adult, everybody thinks you love nothing. It bodes well to our test case though.

interface AdultProps {
  // Usually examples use "type: 'adult' | 'child'" as common property.
  // Let's use a boolean just for fun, to make it clear it can work.
  type: 'adult'; // "isAdult" is a common property between an adult and a Child
  employer: string; // An adult must have an employeer
  jobTitle: "king" | "engineer"; // and work in one of our rather limited fields.
  hobby?: "computers" | "fishing"; // An adult can have hobby, but it's not required.
}

interface ChildProps {
  type: 'child'; // The common property allows Typescript to discriminate the types.
  hobby: "computers" | "mudcakes"; // A child must have a hobby, note it can overlap with adult hobbies.
  school: string; // A child must have school.
  // It must not have employer or jobTitle (from the adult interface).
}

interface CommonProps {
  name: string; // Both a child and an adult have names.
}

// Props is a combo of Common props and either adult or child props.
type Props = CommonProps & (AdultProps | ChildProps);

const Person = (props: Props) => {
  if (props.type === 'adult') {
    // We can't just destructure the props when declaring the function.
    // Typescript won't be sure they'll be available yet.
    // It will be though after we check the common prop and determine type.  
    const { name, employer, jobTitle, hobby } = props;

    return (
      <>
        {`${name}, a(n) ${jobTitle} employed by ${employer}. Loves 
        ${hobby ?? "nothing"}.`}
      </>
    );
  }

  const { name, school, hobby } = props;
  return <>{`${name}, a kid studying at ${school}. Loves ${hobby}.`}</>;
};

export default function App() {
    // Now typescript will warn us if we mess up
  return (
    <>
      <Person
        name="Arthur"
        isAdult={true}
        employer="Townsfolk"
        jobTitle="king"
      />
      <br />
      <Person
        name="John"
        isAdult={false}
        hobby="fishing" // Typescript will warn us that only adults can fish. In it's own words...
        school="Vilnius 1st middle school"
      />
    </>
  );
}

Try it out in this codesandbox. Try adding school="xyz" prop to the Person with isAdult={true} prop. Note how typescript warns you that this Person can not have such a prop.

Growing microgreens in basic hydroponics

2025-03-03T00:00:00Z

After wishing to grow microgreens for some time now, and looking into building all kinds of automated systems involving pumps and aerators, I've decided to start small. Hydroponics may be a bit of a strong word here, actually, but still - technically true.

The beauty of microgreens - the tiny plants that get eaten at around 7 - 15 days of age - is that you really don't (should not, according to tutorials) need much.

(25 Eur) 6 hydroponics microgreen growing trays (generic, everybody sells them)
(6 Eur) Silicone net used for drying vegetables
[(10 Eur) worth of regular seeds bought locally]

You fill up that plastic tray with water, and the seeds sprout roots that go down through plastic webbing, reaching the water. No other medium should be necessary (but we'll see). According to the tutorials, one could improve output by using hydroponics suitable fertilizer in the water, but it's not necessary since the greens are cut so early.

The trays are quite OK for the price. Made from 3 pieces - a bowl for the water, a plastic grid where you put the seeds and a lid for keeping moisture in. The plastic grid has holes which are too large for small seeds, this is where the silicone net comes in, keeping them from dropping through, but still allowing roots to pass through.

A few of the boxes were slightly deformed, with the center of the plastic netting bulging upwards, making seeds roll to the sides.

The silicone is already pre-cut and works perfectly with these trays at [20cm, 28cm] dimensions. For larger seeds, it's not needed. Definitely required for smaller ones.

Regular, basic seeds should be fine, just google the (big variety) of plants that can be consumed early on and don't have poisonous leaves etc. I actually accidentally bought some seeds for radishes nicely covered in a paper strip for easy planting. An extra pain here, but I've actually found the extra paper to hold moisture very well.

I put 400ml of water into each bowl, put the seeds on top, sprayed them with a sprayer and closed the lids. I know it's recommended to compress the seeds and keep them dark for a few days (to emulate conditions under a layer of soil), but I've read they should do fine without the extra steps.

When they sprout, I have a few lamps ready to shine on them for 16 hours a day (it's still early sprint here in Lithuania, it's dark).

I'll update this post when they sprout.

Day 3 update

Beans, both varieties of radishes and brocolli have sprouted. For now the leaves are super small and yellow. I'll start using artificial lights tomorrow on them. I changed the water. The boxes had a weird, spicy smell in them (all of them), I'm slightly worried I should have changed the water in the box sooner - hopefully not a sign of some bacterial infestation yet. I'm spraying all the seeds with water every day.

Worryingly, both radishes, which had their seeds wrapped in paper, developed what I believe to be small mold spots. I suspect this is due to the paper always being super wet. I manually removed the mold spots. I marked them with red rectangles in the photo.

I'll see how this develops further. For now I've started tracking the sprouting (S) and problems (yellow background) in this table.

Day 4 update

All have sprouted except for the smallest seeds of Valerianella Locusta (which I've thought would be the first). The plants remain moist, and seem to be doing well. No more mold growth (which was a surprise, maybe it wasn't mold after all?). I have decided to not change the water today as this would not be sustainable, and LLMs don't seem to think I need to. There was a spicy smell in most of the containers, yet I suspect this is actually the sprouts.

Day 10 update

Ok, so I've made a couple of mistakes that ruined the experiment, however I consider it a success in the sense that I got very quickly that growing microgreens is probably not for me. At least not in this configuration.

We had some excellent 15 Celsius, sunny weather last weeks despite it being early March. And so I made many mistakes (I think):

I kept the lids on during first 6 days or so. The super humid environment caused black funghus on beans. A lot of them died a horrible, gellatinous death.
After that smelly fiasco, I've decided I won't eat the beans, which reduced motivation.
I removed the lids, but did not keep up with spraying schedule - it's just too much work to keep the seeds moist. The smaller seeds quickly dried out in the sun. It was a pity to see the small roots that had developed die too.
The radishes, which were the best performers but enveloped in paper tissue were not able to free themselves from the paper. Some did, some remain under the paper. The paper is what kept them moist I think though.
The broccoli are the only ones that I think I'll be able to eat tomorrow. They grew despite the bad conditions, and without any help from the paper.
The few surviving bean plants are now too large to consider them "microgreens".

All in all, I'll try to eat the broccoli, and a few of the radishes. The rest, I'll try to grow to full size plants by replanting into pots this weekend as to not kill them. I think the experiment has proved that at this time of my life I do not have the patience required to keep such delicate small plants alive. However, I'm still considering building an automated system out of the containers on a small scale - perhaps just 2 boxes.

The good performers:

↑ Broccoli ↑ Radishes (note the paper)

The smelly, poor moldy slimy performers:

↑ Beans (went slimy, moldy, stinky, will not eat but will grow them to full plants)

The dead:

↑ Leafy greens ↑ Beetroot

Transfer thousands of photos from android to mac via ftp

2025-05-29T00:00:00Z

Today I was preparing my old Samsung S23 Ultra for sale after moving to iOS for now. The app "Android transfer", which kind of worked some of the time to transfer files from android to mac was no longer available though. The mac also refused to see the phone as a USB storage device despite multiple attempts to connect it (of course setting the phone to "USB / files transfer mode). The "media transfer" mode also did not work (while trying to import via "Photos" app on my mac).

I then downloaded a one of the many FTP server apps available for android. I was able to easily connect to the FTP server just by using "Finder" app:

However, the finder was super slow / crashed / lost connection to server often (due to 10's of thousands of images in the "DCIM/Camera" directory) and I was not able to transfer them successfully (apart from doing it manually in batches of like a 1000).

I tried to download an FTP client and, to my horror, on the appstore, all were paid (and I don't really need FTP for anything else at this point)

Fortunately, free options still exist, and ChatGPT wrote a script for me which uses lftp. To install via homebrew:

brew install lftp

Save this script download-camera.sh. I had problems with it being unable to create files / directories due to permissions / Apple "System integrity protection" stuff. So the script saves the results to your users home directory, which seemed to work (It will look like /Users/yourusername/result

#!/bin/zsh
set -euo pipefail

# ── connection details (of course match them with your android FTP config)
HOST="192.168.1.202"
PORT="2221"
USER="android"
PASS="yourpassword"
REMOTE_DIR="DCIM/Camera"

# ── target folder (flag or env var) ───────────────────────────────
LOCAL_DIR="${LOCAL_DIR:-$HOME/result}"
while getopts "d:" opt; do
[[ $opt == d ]] && LOCAL_DIR="$OPTARG"
done
LOG_FILE="$LOCAL_DIR/ftp-mirror.log"

mkdir -p "$LOCAL_DIR" 2>/dev/null || {
echo "❌  Cannot write to $LOCAL_DIR — choose another location" >&2
exit 1
}

# ── lftp batch ────────────────────────────────────────────────────
lftp -u "${USER}","${PASS}" -p "${PORT}" "${HOST}" <<EOF
# --- connection settings
set net:timeout 30
set net:max-retries 3
set cmd:fail-exit yes
set ftp:list-options -a
set xfer:clobber on

# --- show remote file list
cls -1 "$REMOTE_DIR"

# --- sequential mirror download
mirror --verbose \
--parallel=1 \
--use-pget-n=1 \
--log="$LOG_FILE" \
"$REMOTE_DIR" "$LOCAL_DIR"

bye
EOF

echo "✅  Finished. Files are in $LOCAL_DIR"
echo "   Transfer log: $LOG_FILE"

Make the script executable: chmod +x download-camera.sh

Run the script: ./download-camera.sh

And it works - it sequentially downloaded the 25k of photos / videos over the few hours. I had to keep my phones screen on though, the FTP app seemed to go to sleep otherwise (I went to developer options of the phone, and selected "Keep screen on" option").

The models are truly becoming an UI for whatether you need - writing programs on the go. Cool but scary.

Kasparas

The Outrun

2026-01-05T00:00:00Z

Amy Liptrot · ISBN 978-1-78689-422-9 · Score 3

I went through the book quickly and really enjoyed it even if it started getting a bit bored at the end. It has a calming quality as it describes the life of an addict getting better through her experiences in nature - the archipelago of northern Scotland isles. Mostly about islands of Orkney and Papay, which I've now looked up in google maps.

It all starts with a painful description (not a memory - she was born on that day) of her father being taken away to a mental institution to the mainland. We then jump to a later time, where she escapes to London, and, as young people do (and older people would love to, but find reasons not to) lives a life with a feeling that things are waiting for her.

Then comes her increasing struggles with alcohol. The addiction theme appears slowly but steadily, as the book first describes seemingly nice things but you know it's not gonna end well. The loneliness of the big city (even if the relation comes from perhaps being a "citizen of internet"), the feelings of being left behind as her group of friends moves on. The paradoxes of coming to big city to get to know different people, but in reality finding a safe group of identical ones.

Later on there's a crisis and successfull rehab programme. Amy stumbles back to the islands, and, in her own words "just get's stuck", but this turns out to be a good thing.

Back in the islands, she founds newfound joy in the simple way of life and the superficially simple landscapes, flora and fauna in there. And this in there, the main theme of the book appears, and what I initially liked about the book as I quickly flipped through it in the library.

The writer describes the island mainly through experiences and how they make her feel, instead of directly describing the landscapes, which, at first sight, would probably look great but would get dull and empty and treeless (due to the extreme wind and saltiness, as the author says) quite quickly if just viewed superficially.

Instead it seems Amy is able to notice an infinite stream of tiny happenings that accumulate into one big and great experience, and it is all described quite vividly. This I kind of relate to, as I find, for example, I'm able to ride the same bike route every day and never find it dull, while some strongly crave new routes. They will see more this is for sure, but the point here is that the difference in how it makes one feel on a different day is enough to make it feel new each day. Together with the smallest changes to the landscape, winds, skies itself which are always there if one looks for it.

Not that she takes the same route though. She enrolls into a job of looking for rare island birds during the short northern nights and scouts an island for the species, square by square. She then looks at the stars, and thinks stuff like "asteroid Apophis which had been initially calculated to have a chance of ±2 percent to hit Earth is out there". She describes rituals involving large fires or simply fires burning trash on the islands, and the people themselves. She started walking, and took to finding meaning in it, started swimming in the sea which, at the temperatures and winds and waves I think to be a big effort.

All the small things gradually help author fight the feeling that nothing is worthwile doing if you don't get drunk during it. I can somewhat relate to it too while to a lesser extent I guess, as I remember quitting smoking and losing the one nice quick thing you can do after any kind of activity. She had it worse though.. but managed to recover.

I especially liked and resonated with one paragraph about how she found snorkeling in the islands uncovered a whole new world. I will paste this here, and end this with that.

Face down in shallow water, coated in neoprene and breathing through a tube, I feel as if I've opened a door that has always been in my house but I had never noticed. Life can be bigger and richer than I knew.

Surely there must be such doors in all of our lives.

P.S. The publishers do a great job by adding first sections of her other books in the end of the book. While I found myself being tired of this one a bit at the end, after reading the start of next 2 ones, I'll probably get them too.

Anything learnt from the book?

I know / knew a lot of alcohol-addicted people. Like my Italian stepfather (RIP), who even had a disability assign by state due to it. This book perhaps could have revealed a bit of how they felt, however it's probably a very personal experience.
One can seemingly live (and live quite nicely) by just floating through opportunities that appear - kind of without perpetual office job etc. Still one must be brave to pursue this, as the author went that road not due to choice, but necessity.
There are even more things to be noticed around that I previously thought (the author tought about birds, underwater, wind, stars, ability to think how other people live, which one kind of knows, but knows more of after this read).

The Gentle Art of Tramping

2026-01-14T00:00:00Z

Stephen Graham · Year 1926

I always enjoy travel books. It took me a long time to actually recognize I might be enjoying them more than being on a long trip myself.

This one originally interested me due to being written 100 years ago at the time of this post (1926). And indeed it is reflected in the language, described landscapes and tools. The language nothing but simple, and was very hard to read initially, but satisfying non the less.

At the core, it's a little book about hiking which tries to be a universal guide. It begins with a collection of connected essays on clothing, sleeping outdoors, the best hiking routes known by the author. Interestingly and fittingly to the policital situation of 2026, Crimea, Caucasus mountains in Russia are some of authors favorite locations, but the author notes that the travel there became very dangerous. "“Since the War, and the Revolution, the Caucasus has, unfortunately, become much more dangerous for travelers of all kinds. The tribes are warlike, and have been badly treated by Bolsheviks and Europeans in general”.

A beautiful section named "The art of idleness" was one I really connected to. It speaks of how "life's quality is in momentws, not in distance run" - meaning the author considers quality over quantity. Beautiful proze gives examples of the benefits of slow travel, even suggesting travel is only worth it if it's not a rush, but "the way" (I interpreted it as the way you live).

If one rushes, then tramping might be only a stamp one puts on his life, "done that" to, as the author says, "a stunt, something done to make a dull person ornamental". A strong statement, but I appreciate the whole text of being opinionated like that, cause what's a book if there's no opinion in it (An encyclopedia or an atlas would fit the bill but you know what I mean).

"It is a fallacy to think that during the siesta you do not tramp; you are tramping, wandering in unknown parts..." - author suggests.

...Reading in progres...

The Roads to Sata - A 2000-Mile Walk Through Japan

2026-01-21T00:00:00Z

Alan Booth · ISBN 978-0-141-99283-9 · Year 2021 (Originally 1985)

I bought this book from an overpriced stationary and writing tool shop, which everyone still visits cause it is so nice, and has a few books for sales matching the mood. I guess it's not that overpriced then as the values lies in the beauty of it but anyway.

It seemed like an excellent book to prepare for my journey to Japan. Sure it was set more than 40 years back, but I wondered if I could still relate when I visit myself. The author traveled through the west side, which I did not visit, but the general atmosphere, I'd say, did not change.

About the book - well, it's gonna be hard to summarize this one, as summarizing a 4 month long journey can be.

It took me a long time to read. Took it to Japan, then stopped reading it right in the middle. I got back to it though, which rarely happens with books I leave behind. I guess it was not a book to be read each day. Maybe, just like any lengthy trip (even so incredible as this one), it can get a bit tedious if you do it all in one go.

Alan Booth, who lived in Japan until his early death at 46 in 1993, spent ±120 days in the on-foot-only (no lifts at all) hike of more than 3000kms from the northern tip of Japans most norther island - Hokkaido, to the most souther one of the larger islands - Cape Sata. He took a route by the western coast, omitting Tokyo.

He describes the people, the incredible landscapes and rising industrial cities, the cool and weird customs, the good and the bad... The great generosity and the extreme racism (not always in a bad way though), the extreme indifference towards the rest of the world and the tremendous beauty of the rituals.

He does all that in extreme detail - a true talent for that. The key structure for each day is the same - start the day, somethig happens. Walk for some 30-40 miles, detail the roads, something happens. Drink a few beers, find a Ryokan (a traditional Japanese guest house), describe it and the evening. In between that, though, a lot happens, as one can expect on such a journey.

He also really knows his stuff - legends, poems, history, mythology is presented in relation the location described.

The book is truly like a journey. It starts fresh, but ends a bit tired, not that it's getting worse technically, but you can feel the author getting tired of it himself I think... I remember the middle, but not the ending at all.

Instead of trying to recount everything, I'll leave a few quotes I marked. It does not represent the book at all, but instead are some caricatures I liked, some small insights the author does not miss in his daily life, and includes together with the otherwise incredible descriptions of this beautiful country.

Describing an evening walk made an impression on me:

In the starlight the narrow road wound up and up into the hills, crossing dark streams on small stone bridges, winding past the last isolated buildings of the town and into the darkness of the forest. I stoped outside one lonely house and listened to a woman singing in her bathroom. The night air was warm, the stars bright silver, and by the time I reached the minshuku at Nakama the white moon had risen high over the woods.

A family description instead:

... where I found a drive-in and had a lunch of noodles while the proprietor and his family hooked fish out of a filthy dirty tank and tossed them with unsettling, secretive smiles into a tin bucket to die.

A discussion about why a sign "Open" is lit but hotel actually closed:

- But you've got a sign all lit up down on the highway
- Yes. We always keep it lit. 
- What for, for goodness sake?
- To make people feel welcome.
- But you're closed!
- That's right.

Later on that evening, to demonstrate the cosmopolitan nature of her family, she brought me a knife and fork with which to eat a bowl of noodles.

Quite a few useful notes in the book, like:

...shops selling rice and its byproducts are ideal places to make inquiries since they are often the oldest established shops in the district...

A few references to weird Manga:

There was also a pile of comic books to amuse the breakfasting customers; the one I galnced at (Eros) featured a naked woman tied up in an automobile body shop being assaulted with breathtaking variety of spanners, jacks and big ends.

The author closes the day, (almost every day), with some beautiful proze:

That night I chuckled myself to sleep, thinking of the sparks coming out of the old woman`s nostrils and hair, and as we slept, each plugged into our dreams, the first snow fell on Mount Fuji.

P.S. I also found a new way to read travel books with this one - not only marking stuff I like with my pencil, but also having my phone nearby in bed, looking up all the places mentioned. This gave entirely new process to the read, cause you still first imagine the place, then discover the real one in the real photos.

Building a 3d model of a kids room cabinet

2026-01-22T00:00:00Z

Our kids bet is a 2-story unit. It is positioned in a leg-towards-the-door orientation which, kids said, was not very cozy as they see a black hole at their legs at night. Also it's ver un-feng-shui.

They also read a lot of books, especially the bigger one. To remedy the situation I've decided to build custom shelving which would act as both a barrier and some nice storage.

The thing is, if I just bought it, it would be oriented towards 1 single side (the non-wall side :) ). But, this would mean a lot of wasted space in my case. This is because the bed itself would obstruct a lot of the shelves.

I decided to use that obstructed space from the other side instead, so some books can be put in there too.

Initially I thought of making it twice deeper and more complex. However, this would be so thick (60cm) that it would almost block the entrance to the room.

All in all, it was really worth modelling the shelving. I was able to arrange available wooden panels I can buy from local shop without any need to cut them up before ordering them. Also it allowed me to visualize that the original shelve (the thick one) will probably not work.

We'll see how it goes when I'll be building it now.

3d printing a tool for drilling shelves

2026-01-24T00:00:00Z

Today I had to solve a problem I knew I'll encounter when building the shelves for my kids. I'll need to drill a lot of holes (12 * 7 shelves), and they had to be perfectly aligned and straight because I was planning to use elegant wooden dowels and glue instead of screws or triangles with screws etc. to hold the shelves.

I knew this was impossible (for me) to do by hand. Turns out all the 3d tinkering at tinkercad was really useful.

The print went for 5 hours. The tool was too big to fit into the printer so I had to glue it from 2 parts with some epoxy.

With the extra adapters the same tool can nicely used for the other orientation I need to drill holes in - this being the most precarious one.

The result was really nice. We'll see if the holes align though when I'll be assembling the shelving unit!

Learning Ink shading, building tool to build book cabinet

2026-01-25T00:00:00Z

Today I was going through the Ink drawing book I've just started. I can tell this is gonna be useful cause I'm encountering various textures and shading ways I'll want in my own drawings already (mainly organic leaf shapes used for shading).

At the horror of any ink connoseur, I was working on my ipad, cause that's where I'm doing most of my illustrations. BUT, I also ordered a certain ink/pen combo. A very cool book, also nicely written / illustrated.

To see what I'm doing with this one could look into my other blog sutemų dirbtuvės .

I also learned a lot about real pens, nibs, ink. It's a world one could easily get lost in, as is the case with any truly useful instrument that is also a thing of beauty (if manufactured well). Specifically I was intrigued by "fude" type of pens which have bent tip allowing to get wide line not only by pressure, but also by rotating the nib.

I also learned that my 3d printed modular tool designed for drilling straigh, well spaced holes in both walls and shelves... works wonders. However, a method I chose to secure the shelving was not ideal. The plan was to use only wooden dowels and glue. The drilled holes were nice and precise enough to match in all 7 * 3 dowel locations, but in the end, I was unable to perfectly weight, clamp or otherwise compress the glue and in some locations a gap of perhaps 0.5mm exists. I think the glue will hold cause it's not like that everywhere, but it does not make me proud at all.

Rendering in Pen and Ink - The Classic Book On Pen and Ink

2026-01-26T00:00:00Z

Arthur L. Guptill · ISBN 978-0-307-83188-0 · Year 2014

People that know me will know I like to doodle and perhaps even paint. Since I've now decided to make my hobby a bit more public and directional by developing a book character, I've decided to also focus my drawing onto a direction I like. That direction is the "old kids book" style of ink countours and shading, supplemented by some watercolor coloring (or sometimes just the ink).

So, to start, I've started working with a (from what I've read) classical guide on ink drawing. This is that book.

And I really like it. It's more of a workbook.

...work in progress...

Wood works and drawing hobby plan

2026-01-28T00:00:00Z

Today I learned that description for this TIL section is probably to be removed, as the the title is long enough to describe the ... short post itself.

I also learned that hammering a rectangular piece of wood into a space that is slightly smaller than it's dimensions is not gonna work. While it seems common knowledge, believe me or not, I spent 10 minutes frantically trying to disprove that. Shocked as I was by my own actions, problem was I had already applied glue and had to get the piece 80cm x 25cm piece of wood in the (too) tight spot until it set. When this did not work at all and the shelves started breaking, I frantically started kniving the non-fitting piece in rough strokes - turns out all the tools are at my cabin.

In the end it worked out OK, but from now on I will measure my rectangles more carefully and adjust with proper tools before applying them.

Yup.

I also created an machine learning based learning / marketing plan for my recent ink drawing studies / hobby. I've decided that it's a good time to start work on my potential "Ratsnack" book - hoping to maybe grow at least the smallest of audiences and validating or disproving the idea (and my capabilities and making an interesting drawing + story).

While ridiculous, it's still plan, and better than nothing. It'll allow me to draw scenes while adapting ink shading exercises, and posting the results to some locations too.

That's mostly it.

Learn pen shading with leafy shapes, varnishing large surfaces, some print CSS styles.

2026-01-29T00:00:00Z

Today I sanded and varnished the new DIY shelve for my kids. Turns out water based varnish will raise the grain of the wood, and it'll look very bad, one must sand it. I learned that sanding is one thing, but you actually seem to "burn in / rub in" the previously varnished surface a bit even until it's smooth - as it even works with a completely worn sanding pad.

Currently it's not the best time to make photos, but I'm proud of finishing it so... Even if it's a bit ...basic. It'll look much better with all the details I'll add later on. I also learned that varnishing is not as simple as it looks. You have to be patient. Can't move the brush all around, as it leaves lines, and they better matched the grain...

One must also provide a good amount of varnish, otherwise it forms blobs, runs etc.

Best way is as usual - slow is fast, take your time. In the end I actually learned to kind of enjoy the tedious and boring process. What helped was thinking about doing the work the best I could.

I then spent a bit of time (as I promised to do this everyday) on my ink drawing book exercises. I encountered the first exercise where I'm having true trouble (can't draw it as it is shown) - and it's the random looking leafy pattern which is not random at all...

What I found helps is imaginging it's leafy shapes and then forgetting you're drawing the pattern - draw leafy shapes instead. It's not exactly the same, but maybe it not necessarily must be. Anyway, I'll return to this tomorrow. This will be very useful in my future illustrations.

I also worked on creating a new subreddit r/NaiveIllustration which will serve as a blog on my learning, kind of, with the idea of the drawings perhaps atracting an audience. Due to all this I was unable to actually finish any drawing and post it. Well, the shelf should take less time tomorrow, maybe then.

At work I also remembered a few printing CSS styles nuances. For example:

it's indeed possible to detect "closing of print dialog":

window.print()
window.addEventListener('afterprint', handleAfterPrint) // nice

I also, once again, confirmed that having 2 versions of a microservice you wrote with both being used in the codebase is not the way to go. I'll start remedying this tomorrow immediatelly.

I also learned this TIL section is truly a nice way to reflect on the day, even if I'll probably have to rename it to "Diary" :)

It being online forces one to try and write in an at least comprehensible manner, even if no one will probably read it. It kind of sums up the day and invigorates me to keep the work tomorrow.