Собрал 8 ключевых законов о которых мы слышим из каждого ящика. В рассылке добавил PDF ч/б версию для печати. Вы знаете кому это отправить

https://devtower.io/p/25-8-essential-laws-of-systems

У меня недавно угнали машину, здесь в UK, и я кое что понял

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

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

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

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

Можно ли это спроецировать на софтверный мир? От части. Взлом стандартной машины, которые тысячами штампуют на заводе и взлом каждой уникальной софтверной системы отличаются необходимой креативностью. Конечно, бывают общие стандартные уязвимости и в софтверном мире, классические дыры в безопасности, вспомним OWASP top 10, но держим в голове, что и обновлять эти системы легче чем "обновлять" авто. Получается, что порог входа в такой взлом варьируется от продукта к продукту. Защита от простых взломов и автоматическое обнаружение уязвимостей, также как и в случае с машинами, просто понижает вероятность того, что рандомный хакер добьется результата. Аналог "упреждающего запугивания" найти сложнее, мне тут подсказали, что это может быть программа bug bounty, факт существования которой уже что-то говорит о том что минимальный порог выше среднего, хотя ничего не говорит о рисках для злоумышленника. А как на счет по страхования?

"Страхование от взлома" звучит крайне органично для физического мира, где за £6/мес можно застраховать нажитое в доме от кражи на £30 000 и несколько сомнительно это звучит для цифрового пространства. Опять же дело в том, что для того чтобы застраховать что-то нужна модель оценки размера премии этого страхования, а тут так или иначе напрашивается некоторая стандартизация разработки продуктов, цена страхования приложений на java может быть одна, приложений на go другая, а на самописном инхаус языке её невозможно определить и такой продукт застраховать нельзя. Точно также можно было бы застраховать соблюдение SLA, чтобы не компания сама несла издержки, а страховая всем за всё заплатила, или даже страховать недополученную прибыль в результате бага в проде.

Что вы думаете про страхование проблем цифровых продуктов? Возможно кто-то здесь работает в страховой компании и может поделиться своими соображениями

Стрим про Spring AI
27 ноября (завтра) 21:30 мск

Собрались с ребятами поговорить про то что такое Spring AI (проект в экосистеме спринга), как к этому относиться и почему на это стоит обратить внимание.
Для участия наличие знаний в машинном обучении или python вам не потребуется :)

Если не хотите пропустить, там есть кнопка Notify me (или как-то так на другом языке)
https://youtube.com/live/5l7WuvTgXUw?feature=shar

Уже сегодня в 21:30 мск

Готовим поп-корн, освобождаем календарь, будем осваивать spring ai и экспериментировать

TypeSpec. Моделирование апи на упрощенном языке

Давно хотел написать про тайпспек и вот пора. По сути, microsoft говорит, что не надо писать openapi спеки больше, их вам сгенерируют из более простой спеки, которая напоминает язык программирования. Похоже на GraphQL, но по факту это не язык общения, это язык дизайна, а дальше всё также на старом добром rest-подобном формате взаимодействия. Выглядит классно и определенно заслуживает внимания. Главный недостаток с первого взгляда - плюс один шаг на CI

https://typespec.io/

Willow - квантовые вычисления стали ближе

В 2018 году в этом канале я писал (реплай ведет на пост) что провел январские праздники за изучением квантового компьютинга. Вообще эта тема мне очень интересна, но в силу низкой прикладной пользы никакой мотивации возвращаться к ней кроме обычного интереса нету. Прошло почти 7 лет! За это время я успел переехать в Питер, потом в Батуми, сейчас в Англии. Годы шли, люди работали и вот новость. Willow - state of the art quantup chip. Пришло ли будущее?

Одна из больших проблем в квантовых вычислениях это масштабирование вычислительной мощности. Чем больше кубитов (квантовых битов) у вас используется, тем больше ошибок накапливается. Удерживание количества ошибок ниже определенного порога это фундаментальная задача на которой работали почти 30 лет. Так вот, судя по всему гугл нашел решение.

Willow не только решает проблему коррекции ошибок, но и демонстрирует что при увеличении количества кубитов работает даже стабильнее и как следствие за 5 минут проходит бенчмарк (random circuit sampling, самый сложный из существующих) на который классический суперкомпьютер потратил бы 10^25 лет (на много порядков больше чем возраст вселенной). Можно сказать "да это всего лишь бенчмарк", но судя по всему это та точка после прохождения которой твое решение воспринимают в серьез.

Прогресс гугла в сравнении выглядит примерно выглядит примерно так:

Год    | Время квантового компьютера | Время классического суперкомпьютера
2019   | 200 секунд                  |  10 000 лет
2024   | 5 минут                     |  10^25 лет

Возможно, у кого-то как и у меня возникнет вопрос, а как так квантовые компьютеры работают аж 5 минут, не должны ли они срабатывать моментально? Я понимаю причину так. Из-за наличия ошибок возникает необходимость запускать вычисления много миллионов раз чтобы получить стабильный результат, в сумме накапливается время на выполнение, т.е. если 300 секунд разделить на 1000000 попыток, то каждая попытка это 0.3 мс. А теперь я напомню, что с увеличением количества кубитов, ошибок должно становиться даже меньше, судя по репорту гугла. Меньше ошибок -> ближе к получению результатов за секунды, но как будто сократив время от невероятного количества лет до 5 минут за перформансом гоняться уже не так критично.

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

https://blog.google/technology/research/google-willow-quantum-chip/

15 неочевидных плюсов и минусов Великобритании

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

Для тех кто ждет чего-то более технического, то чуть позже закину несколько ссылок на видео тоже :)

https://www.youtube.com/watch?v=3VxtiDcmoBU (⏳ 30 мин)

Сегодня планируем полу-спонтанный стрим через 30-40 минут с Димой @javaswag, посмотрим на тренды уходящего года в мире Java и Kotlin

Ссылка скоро

Поехали! Новогодний стрим

https://www.youtube.com/watch?v=t1MDd_Xg4oE
Отличный стрим получился!

Хотелось написать какое-то мудрое пожелание, но после такого придется проветривать от душноты, а за окном зима ❄️

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

🎄С Новым Годом!

p.s. сегодня мы впервые пробили отметку в 500 человек. Ура!

История о том, как я в 24 начал учить английский с нуля

(1/2) Я решил написать этот текст, чтобы вдохновить тех кто постоянно откладывает изучение языка, но понимает что вроде бы надо, однако, недостаточно верит в себя, а иногда думает, что поздно.

Мой уровень английского сейчас где-то между B1 и B2 (Upper-Intermediate) и до C1 мне существенно не хватает собранности, это мой текущий стеклянный потолок. Я вполне могу выразить мысль, говорить складно, понять что говорят собеседники и в быту и в рабочем контексте, хотя быт сейчас превалирует. Всякие походы к врачу, общение со страховой здесь в UK ежедневно учат новым фразам, которые обычно осваиваешь в ламповых условиях уроков.

Эта история началась, когда мне было где-то 23-24 года (2016 год). Всю свою жизнь, начиная со школы, я учил немецкий. Ja ja die deutsche Sprache.

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

Шли недели, мой английский начинал отрываться от абсолютного нуля (по кельвину, конечно) благодаря курсам на работе, я уже знал как сказать “It is cat” (да, без артикля), но было странно приходить на очередной семинар с докладом в котором понимаешь только местоимения. Я начал заучивать тексты, какие-то фразы, а в конце семестра я каким-то чудом сдал на 4 из 5 язык, который учил пол года.

Первое тестирование на практике случилось в нашем свадебном путешествии чуть позже тем годом. Я организовал раунд трип через Чехию, Германию, Люксембург и Францию. Где-то треть всего пути мы ездили с незнакомцами на бла-бла каре, немцами, чехами, французами. В этот момент случилось откровение, я понял, что в принципе могу говорить и меня как-то понимают (я напомню, это где-то А2, но фраза моей жены «май хасбенд спикс инглиш» ломала любые барьеры). Вернувшись, я начал еще усерднее учиться на групповых занятиях на работе и это приобрело какой-то новый смысл.

Позже, к нам в самарский офис приехал немец. Он был как-то связан с заказчиком одного из проектов. Я был очень взволнован его присутствием и постоянно на него поглядывал. Заготавливал фразочки на случай если выдастся возможность что-то сказать и крутил в голове диалоги. В один прекрасный кофе брейк, я вышел из рабочего пространства и встретил его возле вендингового автомата и, как-то естественно, улыбнувшись друг другу, мы начали болтать. Спустя минут 30 он вежливо прекратил нашу беседу и предложил пойти работать, а я понял, что в принципе 30% понимания чужой речи достаточно, чтобы поддерживать разговор. Второй тест был пройден. За оставшееся время в той компании я подтянул английский еще немного до B1 и переехал в Питер.

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

Уже живя в Питере я был еще заряжен на утренние подъемы, так что поставил занятия по английскому на 6 утра с преподом из США, который переехал в Тайланд. Его основной метод - 2 минуты смотрим отрывок видео на ютубе и следующие 2 минуты я всеми правдами и неправдами должен непрерывно говорить о том, что я только что посмотрел.

(2/2) Пожалуй, это была финальная точка где я поверил, что барьера больше нет и как бы я не говорил, меня понимают. Хотя у меня не получилось доходчиво объяснить Девиду из Тая, что не надо называть тех кто верит в теорию большого взрыва «stupid» и аргументировать это фразами вроде «человека очевидно спроектировал бог, это очевидно и не требует доказательств», в конечном итоге я остался очень доволен прогрессом в языке.

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

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

Кто бы мог подумать, что глагол «to coast» это не что-то про побережье, а «двигаться по инерции», благодаря санкам и склонам на спуске к морю? Восторг!

Гугл включил Gemini для пользователей Workspace по умолчанию (умная почта и документы) 🎉

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

Как тот, кто получает обрубленный инструмент за который итак платит, это выглядит не очень, более того в корпоративном мире надо обосновывать эти расходы и как они улучшат перформанс, а это бесполезная работа, которая создает барьеры. Самое грустное, что иногда пробуешь и видишь что инструмент еще сырой или малополезный (у меня такие впечатления были о JB AI Assistant в Intellij Idea несколько месяцев назад), отказываешься от инструмента и не даешь ему расширить базу активных пользователей из которой и растет настоящий фидбек на развивающийся продукт.

Мой вывод: компании которые выносят AI в отдельную подписку ради своего выживания должны сделать его частью основной подписки на инструмент, даже если подписка станет дороже. Что было бы если бы Нетфликс или Кинопоиск выносил в дополнительную плату рекомендательную систему фильмов? Я думаю ответ очевиден. Если это ведет к убыткам, то оптимизировать расходы или поднимать раунды чисто под содержание AI фичей в своем инструменте, чтобы можно было конкурировать с остальными. В конечном итоге, рынок найдет баланс и цена за подписку чуть выше станет нормой, ровно также как подписки и сейчас не бесплатные, а за синхронизацию файликов через облако люди готовы платить при том что флешки никуда не исчезли

https://blog.google/feed/google-workspace-generative-ai-features/

SQL за гранью реляционных баз

Когда я учился в универе я страдал от SQL. Меня злил этот непонятный язык запросов к реляционным базам данных, было совершенно непонятно как этим пользоваться и только с практикой и опытом всё стало на свои места. Последнее время довольно часто мне попадается всё больше и больше сценариев использования SQL за границами реляционных баз на что я и обратил внимание.

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

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

SELECT day_of_week, SUM(amount) as total_amount
FROM some_transactions 
GROUP BY day_of_week

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

Наконец, SQL-like ETL пайплайны. Представьте, что надо обработать какие-то данные из внешней системы в рамках вашего OLAP (Online analytical processing) сценария. Инструменты вроде RisingWave или DuckDB дают вам возможность импортировать в них данные прямо в SQL, а затем в нем же приводить данные к нужному виду. Импорт с S3 выглядит элементарно (пример из документации DuckDB):

CREATE SECRET secret1 (
    TYPE S3,
    KEY_ID 'AKIAIOSFODNN7EXAMPLE',
    SECRET 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
    REGION 'us-east-1'
);

SELECT *
FROM 's3://my-bucket/file.parquet';

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

А где еще вы встречали SQL за границами реляционных баз?

💰История про то как ко мне пришел VC фонд, а я ничего не продавал, но кое чему научился 💡

Где-то в начале января ко мне в Linkedin постучались. Это был один из партнеров английского VC фонда, в портфолио у которого были разнообразные компании, среди которых ElevenLabs (капа $3.3 bln). Мне нечего ему было предложить, так как их фокус на pre-seed и seed фазах, инвестиции до $1-2млн на этапе фаундера и идеи, а мы уже работаем над стартапом для которого сейчас это не нужно. Я явно ему объяснил, что это не матч, а также уточнил, что не смогу даже рассказать чем мы занимаемся из-за nda, тем ни менее мы договорились пообщаться через месяц для расширения нетворка.

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

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

Портрет идеального фаундера для этих ребят выглядел следующим образом:
1. экспертиза в домене
2. способность держать быстрый темп развития продукта
3. провалидированная уникальность идеи и технологического решения

Если 1 и 2 часто формируются естественным путем и приходят с опытом, даже если сфокусороваться только на разработке, то пункт 3 это уже про маркетинг, про способность проверить идею, оценить потенциал для привлечения клиентов.

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