Намери подобно съдържание

Ух, очень продуктивная была поездка. Наши взяли золото, причём, в этом году организаторы решили наградить в том числе экспертов по подготовке, чьи команды выиграли. Не надеялся я, что когда-нибудь ещё раз (после победы в 2022) поднимусь на эту сцену и получу медаль, а оно вот как сложилось. Наверное, по эмоциям от AtomSkills один из самых сильных эффектов. С ним соперничают, разве что, мой первый хакатон VK Hack 2018, и крупнейший в мире хакатон «Цифровой Прорыв», сильно изменивший мою последующую жизнь. В любом случае, каждый год AtomSkills это очень масштабное и классно срежиссированное мероприятие с большим количеством впечатлений, интереса, опыта. А сейчас вот был юбилейный чемпионат — десятый, и такой подгон. Два года не брали медалей, и никогда раньше в нашей компетенции не награждали тех, кто привёз команды. Видимо, мои хакатонные боги-покровители решили, что я засиделся. В задание тоже удалось привнести некоторую новизну. В целом схема такая: эксперты совместно делают задание, придумывают шкалу оценки и критерии. Но при проверке решений каждую команду смотрят только те, кто к этой команде не имеет отношения. При этом критерии оценки это в большинстве своём объективные предикаты, на которые решение проверяется. Например, в критериях может быть фраза «Система позволяет создать нового пользователя: да (3 очка) / нет (0 очков)». Де-факто споров почти не возникает, коллегия экспертов почти всегда сразу видит и понимает, засчитывается тот или иной критерий или нет. Субъективные части в оценке тоже есть, но их влияние на результат в разы меньше, чем в обычных хакатонах. И да, важнейшее ключевое отличие: на AtomSkills решение каждой команды обязательно разворачивается независимо на пустом компьютере и прогоняется через бизнес-сценарии. Нельзя наврать в презентации, будто бы ты что-то сделал, чего нет. Нельзя сделать решение на моках или фейковое. Нельзя вытащить только на харизме и софт-скиллах. В этом году мы, как авторы задания, к обычной энтерпрайз-части добавили алгоритмическую задачу. Стандартно командам предлагается сделать мини-CRM или нечто подобное в заданном домене, что увеличивает влияние заготовок. Если принести с собой слишком много подготовленных форм, CRUD'ов, конфигов и так далее, это экономит тебе много времени, и ты в итоге просто выигрываешь из-за форы. Сейчас же в мини-CRM была специальная функция: написать алгоритм оптимизации расписания работ. Детали задачи я расскажу завтра, но в целом никакие заготовки не помогали решить это эффективно, если не знать задачу заранее (а она до конкурса скрыта, и разглашение карается дисквалификацией). В итоге лично на мой взгляд итоговый балл получился очень взвешенным: — Если команда сделала хороший алгоритм и не провалилась при этом по обычной не-алгоритмической части, она набирала много баллов (как наши) — Если команда сделала неэффективный, но работоспособный алгоритм, у неё был шанс вывезти за счёт супер идеального вылизанного исполнения не-алгоритмической работы (такие получили серебро и бронзу) — Если алгоритм у команды не заработал вообще, то даже при супер идеальном остальном решении в тройку она не попала — Если алгоритм у команды был хороший, но имелся сильный провал во всём остальном — она вообще оказывалась ниже середины В общем, не знаю, попаду ли в следующий раз, но воспоминания и опыт невероятные. #dev

Попробовал этот ваш Cursor. Мне прям несколько человек независимо советовали. Ну, что могу сказать, да, вполне впечатляет. Точнее так: автокомплит хоть и хитрый, но лично у меня восторга не вызвал. Иногда угадывает очень круто, иногда очень плохо. А вот режим агента — это да. Я бы сказал, что это новый значительный качественный шаг в программировании. Большим моделям как раз и не хватало какой-то пристройки, которая позволяет им не только выдавать текст, но и совершать действия. У вас как бы под рукой есть джун, который хорошо знает теорию и делает всё очень быстро. Он не понимает, зачем, не умеет проектировать, склонен к шаблонным решениям. Но всё равно теперь ваша работа состоит в том, чтобы аккуратно объяснять ему задачу обычной человеческой речью (в том числе на русском языке) и указывать на ошибки. Вся утомительная, но когнитивно простая рутина теперь делается за секунды вместо десятков минут. А рутины в разработке очень много, особенно если это продуктовая или заказная разработка на многословном энтерпрайз языке. Стоит сказать, что Cursor, конечно, как и все форки VS Code, остаётся просто текстовым редактором, и ощущается соответственно. Если вы пишете настоящую программу на серьёзном языке, а не текстовый файл, то для надёжной работы вам всё равно параллельно нужно открыть взрослую IDE. Тем не менее, Cursor умеет читать структуру каталогов и учитывать устройство вашего проекта, а к контексту запроса в LLM можно вручную присоединять любое подмножество файлов. Можно ли назвать это явным шагом к исчезновению работы программиста? Я искал информацию о том, какие профессии были уничтожены автоматизацией, и наткнулся на статью, где упоминались кучер и колёсник (тот, кто делал колёса для карет). Один из популярных комментариев: «Буквально вчера заказывал кучера, потому что свою карету отдал колесникам на ремонт помятого диска». Но это шутки, конечно. А так, есть профессии, где увеличение степени автоматизации в конце концов полностью исключает человека (расстановщик кеглей в боулинге, телефонистка, фонарщик), а есть те, где автоматика просто упрощает людям жизнь и помогает выполнять свою работу эффективнее (компьютер помогает математикам, экскаватор строителям, телескоп астрономам). В чём же отличие первых и вторых? Я бы сказал, что у вторых профессий есть факторы непредсказуемости, вызванные необходимостью создания нового. В расстановке кеглей новых задач не появляется, как и в переключении телефонных линий. А в программировании появляется, и вот почему: у человечества возникают как новые процессы, требующие автоматизации, так и видоизменяются старые. И это, по всей видимости, бесконечный процесс. Да, разумеется, сильный ИИ с сознанием и способностью принимать решения будет уметь всё, что умеет человек, и даже больше. Но до этой технологии нам далеко, и нейросети не являются тропинкой к ней. Другое дело, что джуны теперь не нужны, простите. Там, где раньше требовалась команда из сеньора, пары мидлов и пары джунов, теперь справится один сеньор, ну может ещё с одним мидлом, и всё. Советую всем начинающим программистам учить не то, как делать, а то, почему нужно делать именно так. Архитектуру, паттерны, принципы, лучшие практики. Тогда в уходящий айти-поезд ещё можно заскочить. #dev

Первоначально я очень скептически относился к написанию кода нейросетками. Но при этой оценке я допустил ошибку: пробовал технологию на сишарпе, который, во-первых, знаю хорошо, во-вторых, на котором пишут в основном всякий энтерпрайз, где важна архитектура. Нейросети раскрываются, когда тебе нужно закодить чисто утилитарную вещь на малознакомом языке. Архитектуру ты всё равно строишь сам, да и проверить существующий код в большинстве случаев можешь без проблем. Но при этом не обязан помнить, как там в какой-то популярной библиотеке называется нужный метод, или какие есть в этом языке нюансы синтаксиса. Программирование это разговор человека с компьютером на языке компьютера. Нейросети делают шаг в сторону языка человека, но не так, как думают авторы новостных заголовков. Пока ещё в основном нельзя сказать «Сделай мне программу, которая посчитает деньги». Ты всё ещё должен иметь представление о структурах данных, алгоритмах, и, в общем-то, должен быть способен за вменяемое время написать такую программу самостоятельно. Поэтому и с нейросетью ты общаешься соответственно: «Два метода, в первый на вход поступает словарь с таким-то ключом, вытащи из него значения и отсортируй вот этим вот лямбда-выражением, второй метод проверяет пересечение таких-то двух выборок на непустоту и возвращает булев ответ, затем...». И вот это работает очень круто, потому что ты труба шатал помнить, что в этих ваших питонах None вместо Null или как там в каком языке инициализируется список. А так можно написать проект в два-три раза быстрее и с тем же уровнем качества, что и сам. #dev

Подумал о том, что у сезонного бизнеса куча времени на техдолг. Вот что делают программисты какого-нибудь Whoosh с ноября по март? Увольнять их и искать новых каждый сезон неэффективно. Зарплату им тоже на эти месяцы не снизишь, так как сами сбегут тогда. Да, они могут заниматься исследованием новых фич, но всё равно остается уйма времени на шлифовку всего существующего и разбор техдолга. Они в этот период даже могут выпустить в прод кривой билд приложения, и это никак не ударит по бизнесу. Мало где есть такие условия с этой точки зрения. Тем страннее, конечно, наличие сырых неработоспособных фич, по которым запущен маркетинг. #dev

Yandex Cup это феерическое унижение, конечно. Набрал 229 баллов из 500, понятно что в финал не выйду. Думаю мой реальный предел где-то 350-400. Но потратил слишком много времени вот на что: 1. В задаче А (на хеширование) быстро придумал решение, но сотню баллов мне система не выдавала. На каких-то краевых случаях тесты валились, в итоге я набрал 70, потом 75, потом 88. Надо было бросать и идти дальше, в таблице у многих участников эта задача не на 100. Но потерял лишний час, то есть 20% времени. 2. Задача D заключалась в угадывании мыслей авторов. Я обсудил её позже с одним из участников, попавшим в топ-10, и он сказал то же самое. Просто он мысли угадал, а я нет, хотя концептуально я правильно решал. И тоже залип на ней, поскольку было ощущение, что я не учёл какую-то мелочь, и тесты падают из-за этого, а не потому, что она тупо сформулирована. В итоге впопыхах взялся за задачу С на сложный SQL-запрос и не успел, хотя понимал, как. За частичное решение получил 21/100. Ну и задача B на алгоритм расстановки — единственное, что далось на максимум и без задержек, однако в ней я, как мне кажется, считерил, потому что придумал как захардкодить кейсы вместо алгоритмического перебора. В целом, если исключить откровенно непродуманную задачу D, то, пожалуй, претензия у меня такая: в реальной жизни вы можете выяснить, по какой причине в конкретном случае программа не работает, а здесь не можете, и нужно гадать. И тут очень сильно решает опыт предыдущего участия, знание того, как мыслят авторы, и так далее. Не знаю, буду ли пробовать в следующем году. По итогу впечатления скорее негативные, но и отыграться хочется. #dev

Ладно. #dev

Поучаствовал в квалификации Yandex Cup в блоке Backend. Сдал первую и последнюю задачу на максимум баллов (последнюю вообще с первого раза). А остальные две принципиально не стал решать, потому что меня бесит, когда путают бэкенд-разработку и алгоритмы. У них есть отдельная секция "Алгоритмы", куда я не пошёл, потому что не люблю олимпиадное программирование (вот тут писал в конце причины). Но нет же, давайте в бэкенд тоже засунем душноту про модульную арифметику. В общем, дальше как судьба распорядится. Если все поленились или плохо сделали, пройду в полуфинал, иначе нет. #dev

В этом году снова ездил на AtomSkills. Решил написать подробнее на Хабре о том, что там и как, уже с точки зрения члена жюри. https://habr.com/ru/companies/rosatom/articles/824888/ #dev

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

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

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

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