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

В какой-то момент reviewing вопросов на Stackoverflow обеспечивал мне такой поток. Со временем, я решил, что не готов тратить время на reviewing; эато (не помню, раньше или позже) начал почитывать рассылки.

Если в плане веба и немного вширь мне раз в неделю присылает письмо FreeCodeCamp (большую часть я не читаю, но то про какую-нибудь библиотеку компонент узнаю, типа MUI, то про какой-нибудь аспект security, типа примера возникновения ReDoS, послушаю), то в плане System Design и вообще более глубоких знаний место долгое время пустовало.

Но вот месяца 2-3 назад я наткнулся вначале на YT канал ByteByteGo, а потом и подписался на их рассылку – и надо сказать, я доволен. Рассылка состоит из 2 частей: по разу в неделю приходят эпизоды, например в последнем можно найти разбор плана выполнения SQL запроса на примере (с пояснениями, где можно улучшить performance), pull и push архитектура платежей и ещё пара менее интересных мне тем. Вторая часть – это почти что курс, например про распределённое кэширование было 3 коротких письма (тоже выходят раз в неделю), и это, с одной стороны, микро-контент, а с другой – довольно качественный и насыщенный, что меня полностью удовлетворяет. Может, в какой-то момент подпишусь даже на платную версию, там среди прочего доступен архив выпусков – и контент вроде расширенный. В общем, если хотите что-то почитывать про System Design (он же архитектура), рекомендую.

PS А какие источники используете вы?

Печатать много занимает время, особенно когда дело касается таких частых команд как git. Зато можно пользоваться алиасами: зайти в .gitconfig, добавить секцию [alias] и прописать туда что-то вроде:

[alias]
  ch = checkout
  lo = log --oneline
  dc = diff --cached

И тогда можно писать, например, git lo -n 3 вместо git log --oneline -n 3. Кстати, дока подсказывает, что задавать их тоже можно командой: git config --global alias.ch checkout (для нескольких слов стоит обернуть в кавычки: git config --global alias.lo 'log --online').

Пользуетесь ли вы алиасами и если да, какими?

PS Алиасы ещё удобнее для функций, но мне пока создавать их не доводилось, хотя, кстати, знаю 1-2 кейса, где могли бы пригодиться. Примеры можно глянуть, например, тут.

Немного об accessability в вебе глазами разработчика.

Вы когда-нибудь пробовали понять, какую методологию использовать, чтобы сделать интерфейс доступным хотя бы для незрячих пользователей? Скорее всего, ваша попытка разбилась о чтение разного рода спецификаций "за всё хорошее" и крайне фрагментарые статьи, про которые у вас нет даже возможности понять, насколько дельные вещи там написаны. Некоторое время назад я продвинулся на шаг дальше и погуглил codealong, точнее статьи про то, как сделал традиционный счётчик (counter – для тех, кто не в танке, это такое очень простое приложение из собственно счётчика и кнопок "+" и "-"). Думал, "о, ну теперь-то разберусь в теме". Но нет, хоть это и несколько более полезно, после прочтение остаётся миллион вопросов по другой причине.

А причина очень простая. Из тех материалов, что я находил (не в духе спецификаций и других тяжеловесных материалов; может всё-таки в каких-то курсах есть), никто не удосуживается показать, как результат протестировать, как на него "посмотреть" ушами незрячего. 🤦‍♂️

Статья уровня "ок" могла бы упомянуть хотя бы один конкретный ходовой скринридер. Статья хорошего качества – примерный ландшафт (кто-то, наверное, помнит эти таблицы распространённости браузеров, которые ушли в прошлое по мере стандартизации и захвата рынка Хромом) и то, как быстро установить подходящий (хотя бы ссылки; потому что на разных ОС разный набор читалок), чтобы начать что-то тестировать.

Точно так же ни одна, сука, статья даже не пытается что-то поведать про то, как происходит навигация по приложению. Вот у вас есть представление о том, как у незрячего происходит навигация по сайту, скажем, с новостями? Или по соц.сети (инстаграм не счёт)? Хотя бы сэмплы взаимодействия (скринкаст с показом нажимаемых клавиш и звуком из скринридера) уже сильно продвинули бы в понимании вопроса.

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

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

PS Написав последний абзац, ещё раз попробовал найти что-то подходящее на YouTube. Не фонтан, но уже гораздо ближе к делу: мини-курс Web Accessibility for Beginners (второе видео прямо "Accessibility Testing with NVDA Screen Reader for Beginners"), плейлист из коротких внятных видео формата "как часто бывает - в чём проблема - как исправить". Осталось найти что-то формата codealong (ну или создать, если будет время?)

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

Для стилей, конечно, придётся заглянуть – да и разок протестировать, чтобы обнаружить какие-то смешные баги типа React показывает 0 вместо ничего, но в целом такое разделение упрощает жизнь и ускоряет разработку (не говоря уже о рефакторинге, добавлении фич и совместной разработке).

Кроме того, TDD местами подталкивает к лучшей accessibility: вот пишешь селектор для кнопки, а у в кнопке визуально – только иконка. Как же селектить? И как её находит пользователь? Ах да, надо title добавить, хотя бы. А если немного погуглить, можно узнать, почему лучше использовать и title, и aria-label. Впрочем, некоторые гайды рекомендуют избегать кнопок без всегда видимого текста, но это уже зависит от задачи.

Что важно в TDD, так это скорость обратной связи. В этом смысле Vite для перезагрузки проекта в браузере и Vitest для тестов – прям хорошо (несравнимо быстрее Next и Jest + TypeScript, хотя там, конечно, тоже можно оптимизировать, но на это надо тратить время и разбираться). Впрочем, я пока не щупал Vite + Vitest в работе над по-настоящему большими проектами и тем более не сравнивал один и тот же проект, мигрировавший с одного на другое, так что объективного сравнения не будет. Скажу лишь, что Next + TS + Tailwind в одном крупном приложении работали прям очень не очень быстро.

В общем, если не решались, рекомендую попробовать, хотя бы на игрушечном примере.

Написал про некоторые ключевые различия TON от Solidity: https://www.linkedin.com/feed/update/urn:li:activity:7228317246828290048/

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

1. Работа с ошибками через явную передачу:

func isStuffGood() (bool, error) {
    res, err := helperThatCanFail()
    if err != nil {
        return false, err
    }

    res2 := helperThatNeverFails(res)

    return res2, nil
}

Снижает когнитивную нагрузку: всегда понятно, нужно ли что-то обрабатывать, никаких тебе "добавить try-catch или пока забить для скорости?"

2. defer:

func processFile(id string) (error) {
    file, err := openFile(id)
    if err != nil {
        return err
    }
    defer closeFile(file)

    // .. do stuff
}

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