👀 Про эффективных проджект менеджеров.

Сейчас я работаю на Грузовой Порт Сингапура. Они обновляют свою систему, написанную еще при царе горохе на Java 5. И у них встал вопрос "а кого же поставить менеджерами проекта?" Найти на улице менеджеров с IT прошлым или поставить своих?

И они поставили менеджерами проектов людей от сохи. Тех, кто еще недавно занимался планированием погрузки и разгрузки контейнеров. Кто переговаривался с капитанами судов “Судно Hong Yao, заходите в гавань”. В общем тех, кто уже достаточно поварился в этом порту и знает все нюансы работы. Но совершенно не знаком с IT. Ну то-есть на уровне уверенного пользователя iPhone.

И знаете что? Я НИКОГДА не встречал лучших менеджеров!
- Они четко знают что именно нужно от приложения и почему.
- Они способны объяснить любое понятие из доменной области, и Domain-driven Design идет как по маслу.
- Они на короткой ноге с другими пользователями и могут легко и непринужденно выяснить все нюансы работы.

А оказалось что научится рисовать столбики в MS Project и тикеты в jira оформлять - этому можно легко научится. Привет универсальным “эффективным” менеджерам

И как бонус - они понимают что они мало понимают в разработке ПО, поэтому не лезут со своим мнением о том что “рефакторинг нам не нужен, надо было с первого раза правильно писать”. А реально прислушиваются к разработчикам. Так же как и мы к ним. Каждый специалист в своей области - и это прекрасный симбиоз.

P.S. Недавно научил своего менеджера читать JSON 🙂

А вам попадались толковые менеджеры? Поделитесь своей историей в комментарии.

Всем привет, на связи Сережа. Сегодня заметки о жизни в Сингапуре

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

Каждый сингапурец мужского пола обязан отслужить в армии 2 года, а после до 40 лет каждый год на 2 недели обязан ездить на военные сборы. И вот как мне описывает эти военные сборы любой Сингапурец: Представь, на 2 недели ты уезжаешь в лагерь, без жены и детей. Встречаешься с друзьями, которых давно не видел. И у вас там море развлечений: бассейн, тренажерный зал, завтраки-обеды-ужины. Совместные тренировки и игры наподобие зарницы. И пока ты там отдыхаешь тебе платят ровно твою же зарплату. Считай что у тебя +2 недели отпуска в год, да еще и all inclusive.

Как вам такой формат заметок?
👍 - Продолжать разбавлять наше с Женей душнилово такими заметками
💩 - Давай, Сережа, про IT все же.

Привет, Евген на связи! 👋
Начал тут по работе ковырять Rust как замену питону, ибо с питоном одна только боль и страдания в промышленной разработке (но об этом как-нибудь в другой раз побомблю).

Первые впечатление — авторы действительно видели некоторое дерьмо и стараются делать инструмент с учетом граблей, на которых уже скакали. Хоть я еще в самом начале, но мне уже понравился дефолтный пакетный менеджер и система сборки cargo. Чем конкретно:
⁃ Поддержка многомодульных проектов. В больших приложениях без хорошей модульности - гарантия катастрофы (питонистам привет).
⁃ Создание проектов сразу с инициализированным git и .gitignore внутри. Не нужно выполнять 100500 команд и тащить столько же файлов чтобы просто собрать пустой проект.
⁃ Простой формат описания и конфикурации проектов через toml, после gradle с его гибкостью и многословностью немного непривычно.
⁃ Встроенная система управления зависимостями с возможностью обновлений этих самых зависимостей. Позволяет автоматически обновлять минорные версии библиотек (тут есть небольшая грабля, можно наступить если невнимательно читать доку, расскажу потом, когда пойму мотивацию такого решения). Дополнительный плагин показывает обновления мажорных версий
⁃ Подробнейшая инфа о том, что сломалось при сборке. Разве что только сам не исправляет

Если брать сам язык, то пока что заметил, что Result<Ok, Error> уже встроен в стандартную библиотеку Rust и дополнительного ничего не требуется. Также порадовала обстоятельная книга/документация, есть на русском (правда не знаю насколько она актуальна) и даже какой-то интересный вариант с блекджеком и тестами

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

Если вы пишите\писали на RUST дайте нам знать о своих впечталениях в коментариях 👇

Немного душноты на канале 🙂
Специально для тех 7 человек, что просили больше душноты в посте про службу в Сингапурской Армии.

Меня клиент спросил что бы нам такого интегрировать в pipeline, чтобы соблюдать Zero Trust… Пришлось немного поразмыслить и рассказать ему, что Zero Trust - это не фреймворк, и не библиотека, а модель мышления.
Что из этого получилось смотрите в коротком видео https://youtu.be/eV4140g8CMY

Я ожидаю как минимум 7 лайков под этим видео от тех самых ребят ;)

Писал тут про небольшую грабельку с зависимостями. Чуть подробнее теперь. Если в проекте указать версию зависимости 1.0.5 вот так

 
[dependencies]
some_lib ="1.0.5"

а в репе будет последняя версия 1.0.6, то при сборке приедет именно 1.0.6, а не то что написано в конфигурации проекта. Чтобы приехала именно 1.0.5 нужно написать "=1.05" потому что без = в начале обозначает 1.0.5 и выше, согласно https://semver.org/, т.е обновится patch-часть (исходя из соображений поддержания совместимости). Но не пугайтесь, для воспроизводимых сборок есть файл Cargo.lock, который содержит версии зависимостей из которых собран проект. Его рекомендуют положить в репозиторий и обновлять периодически специальной командой. Если же нужно проверить есть ли новая мажорная версия, то это тоже довольно легко, но требует дополнительного плагина, который ставится с полпинка.

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

Пособие по выживанию в китайском 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