Пособие по выживанию в китайском hot-pot ресторане. и как при этом получить немного очков.

Коллеги-китайцы позвали меня в аутентичный китайский hotpot-ресторан. Идя туда я понимал что соглашаюсь прокатится на “американских горках” с завязанными глазами, при том с совершено не ясным финалом. Да и правила безопасности для меня и для них отличаются.

Для контекста: hotpot ресторан - это ресторан, где на каждом столе стоит условно говоря кастрюля с кипящим супом-бульоном. А ваша задача закидывать туда сырые понравившиеся ингредиенты, а потом вылавливать и есть.

Ребята придумали вот какую игру: Они заказывают ингредиенты по китайски, я же не имею ни малейшего представления что это такое и ем это. На следующий день они мне рассказывают что я съел. Забегая вперед, могу сказать что мой закаленный за 3 года желудок меня не подвел, и в игру, я по крайней мере не проиграл :)

И так, 3 самые экзотические вещи, которые я попробовал:
Numb суп. Для меня есть 3 степени остроты.
1. Остро и вкусно. Нямка!
2. Остро и больно. Экстремально, но есть можно.
Остро так что ты просто ничего не чувствуешь - Это вот как раз вот это Numb суп
3. Остро так, что проглотить ты это не можешь.

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

Лягушачьи лапки. На вид мясо как мясо, на вкус курица как курица. Если обвалять в соусе, то вполне вкусно и съедобно.

Говяжья Аорта. Я принял за гриб. Но по веселой реакции коллег понял что я далек от истины. Просто на всякий случай напомнил им, чтобы они мне не говорили что это такое сегодня. А приберегли эту информацию до завтра.

Теперь ребята намекают что хотят попробовать домашнюю аутентичную русскую кухню. Подумываю накормить их Оливье и Окрошкой. Есть идеи лучше?

Мое личное, ни на что не притендующее мнение о будущем ChatGPT и ему подобных. https://youtu.be/nIdTp5Atrsc Душноты ноль. Обещаю 🙂

Продолжаем мучить Rust. Как вызнаете, главная фишка Rust — это его безопасность при работе с памятью. По большому счету управление памятью можно свести к 2м способам — ручное и автоматическое.

Ручное — это когда мы сами должны выделять память и следить за ее очисткой. В таком подходе можно выделить 2 основных косяка — обращение к памяти по невалидному адресу и утечки. Мы получили откуда-то адрес в памяти и пытаемся обратиться по нему, даже не подозревая, что структура данных уже уничтожена и память недоступна. Также память может легко «утечь», если мы вдруг забыли про указатель и не освободили занятую память после завершения операции/функции/метода.

Автоматическое — это когда мы ответственны только за выделение памяти, а среда выполнения сама понимает какие объекты в памяти стали неактуальными и освобождает память. Такое реализовано во множестве современных языков, таких как Java, Go и т.д. Обращение к невалидной памяти тут практически невозможно. Основной недостаток такого подхода — наличие сборщика мусора, работа которого может повлиять на выполнение основной программы (событие stop the world в JVM).

В Rust реализовано нечто промежуточное. Память выделяем мы сами, но за ее корректным использованием следит компилятор, реализуя концепцию владения и заимствования. Если очень кратко, то вот этот код


let first = String::from("Hello");
let second = first;
println!("{}",first);

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

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

Основные архитектуры нейронных сеток - очень коротко и наглядно. Кому интересно дальше, то дальше читать вики (по всякому машинному обучению вики хорошо собрана - просто вводите название нейронки, и будет информация). Но именно по этой картинке, вот расшифровка. А если вы хотите познакомиться с нейронками с нуля и (относительно) просто, то вот отличный Quick Start по теме.

🇻🇳 Стиль жизни: Ездить на работу на байке, не обращать внимание на цены в ресторанах и тискать азиаток в барах-обнимашках… Добро пожаловать к программистам в альтернативном СССР!

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

И так, что мы, It-Бояре, можем себе позволить, зарабатывая от 3K USD (middle) до 5K USD (team lead) в месяц? При среднем доходе на семью в Хо Ши Мине около 500USD? Мы можем позволить себе многое!

🏡Жилье:
500 USD - и у тебя 3х комнатая квартира в экспатском районе. Без бассейна, но с охранником.
1000 USD - это уже кондо с бассейном, закрытой территорией и тренажерным залом и ноль соприкосновения с местной жизнью, если того хочется.

🥳 Как Развлечемся на оставшуюся сумму? Попробуем прикинуть.

Сходили мы с другом и женой в дорогой 🫕hotpot ресторан, я знатно прифигел с местных цен в сотни тысяч Вонг. Нолики считать очень сложно (1 USD = 22.000 Вонг). Побеспокоился, выпил 🍻. Беспокойство прошло. Счет принесли на 50 долларов (на 3их).

Идешь ты на встречу, или на работу. А тебя стоит и манит кофейня. Нельзя просто так не сесть на стульчик, меланхолично залипнув минут на 20, созерцая трафик из байков. Кофе 1-2 USD. Поучили счет на 3 USD - вы зашли в топ-енд кофейню. У меня до сих пор в венах течет flat white, а не кровь…. Не мог пройти мимо.

Да что я все о еде да о еде. Пора и за экспириенсом сходить. Выбрали мы Экспириенс потребления алкоголя в Японии. Теплое Сакэ (🍶 <- вот прямо ОНО) закусываемое холодным тунцом…. Ммммм…. Я привык к холодному алкоголю и горячим закускам…. Затейники эти японцы… 45USD на троих за вечер…

На выходе нас встретили милые вьетнамские девочки, оккупировавшие квартал японской выпивки. И никакие увещевания о том что нашим коллегам-разработчикам в ТГ-канале будет интересно узнать о соотношении цена-качества не помогли перебить укоризненный взгляд жены. Поэтому перескажу то что “Хулиганы на улице рассказали”.

Ставь 👍 если продолжаем разговор о Жизни во Вьетнаме…

Пока ковырялся в Rust, нашел несколько полезных/интересных материальчиков.

https://doc.rust-cqrs.org/ — крейт для построения CQRS и Event Sourcing приложений. Также там есть примеры построения агрегатов, объектов-значений и тд.
https://cheats.rs/ — хороший справочник по возможностям Rust. Также там есть ссылки на примеры, книги и тд.
https://www.youtube.com/@letsgetrusty — небольшой, но интересный канальчик, кстати у него тоже есть свой cheatsheet(ссылка придет на email).

Сохраните себе на случай когда к вам придет менеджер и попросит оценить большой проект 😉

https://youtu.be/1WfGSJf1Gmc

Так, ребятки. Мы тут вздумали провести вебинар на тему Как управлять техдолгом. Поделимся собственным опытом выплаты технической ипотеки и расскажем как устраивать диверсии на проекте будучи рядовым гребцом и не обладая необходимыми полномочиями. Ждем всех желающих и нежелающих в эту субботу 4 марта в 11 часов по московскому времени.

Записываться тут -> https://howto.stringconcat.com/technical_debt

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

Quick Tip: Как сделать так, чтобы менеджер сам брал тех. долг в итерацию https://www.youtube.com/watch?v=XHWTHeIDDr0

https://www.youtube.com/live/LsE-DRP4sKI? го, мы создали!

Практический курс
Разработка Enterprise-приложений без боли и сожалений

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

- Наш курс поможет вам это исправить!
Пример лекции: youtube.com/watch?v=JDO81HrTGpg

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

Мы отвечаем на три фундаментальных вопроса:

1. Как разработать продукт, за который не стыдно?
2. Как поддерживать и развивать проект, не жертвуя сном и здоровьем?
3. Как перестать выгорать и начать жить?

Начать бесплатно: howto.stringconcat.com/enterprise?utm_source=telegram&utm_medium=cpc&utm_campaign=km&utm_content=zakrep

Открываем номинаицию самый waterfall’ный проект года!

Мы только-только планируем как реализовывать проект для клиента длиной в год, в котором будет задействовано около 30 разработчиков.
Клиент заверяет что он самый agile’ный и самый гибкий. Но, конечно же просит предоставить оценку в часах на год вперед. Но кого этим уже удивишь? 😅

Но он смог! Перед релизом нужно пройти сканирование кода на уязвимости. И клиент просит сказать сколько строк кода нужно будет сканировать в конце проекта.
То есть он спрашивает “а сколько строк кода будет в проекте через год”.

Пишим ответ, помножая количество кода, производимого программистом за день на 30*247. Обсуждаем есть ли метрики, указывающие а сколько линий кода программист обычно удаляет. Стоит ли ставить KPI на количество срок в день? А отчитываться на утренних стендах сколько ты вчера накодил и сколько планируешь накодить сегодня. Надеемся клиент оценит юмор :)

Как вам такой кандидат на звание самого ватерфольного?
Буду рад почитать в комментариях подобные примеры с вашей работы!

Парочку интересных статей с vc о том что такое GPT и как оно устроено. Для тех, кто ничего в этом не понимает (вроде нас) показалось интересными. Никогда бы не подумали, что Т9 — это далекий предок GPT. Во дела…

Начало
Продолжение

Забирайте в закладки!

Не успели мы с вами закончить переживать про то что ChatGPT отнимет наше любимое формошлепство, как новая напасть.

Все мы используем шифрование с открытым ключом: вот эти ваши HTTPS, секретные чатики в телеграмме и дикпик-фотки в iCloud.

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

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

Приятного просмотра под кофеек!

https://www.youtube.com/watch?v=f5slLeCz7p8

С удивлением обнаружил что многие команды до сих пор оценивают задачи в часах. А потом в эти оценки не вписываются, перерабатывают и выгорают. Виной тому тот факт что 1 идеальный час != одному реальному.

Пришлось записать видео с изложением своей позиции. https://youtu.be/uLp-Ht_cRk8

А вы когда-нибудь попадали в оценку, используя часы?

Как можно раздуть стоимость проекта на 1.5 пользователя? Об AWS, девопсе, контейнерах и микросервисах

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

Потом пришел Kubernetis, и эта идея стала мегапопулярной. Я думаю многие из вас набирали EC2 инстансы и разворачивали на них кластеры. Очень удобно. К примеру, набрал три EC2 инстанса по 16ГБ и 4CPU, и твои 10 микросервисав кубернетис по ним раскатал равномерно. И отказоустойчивость вам, и доступность, и еще и экономия ресурсов за счет шаринга.

Потом AWS сказал, а зачем вам вообще парится с этими EC2 инстансами, которые являются виртуальный машиной по-сути. Мы вам дадим Fargate. Вы нам просто говорите сколько каждому контейнеру(ок, ПОДу) нужно. А дальше мы уж сами разместим их как нужно. Казалось бы, действительно хорошо. У нас на один уровень инфраструктуры стало меньше. Разработчики рады, девопсы пьют пиво. Но заметили ли вы, что мы уже ушли от идеи шаринга ресурсов? Теперь мы каждому контейнеру(хорошо, хорошо ПОДу) выделяем фиксированные ресурсы. И если у вас контейнер потребляет по пол ложки CPU в час, AWS не забудет билить вас за весь CPU.
И вот, изначальная, очень хорошая идея экономии куда-то испарилась.

Теперь вспомним как начинается любой проект: Tech lead становится к доске и рисует микросервисы будущего проекта. Надо по-больше, чтобы в резюме хорошо смотрелось. Да и заказчик, зачастую приходит с запросом навалить ему микросервисов по-больше, ибо модно. И еще не забыть про отказоустойчивость и доступность.

И в итоге, приложение, которым будет пользоваться 35 человек 8ч часов будет крутиться на AWS за 10К USD в месяц.
Это реальный кейс. 35 пользователей и 10k USD в месяц. И никого это не смущает.

Вот и ролик в тему вам под кофеек: https://www.youtube.com/watch?v=nqa_Uyz1pBE

Я считаю что layered architecture — худшее что может случиться с проектом.
Появляется спонтанно, не несет никакой упорядоченности, и в конечно итоге скатывается в big ball of mud. Всегда.
Не сдержался, записался видео на тему https://youtu.be/lvUK92gYrn8

С радостью обсужу в комментариях 😉

Разобрали проблемы Layered Architecture, теперь поговорим о чем-то позитивном. Например о Clean Architecture и как она решает проблемы, созданые Layered Architecture https://www.youtube.com/watch?v=A37crsbFYeo

Почему Hexagonal Architecture лучше Layered Architecture, почему с ней проекты реже превращаются в big ball of mud? Потому что она точнее описывает правила и оставляет меньше возможностей для различной интерпретации. Вот скажите разработчикам “используем Layered architecture” и один сделает зависимости из домена на слой доступа к данным, а другой наоборот. Один решит что можно и пропустить слой домена и вызвать из API сразу Repository, чтобы сохранить несколько тактов процессора. А другой решит что так нельзя. И каждый из них по-своему прав. Слоненка она такая…