Такты, стеки, два колеса

Посмотрел у Rozetked краткую выжимку с презентации Google IO, где они 90% времени хвалили свою нейросетку Gemini. И что подумал: задач для просто болтовни с ИИ в чате не так много. А вот научить робота делать за тебя всякую рутину это уже гораздо интереснее. И тут огромное преимущество Гугла над OpenAI — у Гугла уже полно очень популярных сервисов, на которые можно навесить ИИ-функциональность. В презентации так и показывали, например почта с нейросеткой — Gemini залезает в каждое ваше письмо и даже читает вложения, а затем, например, может вам сказать, сколько вы денег (по чекам в почте) потратили на определённую категорию товаров за какое-то время. Ну, пример немного вырожденный, но если нейросетки за нас научат надёжно пользоваться веб-сервисами и приложениями, это будет по-настоящему полезным применением. Я бы хотел рассказать экселю обычным человеческим языком, какая мне нужна таблица, и чтобы он её сделал. Ребята из GigaChat, тем временем, показали мне function calling — как раз попытку поженить машинный интерфейс и языковой процессор. И мне даже хочется попробовать сделать что-то простое. Можете накидать идей в комментах. Нужен какой-то сервис с API, который я смогу вызывать, либо другая формализованная машинная работа. И к ней какая-то рутинная задача, которая может быть создана из текстового запроса на естественном языке. Что бы это могло быть? #dev

Порассказывал в нашем корпоративном подкасте о нюансах айти в атомной промышленности. Технических деталей и внутренней кухни особо нет, но по верхам нормально прошлись. 💙ВКонтакте 🎵Яндекс Музыка 🌐Mave #dev

В C# есть модификатор доступа internal, который закрывает свойство или метод для всего, кроме текущей сборки (сборка это по сути группа пространств имён). И это чертовски удобно для построения правильной архитектуры по DDD — ты делаешь домен отдельной сборкой без внешних зависимостей, у сущностей закрываешь сеттеры и другие поля модификатором internal, а бизнес-правила с открытыми методами уже пишешь в агрегатах, которые содержат эти сущности. Агрегаты объявлены в той же сборке, так что они могут с сущностями делать что угодно, но слой приложения уже сможет вызвать только метод агрегата. Пример. Есть бизнес-процесс, который включает в себя две сущности: письмо и прикреплённый к нему документ. У каждой из этих сущностей разные жизненные циклы, но письмо можно отправить только в том случае, если статус документа "Согласован". Мы делаем агрегат "письмо с документом" и там public-метод отправки письма сначала проверяет статус документа, а потом вызывает internal-метод отправки в сущности письма. Снаружи (вне домена) вызвать сразу отправку письма невозможно. Но как эту задачу решают разработчики на других языках? Я совершенно не понимаю, как сделать хорошую архитектуру без internal. Окей, в некоторых языках вообще нет вменяемого ОПП и системы типов, но и к таким ребятам я бы не подходил с вопросами об энтерпрайз-архитектуре. Однако, многие серьёзные проекты пишутся на Java или, скажем, Go, что делают разработчики там? Может, кто-нибудь знает, и расскажет мне в комментариях? #dev

Обновил ноут, так что для истории выложу крышку старого. По наклейке на каждый конкурс, хакатон и айти-конференцию, где я принял участие, выиграл, был жюри и так далее. Целые слои истории. Смотришь и вспоминаешь то бессонную ночь в Салехарде на хакатоне ЯНАО, то кофе с чак-чаком в Казани на финале Цифрового Прорыва, то огромный призовой фонд в SmartMarket и ещё бОльший в "Код Петербурга"... Новый ноут побольше и на крышке у него места пока очень много, будем продолжать :) Кто не знает, почти со всех интересных хакатонов и конкурсов я пишу рассказы, например: • С первого раза взяли гран-при • Cамый большой хакатон в мире • Крупнейший европейский хак Junction • Конкурс для разработчиков на 2.5 млн рублей и другие #dev

Два дня был экспертом на хакатоне по разработке для студентов. Участники, как правило, 4-5 курс, бакалавры и магистры. Многие ребята очень сильные, показали отличный результат, получше, чем у некоторых взрослых программистов с резюме и зарплатой. Так вот, заметил интересный эффект. Студенты — даже очень компетентные — не могут побороть желание переусложнять систему и использовать чуть ли не все известные им фреймворки и технологии. Даже не знаю, какую аналогию привести — представьте что терапевт делает вам 20 различных видов осмотра на приёме и просит сдать 20 анализов на разные виды вирусов и других болезней, которые ему известны. Вроде и плохого ничего, но и не нужно. С архитектурой приложений аналогично: надо не только знать, что и когда применить, но и чувствовать, что и когда НЕ применять. Это, конечно, приходит с опытом. Справедливости ради, многие энтерпрайз системы, которые делаются состоявшимися специалистами, тоже переусложнены: условному Твиттеру, конечно же, не нужна никакая тысяча микросервисов. Но там на разработку еще и бизнес влияет и избыток ресурсов, а здесь у студентов тяга к умножению сущностей проявилась особенно ярко и характерно. Например, команда крутых технарей из Бауманки сделала чат-бота на 40 контейнерах, девопс там конечно красавчик, но к дедлайну до конца соединить не успели (хотя всё равно заняли призовое место). #dev По теме мне особенно нравится вот эта картинка:

Меня иногда спрашивают, заменят ли нейросети программистов (или "когда заменят"). Мне на эту тему очень нравится картинка ниже. Давайте подумаем, что делает ценным квалифицированного специалиста. Задача специалиста это принять на вход некоторые стартовые условия, а потом произвести над ними манипуляции, чтобы выдать требуемый результат. Хирург получает тело человека с каким-то заболеванием и должен в нужных местах совершить надрезы и наложить швы, чтобы в качестве результата человек остался живым и более здоровым, чем раньше. Адвокат получает материалы дела с каким-то конфликтом и должен произвести некоторую последовательность воздействий на суд так, чтобы именно его клиент вышел из конфликта победителем. Строитель-прораб получает чертежи здания, площадку и бюджет и должен сформировать цепочку управляющих команд для рабочих, чтобы в итоге получилось здание, которое не упадёт и пройдёт нужные проверки. Если между набором стартовых условий и конечным результатом всегда одинаковая последовательность манипуляций, такой труд автоматизируется. Сложно как-то принципиально по-разному рассчитать клиента на кассе. Сложно выбрать несколько путей оформления одного и того же шаблонного документа. Нельзя десятью способами нарезать резьбу с заданным шагом на заданной заготовке. Так что для всего этого есть станки, аппараты, программы и роботы. Квалификация подключается там, где путей много, и для выбора правильного недостаточно просто описать желаемый конечный результат. У специалиста есть знания, опыт и интуиция, которые позволяют ему именно в каждом конкретном случае принимать решения. Относится ли программирование к подобным областям? Безусловно. Одну и ту же программу можно написать сотней способов и между этими способами будут серьёзные отличия, которые повлияют впоследствии на использование и развитие этой программы. Ну хорошо, но мы ведь загрузили в нейросеть весь опыт и знания программистов. Что мешает ей пройти тот же путь, что пройдёт программист, и точно так же принимать решения, исходя из ситуации? Два момента. Во-первых, у человека есть воля, а у нейросети нет. У человека есть способность как бы создавать новые решения внутри себя, а не в результате некоторой инструкции извне. И воля квалифицированного специалиста — важный аспект его работы. Грубо говоря, в части случаев мы хотим, чтобы специалист совершил творческий акт, принимая решения. Во-вторых, опыт практически в любой области, требующей квалификации, частично включает в себя понимание всего многообразия контекстов человечества в целом. То есть как бы знания того, что такое человек, в каких ситуациях он будет пользоваться результатом твоей работы и так далее. Так что нет, нейросети не заменят программистов. Исключение, пожалуй, такое: программа, которая запускается один раз для выдачи конкретного результата, не требующего высокой надёжности. Если мне нужно один раз для личного удобства переименовать тысячу файлов, то в целом программа, которая это делает, может быть написана сколь угодно плохо, лишь бы работала. Но это совсем небольшой процент реальных сценариев. #dev

В этом году я читаю небольшой курс лекций студентам Высшей Инжиниринговой Школы НИЯУ МИФИ, вот на прошлой неделе начал. Тема: архитектура приложений. Сначала SOLID, простые паттерны, а потом сложные паттерны и DDD. Долго думал над тем, какие примеры приводить. Классические книжные не хотелось, типа вот у нас класс "Животное", у него наследник "Кошка". Это понятно для жизни, но далеко от реального программирования. И примеры со своей работы не хотелось, потому что без знания специфики не будет понятно, что такое "Цифровая ведомость объёмов работ", и почему в ней есть те или иные ограничения. Так что придумал вот такой сценарий для студентов: примеры из видеоигр. Любая видеоигра это программа, написанная разработчиками на языке программирования. Это реальные люди, которые сталкивались с реальной необходимостью применить какие-либо паттерны и архитектурные подходы. Я, конечно, не знаю, как та или иная функция была реализована в игре на самом деле — вполне возможно, что из-за спешки, производственного ада, использования устаревших технологий или проблем планирования что-то написано очень плохо, коряво, без архитектуры и с огромным техническим долгом. Но я просто показывал ситуации, в которых какой-то конкретный структурный подход кажется уместным, и рассказывал, как можно такую ситуацию реализовать на практике. Вроде получилось неплохо, студентам зашло. Обратная связь по лекции пришла положительная, так что будем продолжать :) #dev

Офигенная история про бытовой кибертерроризм. Я уже вам рассказывал пару раз о вредоносных закладках в OpenSource коде — описывал, например, борьбу одиночек с корпорациями таким способом, хотя последнее время больше внимания к антироссийским закладкам по политическим мотивам. Обычно мы понимаем работу софта, как что-то в компьютере, а вот тут случай из мира Internet Of Things. Baza написала об этом без технических подробностей, поэтому мне пришлось порыться самому. В интернете есть куча проектов "умной гирлянды" для украшения окон к новому году. Как правило, это прямоугольная матрица из адресных светодиодов: ей завешивается окно целиком, а микроконтроллер позволяет (путём изменения цвета каждого диода) выводить любой рисунок, надпись, анимацию. Как работает и выглядит можно посмотреть вот тут. В очередной такой версии один из участников форума AlexGyver'а (не сам Алекс) выложил форк прошивки для управления адресными диодами. Прошивка подключается по вайфай к роутеру, чтобы с телефона можно было через удобный UI настраивать эти самые тексты и анимации. Так вот, оказалось, что автор изначальной версии — украинец. В свою версию кода три месяца назад он добавил закладку: устройство, пользуясь подключением к ВайФай, определяет по IP местоположение, откуда оно запущено. Если это Россия, то из постоянной памяти считывается последовательность кодов символов так, чтобы в полночь первого января устройство отключало все внешние кнопки и выводило на окно надпись, прославляющую Украину. Такая надпись в итоге появилась, по видимому, у нескольких людей, использовавших эту гирлянду. И как минимум одного из них заметили соседи и настучали, вроде как дело завели даже. Морали лично для меня две: — Компьютерное уже давно не только в компьютере, а вполне влияет на физический мир. Это очевидно, но не во всех случаях эту мысль просто принять. — IoT должен быть только из источников, которым вы полностью доверяете, либо написан самостоятельно. P.S. Кстати, забавно видеть, что комментарии к коду у этого разработчика до определённого времени все по-русски, а в новых правках исключительно по-украински. То есть вроде как от вражеского языка отказался, но отредактировать всё предыдущее лень. #dev

В этом году не успел поучаствовать в VK Fresh Code, зато меня позвали оценить конкурсные проекты и посодействовать в награждении. Кажется, из всех постоянных конкурсов, в которых я участвовал, Fresh Code это единственный, который не скатился в тупые метрики (привет, Яндекс Диалоги), а его до сих пор судит команда жюри, что приводит к появлению большого количества действительно разнообразных проектов. В 17:00 будет стрим, можете посмотреть, и я там буду :) #dev https://vk.com/video-166562603_456239155

На выходных посетил HolyJS — это такая конференция для Frontend-разработчиков. Обратил внимание на то, что уровень технической погруженности докладов был ниже, чем на Joker (конфа по Java), при этом дисперсия интересности более кучная — на HolyJS было существенно больше докладов, которые мне понравились на уровне "хорошо", а на Joker некоторые доклады прям совсем не зашли, и я оценил их на "так себе". Кстати да, у JUG (организатора этих всех IT конференций) такая шкала оценки доклада: Ужасно, Плохо, Так себе, Нормально, Хорошо, Отлично, Супер. Я поставил одну "Так себе", одну "Нормально", одну "Супер" и кучу "Хорошо". Считаю, что оценку "ужасно" можно ставить, если докладчик пришёл бухой и вместо рассказа кидался в зал огрызками яблок. Потому что все доклады проходят отбор, и там не бывает именно критически низкого качества. Бывает, что вам не зашла тема, либо докладчик рассказал не то, что вы ожидали — но это, как мне кажется, не заслуживает оценки "ужасно". Думаю, в большинстве случаев такая оценка это просто эмоции: личная неприязнь к докладчику, либо несогласие с какой-то его идеологической позицией. Я сам "ужасно" никогда не ставлю. При этом на HolyJS было очень много разнообразных по темам и направлениям докладов, и это следствие того, что фронтенд можно исследовать в ширину сильнее, чем какую-нибудь Джаву, которую скорее копают в глубину (и поэтому на Joker доклады технически более сложные). Джава, хоть и запускается на миллионах устройств, делает это примерно одинаково везде. Во фронтенде же куча фреймворков и множество совершенно различных путей приложения: тут тебе и 3D, и процедурка, и сайты, и мобильные приложения, и какие-нибудь киоски, и геймдев, и умные телевизоры. Так что, резюмируя, я бы посоветовал HolyJS как точку входа в конференции для разработчика, если он не строго прилип к какому-то одному стеку. Тем более, честно говоря, для современных программистов знать хотя бы по верхам фронтенд это полезно независимо от основного направления, в котором они работают. #dev

Компания Volvo отключила россиянам свои онлайн-сервисы, в том числе мобильное приложение для взаимодействия с автомобилями, ПО для сервисных центров итд. Причём, ограничение работает даже в том случае, если вы смогли перевезти свой автомобиль в другую страну: достаточно того факта, что он изначально был поставлен в Россию. Пару лет назад мы с командой выиграли IT-хакатон от компании Volvo. По окончании нас попросили подписать документы о полной передаче нашего кода в собственность компании и отказе от любых прав на него. Не исключено, что этот код был в итоге как-то использован, и крутится где-нибудь на серверах Volvo. Если не код, то хотя бы концепция наша им тогда очень понравилась. Как говорится, можно вывезти Volvo из России, но... #dev

Сходил для интереса на конфу для Java-разработчиков, хотя не пишу на Java уже давно (а на хорошем уровне не писал никогда). Было много всего интересного, но особенно меня впечатлила лекция об истории развития этого языка. Java, на секундочку, вероятно самый распространённый язык программирования в мире с точки зрения количества разных устройств, на которых он присутствует. То есть буквально один из столпов современной цифровизации всего человечества. Так вот, когда он только зарождался, компания Sun Microsystems наняла себе в помощь несколько сотен разработчиков из России, бОльшая часть которых сидела у нас в Питере — это были выходцы из матмеха СПбГУ. Более того — в какой-то момент именно питерская ячейка стала крупнейшей по числу инженеров, превзойдя даже ту, которая располагалась в Калифорнии. И люди периодически ездили в США, чтобы синхронизировать свою работу с тамошним офисом (пересылали diff репозитория архивами по почте!). Потом Sun купила Oracle и постепенно ушла из России. Но вклад наши внесли, оказывается, очень существенный. #dev Перерисовал на эту тему картинку из XKCD