arka triymfalnaya

подключаем lcd дисплей к arduino

2026-04-17T00:00:00Z

с портами дело стандартное:

GND -> GND // земля
VCC -> 5V // питание
SDA -> A4 // линия данных
SCL -> A5 // линия синхронизации

и пример скрипта отображения текста:

#include "Wire.h" // библиотека для протокола i2c
#include "LiquidCrystal_I2C.h" // библиотека для дисплея

LiquidCrystal_I2C lcd(0x27,16,1); // присваиваем имя дисплею

String message = "there's a bluebird in my heart that wants to get out but I'm too tough for him, I say, stay in there, I'm not going to let anybody see you. there's a bluebird in my heart that wants to get out but I pour whiskey on him and inhale cigarette smoke and the whores";

void setup() {
lcd.init();
  lcd.backlight();

  // добавляем пробелы в начале, чтобы текст выходил из-за края
  message = "                " + message;
}

void loop() {
   for (int i = 0; i < message.length() - 16; i++) {
    lcd.setCursor(0, 0); // установка курсора на 1-ю строку
    lcd.print(message.substring(i, i + 16)); // вывод 16-ти символов
    delay(100); // скорость бегущей строки
  }
}

убедитесь в том, что на плате постоянное питание (не от батарейки)

плавающее оглавление на solidjs

2026-03-24T00:00:00Z

иногда плавающее оглавление кажется довольно простой штукой: берёшь заголовки, рисуешь список, добавляешь якоря — готово.

в этой статье — разбор table of contents, который я собрал на solidjs: от поиска заголовков до sticky/fixed поведения и адаптивного ui.

контекст

задача :

собрать список заголовков статьи
сделать быстрые переходы по клику
подсвечивать текущий раздел при скролле
поддерживать мобильный и десктопный режим
уметь скрываться и появляться

сбор заголовков из документа

вся система начинается с обхода dom и поиска заголовков внутри контейнера статьи.

const updateHeadings = () => {
	const parent = document.querySelector(props.parentSelector);

	if (!parent) return;

	const nodes = Array.from(
		parent.querySelectorAll<HTMLElement>("h1, h2, h3, h4"),
	);

	setHeadings(nodes);
	setAreHeadingsLoaded(true);
};

по сути это “снимок структуры документа”.

debounce пересборки оглавления

чтобы не пересобирать список слишком часто:

const debouncedUpdateHeadings = debounce(500, updateHeadings);

это особенно важно, если контент может динамически изменяться.

определение активного заголовка

самая “живая” часть компонента — отслеживание скролла.

const isInViewport = (el: HTMLElement) => {
	const rect = el.getBoundingClientRect();

	return rect.top <= DEFAULT_HEADER_OFFSET + 24;
};

и дальше поиск активного элемента:

const updateActiveHeader = throttle(50, () => {
	const index = headings().findIndex((h) => isInViewport(h));

	setActiveHeaderIndex(index);
});

переход к заголовку

при клике происходит ручной scroll с компенсацией fixed header’а:

const scrollToHeader = (element: HTMLElement) => {
	const top =
		element.getBoundingClientRect().top -
		document.body.getBoundingClientRect().top -
		DEFAULT_HEADER_OFFSET;

	window.scrollTo({
		top,
		behavior: "smooth",
	});
};

состояние компонента

оглавление держит сразу несколько слоёв состояния:

const [headings, setHeadings] = createSignal<HTMLElement[]>([]);
const [activeHeaderIndex, setActiveHeaderIndex] = createSignal(-1);
const [isVisible, setIsVisible] = createSignal(true);
const [areHeadingsLoaded, setAreHeadingsLoaded] = createSignal(false);
const [isDocumentReady, setIsDocumentReady] = createSignal(false);

подписка на скролл

основная реактивность строится через window scroll:

onMount(() => {
	setIsDocumentReady(true);

	debouncedUpdateHeadings();

	window.addEventListener("scroll", updateActiveHeader);

	onCleanup(() => {
		window.removeEventListener("scroll", updateActiveHeader);
	});
});

реакция на изменение статьи

если меняется тело статьи — пересобираем структуру:

createEffect(
	on(
		() => props.body,
		() => {
			if (isDocumentReady()) {
				debouncedUpdateHeadings();
			}
		},
	),
);

рендер списка

основной ui — это список кнопок, привязанных к заголовкам.

<ul class={styles.TableOfContentsHeadingsList}>
	<For each={headings()}>
		{(h, index) => (
			<li>
				<button
					class={clsx(styles.TableOfContentsHeadingsItem, {
						[styles.TableOfContentsHeadingsItemH3]: h.nodeName === "H3",
						[styles.TableOfContentsHeadingsItemH4]: h.nodeName === "H4",
						[styles.active]: index() === activeHeaderIndex(),
					})}
					innerHTML={h.textContent || ""}
					onClick={(e) => {
						e.preventDefault();
						scrollToHeader(h);
					}}
				/>
			</li>
		)}
	</For>
</ul>

визуальная иерархия заголовков

уровни заголовков просто сдвигаются визуально:

.TableOfContentsHeadingsItemH3 {
	padding-left: 8px;
}

.TableOfContentsHeadingsItemH4 {
	padding-left: 16px;
}

активный пункт

подсветка текущего раздела минимальная, но важная:

.TableOfContentsHeadingsItem.active {
	font-weight: 700 !important;
}

sticky поведение на десктопе

на больших экранах оглавление становится sticky-блоком:

.TableOfContentsContainer {
	@include media-breakpoint-up(xl) {
		position: sticky;
		top: 100px;
		height: calc(100vh - 120px);
		flex-direction: column;
	}
}

mobile режим (fixed bottom panel)

на мобильных это уже не sidebar, а выезжающая панель:

.TableOfContentsFixedWrapper {
	@include media-breakpoint-down(xl) {
		position: fixed;
		bottom: 0;
		left: 0;
		width: 100%;
		max-height: 50vh;
		background: #000;
		color: #fff;
	}
}

toggle видимости

оглавление можно скрывать и показывать:

const toggleIsVisible = () => {
	setIsVisible((v) => !v);
};

итог

в итоге это не просто оглавление.

это:

парсинг DOM структуры статьи
debounce пересборки контента
scroll tracking с throttle
вычисление активного раздела
sticky + fixed адаптивный layout
UI, который живёт вместе со скроллом

и самое интересное — такие компоненты всегда выглядят простыми в начале, но постепенно превращаются в полноценный слой навигации поверх документа, который “понимает” структуру текста и помогает по нему двигаться.

source code

image cropper на solidjs

2026-03-24T00:00:00Z

иногда кажется, что кроп изображения — это просто ui-компонент: выделил область, обрезал, сохранил.

но когда ты начинаешь делать это руками через canvas, drag’n’drop и пересчёт координат с учётом scale — внезапно получается маленький графический редактор.

в этой статье — разбор image cropper, который я собрал на solidjs: от canvas-рендера до экспорта файла.

контекст

задача была простой на словах:

загрузить изображение
дать пользователю выбрать область
добавить зум
сохранить результат как файл

но почти сразу стало понятно, что это не dom-задача, а работа с пикселями.

сам компонент

это основной компонент кроппера. он держит всё состояние внутри: canvas, drag, scale, загрузку и экспорт.

import { UploadFile } from "@solid-primitives/upload";
import { clsx } from "clsx";
import { createSignal, onCleanup, onMount, Show } from "solid-js";
import { useLocalize } from "~/context/localize";
import { Button } from "../Button";

import styles from "./ImageCropper.module.scss";

interface CropperProps {
	uploadFile: UploadFile;
	onSave: (arg0: any) => void;
	onDecline?: () => void;
}

export const ImageCropper = (props: CropperProps) => {
	let canvasRef: HTMLCanvasElement | undefined;
	let imageRef: HTMLImageElement | undefined;
	let containerRef: HTMLDivElement | undefined;

	const { t } = useLocalize();

	const [isLoading, setIsLoading] = createSignal(false);
	const [cropData, setCropData] = createSignal({
		x: 0,
		y: 0,
		width: 200,
		height: 200,
	});

	const [isDragging, setIsDragging] = createSignal(false);
	const [dragStart, setDragStart] = createSignal({ x: 0, y: 0 });
	const [imageLoaded, setImageLoaded] = createSignal(false);
	const [scale, setScale] = createSignal(1);

	// логика ниже
};

стили: это уже не просто ui

.cropperContainer {
	display: flex;
	flex-direction: column;
	align-items: center;
	gap: 1rem;
	padding: 1rem;
	background: var(--black-50);
	border-radius: var(--comment-radius-md);
}

идея простая:

центрированная рабочая зона
ощущение инструмента, а не формы
минимум отвлекающего ui

canvas как рабочая поверхность

.cropperCanvas {
	display: flex;
	justify-content: center;
	align-items: center;
	background: var(--background-color);
	border-radius: var(--border-radius);
	padding: 10px;
	box-shadow: 0 2px 8px var(--shadow-color-medium);
}

canvas визуально отделён — как холст в редакторе.

grab vs dragging

.cropperCanvas canvas {
	cursor: grab;
}

.cropperCanvas canvas.dragging {
	cursor: grabbing;
}

zoom контролы

.zoomControl {
	background-color: rgba(0, 0, 0, 0.5);
	border-radius: 50%;
	width: 30px;
	height: 30px;
	font-size: 24px;
	display: flex;
	align-items: center;
	justify-content: center;
	color: #fff;
	cursor: pointer;
}

адаптивность

@media (max-width: 768px) {
	.cropperContainer {
		padding: 0.5rem;
	}

	.cropperCanvas canvas {
		max-width: calc(100vw - 2rem);
		max-height: 300px;
	}
}

как работает рендер

const drawImage = () => {
	const ctx = canvasRef.getContext("2d");
	if (!ctx || !imageRef) return;

	const img = imageRef;
	const currentScale = scale();

	ctx.clearRect(0, 0, canvas.width, canvas.height);

	const displayWidth = img.naturalWidth * currentScale;
	const displayHeight = img.naturalHeight * currentScale;

	const offsetX = (canvas.width - displayWidth) / 2;
	const offsetY = (canvas.height - displayHeight) / 2;

	ctx.drawImage(img, offsetX, offsetY, displayWidth, displayHeight);

	ctx.fillStyle = "rgba(0, 0, 0, 0.5)";
	ctx.fillRect(0, 0, canvas.width, canvas.height);

	const crop = cropData();
	ctx.clearRect(crop.x, crop.y, crop.width, crop.height);

	ctx.strokeStyle = "#fff";
	ctx.strokeRect(crop.x, crop.y, crop.width, crop.height);
};

drag логика

const handleMouseDown = (e: MouseEvent) => {
	const rect = canvasRef?.getBoundingClientRect();
	if (!rect) return;

	const x = e.clientX - rect.left;
	const y = e.clientY - rect.top;

	const crop = cropData();

	if (
		x >= crop.x &&
		x <= crop.x + crop.width &&
		y >= crop.y &&
		y <= crop.y + crop.height
	) {
		setIsDragging(true);
		setDragStart({ x: x - crop.x, y: y - crop.y });
	}
};

перемещение области

const handleMouseMove = (e: MouseEvent) => {
	if (!isDragging() || !canvasRef) return;

	const rect = canvasRef.getBoundingClientRect();
	const x = e.clientX - rect.left;
	const y = e.clientY - rect.top;

	const drag = dragStart();

	const newX = Math.max(
		0,
		Math.min(canvasRef.width - cropData().width, x - drag.x),
	);
	const newY = Math.max(
		0,
		Math.min(canvasRef.height - cropData().height, y - drag.y),
	);

	setCropData({ ...cropData(), x: newX, y: newY });
	drawImage();
};

экспорт кропа

const cropImage = () => {
	const crop = cropData();
	const currentScale = scale();

	const img = imageRef;

	const displayWidth = img.naturalWidth * currentScale;
	const displayHeight = img.naturalHeight * currentScale;

	const offsetX = (canvas.width - displayWidth) / 2;
	const offsetY = (canvas.height - displayHeight) / 2;

	const sourceX = (crop.x - offsetX) / currentScale;
	const sourceY = (crop.y - offsetY) / currentScale;
	const sourceWidth = crop.width / currentScale;
	const sourceHeight = crop.height / currentScale;

	const cropCanvas = document.createElement("canvas");
	cropCanvas.width = 300;
	cropCanvas.height = 300;

	const ctx = cropCanvas.getContext("2d");

	ctx.drawImage(
		img,
		sourceX,
		sourceY,
		sourceWidth,
		sourceHeight,
		0,
		0,
		300,
		300,
	);

	return cropCanvas;
};

сохранение файла

const handleSave = () => {
	const croppedCanvas = cropImage();

	croppedCanvas.toBlob((blob) => {
		const file = new File([blob], `cropped-${props.uploadFile.name}`, {
			type: "image/png",
		});

		props.onSave(file);
	}, "image/png");
};

итог

в итоге это не просто кроппер.

это:

canvas-рендеринг
ручная система координат
drag & zoom
экспорт в файл

и самое интересное — чем дальше ты заходишь, тем меньше это похоже на ui-компонент и тем больше на мини-редактор изображений внутри браузера.

source code

кастомный аудиоплеер на solidjs вокруг нативного audio api

2026-01-24T00:00:00Z

как я добавил в проект аудиоплеер с плейлистом, контролами и базовым управлением звуком. это не отдельный виджет, а часть страницы с текстом, поэтому он связан с контентом (заголовки, шаринг и т.д.).

данные и состояние

на вход приходит массив медиа (media), который я сначала нормализую:

добавляю id
добавляю флаги isCurrent и isPlaying

const prepareMedia = (media) =>
	media.map((item, index) => ({
		...item,
		id: index,
		isCurrent: false,
		isPlaying: false,
	}));

дальше всё состояние плеера живёт в этом массиве tracks.

текущий трек определяется через isCurrent. если его нет — автоматически выбирается первый.

тут есть небольшой сайд-эффект — если текущего трека нет, он выставляется прямо внутри геттера. не идеально, но в этом месте это упростило код.

переключение треков и play/pause

при клике на трек или кнопку play я полностью пересобираю массив:

setTracks(
	tracks().map((track) => ({
		...track,
		isCurrent: track.id === m.id,
		isPlaying: track.id === m.id ? !track.isPlaying : false,
	})),
);

только один трек может быть текущим
только один может играть

не стал выносить это в отдельный store — здесь проще пересобрать массив, чем поддерживать несколько источников состояния.

при переключении next/prev:

считается индекс текущего трека
выбирается следующий или предыдущий (с зацикливанием)

синхронизация с `<audio>`

есть отдельный audioRef, который реально воспроизводит звук.

через createEffect я слежу за текущим треком:

if (audioRef.src !== getCurrentTrack().url) {
	audioRef.src = getCurrentTrack().url;
	audioRef.load();
}

если трек поменялся — обновляется src.

воспроизведение

при play:

если контекст звука “спит” — резюмлю его
вызываю audioRef.play() или pause()

if (getCurrentTrack().isPlaying) {
	await audioRef.play();
} else {
	audioRef.pause();
}

прогресс и время

прогресс обновляется вручную:

progressFilledRef.style.width = `${(audioRef.currentTime / duration) * 100 || 0}%`;

беру currentTime из <audio>
делю на duration
пишу в width

прогресс обновляется напрямую через style — это проще, чем городить отдельную реактивную прослойку.

время форматируется через Date:

new Date(point * 1000).toISOString().slice(14, -5);

перемотка (scrub)

при клике по прогресс-бару:

audioRef.currentTime = (event.offsetX / progressRef.offsetWidth) * duration;

при зажатой кнопке мыши — обновляется на mousemove.

используется offsetX, что не всегда идеально, но для этого кейса оказалось достаточно.

обработка событий audio

onTimeUpdate → обновляю прогресс и текущее время
onLoadedMetadata → получаю длительность
onEnded → сбрасываю прогресс и время

громкость через web audio api

я не использовал просто audio.volume, а сделал через AudioContext:

const track = audioContext().createMediaElementSource(audioRef);
track.connect(gainNode()).connect(audioContext().destination);

и дальше:

gainNode.gain.value = Number(volumeRef.value);

громкость управляется через input[type=range].

громкость сделал через web audio api — немного оверкилл, но зато полный контроль.

с range-инпутом пришлось немного повозиться из-за разных браузеров.

header (контролы)

в PlayerHeader:

play / pause
next / prev
кнопка громкости

громкость открывается как popover:

const [isVolumeBarOpened, setIsVolumeBarOpened] = createSignal(false);

и закрывается через кастомный хук useOutsideClickHandler.

плейлист

в PlayerPlaylist:

список треков (<For each={tracks}>)
кнопка play у каждого трека
отображение текущего состояния (play/pause иконка)

getCurrentTrack().id === m.id && getCurrentTrack().isPlaying;

список не просто отображает данные — он тоже участвует в управлении плеером.

у каждого трека есть кнопка шаринга:

<SharePopup
  title={m.title}
  description={getDescription(body)}
  imageUrl={m.pic}
  shareUrl={...}
/>

используется заголовок трека
описание берётся из текста статьи
ссылка формируется от articleSlug

стили

в css:

flex layout для header и контролов
адаптив через breakpoint
кастомный progress bar (через border и ::after)
кастомный range input для громкости (webkit / moz / ms)

прогресс-бар и ползунок громкости полностью переопределены, дефолтные стили не используются.

в итоге это не отдельный плеер, а часть страницы — с текстом, шарингом и списком треков, которые живут вместе.

source code

как конвертировать пачку изображений в webp

2025-09-24T00:00:00Z

для этого понадобится либа cwebp, которая принимает на вход степень сжатия (1..100), имя входного и выходного файлов, и простой баш цикл. соберем все картинки в одну директорию и перейдем в нее, после чего опишем скрипт:

for file in *
do
cwebp -q 100 "$file" -o "${file%.png}.webp"
done

дневник от 01/08/25

2025-08-01T00:00:00Z

а так, все мы - скитальцы. мечемся из угла в угол, ищем монументальную силу, перед которой можно склониться, которой можно передать ответственность. кто-то находит ее в религии или любви, кто-то во власти над другими, кто-то в карьере, кто-то в философии, а кто-то просто спивается, потому что все эти столпы - чепуха, им не побороть тьму и пустоту умершего мозга

дневник от 25/06/25

2025-06-25T00:00:00Z

эгоизм, разбежавшийся по свету повально и поголовно, покрывает животные инстинкты самосохранения быть человеком не есть быть очередным экземпляром а есть быть осознанным, помогающим более глупому рядом стоящему, быть Человеком - альтруистом иначе тот самый глупец, которого мы часто лелеем, станет очередным помешанным, уверовавшим, или всего лишь всецело убежденным в грации, верности и столпоопределении своего пути который после будет давить на веру стремящегося, формирующегося и будущий баланс нарушится от ограниченности одного и попавшего под влияние пока еще неосознанного другого

генерируем xlsx из rss фида

2025-05-24T00:00:00Z

нагулял задачу генерации таблиц из rss фида, парсеры выходят на арену. план такой: из терминала кормим скрипт набором аргументов с линком к rss фиду и его настройками, добавляем прогресс бары для отзывчивости, на выход отдаем сгенерированную таблицу.

сперва набросаем пачку зависимостей:

yarn add rss-parser
yarn add --dev exceljs moment posthtml progress request request-promise yargs

за дело! импортирую переменные и определяю парсер:

const ExcelJS = require("exceljs");
const Parser = require("rss-parser");
const posthtml = require("posthtml");
const rp = require("request-promise");
const moment = require("moment");
const ProgressBar = require("progress");
const yargs = require("yargs");

const parser = new Parser();

описываю обязательные и не очень аргументы, определяю входную функцию и на ходу рассказываю о прогрессе в терминал:

const options = yargs
	.usage(`Usage: -f <rss uri>`)
	.option("f", {
		alias: "feed",
		describe: "RSS feed uri",
		type: "string",
		demandOption: true,
	})
	.option("a", {
		alias: "amount",
		describe: "Needed RSS feed posts amount",
		type: "string",
	})
	.option("n", {
		alias: "outputFileName",
		describe: "XLS output file name",
		type: "string",
	})
	.option("o", {
		alias: "cellOptions",
		describe: "Sheet cell additional options",
		type: "array",
	}).argv;

process.stdout.write(`great options, bruh, let's start already!\n`);

entry(
	options.feed,
	options.amount,
	options.outputFileName,
	options.cellOptions,
);

главная функция будет принимать на вход обязательный линк на фид и необязательные количество постов, имя таблицы на выходе и набор кастомных настроек для ячеек. назначаю нужные столбцы и их ключи:

let entry = async (
	rssFeed,
	amount = 5,
	outputFileName = "result",
	cellOptions = [],
) => {
	process.stdout.write(`parsing your rss feed...\n`);
	let feed = await parser.parseURL(rssFeed);

	process.stdout.write(`creating excel workbook...\n`);
	const workbook = new ExcelJS.Workbook();
	const worksheet = workbook.addWorksheet(outputFileName);
	worksheet.columns = [
		{
			header: "text",
			key: "col_text",
		},
		{
			header: "url",
			key: "col_url",
		},
		{
			header: "images",
			key: "col_images",
		},
		{
			header: "time",
			key: "col_time",
		},
	];
};

приступаю к генерации новых строк и добавляю тикающий прогресс бар:

process.stdout.write(`generating posts from rss feed...\n`);
let generatedRows = await generatePostsMetaFromFeed(feed, amount);
let generatedRowsBar = new ProgressBar(
	"[:bar] :current/:total table rows generated\n",
	{
		incomplete: " ",
		complete: "#",
		total: generatedRows.length,
	},
);

функция generatePostsMetaFromFeed займется пирсингом элементов фида и генерацией набора с нужными таблице полями:

let convertFeedToPosts = (feed) => [...feed.items.map((item) => item.link)]; // для пагинации по страницам фида понадобятся линки

let generatePostsMetaFromFeed = async (feed, amount) => {
	let res = [];

	let posts = [];
	let feedLink = feed.link;

	if (amount > 10) {
		process.stdout.write(`wow, so much posts? taking care of it...\n`);
		let pages = Math.round(amount / 10); // пагинация для доступа к последующим страницам фида
		let pagesLoadingBar = new ProgressBar(
			"[:bar] :current/:total processed\n",
			{
				incomplete: " ",
				complete: "#",
				total: pages,
			},
		);

		posts.push(...convertFeedToPosts(feed));

		process.stdout.write(`loading needed pages...\n`);
		for (let i = 2; i <= pages; i++) {
			await rp(encodeURI(`${feedLink}?feed=rss&paged=${i}`))
				.then(async (rssPage) => {
					let parsedRSSFeed = await parser.parseString(rssPage);
					let isLastPage = i === pages;

					if (isLastPage) {
						let modItems = parsedRSSFeed.items.filter(
							(_, index) => index < amount % 10,
						);

						posts.push(
							...convertFeedToPosts({
								items: modItems,
							}),
						);
					} else {
						posts.push(...convertFeedToPosts(parsedRSSFeed));
					}

					pagesLoadingBar.tick();
				})
				.catch((err) => {
					console.error("huh, rss pagination failed", err.code);
				});
		}
	} else {
		process.stdout.write(`not a lot of posts, gonna be quick!\n`);
		posts.push(
			...convertFeedToPosts({
				items: feed.items.slice(0, amount),
			}),
		);
	}

	process.stdout.write(`time to generate some text for our table!\n`);
	let postsHandlingBar = new ProgressBar(
		"[:bar] :current/:total posts handled\n",
		{
			incomplete: " ",
			complete: "#",
			total: posts.length,
		},
	);

	for (let i = 0; i < posts.length; i++) {
		let postLink = posts[i];
		let title, description, image;

		await rp(postLink)
			.then((html) => {
				process.stdout.write(`wuush, working on it...\n`);
				posthtml()
					.use((tree) => {
						// парсим дерево и только нужные таблице значения нод
						tree.match(
							{
								tag: "title",
							},
							(node) => {
								title = node.content[0];
							},
						);
						tree.match(
							{
								attrs: {
									name: "description",
								},
								tag: "meta",
							},
							(node) => {
								description = node.attrs.content;
							},
						);
						tree.match(
							{
								attrs: {
									property: "og:image",
								},
								tag: "meta",
							},
							(node) => {
								image = node.attrs.content;
							},
						);
					})
					.process(html);

				postsHandlingBar.tick();
			})
			.catch((err) => {
				console.error("huh, post parsing failed", err);
			});

		res.push({
			title,
			description,
			image,
			link: postLink,
		});
	}

	return res;
};

строки сгенерированы, пора вернуться во входную entry функцию и прикрутить их к инстансу worksheet, используя метод addRow:

process.stdout.write(`making some rows for your sheet...\n`);
for (let i = 0; i < generatedRows.length; i++) {
	let { title, description, image, link } = generatedRows[i];
	let columnText = `${title}\n\n${description}\n\n${link}`;

	if (cellOptions.length) {
		cellOptions.forEach((cOption) => {
			if (cOption === "noImage") {
				image = "";
			}
			if (cOption === "noOGCard") {
				link = "";
			}
		});
	}

	worksheet.addRow({
		col_text: columnText,
		col_url: link,
		col_images: image,
		col_time: moment().add(i, "days").format("DD/MM/YYYY hh:mm").toString(),
	});

	generatedRowsBar.tick();
}

lift off! теперь можно отдавать таблицу:

process.stdout.write(`creating your ${outputFileName} file...\n`);
await workbook.xlsx
	.writeFile(`${outputFileName}.xlsx`)
	.then(() => {
		process.stdout.write(`${outputFileName} created allright!\n`);
	})
	.catch((err) => {
		process.stdout.write("huh, creating error: ", err);
	});

process.stdout.write(`all done, love!\n`);

profit!

source code

дневник от 15/03/26

2025-03-15T00:00:00Z

ее побеждать как раз для того, чтобы стать Человеком. она правит бал, она наставляет и указывает, не прося разрешения. она унижает и ставит в ряд с неспособной мыслить жизнью. но, раз уж мы взошли на биологически высший эверест, есть пора ломать животное, пошлое, ушлое и сохраняющее внутри. нет сути в природе, она просто есть. кто знает, откуда, но и это не важно. а важно то, что у нее нет морали, которую человек выдумал, чтобы контролировать более глупого и менее обремененного. у природы нет цели, потому она слаба. и быть Человеком - это быть выше, быть не просто ради субъективного счастья ЭГО, быть концом всего подавляющего большинства глупцов кругом, быть мессией группового, массового и всецельного суицида, потому что без человека не будет и страдания.

чистая архитектура [перевод]

2025-02-24T00:00:00Z

Вольный перевод статьи Robert C. Martin "Clean Architecture"

Чистая архитектура

Всего за несколько недель после того, как я начал говорить о необходимости чистки нашей архитектуры, заметил удивительное сопротивление этой идее. Очевидно, что мнение о том, что хорошо было бы скрывать фреймворк, UI или БД от кода нашего приложения, не является общепринятым.

Есть одно несколько отличное мнение, высказанное Разочарованным Архитектором (The Frustrated Architect) в его блоге, где он показывает картинку, которую я повторю:

Он пытается донести мысль, что, если UI и БД являются гораздо большей частью системы, чем бизнес-логика, то архитектура системы должна быть в большей мере ориентирована на эти более крупные элементы. Я, конечно, не согласен. Независимо от того, насколько велика какая-либо часть системы, остальные части должны быть отделены от нее.

Другие несогласные (или, возможно, более подходящее слово - “скептически настроенные”) взгляды были менее формальными. Один человек задал мне вопрос: “А вы вообще делали это в Rails проекте?”, как будто Rails был чем-то особенным и настолько изменил игру, что нормальные правила хорошего проектирования больше не применяются.

Другие ребята беспокоятся, что результатом моего совета будет куча дублирующегося кода и многократное копирование данных из одной структуры данных в другую через все уровни системы. И этого я, конечно же, не хочу; ничто из того, что я советовал, не приведёт к повторению структур данных и нарушению копирования полей. Позже я объясню почему.

Была одна особенно яркая жалоба: “Эти слова слишком громкие, я хочу увидеть код”. Хотя я сочувствую этой точке зрения, представленные здесь концепции не так сложны для понимания; и, на самом деле, большое количество кода может сокрыть их больше, чем помочь.

Никакой это не Rocket Science

Никакой это не Rocket Science. Главная идея очень проста. Вы разделяете UI от бизнес-логики, передавая простые структуры данных между ними, не позволяете своим контроллерам ничего знать о бизнес-логике. Вместо этого контроллеры распаковывают HttpRequest в простую ванильную структуру данных, а затем передают эту структуру данных объекту-интерактору, который реализует сценарий использования, вызывая бизнес-объекты. Затем интерактор собирает данные ответа в другую ванильную структуру данных и передает их обратно в UI. Представления ничего не знают о бизнес-объектах, а просто смотрят в эту структуру данных и представляют ответ. На деле, конечно, деталей больше, и они хорошо описаны в ссылках выше. Но, на самом деле, это все, что нужно сделать.

Выгода должна быть очевидной. Код приложения полностью отделен от UI. Вы можете тестировать код без UI представления. Не нужно запускать веб-сервер, или контейнер, или Rails, или любой другой фреймворк для запуска ваших тестов. Более того, если текущий UI вам не нравится - можно заменить его другим.

Идеальная ли это схема? Конечно, нет. Возможно ли, что один тип UI быть настолько отличным от другого, что они не смогу использовать общий интерфейс? Возможно. Значит ли это то, что подобная техника - пустая трата времени? Да ты шутишь, что ли?

Это будет меня тормозить

Нет, не будет. Ради всего святого, вас это еще и ускорит. Вы сможете запускать свои тесты без задержки, откладывать принятия решений относительно вашего UI, тестировать бизнес-логику без UI представления. Такая гибкость и разделение всегда будут ускорять вашу работу*.* Хоть одну вещь за последние пятьдесят лет мы усвоили. Нет ничего лучше, чем то, что тебя тормозит.

Мы не должны откладывать решения

Одним из моих самых резких высказываний было то, что хорошая архитектура позволяет вам откладывать критичные решения по поводу UI, фреймворков, баз данных и прочего. Некоторые люди говорят, что клиенты не хотят отложенного UI, а администраторы - отложенных баз данных. От итерации к итерации, они хотят видеть полностью рабочую систему, включая UI, БД и фреймворки, и не хотят, чтобы итерация проводилась исключительно по бизнес-правилам. Действительно, хорошая agile практика требует длинных тонких срезов по всей архитектуре.

Со всем этим я согласен, конечно. Однако длинные тонкие срезы не должны быть связаны между собой. Хорошая архитектура не заставляет, а позволяет вам откладывать критичные решения. И, если вы можете их отложить, то получите большую гибкость. Например, для нескольких первых спринтов сможете создать простой промежуточный UI, и только потом заменить его на более функциональный.

Что насчёт GOOS?

Одной из лучших книг по проектированию ПО является “Growing Object Oriented Software” от Стива Фримана и Ната Прайса. Они рекомендуют сторонний подход к разработке систем. Вы начинаете с интерфейса и переходите к бизнес-правилам.

На первый взгляд, звучит это всё так, будто я противоречу своему совету. В конце концов, я фокусируюсь на юзкейсах и считаю UI маленькой раздражающей деталью. Тем не менее, нет ничего плохого в том, чтобы сначала работать с раздражающими небольшими деталями, если вы отделите от них свои бизнес-правила. В идеологии GOOS нет ничего, что препятствовало бы отделению бизнес-правил от UI.

По правде говоря, я не следую методологии GOOS, а предпочитаю другой подход: сначала фокусироваться на бизнес-правилах, и только после этого добавлять UI вокруг. Но это не значит, что GOOS плох (это не так) или что, используя эту технику, вы не добьетесь разделенной архитектуры (а вы добейтесь!).

Oh no, it’s Big Up Front Design!

Нет, все не так. Я не говорю вам месяцами рисовать UML диаграммы. Я говорю вам разделять. Можно разделять, пока вы пишете код и выполняете тесты. Не нужен предварительный план, чтобы создать красиво разделенную архитектуру. Все, что нужно сделать - это думать о проблеме, для решения которой вы пишете код.

Однако, я должен отметить, что нет ничего плохого в том, чтобы потратить несколько часов или даже дней, чтобы обдумать форму вашей системы. Нет ничего плохого в том, чтобы нарисовать несколько UML или прочих диаграмм, чтобы получить парочку идей о структуре вашей системы. Я не прошу вас делать это месяцами, но нет ничего плохого в обдумывании. (см.: Hammock Driven Development)

Это не ново

Я был удивлен реакциям на эти идеи. Понимаю, что люди сопротивляются переменам, и множество программистов еще не привыкли к идеям разделения (прочтите это предложение несколько раз и похнычьте). Но это не новые идеи, которые снизошли до меня, а старые. Они пришли от людей, вроде Дэвида Парнаса, Тома Демарко, Грейди Бутча, Ивара Якобсона и многих других. Факт того, что идеи стары, не означает, что они хороши, но в этом случае - означает.

Что с нами стало? Как мы могли забыть об этих правилах? Когда они успели испариться из нашего сознания? Неужели мы настолько наивны и, собрав в кучу компоненты, надеемся построить сложную систему, потрясывая ее пока все не заработает?

arka triymfalnaya

подключаем lcd дисплей к arduino

плавающее оглавление на solidjs

контекст

сбор заголовков из документа

debounce пересборки оглавления

определение активного заголовка

переход к заголовку

состояние компонента

подписка на скролл

реакция на изменение статьи

рендер списка

визуальная иерархия заголовков

активный пункт

sticky поведение на десктопе

mobile режим (fixed bottom panel)

toggle видимости

итог

image cropper на solidjs

контекст

сам компонент

стили: это уже не просто ui

canvas как рабочая поверхность

grab vs dragging

zoom контролы

адаптивность

как работает рендер

drag логика

перемещение области

экспорт кропа

сохранение файла

итог

кастомный аудиоплеер на solidjs вокруг нативного audio api

данные и состояние

переключение треков и play/pause

синхронизация с <audio>

воспроизведение

прогресс и время

перемотка (scrub)

обработка событий audio

громкость через web audio api

header (контролы)

плейлист

шаринг

стили

как конвертировать пачку изображений в webp

дневник от 01/08/25

дневник от 25/06/25

генерируем xlsx из rss фида

дневник от 15/03/26

чистая архитектура [перевод]

Чистая архитектура

Никакой это не Rocket Science

Это будет меня тормозить

Мы не должны откладывать решения

Что насчёт GOOS?

Oh no, it’s Big Up Front Design!

Это не ново

синхронизация с `<audio>`