😏 Вайб-прожарки

Много разговоров вокруг вайб-кодинга. Вот тут хорошая серия постов вышла про то, как это работает (хуево).

Короче, сегодня попробовал сделать такую штуку. Я постоянно во время прожарок веду параллельные записи в Obsidian. Мне это важно, чтоб лучше в голове откладывалось.

А сегодня открыл ChatGPT и стал вбивать туда какие-то штуки по встрече.

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

И тут в голову мне пришла светлая мысль

🧠 А что если быстро захуярить прототип!? 🧠

Быстро прям в процессе попросил чатик сгенерировать мне код на js, который накладывает вотермарку на страницу. Да получился говнокод, но его для быстрой демонстрации идеи ваще хватило. Вбил это говно в консольку и вуа-ля! 🔮

Как итог – все такие – “о, а это прям то что надо!”
И со встречи ушли не просто типа "вот это поизучать, вот тут поспайкать и соберемся через недельку, чтобы обсдуить дальнейшие шаги“ (к моему ужасу все шло именно к этому), а сразу с задачей. Потому что все посмотрели, и сказали – "да это то, что нужно!”

Мне заебись, потому что я ненавижу кучи встреч и встречи без результата. Всем остальным заебись, потому что порешали все вопросики. Кайф!

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

🆘 А еще чуваки, у меня к вам огромная просьба 🆘

Кто-то поставил буст вашему скромному Димасу (ладно, я у его жены выпросил 🤡), и теперь у меня есть потребность выбрать один кастомный эмодзи, который я смогу добавить в текущий эмодзи-пак канала :

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

Голосуйте, или проиграете! (ладно проиграю только я, если вы не проголосуете)

Ну что же! Пора узнать, кто победил. Делайте Ваши ставочки, господа и дамы

Будет смешно, если и тут каким-то образом победит Анора

🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸
Миллион лайков и благодарностей от меня всем, кто поучаствовал в этом невероятном демократическом процессе! 💗
🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸

🧛 DNS записи и что они делают в тени

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

Может и вам будет полезно.

Буду идти не от типа записи, а от юзкейсов:
К примеру вы купили домен superstas93.com (кстати, пока не занят, так что торопитесь)

Какой минимальный набор записей нам нужно создать:

1. NS (Name Server) – Самая важная запись

👉 Указывает, какие серверы хранят DNS-записи домена.
⛔ Ручками не создаём — их задаёт регистратор.
Но знать, что есть такая штука важно.
📌 Пример:
superstas93.com. IN NS ns1.dnsprovider.com.

2. A (Address) – Вторая самая важная запись

👉 Указывает IP-адрес, на который ведёт домен (IPv4).
📌 Пример:
superstas93.com. IN A 192.0.2.1

3. AAAA (IPv6 Address) – Это уже не обязательная запись, но очень желательная

👉 То же самое, но для IPv6.
📌 Пример:
superstas93.com. IN AAAA 2001:db8::1

4. CNAME (Canonical Name) – Эта запись не обязательная, но есть НО

👉 Псевдоним, который указывает на другой домен.
📌 Пример (редирект с www на основной домен.

⚠️ ВАЖНО: CNAME нужен, если кто-то остался в 2007ом и до сих пор начинает вводить название сайта с www

www.superstas93.com. IN CNAME superstas93.

P.S.: Есть еще одна важная запись – CAA, но она в резолве не участвует, поэтому про нее отдельно.
P.P.S.: Всего типов записей 15 штук (включая обсолетные и экспериментальные) – можно глянуть их тут

💃️️ Всех с днем борьбы за права женщин!

В этот день просто хочу напомнить, что разрыв в оплате труда между мужчинами и женщинами составляет в среднем >30%

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

Короче – это неравенство. А 8 марта, как праздник, придуман не для того, чтобы подарить тюльпанов, а для того чтобы неравенство убирать. Тюлпанчики тоже ничо так, но ИМХО хорошая зарплата будет получше 🐸

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

А еще подблагодарю каждую компанию, где это неравенство полностью побеждено! Вы действительно делаете мир лучше ❤️

Всех с праздником!

🧛 DNS записи и что они делают в тени. Прикладная часть
Спасибо ребята, за классные комменты 1 и 2 к прошлому посту! Кажется, есть вариант еще покомментировать, потому что я разобрался с тем
как добавить субдомен? 🏗 🐸

К примеру хотим сделать development.superstas93.com. в дополнение к продовому стасу93

Что приятно – денег платить не нужно 🛍

Тут есть два варианта:

1️⃣ Вы хотите перевести запросы на новый сервак.
Добавляем A-запись:

development.superstas93.com.  IN A  192.0.2.100

Теперь запросы к development.superstas93.com пойдут на этот IP.

2️⃣ Вы хотите перевести запросы на тот же сервер

Используем CNAME:

 
development.superstas93.com.  IN CNAME  superstas93.com.

Теперь development.superstas93.com автоматически указывает на IP-адрес основного домена.

Я еще сделал себе короткую памятку, как внутри работает DNS резолв, но она все равно получилась длинной… 📏

🧛 DNS записи и что они делают в тени. Как все это работает внутри?

Короче, я если честно когда-то давно прочитал книгу Танненбаума про сети и там вроде все было понятно. Мы идем сначала в одну табличку, потом в другую, потом в третью, потом в четвертую. Ну и как-то получаем свой IP.

Но пока возился с настройками, захотелось про это подробнее почитать, и я ну короче начал и подумал: “Да это же пиздец как сложно! Проще было сразу айпишники запоминать, чем такую квантовую систему городить!”

Я попробовал это записать в виде, ну не то чтобы но типа сиквенс-диаграмы (по скидке)

Итак, вы заходите на superstas93.com у вас есть

🅰️ ваш компьютер
📍 роутер
🚰 оператор СтримОнлайн
А также куча DNS серверов: Root, TopLevelDomain (TLD), NameServers(NS)

Процесс:

1️⃣ Компьютер «Привет, Роутер! Какой DNS-сервер мне использовать?» → Роутер «Используй DNS-сервер 217.69.144.60.»

2️⃣ Компьютер «Какой IP-адрес соответствует superstas93.com?» → DNS-сервер провайдера «сейчас посмотрю»

3️⃣ DNS-сервер провайдера «К какому TLD-серверу обратиться для домена .com» → Root DNS-сервер «вот адрес TLD-сервера, ответственного за домены .com например 198.41.0.4»

4️⃣ DNS-сервер провайдера «Какой авторитетный DNS-сервер отвечает за домен superstas93.com?» → TLD-сервер .com «сейчас посмотрю свои NS записи, вот адрес NS-сервера для superstas93.com 117.69.0.4»

5️⃣ DNS-сервер провайдера «Какой IP-адрес соответствует superstas93.com?» → NS-сервер superstas93.com «сейчас посмотрю свои A записи, вот адрес NS-сервера для superstas93.com 192.0.2.1»

6️⃣ DNS-сервер провайдера «superstas93.com соответствует IP-адресу 192.0.2.1.» → Компьютер «спасибо DNS-сервер провайдера, ты настоящий друг!»

😭 DNS-сервер провайдера - я не настоящий

Короче, 6 шагов. Что хорошо – на каждом может быть кэш. И это хорошо. Потому что многие запросы на практике отсановятся на третьем шаге, так как DNS сервер провайдера все уже знает.

⏲ TTL
Что плохо – на каждом шаге может быть кэш. И если вы поменяли сервер и запись в кэше живет достаточно долго, то изменения вы увидите не скоро. Это может быть критично, особенно, если у вас резко поменялся адрес сервера, а клиенты еще сутки будут стучаться на старый адрес. Выглядеть это будет так что ваш сервер не работает. А он работает, просто он работает там, куда никто не приходит 🗑

Что хорошо – мы все же можем сами рулить временем кэша и задавать TTL в секундах. Вот список ориентировочного времени жизни для записи в DNS

300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»
Отсюда спизжено

У меня TTL стоит вот как на пояснительном дикпике. Из него можно видеть, что мой TTL короткий. Но я решил, что так будет хорошо на время тестирования.

Время тестирования правда уже прошло, но это уже другой вопрос.

🧛 DNS записи и что они делают в тени: Тулинг

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

Поэтому вот моя шпора про то как проверить свой DNS после настройки:

🅰️ Как Проверить A-запись

nslookup superstas93.com

- должен выдать айпишник вашего сервиса

Проверить CNAME-запись

dig www.superstas93.com CNAME +short

– если все зарегано праваильно, то выдаст superstas93.com

Если какие-то записи не появляются, стоит подождать (обычно до 24 часов, но чаще 5-10 минут) или очистить DNS-кэш:

Кажется, что это популярные команды, но все же, пусть будут)

Для Linux

sudo systemctl restart systemd-resolved 

Для Windows

ipconfig /flushdns

🅰️ 🦆 Практика ADR

Делал сегодня странное. На проде прокидывал метрики поискового движка через дотнетный сервис.

И это не моя прихоть – движок (meilisearch) закрывает эндпоинт metrics авторизацией и у нашей инфраструктуры пока что нет инструментов подпихивать в сборщики auth-токены для такого дела.

😠 Проблема
Если делаешь вынужденное ебанутое решение, то через годы забываешь, зачем вообще ты такое делал. И когда тебя спрашивают, то потупленно смотришь на свои тапочки и думаешь что-то вроде “Так, а и правда, зачем?”

Потом конечно вспоминаешь, но все же.

Так вот от такой штуки может спасти практика ведения Arhitecture Deceision Records или ADR

🤓 Решение
Короткая записка в папочке adr и в формате md (к примеру adr/adr-002.md в пояснительном дикпике выше показано как это выглядит) спасет вас от любой напасти!

Я про эту практику слышал лет пять назад, но внедрять не приходилось. А тут говорили вчера с нашим ЕМом Женей Васильевым и он вот предложил вести. А я быстро согласился и уже сегодня мне эта штука пригодилась!

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

# Заголовок:
Название документа должно быть короткой именной фразой, например, «Развертывание на Ruby on Rails 3.0.10» или «LDAP для многопользовательской интеграции».

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

## Решение:
Здесь описывается наш ответ на перечисленные силы, излагаемый полными предложениями в активном залоге («Мы будем …»).

## Статус:
Решение может быть в статусе:
1. Предложено – если ещё не согласовано всеми заинтересованными сторонами
2. Принято – когда оно согласовано
3. Устарело – если позднее ADR изменяет или отменяет решение
4. Заменено – с указанием ссылки на новое решение

## Последствия:
В этом разделе описывается итоговый контекст после принятия решения. Здесь должны быть перечислены все последствия – положительные, отрицательные и нейтральные, так как они влияют на будущую работу команды и проекта.

🅰️ Итого: Если приходится делать ебанутые вещи, то попробуйте залогировать это в вышеприведенном формате. Быстро и потом голова болеть не будет у того, кто все это будет поддерживать. Ну точнее болеть будет, но вас он уже не сможет наругать.

И кстати, это вообще универсальный метод и мобильщикам подойдет! 📞

Оффтоп: Кстати, посмотрите офигенный доклад Жени про Тестирование сервиса через API. Давно считаю эту практику одной из мастхэвных и мне кажется, что она есть уже у всех. Но если у вас нет, то вам точно будет полезно!

🆘️️️️️️ Детективная загадка на субботу с неожиданным финалом: Что будет с адресами в памяти?

Короче, пиздец, чуваки, готовлюсь занять нишу Сидристого для малышей! 🤰

Делаю доклад для самых маленьких про память в дотнете (по карйней мере моя задумка сделать так, чтобы понял ну прям ваще максимально зеленый юнит) и дошел вот до такого примера:

int varInStack = 123456789;
int[] varInHeap = new int[1];
varInHeap[0] = 42;

unsafe
{
    int* p = &varInStack;
    Console.WriteLine(
  $"Address of varInStack: 
0x{(long)p:X}");

    fixed (int* q = varInHeap)
    {
        Console.WriteLine(
  $"Address of varInHeap : 
0x{(long)q:X}");
    }
}

Не пугайтесь ансейфа и фикседа – тут просто выводится адрес в памяти для переменной в стеке и для переменной в куче.

❓ Вопрос: При каждом запуске программы выводимые адреса будут одни и те же, или будут меняться каждый раз?

Короче, я сразу в комментариях ответ напишу

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

https://github.com/Undermove/SimpleMemorySaveToolsExamples/tree/main

Все, заканчиваю спамить 😎

💰 Затащил чаевые для курьеров во всех странах

Вот уже месяц работаю в новой команде – делаю базу знаний (эдакий внутренний Notion/Confluence для сотрудников). Состоялось возвращение в родное b2b, где у нас пилят крутотень для ребят и девчат в пиццерии.

За полтора года в b2c попробовал и менеджерить и разрабатывать бэк (один только курьер на карте чего стоит!) под мобилки и позапускать под дебагом код наших Android и iOS приложений. Короче, кажется было вообще все, что только можно!

b2c у нас очень сильно отличается от b2b по вайбу. Это заметно даже по организации процессов. Вокруг релиз-трейнов мобилки выстроена вся логика производства фич:

1️⃣ Постоянно шуршишь, стараешься затащить фичу в срок, потому что иначе поедет она аж через месяц. И все это время не будет собираться обратная связь, нарабатываться опыт, пользователи не получат свои крутые аватарки, а бизнес не получит деняк.

2️⃣ От этого ищешь компромиссы – где расположить логику, на бэке или на платформе?

3️⃣ Иногда логику проще положить как можно ближе к клиенту. Так как только на клиенте мы владеем наиболее актуально инфрмацией, куда пользователь кликнул, что обновил, куда смахнул и так далее. Но тогда цена ошибки выше – откат релиза на мобилке будет стоить дороже обычного передплоя. Иногда все ровно наоборот, нужно класть логику на бэк, так как если платформы разъедутся, то будет неприятно. А иногда что-то вообще нужно класть только на бэк, так как в таком случае вы сможете это все быстро помнять и настроить.

В каждом отдельном случае нет идеального решения и это прям отрезвляет, заставляет что-то выдумывать.


Короче, все было интересно и круто! 🐸 Но в душе я так и остался b2b-чуваком, которому в кайф делать штуки для наших чуваков и чувих в пиццерии 🐸. И поэтому моя любимая фича за все это время, которую я делал – это чаевые для курьеров! 💰💰💰

Они у нас уже были и работали исправно, но доступны были только в России. Моя же задачка была – дать возможность оставлять чаевые и в других странах. И вот на той неделе я впервые оставил чаевые в Грузии! (Пояснительный дикпик в пруфы)

Когда только пришел в Додо видел, как один крутой разработчик Женя Биккинин делал эту фичу. И я тогда думал, что “Ну нихрена себе чувак тащит в солянову фичу, которая принесет деняк чувакам, которые везут людям пиццу и в лютый мороз и в палящую жару и даже в комфортную для прогулки погоду! Крутой. Хочу быть как он!”

Вот теперь тоже часть такой фичи затащил довольно быстро и без багов (по крайней мере мне никто не жаловался ☺️). Не в солянову, конечно, но бэкерскую часть затащил. Так что вот такой вот финальный аккорд в b2c.

🔜 Последнюю неделю потею над докладом на DotNext.

На всякий случай – это такая охренительно крупная конфа по .NET. (на момент написания поста сайт правда лежит 👋 )

Готовлю спидран по куберу. Очень хочу сделать такое выступление, после которого любой джун/миддл (да и синьор) начнут играться с кубером, как с конструктором лего. 🥇 Поэтому над каждым слайдиком и анимацией сижу, как ОРЛИЦА НАД ОРЛЕНКОМ – выверяю, где картинка помогает восприятию, а где тормозит. Где стоит вставить шуточку, чтобы всех взбодрить, а где наоборот это только отвлечет от сути.

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

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

(по традиции пояснительный дикпик прилагается)

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

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

P.S.: Кстати, доклад придумывал и готовил по схеме, которую описывал вот в этой статье. Так что если у вас тоже есть желание что-то начать рассказывать на конфах, но не знаете с чего начать, то может поможет расступориться 🌺

⭐️ Подписки мои подписки

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

Я сейчас делаю базу знаний — это такая внутренняя википедия для сотрудников пиццерий.

С одной стороны, штука вспомогательная (денег напрямую не генерит), с другой стороны, охуенно важная.

Ибо сердце качества продукции — это стандарты. А стандарты — это, по сути, обучение сотрудников тому, как делать свою работу хорошо и как не делать её плохо.

Обучать людей сложно. Вот недавно вышла статья на Хабре, где Джруже Обломов делится, как сложно это выстроить так, даже для одной хотдожной. А для целой сети пиццерий — это прям целая наука, которая без удобных инструментов просто не заработает.

Короче, знания — это база!