dev notes

как человек, работающим с докером только в рамках докеризации небольших кусков приложений, открыл для себя крайне интересную вещь может быть, для многих очевидную, но как показал опрос коллег - мало кто про это знает :) unionfs - это слоистая файловая система, 1 из 4-х базовых компонентов любого контейнера почему система называется слоистой? потому что одно действие, например через директиву RUN в Dockerfile - выполняется на одном слое, затем этому слою выдается hash, который в дальнейшем может быть переиспользован на последующих слоях так вот докер помечает все ранее выполненные слои как read only, и каждая следующая команда не может изменить данные, оставшиеся на слое выше иначе говоря, если мы пытаемся скачать архив, затем распаковать его, переместить файлы и удалить, и делаем это 4-мя разными командами:

RUN wget https://releases.hashicorp.com/terraform/0.12.28/terraform_0.12.28_linux_amd64.zip
RUN unzip terraform_0.12.28_linux_amd64.zip
RUN rm terraform_0.12.28_linux_amd64.zip
RUN mv terraform /usr/local/bin/

у нас ничего не получится, в таком случае 3-я команда не сможет удалить данные, а 4-ая не сможет их перенести чтобы все сработало, нужно сделать это в одну команду:

RUN wget https://releases.hashicorp.com/terraform/0.12.28/terraform_0.12.28_linux_amd64.zip \
  &&  unzip terraform_0.12.28_linux_amd64.zip \
  && rm terraform_0.12.28_linux_amd64.zip \
  && mv terraform /usr/local/bin/

пожалуй, лучшее объяснение того, как устроены мапы в golang - это доклад Кейта Рэндалла на GopherCon 2016 - https://www.youtube.com/watch?v=Tl7mi9QmLns Кейт работает в google, занимается райнтаймом языка и точно знает, о чем говорит ниже - небольшой конспект первой части доклада - устройство мапы в памяти, за деталями и подробностями советую просмотреть сам доклад мапа - это структура данных, позволяющая хранить данные в формате ключ-значение простейшая реализация мапы делается в два действия: создаем структуру полем-ключом и полем-значением, и объявляем массив этих структур какая основная проблема такой реализации? в случае большого объема данных мы теряем в скорости: для поиска конкретного ключа нам нужно перебрать все данные как решить? разбить данные на несколько групп например, по алфавиту мы бы могли разбить на 4 группы: A-F - первая, G-M - вторая, N-S - третья и T-Z - четвертая возникает другая проблема - данные могут распределиться неравномерно например, ключи могут быть ссылками, ссылки начинаются с http, и все данные в таком случае улетят у нас во вторую группу в качестве решения мы можем взять хорошую hash-функцию, которая равномерно сможет распределить данные по группам в go такие группы называются buckets один бакет может содержать максимум 8 пар ключ-значение в случае, если пачка данных не вмещается в один бакет (что решает hash-функция), структура может содержать указатель на дополнительный бакет когда мы выделяем мапу через var m map[string]float64 m - это указатель указывает m на область памяти, называемую map header header хранит указатель на массив с бакетами, информацию о размерности мапы, информацию о количестве бакетов и другую мета-информацию завтра разберем вторую часть - работу рантайма и его реализацию поиска по мапе ключам разных типов, что, кстати, отлично иилюстрирует ответ на вопрос "зачем нужны дженерики"

открыл для себя тулзу для интеграционного тестирования gonkey - https://github.com/lamoda/gonkey если коротко, она позволяет поднять в пару строк моки на все внешние сервисы, в интеграции с которыми будет тестироваться приложение, описать сценарии в yaml-файлах, где можно задать нужные фикстуры и указать их порядок, описать ответы на запросы и проверить, что в итоге залетело в базу затянул на все свои проекты, и крайне рекомендую, если ты пишешь на go

ну чтож, дубль 2 постом выше я собирался восстановить тут активность, но случилась мобилизация активность, конечно, восстановилась, но не в канале :) перед тем как начнем, важное напоминание для тех, кто остался: мобилизацию никто не заканчивал, военкоматы - избегайте, повестки - не берите, если есть возможность - уезжайте 3 месяца фултайма на go прошли успешно, испыт пройден могу резюмировать, что свичнуть эти два языка между собой, если мы говорим о написании типового бэкенда, можно без особых проблем если ты давно хотел, но никак не мог решиться - можно не бояться :) теперь немного о том, о чем я планирую писать в ближайшие несколько месяцев в общем и целом - я собираюсь подготовиться к ряду собесов, которые начну проходить с начала-середины 23-его года опыта сложных собесов на go у меня мало, пробелов в знаниях в силу опыта на этом языке - тоже вагон, так что мне точно есть что разбирать и, соответственно, о чем писать, что-то в формате конспектов, что-то в формате заметок в ближайшие пару недель буду делиться интересным из курса по concurrency: https://www.udemy.com/course/concurrency-in-go-golang в целом большинство тем мне знакомы, многое пропускаю, но вот раздел про планировщик go прошел с большим интересом в golang есть такая интересная вещь, как netpoller - это пакет, который позволяет преобразовать асинхронный ввод/вывод в блокирующий зачем это нужно? golang заточен работать под блокирующие вызовы например, происходит синхронное чтение из файла, горутина блокируется и ждет, пока чтение завершится планировщик, через 10 мс выбрасывает ее вниз очереди ожидания, и берет в работу другую горутину с синхронными вызовами все просто и понятно а что если вызов асинхронный? в go поступили просто - умеем работать с синхронными? значит сделаем из асинхронного синхронный :) тут в дело вступает netpoller - компонент рантайма, который умеет блокировать горутину, при этом не блокируя текущий поток выполнения текущий поток выполнения берет в работу новую горутину из очереди, а netpoller тем временем подписывается на API операционной системы, которое работает с асинхронными вызовами как только API выбросит событие, что ответ получен - netpoller разбудит горутину и сообщит планировщику, что ей нужно выделить процессорное время после чего планировщик заберет горутину в один из потоков и возьмет ее на выполнение второй интересный момент из модуля про планировщик - asynchronous preempation это механизм, добавленный в go 1.14, позволяющий вытеснить горутину, работающую дольше 10 мс, и дать возможность поработать другим горутинам из локальной очереди да, до версии 1.14 в случае, если мы работали на одном ядре и запускали там горутину с бесконечным циклом - поток блокировался до явного вызова runtime.Gosched() более подробно, если тебе интересно, про это можно почитать тут - https://habr.com/ru/post/502506/

в очередной раз все пошло не по плану :) план, собственно, был описан выше предприму еще одну попытку оживить тут активность, и в этот раз у меня есть, что писать несколько недель назад я сменил работу - полностью перешел на golang и теперь пишу только на нем сейчас вкатываюсь в процессы, смотрю как тут решаются разные задачи и радуюсь красоте этого языка :) параллельно решил добить все-таки курс от бывшего mail.ru group на coursera, последний раз я остановился на том, что решил легендарную вторую домашку и дальше забил курс оплачен, отображается (кстати, надолго ли? или coursera решила все-таки оставить уже начатые курсы?), и надеюсь его получится завершить пока в планах описывать разное полезное с работы касательно go, архитектуры и процессов собственно, далеко ходить не буду и отвечу на вопросы, которым я задавался когда менял стек: насколько сильно обычная backend-разработка на go отличается от разработки на php, как отличается реальная структура проекта от описанной в golang-layout, как отличаются паттерны описания сервисов и репозиториев от тех, что можно найти в разных статьях на medium и видосах на youtube? ответ: почти не отличаются те примеры, что видел я и базовую структуру которых повторял в своих проектах оказались очень похожими на правду, за исключением некоторых субъективных моментов так что всем страждущим и желающим перейти на go могу однозначно посоветовать следующие ресурсы: https://www.youtube.com/c/TheArtofDevelopment - хорошие построения базовой структуры rest-приложения, примеры построения ddd-архитектуры и в целом большое количество видосов и автор, умеющий объяснить https://www.youtube.com/c/MaksimZhashkevych - примеры построения приложений, выделения структуры сервисов, репозиториев и интеграции всего этого вместе https://github.com/golang-standards/project-layout - пример структуры приложения, де-факто стандарт на практике многое отсюда заимствуется, что-то пропускается кто-то считает этот пример плохим и пилит свой но ознакомится и попробовать точно стоит

Вообще, посты у меня и так были не часто, а на фоне всего происходящего очень сложно вести канал и поддерживать какую-либо работу. С одной стороны - это кажется неуместным, и, вероятно, так и есть. С другой, я попробую продолжить это делать, и надеюсь, кому-то это будет сейчас полезно: любая такая информация это возможность что-то изучить и что-то в последующем поменять. Немного скажу про то, что я тут пилил пару недель назад в режиме лайвкодинга. Зрителей было немного, но основная идея - приложение, которое будет отслеживать реальный уровень инфляции. Источников, которые показывали бы всё кристально чисто - я не нашёл. Смысл такой: каждый день через определённые интервалы времени я набираю одну и ту же продуктовую корзину, и смотрю, насколько изменилась цена за предыдущий день. Раз в неделю смотрю, как изменилась за неделю. И раз в месяц финалим стату за 30 дней. Собственно, софтина готова, кроме ротации проксей, небольшого количества асинхронщины и интеграции с парой крутых либ - особо интересного там ничего нет, поэтому код пока открывать смысла не вижу. Изначально идея была настроить автопостинг этого в твиттер, но переписка с dev-саппортом твиттера затягивается, поэтому на днях сделаю автопостинг этого в отдельный канал в telegram. Вероятно, кому-то будет интересно посмотреть, что происходит с ценами, и насколько больше/меньше сегодня нужно будет заплатить, чем вчера. Затем, если будут заинтересованные, может провести несколько сессий по рефакторингу в режиме лайв-кодинга: есть идея прикрутить дженерики, добавить больше асинхронщины и в целом привести всё к божескому виду.

Иногда человек живет только для одного дела, одного слова, одного шага. Не поднять руку, когда подняли все. Выйти на площадь, когда не вышел никто. Не стрелять, когда выстрелили все. Если моя жизнь такая, то я родился, учился и работал, чтобы написать этот текст: https://zelenyikot.livejournal.com/164038.html

нет войне

проверил бота выше, всё работает единственное, судя по всему из-за нагрузки, крипта конвертится чуть дольше, чем за 72 часа, у меня пришло почти через 4 дня

Кому нужна международная Visa карта для оплаты сервисов - @Bankoff_Bo_Bot работает. Карта выдается в телеграм боте, чтоооо вообще происходит:) Пополнение через крипту USDT (её TRX или BEP20 вариант, не ETH) — видос о том, как купить крипту, был на канале. На бинансе было бы дешевле, но я брал на kassa.cc. Пополнение этой карты с крипты долгое, до 72 часов. Много людей к ним повалило и они зашиваются, там похоже команда вся 4 офигевших от своего счастья человека:). Но я вчера пополнил, сегодня дошли. Оплатил снова Ютуб премиум, чтобы видосы слушать можно было на телефоне, свернув программу. Работает. Только ребят, дисклеймер — я ответственности никакой не несу за этот банкофф и никого не призываю туда слать крипту. Просто рассказал о своём опыте, он положительный.