Парадокс p-value

Для проверки продуктовых гипотез в ab экспериментах часто используется значение p-value, которое показывает вероятность того, получили мы наш результат случайно или нет. Или по-простому: p-value - это шанс, что наблюдаемая разница в эксперименте произошла просто из-за удачи. И если p-value меньше, скажем, 0.05 (5%) - значит, с большой вероятностью улучшение не случайное.

Собственно сам парадокс (по сути то разницы почти никакой, одна тысячная):
- p-value = 0.0499 - все радуются, радуга, единороги скачут, фича катится на прод
- p-value = 0.0501 - все плохо, не работает, пошли проверять другую гипотезу

Почему многие уперлись в 0.05?
Эта граница была предложена примерно 100 лет назад статистиком Фишером. Он предложил p < 0.05 как удобную границу для определения статистической значимости. И тк люди обожают четкие правила, то 0.05 стало практически законом.

В нашем продуктовом мире, где каждое решение может стоить кучу денег (в зависимости от аудитории), важно осознавать, что p-value это подсказка и что даже если p-value чуть выше 0.05, то возможно это просто повод копнуть глубже. Поэтому важно смотреть не только на p-value, но и включать голову, а не следовать слепо числам.

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

Для тех, кто не в курсе: Cursor - это редактор кода на базе VS code, но с глубокой интеграцией с AI. Фишка в том, что он не просто подсказывает, а может в целом сделать все за тебя. Можно описать идею в свободной форме и вуаля! Можно вообще не уметь программировать и все равно получить работающий результат.

Вот отличный пример от Артема, когда без особых навыков программирования с помощью Cursor сделать гоночки 🏎️. И это если честно немного сносит крышу.
По сути, сейчас любой человек с фантазией и базовым пониманием, как должно работать, может реализовать свою идею сам.
Нужны просто Cursor с AI и желание поиграться.

Тут Миша затронул интересную тему взаимоотношений в коллективе.
Что мол никакой дружбы на работе, никакой привязанности. А если у команды есть общие интересы помимо работы - то это плохая команда.

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

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

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

Резонный вопрос - а зачем мне это делать? Зачем руководителю пытаться создавать такую атмосферу?
Можно же выжимать все соки с сотрудников, и, возможно, на короткой дистанции это будет еще более эффективно
Мой опыт показывает мне, что при правильном применении это благотворно влияет как на бизнес, так и на сотрудников и позволяет стратегически на долгой дистанции компании показывать офигительные результаты.

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

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

Ну и конечно я считаю, что более сплоченная и дружная команда показывает лучшее качество и большую эффективность. И такую команду еще больше объединяет общая цель, общее видение результата, общие сроки и проблемы.
А теперь сжали булки в едином порыве и го работать! 🫶

PS: Конечно же есть минусы и негативные кейсы. Про них расскажу отдельно.

Ровно год назад я пришел в Звук.
Много получилось улучшить: качество продукта, процессы, структура, внутренние инициативы, подход к техническому долгу, взаимодействие между командами.
Что-то, конечно, не вышло, где-то недооценил сложность, где-то переоценил свои силы. Но так и бывает, все не может выходить идеально.

Я шел сюда за определенным опытом и получаю его сполна.
Теперь я точно знаю, как работают большие экосистемы, какие есть нюансы взаимодействия с "большим братом" и почему иногда даже банальная интеграция превращается в мини-квест.
И конечно же люди! Как это работать с командой в пол тыщи человек. Новая команда, новые правила и взгляды. Найти подход, построить доверие, наладить взаимодействие - это очень непростая задача. Кажется, что получается. 🫶

Впереди еще много планов и вызовов.
Спасибо тем, кто рядом и помогает! ❤️
Го работать! 💪

А мы, кстати, выкатили новый https://zvuk.com! 🥳

Ого, исследователи из MIT, KAUST, ISTA и Яндекса представили новый метод сжатия LLM. А значит это, что теперь огромные ИИ-модели, которые раньше запускались только на мощных серверах, можно сжать так, что они будут вполне себе неплохо работать на обычных смартфонах и ноутбуках без особой потери качества. Без интернета, без облака, без серверов и API.

Всю последнюю неделю активно обсуждается статья-прогноз https://ai-2027.com про развитие ИИ в ближайшие 5 лет. Если у вас есть свободный час (или немного больше), очень советую прочитать. К тому же уже сделали перевод на русский и выложили на хабр:
- Часть 1
- Часть 2
- Часть 3. Концовка Гонка и конец человечества
- Часть 4. Концовка Замедление

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

Прогнозы такие:
- ИИ будет развиваться быстрее, чем мы думаем.
- Проблемы начнутся не когда он станет умнее нас, а когда мы не успеем адаптироваться.
- Те, кто управляют ИИ - начнут управлять всем.
- Ну или ИИ будет упарвлять всем и всеми 🫠

Прочитав, мне сразу вспомнились 2 фильма - “Мстители. Эра Альтрона” и “Интерстеллар”, Альтрон и TARS соответственно. Альтрон как результат Гонки и TARS, как результат Замедления.
Узнаем лет через 5 что нас ждет, или не узнаем 😎

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

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

И мне сегодня вспоминается одна старая история.
Когда я писал диплом в институте (а был это 2006 год), нужно было собрать аналитическую часть с характеристиками суборбитальных аппаратов. Тогда интернет еще только зарождался и особенно в таких узких темах инфы было очень мало.

За пару лет до этого завершился Ansari X Prize - это такой конкурс на разработку частного космического корабля, способного доставить человека в космос на высоту 100км и вернуть его обратно. Собственно мой диплом был об этом же. Победил тогда SpaceShipOne Ричарда Бренсона, но участников было много.

Так вот, я тогда решил написать письма всем участникам конкурса с просьбой поделиться техническими характеристиками их аппаратов, которых не было в открытом доступе. И никто не ответил, кроме одного человека.
Это был Джон Кармак, создатель DOOM, Quake, Wolfenstein 3D, а так же основатель компании Armadillo Aerospace. Для меня тогда, да и сейчас, это было что-то невероятное. Я очень сильно впечатлился и до сих пор помню этот момент.

Да, не у всех получается, но пока остаются такие энтузиасты, как Джон Кармак и Илон Маск, которые не боятся мечтать и пытаться строить - у нас у всех еще есть шанс.

И, надеюсь, что и мне удастся увидеть своими глазами изгибы нашей планеты, с высоты не менее 100 километров.
С Днем космонавтики! 🫶🏻

картинка смешная, ситуация страшная 🤣🤣

Любая работа занимает именно то время, которое на нее отведено

Все, кто работает в IT знают, что стори поинты в части оценок - это всегда лишь приблизительный ориентир. А все оценки - это всего лишь прогнозы, попытка увидеть конец незнакомого будущего.
И часто, когда мы планируем задачи, ставим сроки, и думаем что все пойдем по плану - потом видим, что наша оценка «подстроилась» под предоставленные сроки. И в большинстве случаем если у тебя есть целый день, задача займет целый день, даже если ее можно было бы сделать всего за пару часов.

Куда же без законов! Они тут тоже есть:
- Закон Хофстадтера: «Выполнение любой задачи всегда занимает больше времени, чем ожидаешь, даже если учитывать, что она занимает больше времени» – рекурсия 😎.
- Закон Брукса: «Добавление новых разработчиков к уже отстающему проекту только замедляет его» – увеличение команды в попытке ускорить работу часто приводит к обратному эффекту.
- Ошибки планирования: когнитивное искажение, когда недооценивается время и ресурсы, необходимые для выполнения задачи. Не совсем закон, а исследование, но не суть.
- Закон тривиальности: люди склонны обсуждать несущественные детали, при этом упуская в расчет реальные сложности основных задач.
- Закон Пракинсона: «Работа заполняет все время, отпущенное на нее» – если срок кажется долгим, то задача растягивается.
- Правило 90-90: «Первые 90% кода пишутся за 90% времени, а оставшиеся 10% занимают ещё 90% времени» – последний этап, связанный с отладкой и доработкой, оказывается гораздо сложнее и требует больше усилий.
- Конус неопределенности - еще одна важная идея. На ранних стадиях проекта, когда требования далеки от окончательных, неопределенность максимальна. Чем дальше продвигается проект, тем больше деталей становится ясно и неопределенность снижается.

А что, собственно, делать?
Есть замечательная книга “Software Estimation Without Guessing”, где предлагается несколько методов улучшения оценок, которые по моему опыту действительно работают:
- Отслеживайте прогресс (например, с помощью burn-up charts)
- Нужно планировать с запасом, включать буфферы на непредвиденные обстоятельства
- Нужно четко определять, что считается завершенной задачей
- Разбивать большие задачи на мелкие, управляемые единицы (3 дня максимум, в идеале до 2-х дней)
- Задавайте вопрос - мы делали что-то подобное раньше? Если нет, это нужно учитывать в оценке. Как и если да )

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

No-code инструменты для автоматизации

Сейчас на рынке довольно много разных no-code инструментов, которые помогают автоматизировать разные процессы. И если вы следите за темой мультиагентных систем, то должны были слышать про n8n.io. Если нет - то обязательно попробуйте!

n8n - опенсорсная платформа для визуального построения рабочих процессов, которая позволяет соединять кучу разных сервисов между собой и запускать нужные действия в зависимости от различных условий.
Можно, конечно, вспомнить более простые и популярные аналоги, типа IFTTT и Zapier. Но они подходят для более простых сценариев.

n8n же дает возможность настроить взаимодействие между несколькими ИИ-агентами, подключить chatGPT, базу данных, бота в телеге, почту и в целом все что угодно. И тут это можно настроить очень быстро и визуально понятно. Просто логическая цепочка из блоков if-then-else 😁
Так же его можно кастомизировать и дописать свой код, если в этом есть необходимость. В общем рекомендую попробовать 🫶

Признавайтесь - какие штуки вы уже автоматизировали? Поделитесь сценариями использования.

Встретились вот таким скромным 🤪 тимлидовским составом — на Zvuk Teamlead Meetup.

🖤 100 лидов из самых разных компаний собрались у нас на площадке, чтобы поразгонять о своем: онбординг, развитие хардов, выгорание, экологичное увольнение. В общем, типичная ворклайф тимлида.

Кликаем на ссылки, чтобы поймать вайб митапа:
👉фотки
👉слайды спикеров
👉запись трансляции

И как обещали, среди всех подписчиков с митапа рандомно разыграли мерчовый гусиный стартерпак — поздравляем счастливчика @Panixa 😄

Следующие митапы — coming soon…

Здорово, что у нас проводятся подобные мероприятия!
Митап получился очень крутым, как и все наши митапы!
Каждый раз мы приглашаем офигенных спикеров, рассматриваем полезные темы и обмениваемся опытом. В этот раз мы говорили не про технологии, а про людей и то, как с ними работать руководителю.
Что лично для меня, то поддерживать и развивать сообщество - одна из лучших инвестиций, которую мы можем делать. И я очерь рад, что у нас в Звуке есть ребята, которые так же поддерживают эту инициативу, и что у нас есть площадка, где можно это делать. Организатором отдельный респект - все как всегда на высоте ❤️

Добавился тут ко мне в LinkedIn Стив. Из NY. А на фото - индус. До этого был Алекс, тоже китаец. "Одним словом - румын!" - как в Брат-2 😁

И вспомнилось - когда я работал в START, у нас были китайские b2b партнеры. И вот у них у всех тоже были европейские имена. Меня это сильно впечатлило.
Кто-то был Майком, или Ником. А вот в почте у них были их реальные имена, типа какой-нибудь “Son Min” или “Li Xiaomi”.

И это про практичность. В международной бизнес среде твое родное имя может быть сложно произнести, сложно запомнить, сложно правильно написать. А если ты Стив или Том - вопросов нет. Практически как у нас Александр - Саша, Дмитрий - Дима, Олег - Олег 😎.
Важно, что это не про отказ от идентичности, это про адаптацию. И восприятие общения с такими именами на психологическом уровне проще, так мы устроены.

Еще про удобство и адаптацию в части имен - много лет назад я работал в турфирме, и у нас было две Маши. Чтобы не путаться для клиентов, одна стала Сашей. И все звали ее “Саша Маша”. И все работало, никакой путаницы 😁

Так что уметь чуть-чуть подстроиться под других, чтобы стало легче жить и работать вместе - очень важный навык. Даже в таком интересном аспекте, как имя.

Продолжая рассуждение про пожизненное обучение отдельно мысль про обучение управлению.

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

Но вот что интересно - универсальных рецептов почти не бывает (не то, что в кулинарии - ХАХА! Шат и мат айтишники! 😁). А все потому что в управлении важна не просто база знаний, а умение собирать подходящую комбинацию решений под конкретную ситуацию и другие внешние и внутренние факторы. Иногда даже не под компанию, а под конкретную команду, культуру или одного конкретного сотрудника.

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

Управление - это не про "все давно придумано". Это про умение найти то, что работает здесть, сейчса, для этих людей и для этой компании. И вот тут становится особенно важно не просто учиться, а учиться думать.
Так что учитесь думать 🫶

Гордость за подрастающее поколение

Чувство, которое сложно передать. Сегодня я особенно рад, потому что моя дочь Даша стала победителем олимпиады школьников по труду среди 8 классов, набрав 81,6 балла из 85.

Она делает крутые игрушки своими руками, причем очень креативные и удивительные. Сами посмотрите! И этот дает веру в то, что будущее действительно в надежных руках. Горжусь ❤️

Типология программистов

Антон Поваров, с которым мы сто лет проработали вместе в Badoo/Bumble, напомнил мне в комментариях мой же давнишний пост. В Телеге пост не публиковался, но он стоит того, чтобы скопировать его сюда хотя бы частично.

Итак, типология программистов глазами стартапера. Внимание! Присутствует ненормартивная лексика.

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

1) Тупой программист: в горы? ну значит в горы.
2) Всех заебавший программист: какие нахуй горы ебаныйврот! ну какие ещё нахуй в пизду блядь горы вы под стол блядь ходить научитесь а они уже в горы блядь долбоебы блядь. В горы они собрались олухи блядь. Пидарасы блядь.
3) Старый программист (про себя): гоооры... вот ведь блядство. затем, обращаясь к манагеру (ну или кому там) - голосом, как разговаривают с румяной пятнадцатилетней соседкой: друг мой, а что мы собираемся делать в горах? как долго? какие у нас будут горы? высокие? низкие? какие погодные условия?
4) Угарный программист поворящиваясь к монитору, открывая vim, занося руки над клавой как моцарт, с взъерошенниыми волосами, в пол-оборота оглядываясь с ухмылкой: Итак, нарисуем горы v0.1 ...

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

––––––––––––––

Для тех, кто учится проектировать надёжные распределённые системы или готовится к собеседованиям с архитектурным уклоном: приходи на наш курс по очередям.

Разговаривать через рот

Есть такая сцена из Эйс Вентуры, где Джим Керри разговаривает не ртом, а жопой. И нередко, глядя на корпоративные коммуникации я вспоминаю эту часть фильма.

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

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

И тут я могу ответственно заявить: умение “разговаривать через рот” - один из важнейших софт-скиллов! А для любого руководителя - это мастхев.
Услышать, понять, переформулировать, договориться, уточнить, что ты имел в виду или что имел ввиду твой оппонент. И если нужно - пойти на компромисс.
Не продавить, не переиграть, не доказать, что ты прав, а сделать так, чтобы всем стало чуть-чуть лучше. Возможно даже сесть на оба стула для общего блага.

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

Так что если вы хотите, чтобы у вас в команде все работало и цели достигались - начните с самого банального.
Научитесь, пожалуйста, разговаривать. Через рот. 🫶🏻

1 апреля прошло и эта шутка, пожалуй, лучшая 😎

https://www.youtube.com/watch?v=3w5dEa0YFkc

Пожизненное обучение

С раннего возраста мы начинаем учиться. Сначала школа, потом институт. И продается это все так, что вот он финал: диплом в руках с знаний достаточно, можно идти спокойно работать. До сих пор помню свои ощущения после защиты диплома в институте - учеба КОНЧИЛАСЬ! 17 лет обучения подошли к концу!
Но на самом деле, именно после учебы начинается настоящее обучение.

Сейчас читаю книги по финансам, и в некоторых примера упоминается Чарли Мангер. Это легендарный инвестор, вице-президент Berkshire Hathaway и правая рука Уоррена Баффета. Но помимо его финансовых успехов меня зацепила его философия. Она строилась не только на умении находить хорошие инвестиции, но и на глубоком понимании мира и правильных жизненных установках.
Он говорил: «Накопление мудрости - не только ваша практическая обязанность, но и моральная тоже. У этого утверждения есть следствие, очень важное следствие. Оно означает, что все мы обречены на пожизненное обучение, и без этого обучения ничего хорошего нам не светит. Вы не пойдете далеко, если будете руководствоваться только тем, что знаете сейчас. Прогресс возможен только при условии того, что вы будете узнавать что-то каждый день. Это значит, что вам придется научиться учиться.»

Меня это утверждение сильно зацепило, ведь если задуматься, то из этого вытекает очень простая, но важная мысль: учиться придется всегда (но не говорите это своим детям, которые сейчас ходят в школую, их мотивация может подорваться 😂)🤣 . И если ты хочешь расти и развиваться, то это действительно так.

Никто не уходит далеко, опираясь только на то, что он знает прямо сейчас. Все, что мы умеем сегодня, устаревает быстрее, чем кажется. Особенно в IT - это постоянная игра в догонялки с новыми технологиями, новыми подходами, новыми проблемами.
Но, как говорится - есть нюанс 😎. Информационный поток сейчас безграничен! И учиться - это не значит бесконечно поглощать информацию. Можно пересмотреть сотни лекций, но так и не понять, как все это работает.
Поэтому настоящее обучение - это не просто «узнавать что-то новое», а видеть базовые принципы, разбираться в причинно-следственных связях и учиться рассуждать здраво, докапываться до сути. Учиться по-настоящему - это понимать, как все устроено.

Я, например, в тех направлениях, где мои знания не так глубоки, как мне хотелось бы, стараюсь не просто узнать расшифровку новой аббревиатуры, а действительно разобраться в сути и погрузиться детально. Понятно, что-то не на экспертном уровне (хотя все зависит от необходимости), но так, чтобы мог объяснить это другому человеку.

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

Кроме шуток - подписчики этого канала самые умные и красивые! ❤️ 🧠

Сейчас столько разговоров про LLM, и очень часто в контексте их использование упоминается аббревиатура RAG. Сегодня объяснение в рубрике #systemdesign.

RAG, Retrieval-Augmented Generation, или Генерация с дополненной выборкой - это процесс оптимизации ответа большой языковой модели (LLM) с учетом дополнительной базы знаний, которой у модели не было на этапе обучения.

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

Как это работает:
1. Пользователь вводит запрос в интерфейсе LLM. Запрос передается на сервер, где преобразуется в векторное представление.
2. Затем запрос отправляется в поисковую систему.
3. Эта система может искать данные в различных источниках: PDF-документах, веб-страницах, коде, базах данных, API и т. д.
4. Найденная информация возвращается в модель RAG.
5. RAG дополняет исходный запрос пользователя этой информацией и отправляет его в LLM (например, GPT, Claude, Gemini, Gigachat 😎 и т. д.).
6. На основе расширенного контекста LLM формирует ответ.

Таким образом, вместо того чтобы полагаться только на "память" модели, RAG позволяет использовать актуальные данные в момент запроса. Это особенно полезно, если информация обновляется или является специализированной.

Если при использовании моделей вы вместе с запросом в LLM сразу вкидываете контекст в виде дополнительной информации - это по сути тот же RAG.

Жизнь слишком коротка, чтобы…

Эту фразу я впервые прочитал в биографии Джереми Кларксона, одного из ведущих ТопГир. Он говорил, что жизнь слишком коротка, чтобы ездить на плохих машинах. Тогда, через месяц после этого я купил миник, о котором давно мечтал. Потому что понял: зачем ждать?

Но эта мысль работает не только с машинами. Жизнь слишком коротка, чтобы:
- Ходить на скучную работу, которую ненавидишь.
- Носить неудобную обувь или одежду.
- Читать плохие книги только потому, что нельзя бросать.
- Доказывать что-то людям, которые не хотят тебя слушать.
- Ждать идеального момента или 1 числа месяца, чтобы начать делать то, что давно хотел.

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

А как бы вы закончили эту фразу?

Оставлю здесь очень интересную статью про инфляцию на пальцах. С примерами и конкретными цифрами.

Сразу видно, что ИИ. Банкомат то старый! 🤣🤣🤣

монолит, микросервисы и красивая мультиагентна система )

Внешние консультации

Привлечение внешних экспертов - это один из самых недооцененных инструментов, которым многие руководители почему-то пользуются редко. Кто-то боится, что его посчитают некомпетентным, что утекут очень важные секретные данные, страшно попросить бюджет у руководства или просто обратиться к коллегам по цеху. И очень зря!

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

Внешняя экспертиза (слово аудит мне нравится меньше, но можно воспринимать и так) - это не про "прийти и покритиковать". Это про свежий взгляд, новые инструменты и объективный разбор ситуации. Приходят внешние DBA - находят просадки в производительности и предлагают решения или крутые инструменты мониторинга. Привлекаем консультанта по управлению проектами - и внезапно может оказаться, что половину встреч можно убрать, а процессы выстроить так, чтобы они реально помогали.

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

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

Так что иногда лучший способ подтянуть качество работы - просто пригласить кого-то, кто задаст правильные вопросы.
Пользуйтесь 🫶

Самозванцы есть? А если найду?

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

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

Важно понимать, что этот синдром самозванца это не про реальный уровень компетенций, а про внутреннее восприятие. И чем выше уровень, тем больше зон ответственности и сложнее задачи. А значит, тем чаще ты сталкиваешься с ситуациями, где не все знаешь. И это нормально, не нужно все знать.
Как мне сказал в начале 2000-х мой профессор, один из умнейших людей, которых я встречал - "Умный человек не тот, кто все знает, а тот, кто знает как где что найти и решить проблему". Гугла и интернета в том виде, в котором мы сейчас его знаем, тогда не было.

Что с этим делать?
- Перестаньте сравнивать себя с кем-то, особенно с идеальными образами.
- Фокусируйтесь на реальных результатах, а не на ощущениях.
- Не бойтесь спрашивать и признавать, что вы что-то не знаете. Это не слабость, а сила.

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

А еще на арену LLM с двух ног заходят господа из LG!
LG Group представила семейство моделей искусственного интеллекта Exaone Deep с «расширенными возможностями рассуждений». И графики у них там все такие красивые!
Вспоминается реклама про умный пылесос LG. Теперь он сможет кодить за вас 😁

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

И выяснилось, что компания использовала Толоку и Яндекс Задания привлекала индусов и людей и других стран для ручного распознавания, такой вот Human AI😎

Надеюсь у нас в ЖКХ не так 😁

какие у кого планы на будущее? 🤣

AI or Not?

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

И тут образовалась новая ниша для стартапов - выявление того, что сделано с помощью ИИ, а что нет 😎.

Один из таких стартапов, AI or Not, недавно привлек 5 мультов на развитие технологий распознавания контента, сгенерированного нейросетями. Их алгоритмы, как заявляется, могут анализировать изображения, видео, аудио и текст, выявляя признаки подделки. Пока не очень ясно насколько большой будет процент ошибок, но тренд явно намечен. Я заюзал бесплатную версию и у меня все четенько определилось.

Есть еще одна интересная ниша, в которой явно сейчас будет бурное развитие, помимо понимания того AI это или нет, понимать не обман ли то, что выдало AI и можно ли этому доверять. Ждем появления AI инструментов, которые будут проверять другие AI инструменты. Но кажется все равно без кожаного мешка в этой цепочке все равно не обойтись 😁

У нас в IT много шутят, но кажется самое большое количество шуток про JS (или JavaScript). Это один из самых популярных языков программирования и его используют практически все компании. Он простой в изучении и имеет множество достоинств.

Но почему JavaScript вызывает столько шуток? Нашел статью на хабре, где в целом все написано - и про слабую типизацию, и про неожиданное поведение (хотя 0.1 + 0.2 не равно 0.3 случается во многих языках), и про другие особенности.
А еще web в целом одна из самых динамично развивающихся платформ. Спросите у разработчика как оно относится к тому, что выходит какой-нибудь новый формат экрана, который теперь нужно будет поддерживать 😁

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

Тут вышла расшифровка нашего диалога про использование genAI в разработке с коллегами из Яндекса, Альфа-Банка, MTS AI и Just AI.

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

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

Это легендарное меню сделали мои друзья из Start на мою farewell пати год назад. Конечно же я взял себе его на добрую память ❤️

Сохраняейте в избранное - меню на все случаи жизни 🤣

В четверг был на одной СТО-шной встрече в одном крупном банке, где вместе с ребятами из других крупных российских компаний дискутировали о том, как новые регуляторные правила влияют на бизнес. Business VS Government. Всю дискуссию пронизывала одна общая концепция - это ХОРОШО, это помогает нам расти, получать новый опыт и вот это все. Что наши инженеры ууух какие сейчас умные станут, свои БД напишут, операционки сделают, может даже и до процессоров дело дойдет, не говорю про ноутбуки! И постгри научимся оптимизировать для работы с сотнями терров данных! Вот такие у нас будут крутые инженеры!

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

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

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

Вот взять на законодательном уровне запретить в России все европейские машины, мерседесы там, и так далее.
Уверен, что изи можно взять и это сделать при желании, пересадить всех на Лады. Будет ли от этого наш автопром быстрее развиваться - скорей всего. Но будет ли нам, пользователям, лучше? Почему не лучше конкурировать с чем-то более качественным?

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

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

Ну и последняя мысль - те условия, в которые нас поставили, скорее напоминают пословицу «Бьет - значит любит». Конечно мы ко всему приспособимся. Человек вообще такое существо, которое может приспособиться к любым условиям. Но как можно радоваться тому, что вас пиздят, и говорить, что это делает тебя сильнее и закаляет твой дух?
Зачем?

НМА или Нематериальные активы

ИТ-руководителю важно понимать финансовую сторону разработки. И один из ключевых аспектов здесь - учет нематериальных активов (НМА). Под НМА понимаются активы, которые не имеют физической формы, используются больше года, имеют ценность для компании и будут приносить доход в будущем в течение определенного времени, в ИТ-компаниях это чаще всего: веб-сайты, мобильные приложения, платформы, патенты, алгоритмы и т.д. Платформы иногда внутри разбиваются на несколько НМА, например основной сервис и CMS.

Зачем вообще учитывать нематериальные активы?

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

Как это работает?
В общих чертах стоимость актива распределяется на его предполагаемый срок полезного использования. Например, если веб-сайт или мобильное приложение оценивается в 12 миллионов рублей и ожидается, что они будут приносить пользу компании в течение 5 лет, то ежемесячно в бухгалтерском учете будет отражаться амортизация в 200 тысяч рублей.

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

Стоимость актива во время разработки копится на спец счете (вложения во внеоборотные активы). А когда доработка готова (например, через полгода или год), то ее ставят на баланс, либо в виде докапитализации, ливо в виде НМА (например, версия 2.0). Такой подход позволяет более точно оценить финансовое состояние компании, выявить скрытую стоимость и дать ясное понимание, как инвестиции в инновации и разработки влияют на PnL. Плюс это помогает избежать искажения финансовой картины, так как если бы всю стоимость актива списали сразу, прибыль компании была бы искусственно занижена в тот период, а затем завышена.

Нашел очень интересное мнение на реддите. Можно с ними соглашаться или нет, но то, что AI меняет (или можем в перспективе поменять) вообще все подходы, которые ранее были приличными - факт. А вы что думаете?

Похоже, мы на пороге большого шухера большой перемены в том, как вообще работает софт. Если коротко: AI не просто "съедает" приложения, а полностью меняет правила игры.

Ключевые цифры и факты:
• Gartner прогнозирует падение использования мобильных приложений на 25% к 2027 году из-за AI-ассистентов 📉
• При этом рынок AI-приложений в 2024 достиг $3.3 млрд и вырос на 51% за год 📈
• Уже сейчас пользователи потратили более $1 млрд на AI-приложения

Суть перемен, которые на подходе:
Представьте: вместо открытия 10 разных приложений для бронирования билетов, проверки погоды и оплаты счетов - вы просто говорите с AI-ассистентом, который всё делает в одном месте. Без скачивания, без переключения между приложениями.

Что это значит технически:
1. От монолитных приложений к микросервисам - функциональность будет "вызываться" AI по требованию
2. Приложения становятся модульными и динамическими вместо статичных программ
3. Разработчики будут создавать "навыки" или "агенты" вместо отдельных приложений

Неизбежные последствия для бизнеса:
• App Store'ы теряют 30%-ную комиссию - экономика платформ рушится 💸
• Контроль над дистрибуцией ослабевает - AI работает в облаке и меньше зависит от платформы
• Вертикальные AI-решения (для юристов, финансистов и т.д.) станут ценнее, чем общие LLM

При этом сейчас происходит обратный процесс - AI-приложения бурно растут внутри существующих магазинов приложений (тот же ChatGPT набрал 100 млн пользователей за 30 дней), но параллельно подрывают саму модель этих магазинов. Похоже на то, как вода отходит от берега перед цунами.

Выводы:
• Если ваш бизнес завязан на традиционные приложения - пора задуматься о стратегии перехода
• Компании с низким уровнем удержания пользователей в приложениях рискуют больше всех
• Новая золотая жила: создание вертикальных AI-решений для конкретных индустрий

В общем, мы наблюдаем не просто эволюцию, а настоящий переворот.
От парадигмы приложений и магазинов приложений переходим к ассистентам с ассортиментом навыков с монетизацией.
Вопрос только в том, кто оседлает эту волну, а кого она смоет? 🏄‍♂️🌊

Собственно сама задача и базовый сценарий.

Вчера состоялось еще одно интересное событие - сообщество ИТ-архитекторов Сбера проводило Architectural Katas.

Это такое мероприятие, где собирались команды архитекторов из крупных компаний, таких как Сбера, Норникеля, Т-Банка и Cloud ru и конечно же Звук,и решали определенную задачу.
Участники должны были презентовать архитектурное видение системы. Решение должно раскрывать следующие аспекты решения:
1. Общая архитектурная схема решения.
2. Ограничения и функционирование основных компонент.
3. Стоимость эксплуатации и риски.

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

Наши ребята отлично выступили, засудили!!! Горжусь нашей командой! 🫶💪
📹 Записи встречи ArchSync можно посмотреть на тут.

И еще с удовольствием делюсь ссылкой на канал Сообщества ИТ-архитекторов СБЕР. Там можно отслеживать подобные интересные события.

Сегодня мы с Сашей Ульяновым, нашим Директором по Персонализации, рассказали студентам ВШЭ в Питере про Звук, и где и как мы применяем GenAI в нашем сервисе. Рассказали про практическое применение в продукте - Гигамикс и майнинг данных, про smm-ассистента в Студио для артистов.
Вместе с нами Дима Бугайченко, CDS Сбера, рассказал по AI агентов и даже на практическом примере показал демо работы мультиагентной системы. Можно потыкать и даже законтрибьютить что-то 😎
Уверен будущим инженерам это было полезно 🫶🏻

Ключевые сотрудники

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

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

Интересный вопрос - как их удерживать? Потому что потерять сильного специалиста - это потерять часть экспертизы, и иногда стабильность процессов. уУерживать ключевых сотрудников не так просто.
Многие компании даже не знают что предложить таким людям.
Говорят на Западе все чуть лучше - там ключевой сотрудник знает, что он ключевой, и у него есть понятный план развития на несколько лет. У нас же часто все работает по принципу “если хочешь расти - принеси контр-оффер”. И это скорее показатель отсутствия культуры, чем реальной заботы.

Что реально работает?
- Долгосрочная мотивация. Опционы, бонусы и программы удержания. Люди ценят, когда компания вкладывается в них не только здесь и сейчас. Но, к сожалению, далеко не все компании могут себе это позволить.
- Прозрачная карьерная лестница. Управленцы и технари - это разные пути. И у хорошего инженера должна быть возможность зарабатывать не меньше, чем у руководителя. Если хочешь удержать сильного технического специалиста - дай ему возможность расти и оставаться в зоне комфорта. Будь то тимлид или principal.
- Менторство и наставничество. Предоставление возможности иметь как сильного ментора, так и самому быть наставником - сильный мотиватор. У многих компаний есть программы внутреннего менторинга. Или есть возможность найти сильного наставника из других крутных компаний. Это часто помогает раскрыть потенциал сотрудника.
- Интересные и сложные задачи. Не все, но большинство крутых ребят ищут интересные задачи. Но интересные не всегда значит сложные.
- Хорошая атмосфера в компании. Даже, если чего-то из пунктов выше нет, то нормальные взаимоотношения в коллективе порой лучше всего остального.

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

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

А вы видели, как утилизируют скафандры?
Сразу представляется картина из фильма: космонавт чинит что-то на внешней обшивке, его случайно отстегивают и он уходит в бесконечность, немножко стремновато. Решил почитать - а как это происходит? Когда скафандр на МКС отрабатывает свой ресурс, его действительно выбрасывают в открытый космос. И он какое-то время просто дрейфует на орбите, а потом сгорает в атмосфере. Такая вот космическая печь. Кстати, на видео скафандр отстегивается рядом с российским модулем Пирс, который сам был сожжен аж в 2021 году. Так что это мы нагадили 😁.

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

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

Ну и залипалово на ночь. Университет Техаса создал портал AstriaGraph - интерактивную карту космического мусора. На нее нанесено 26 тысяч объектов - обломки ракет, неработающие спутники и другой мусор.
Добавляются ли туда выброшенные скафандры - не известно.

Недавно ко мне обратились ребята из Holyweb и South HUB - они собирали подборку каналов и книг, которые читают технические директора и С-левелы, и почему.

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

А вы какие каналы читаете или какие книни порекомендуете? Может есть что-то интересное на что стоит добавить обратить внимание?

Интересные новости - приватные репозитории GitHub компаний из списка Fortune 500 оказались доступны через Microsoft Copilot 😎.
Недавно Lasso Security выявила критическую проблему безопасности, связанную с Microsoft Copilot и механизмом кеширования Bing.

Суть простая - информация, которая когда-либо была публичной, даже кратковременно, может оставаться доступной и распространяться через Microsoft Copilot. Пупупупупу 😁

Давайте посмотрим на масштабы:
- Более 20000 извлеченных репозиториев GitHub.
- Свыше 100 внутренних пакетов Python и Node.js, уязвимых для атак типа “dependency confusion”.
- Более 300 экспонированных приватных токенов, ключей и секретов, связанных с GitHub, Hugging Face, GCP, OpenAI и другими платформами.
- Затронуто свыше 16000 организаций, включая такие крупные компании, как IBM, Google, Tencent, PayPal и даже саму Microsoft.

Что это значит для организаций и разработчиков - будьте бдительны. Сканеры везде вокруг нас, и даже кратковременное открытие доступа приводит к сливу данных. У меня в карьере так же был подобный неприятный опыт, когда сканер заснифал слепок части базы, которая случайно кратковременно была доступна в публичном интернете - повторять не хочется.

REST vs GraphQL - битва двух якодзун

В проектировании API есть два самых популярных подхода - REST и GraphQL. Что конкретно использовать - часто очень спорный вопрос. Оба подхода решают одну и ту же задачу: позволяют клиенту общаться с сервером, но делают это по-разному. Мы на днях с ребятами в команде архитекторов в очередной раз обсуждали - а не стоит ли поменять наш текущий подход на другой?

REST (Representational State Transfer) это классика жанра, стандартный способ организации API. Каждая сущность (например, плейлист или едтиница контента) имеет свой эндпоинт - URL, по которому ее можно получить или изменить.

Плюсы:
- Простота и предсказуемость – легко понять, как все работает. Консистентный.
- Хорошо кэшируется - можно экономить ресурсы, сохраняя ответы.
- Подходит для стандартных CRUD-операций (Create, Read, Update, Delete).

Минусы:
- Либо получаете лишние данные, либо не хватает нужных.
- Жесткость - если добавляются новые поля, приходится менять API и клиентов.

GraphQL - это более гибкий способ общения клиента с сервером. Вместо множества эндпоинтов есть одна точка входа (/graphql), куда отправляется запрос с описанием данных, которые нужны. И сервер вернет только запрошенные поля - ничего лишнего.

Плюсы:
- Гибкость - клиент запрашивает только нужные данные.
- Меньше запросов - можно за один запрос получить данные из нескольких источников.
- Удобно при частых изменениях интерфейса - не нужно менять API при добавлении новых полей.

Минусы:
- Сложнее кэшировать - стандартные механизмы, работающие с REST, тут не всегда работают.
- Безопасность и нагрузка - сложные запросы могут перегружать сервер, если не настроить лимиты (rate limiting).
- Требует больше усилий на настройку и поддержку.

В реальной жизни часто используется гибридный подход. Например, публичное API может работать на REST, а внутреннее (для админок например) на GraphQL, где важна гибкость. Или наоборот, когда клиент работает на GraphQL, а межсервисное взаимодействие по REST. И что конкретно выбрать зависит от многих факторов, поэтому выбирайте с умом 😁.

Ну и наглядная картинка, чтобы всю эту разницу показать 😎.

Сразу вспоминаются 2000-е, когда музыку, фильмы и мемасики передавали из локалки МГУ на хардах из рук в руки. Потому что флешек такого размера еще не было. Или в городских локалках в DC++ хабах 😂

В галерее «Модный сезон» на Манежной площади напротив Госдумы продают вип-флешку в машину с музыкой за 38000 рублей. Продавец говорит, что на ней «вообще вся музыка от А до Я российская и зарубежная». Если финансы поджимают, то можно взять укороченную версию за 7 тысяч (по словам продавца, ее берут чаще всего). Если же вкусы ваши специфичны, то можете купить флешку в виде кассеты с эмблемой Gucci за 18 тысяч и закачать туда своей музыки.

Закон Конвея

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

Этот закон сформулировал Мелвин Конвей еще в 1967 году, когда заметил, что структура коммуникации в компании и архитектура систем архитектуру связаны. “Любая организация, разрабатывающая систему, неизбежно создает проект, структура которого копирует коммуникационную структуру этой организации.” И с тех пор его идея подтверждается на практике.

Те, если в компании есть четыре команды - у вас будет система с четырьмя крупными модулями. И если две команды не разговаривают друг с другом, то их части кода тоже не будут взаимодействовать нормально. Если у вас хаос в коммуникациях, он неизбежно отразится в системе: появятся дублирование, кривые интеграции и костыли.

Получается интересное - налаживая коммуникации налаживаются и взаимодействия между частями системы. А так же изменение структуры людей требует изменений и в архитектуре системы!
Поэтому, когда вам кажется, что система сложная и плохо управляется, посмотрите на организацию команд: как выстроена работа людей, так и будет выстроен ваш продукт. И наоборот.

Итак, момент испробовать сковородку для блинов настал 😁.
Напомню, что пару недель назад я взял Swiss Diamond 26 см.

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

Теперь к самому важному - рецепту блинов.
Я всегда готовлю по рецепту бабушки, котики его тоже уважают. Вот он:
- 12 ст. ложек муки с горкой
- 2 яйца
- 3 стакана молока
- 0.5 стакана растительного масла
- 2-3 чайных ложки соли (по вкусу)
- 2 столовых ложки сахара (по вкусу)
- 0.5 чайной ложки соды, гашеной уксусом
- любовь ❤️
После выпекания смазать сливочным маслом.

Го делиться своими рецептами в комменты! Буду каждые выходные пробовать новый рецепт от вас 🫶.
Всех с праздником!

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

По разным оценкам, за 2024 год было украдено 6-7 млрд учетных записей. И если вам кажется, что это касается кого-то другого, то скорее всего ваши данные там тоже есть. Вот несколько крупных утечек только за прошлый год:
- Онлайн-казино 1Win - 122 млн учетных записей
- Интернет-магазин rendez-vous.ru - 6 млн
- Магазин winelab.ru - 4 млн
- Сервис доставки еды pizzasushiwok.ru - 2 млн

Из интересного - свежий хит-парад самых популярных паролей. И тут, конечно, ничего нового. Люди не меняются 😁.

Топ-10 кириллических паролей за 2024 год:
1. йцукен
2. пароль
3. рандеву
4. привет
5. 123йцу
6. Пароль
7. марина
8. 1234йцук
9. 1й2ц3у4к
10. 12345йцуке

Топ-10 паролей за все время (латиница и цифры):
1. 123456
2. 123456789
3. qwerty123
4. 12345
5. qwerty
6. qwerty1
7. password
8. 12345678
9. 111111
10. 1q2w3e

Не знаю, что здесь удивительнее - что люди продолжают использовать 123456, что “йцукен” стабильно держится в лидерах уже который год, или что в чарты ворвалась Марина 🤣.

Еще есть 10 самых популярных кириллических паролей за все время. Тут все наши любимые имена 😎.
1. йцукен
2. пароль
3. любовь
4. привет
5. наташа
6. максим
7. марина
8. люблю
9 .андрей
10. кристина

Собственно, стандартные советы как защититься:
1. Используйте уникальные пароли для каждого сервиса. Один утек - остальные в безопасности.
2. Включите двухфакторную аутентификацию (2FA). Даже если пароль утечет, без второго фактора доступ получить не получится.
3. Пользуйтесь менеджерами паролей. Тот же эппл в keychain придумывает такие пароли, которые никогда не запомнить, но они всегда доступны и в безопасности.
4. Ну и периодически проверяйте себя. Используйте сервисы вроде Have I Been Pwned - они покажут, если ваши данные где-то уже утекли.

Всем йцукен 🫶

Сегодня международный день лайка!

Лайк ❤️ - это больше, чем просто кнопка. Это универсальный жест одобрения, способ сказать, что мне это нравится, без лишних слов. Лайки стали частью нашей жизни, от соцсетей до рабочих чатов.

Исторически первый лайк появился в 2007 году в Facebook (тогда это была "Awesome Button" или "Кнопка Круто") и с тех пор этот жест распространился повсюду. Сегодня лайк есть практически в каждой платформе - будь то ютуб, инста, Звук или даже GitLab.

Лайки очень важны!
- Для создателей контента. Каждый лайк это сигнал что то, что ты делаешь, важно и ценно. А еще - мотивация продолжать. Такая доза дофамина, которая делает нас счастливее. Поставил - приятно. Получил - приятно вдвойне😎.
- Для алгоритмов чем больше лайков - тем выше шанс, что вам подберут более релевантный контент, например рекомендации в стриминге.
- Для разработчиков лайк - признание, что работа выполнена качественно.

Это как в реальной жизни сказать -ты молодец, спасибо за помощь. Чтобы человеку стало теплее на душе.

Всем лайки ❤️

как хорошо, что сегодня пятница 😎

Мы пилим монолит на микросервисы!

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

Зачем? Стандартные ответы следующие:
- Накопилось легаси, и нам посоветовали переписать.
- Сервис нестабильно работает, решили, что микросервисы надежнее.
- Хотим ускорить сервис, ведь микросервисы быстрее.
- Разработчики хотят новый стек, а с микросервисами проще внедрять другие языки.
- Инфраструктура будет дешевле, ведь масштабировать можно по-отдельности.

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

Если все сделать правильно, можно получить и другие плюсы:
- Масштабируемость - можно отдельно увеличивать нужные компоненты.
- Отказоустойчивость - сбой одного сервиса не положит весь продукт.
- Мультистек - каждая команда может выбирать технологии, подходящие под ее задачу.
- Переиспользование - модули можно использовать в разных частях продукта.

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

В глазах бизнеса это выглядит как:
- Мы тратим кучу денег, а где результат?
- Почему я не вижу новых фич?
- Зачем все так усложнять, если раньше и так работало?

Второй нюанс - поддержка микросервисов стоит дороже:
- Оркестрация (Kubernetes и вся его магия).
- Нюансы с консистентностью данных.
- Сетевые задержки между сервисами.
- Сложности с end-to-end тестированием.

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

PS: Да и мы в компании сейчас как раз дораспиливаем монолит. 😎
PS2: Есть замечательный ресурс microservices.io, где собраны ценные материалы по этой теме.

Про типы данных для чисел и float

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

Какие бывают типы данных для чисел?
Целочисленные (int, long, bigint)
- Хранят только целые числа (например, 5, -42, 1000000).
- Не подходят для работы с дробями, но идеально справляются с подсчетами, где важна точность (например, копейки или центы).
Числа с плавающей запятой (float, double)
- Используются для представления дробных чисел (например, 0.1, 3.1415).
- Работают на основе двоичной системы, что вызывает проблемы с точностью.
Десятичные числа (decimal, numeric)
- Хранят числа в десятичной системе с фиксированной точностью.
- Используются там, где ошибки округления недопустимы - например, в финансовых расчетах.

Что не так с float?
Есть крутой сайт 0.30000000000000004.com, где подробно это объясняется. Можно увидеть, что в разных языках - разное поведение 😁.
Проблема float в том, что этот в этом формате не могут точно представлять все десятичные числа. Виновата двоичная система, в которой хранятся значения. Например, в десятичной системе 0.1 - это обычная дробь, но в двоичной она превращается в бесконечную последовательность 0.0001100110011… и при хранении происходит округление, которое вызывает ошибки.

Вот классический пример из программирования:
print(0.1 + 0.2)
На выходе будет не 0.3, а 0.30000000000000004.

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

Если не углубляться в детали происходящего, то есть IEEE 754 (стандарт для представления чисел с плавающей запятой), и его суть проста:
- Двоичная система не может точно представить все десятичные дроби.
- Округление при переводе вызывает микропогрешности.
- Чем больше операций, тем больше ошибок.

В общем использовать float - это как считать деньги на калькуляторе с погрешностью ±1%. Вроде и работает, но точно не для серьезных задач. Поэтому если работаете с деньгами, например в системах биллинга - float это не ваш выбор.
Но! Если погрешность не критична и не приведет к катастрофе, когда важна скорость вычислений и нужно работать с большими объемами данных, для машинного обучения и мультимедиа - там float идеально подходит.

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

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

Во-первых - охлаждение до почти абсолютного нуля (-273 °C).
Большая часть того, что видно визуально - это криостат, многослойная башня, похожая на люстру. Кубиты работают при температуре около 0,01 Кельвина (чуть выше абсолютного нуля). Такое охлаждение необходимо, чтобы убрать тепловой шум, который разрушает квантовое состояние.

Во-вторых - многослойная структура - каждый уровень имеет свою задачу. Люстра состоит из нескольких слоев, каждый из которых снижает температуру и защищает (экранирует) кубиты:
- Верхний уровень: отсек с обычной температурой (электроника управления).
- Промежуточные уровни: охлаждение жидким гелием (4 К, -269 °C).
- Нижний уровень: зона с кубитами (~0,01 К, почти абсолютный ноль).

В-третьих - специальные провода. Для управления кубитами используются коаксиальные кабели, которые проводят микроволны. Эти волны помогают задавать состояние кубитов (подготавливать их к вычислениям) и считывать результат (когда измеряют суперпозицию).

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

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

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

Мне стала интересна сама передача данных - с помощью библиотеки ggwave. Она реализует простой протокол передачи, основанный на частотной манипуляции (Frequency-Shift Keying, FSK), и может быть легко интегрирована в различные проекты.

Так же используется коррекция ошибок для повышения надежности передачи - кодирование Рида-Соломона.

ggwave поддерживает передачу данных как в слышимом диапазоне, так и в ультразвуковом спектре, что позволяет передавать информацию незаметно для человеческого уха. Есть мнение, что последнее, что услышит человечество - как раз подобные сигналы 😁. Или не услышит 🤣

Но, кожаные мешки, конечно у нас есть шанс!
Теоретически можно заглушить передачу, поскольку ggwave передает данные через звуковые сигналы в узком диапазоне частот, если создать достаточно мощный помеховой сигнал (джемминг) в том же диапазоне, он сможет перекрыть полезный сигнал. На GPS научились.

Квантовые компьтеры

На днях Майкрософт объявила о создании Majorana 1 - первого в мире квантового процессора с топологическими кубитами, что как они говорят может привести к революции в вычислительных технологиях.

И я понял что слабо себе предствлял что такое квантовый компьютер в принципе. Так вот - в отличие от классических компьютеров, оперирующих битами (0 или 1), квантовые компьютеры используют кубиты, способные находиться в состоянии суперпозиции, то есть одновременно быть и 0 и 1. Это позволяет квантовым системам обрабатывать огромное количество состояний параллельно.

Еще эти кубиты бывают разные: какие-то сверхпроводящие микросхемы, ионы (захваченные ионы, квантовым состоянием которых манипулирую с помощью лазеров), фотоны.

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

Зачем строят квантовые компьютеры? Они обещают (точнее мы верим, что они такими будут 😎) решать задачи, которые недоступны или требуют огромных ресурсов от классических компьютеров. Это включает моделирование сложных молекул для разработки новых лекарств, оптимизацию логистических процессов (задачу Коммивояжера помните?), взлом шифров 😂 и многое другое.

А еще квантовые компьютеры выглядят просто мега футуристично! 😍

Как работают банковские платежные системы

Надеюсь, что происходящее вокруг скоро закончится и международные банковские платежные системы, такие как VISA и Mastercard вернутся в РФ. Но мало кто понимает зачем они вообще нужны, как они работают и зарабатывают деньги. Попробуем разобраться.

На самом деле экономика платежного потока по кредитной карте довольно проста.

1. Держатель карты платит продавцу, например, 100 долларов за покупку товара.
2. Считается, что продавец получает выгоду от использования кредитной карты за счет более высокого объема продаж и должен компенсировать эмитенту (банку, который выпустил карту) и сети карт предоставление платежного сервиса. Банк-эквайер устанавливает комиссию с торговцем, называемую «комиссией за комиссию за транзакцию». В данном случае это 2 доллара.
Применительно к реальной жизни - когда вас просят заплатить наликом, то это как раз из-за комиссии, которую продавец не платит в случае получения нала. Бабки сразу падают в карман 😁.
3-4. Банк-эквайер удерживает 0,25 доллара в качестве наценки на эквайринг, а 1,75 доллара выплачивается банку-эмитенту в качестве комиссии за обмен. Все покрывается за счет продавца.
5. Банковская система устанавливает сетевые начисления и комиссии для каждого банка, который ежемесячно оплачивает услуги карточной сети. Например, VISA взимает начисление в размере 0,11% плюс комиссию за использование в размере 0,0195 долларов США за каждый платеж.
6. Владелец карты оплачивает услуги банка-эмитента.

Почему банк-эмитент получает компенсацию?
- Эмитент платит продавцу, даже если владелец карты не платит эмитенту.
- Эмитент платит продавцу до того, как владелец карты заплатит эмитенту.
- Эмитент несет другие операционные расходы, включая управление счетами клиентов, предоставление выписок, выявление мошенничества, управление рисками, расчеты и т.д.

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

Итак, мои дорогие любители готовить!
Ставки сделаны - ставок больше нет! 😁

После многих часов изучения интернетов, соменний и метаний, и конечно же личных ощущений от сковородок, были куплены:
- Ballarini Salina 28 и 20 см с титаном
- Swiss Diamond 26 см для блинов

Первые две прекрасно показали себя сегодня на тестовом приготовлении омлета и яишницы 😎
Блины будут на следующей неделе, тем более масленица!

Го готовить!