Сбер выкатил сегодня свой Гигачат на всех (до этого была только закрытая бета). Немного обидно за ребят — ещё год назад этот релиз был бы очень значимым, но сейчас разговаривать с откровенно косячащим и допускающим детские ошибки Гигачатом совершенно неинтересно, если вы видели, как работает GPT4, в том числе на русском языке. За решением практических задач тоже нет никакого смысла (пока что) ходить в русские сетки Яндекса и Сбера, потому что GPT4 просто делает лучше абсолютно всё. Он реже ошибается, у него лучше с логикой, он отвечает одинаково на одинаковые запросы (у Яндекса с этим очень большие проблемы пока что), более точен в фактах и рассуждениях.
Ещё команда Гигачата ведёт очень странный маркетинг: будто бы это телепередача для домохозяек. Начиная от частых унылых инфоповодов в духе "Сегодня день резиновых уточек, спросим у гигачата что он думает про резиновых уточек" и заканчивая восторгами по поводу туповатых ответов нейросетки на попсовые запросы ("Пять отмазок не идти на работу").
Создаётся впечатление полного отсутствия product-market fit — Сбер не понимает, что это за продукт, для какой аудитории он нужен, кто будет готов за него платить и в каких обстоятельствах. Домохозяйки вряд ли будут. Впрочем, Яндекс про свою сетку запостил полторы новости и замолчал, так что я даже не знаю, что хуже. Но зато у Яндекса есть preview API, и мне удалось его погонять. Ожидаемо хуже, чем GPT4. Как я уже сказал, основная проблема в том, что пять одинаковых запросов вернут пять разных ответов, причём даже по размеру разных: объём текста может отличаться в несколько раз.
#dev
На работе переезжаем с микросервисов на монолит. Наигрались )
Вообще, удивительно, как идея микросервисов заразила когда-то умы людей в айти сфере. Почему-то на уровне концепции действительно кажется, что это вау, офигенно, переворачивает игру и так далее. Сейчас сделаем микросервисы и заживём: масштабирование, изоляция, параллельность разработки и так далее.
В общем, у нас, как лично мне кажется, повода делать микросервисы особо не было, но несколько лет назад, когда проект начинали, поддались общей моде. После трёх огромных архитектурных рефакторингов стало ясно, что каждая микросервисная фича стоит дороже, чем объём реальной пользы, которую она приносит. И, в целом, я от других разработчиков много слышу последний год-два, что лодка качнулась обратно в сторону монолитов, в том числе модульных, так что мы даже в каком-то смысле опоздали с переездом.
Через полгода расскажу вам, что в итоге вышло. А в комментариях, если вы работаете в большом энтерпрайзе, можете рассказать, как у вас сделано и почему.
#dev
Автор OpenSource библиотеки тайно ворует данные разработчиков, чтобы проверять, донатят они ему, или нет.
Вообще, скандалы с опенсорс-библиотеками бывают не так уж и редко. Разработчики делают что-то бесплатно, этот труд оказывается нужен тысячам людей, включая большие корпорации, а дальше возможны варианты. За последние пару лет ожидаемо было много политических заявлений и даже вредоносного кода по признаку страны, из которой запускается софт. Просто, стартуя с какой-то версии, какая-нибудь библиотека начинает делать что-то постороннее, помимо своей основной функциональности.
К чести комьюнити, такие вещи всегда очень жестко критикуют, даже если идеологические взгляды разработчика выглядят общепринятыми в той среде, где это комьюнити развивается.
Вот на днях новый такой скандал. Впервые в моей жизни в такую ситуацию попала библиотека, которую используем на работе — а именно Moq для .NET. Автор написал код, который спаунит новый системный процесс и командой git config --global user.email читает почту разработчика, а затем с помощью почти зашифрованной закрытой DLL-библиотеки, помещённой в поставку Moq, отправляет данные в сервис GitHub SponsorLink, чтобы проверить, платит ли разработчик донаты.
Конечно же, система безопасности на проде не даст никуда сходить этому коду и ничего плохого сделать. Но, помимо прода, рабочие проекты запускаются еще и на компьютерах разработчиков локально. Вот тут заложена настоящая опасность. Где запрос почты, там может быть следующим шагом что угодно другое — скачивание ваших интимных фото и передача вовне, чтение файла с паролями из папки браузера, поиск номера кредитки... Разумеется, всё во имя самых благих целей.
В общем, комьюнити порассуждало о том, что это критический подрыв доверия, хотя автор оправдывался как мог (как moq, хе-хе). Народ просто закидал его камнями, начал массово исключать Moq из своих зависимостей, ставить дизлайки, отправлять репорты. Вроде как это вынудило мейнтейнера откатить изменения.
Но на всякий случай Moq лучше не обновлять больше никогда и постепенно заменить на аналоги. Доверие — важнейший ресурс в опенсорсе.
#dev
Впервые использовал нейросетку для реальной практической пользы в коммерческом заказе.
У заказчика есть база данных, куда информация вносится кое-как. Представьте, что вы составляете каталог, например, книг, и в базе данных предусмотрены поля: "Автор книги", "Название книги", "Число страниц" и ещё десяток других полей с информацией. Но заполняют эту базу другие люди, которых вы не контролируете, поэтому информация может случайным образом лежать в любом произвольном поле, быть введена с ошибками, опечатками и так далее. В реальном заказе были не книги, я просто привожу пример такой же задачи.
Вот как это может выглядеть:
1. В поле "Автор" написано "Лондон, Дж. Белый Клык", поле "Название" при этом пустое.
2. В поле "Название" написано "150-страничный сборник рецептов", поле "Число страниц" пустое
3. В поле "Название" написано "джеклондон мартин иден", поле с автором пустое
4. В поле "Автор" написано "150-стр.3изд,доп.перераб инструкция по пользованию подстанциями типа ТП-13, М.Васильев москва 98"
...и так далее. А нужно искать нормально по автору, названию, числу страниц, городу и году издания. Никакими прямыми алгоритмами это не берётся: регулярки, поиск по ключевым словам, морфология, нечёткая логика — всё это либо даёт много ложноположительных результатов, либо (если подкрутить пороговые значения) вообще перестаёт искать.
И вот тут в какой-то момент мы решили попробовать запрашивать через API GPT. Нейросетке задаётся следующий промт:
"Есть следующая информация: «150-страничный роман джеклондон мартин иден». Если здесь есть то, что похоже на имя автора книги, напиши мне его, иначе ответь null". И, надо сказать, даже 3.5 справляется с этой работой очень хорошо. Получилось сравнительно без ошибок разметить около 80% данных (остальные с ошибками даже после нейросетки).
Но, важный нюанс. Сначала мы пытались поймать все данные одним запросом: "GPT, выведи мне JSON, в котором есть автор, название, число страниц...", но тесты показали, что значительно эффективнее будет отдельно спросить 5 раз про 5 разных типов данных. Да, это расходует больше токенов, но они и так сравнительно дёшевы.
Кстати, API у OpenAI безбожно глючит даже на платном тарифе. Обещанных 3500 запросов в минуту нет даже приблизительно. По факту удаётся отправлять около 200-300 запросов в минуту, потом оно вываливается в таймауты или ошибку 429, нужно делать какие-то умные паузы, ждать итд. Над этим всем пришлось повозиться, зато результат вполне ощутимый.
#dev
Целых две недели ничего не писал, потому что была большая загрузка по работе. Только недавно вернулся с AtomSkills этого года.
Про чемпионат для профессионалов AtomSkills я вам уже рассказывал год назад. Тогда мы выиграли золото, поэтому поехать участником я не мог по правилам, так что поехал членом жюри. Было классно посмотреть изнанку.
В нашу задачу входила разработка задания, определение критериев проверки, составление сценария проверки и, собственно, сама проверка с выставлением баллов. Напомню, что на обычном хакатоне можно сделать неработоспособный продукт на моках и выиграть одной презентацией с хорошими скринами. А вот на AtomSkills есть строгие критерии проверки: работу каждой команды деплоят с нуля на чистую машину и вручную прогоняют по сценариям, давая баллы за то, что программа позволяет реализовать нужные бизнес-процессы.
Разработка способа справедливо и быстро оценить довольно разные работы — не самое простое дело. Да еще и в этом году были рекордные 12 команд. Сразу стали видны ошибки, которые мы, например, допустили при формировании задания; сразу понадобилась способность быстро договориться и выработать какой-то общий подход к спорным моментам. В общем, как и в любом деле, тут нужен опыт. Но было интересно, чемпионат раскрылся для меня с несколько новой стороны.
Ещё не мог не обратить внимание на то, как быстро команда жюри нашла контакт друг с другом, и как согласовано работала. Да и вообще, от общения с ребятами получил много удовольствия: и на уровне деловых взаимоотношений, и на уровне шуток и приколов, и на уровне гиковых бесед — было прям очень круто. Подумал о том, что это связано с совпадением людей сразу в нескольких аспектах. Во-первых, все айтишники, и это уже какая-то первичная выборка, показывающая общие интересы. Во-вторых, все работают в похожем режиме: на постоянке в корпорации, имея сотрудников в подчинении и так далее. Потому что, например, айтишник без работы по графику уже не во всём поймёт айтишника работающего, я был в обеих ролях и знаю, о чём говорю. В-третьих, что тоже немаловажно, в жюри никого не заставляют ехать, туда попадают люди, которым интересен чемпионат, интересна организация какой-то движухи, интересно помогать коллегам в развитии и совершенствовании. Тоже нужно обладать определёнными жизненными целями и ориентирами.
Посмотрим, удастся ли поехать через год, и в какой роли.
#dev
Stackoverflow подвёл итоги ежегодного голосования разработчиков. По общим показателям ничего шибко интересного (разве что зарплата разработчиков на C# наконец-то превысила зарплату джавистов).
А вот что любопытно, это новый вид графика оценки разработчиками языков и технологий. Раньше были блоки "любимые языки/технологии", "ненавистные языки/технологии". А теперь это шкала Admired & Desired.
Синие точки: уровень "хайпа" (этот термин используют прямо авторы исследования) — процент разработчиков, которые хотят попробовать язык или технологию X, потому что, например, считают его интересным, популярным, востребованным и так далее. Красные точки: "почитаемость" — процент разработчиков из тех, кто попробовал X, которые хотят продолжать это делать.
Таким образом, авторы исследования предлагают смотреть на ширину линии. Чем более узкая линия, по версии авторов, тем больше работы по популяризации технологии выполняет хайп, а не качество/крутость/интересность самой технологии. Хайп — синяя точка — создаёт инерцию, а красная показывает степень её роста или угасания уже после использования.
Ну вот например JavaScript и Python явно перехайплены. Мой любимый C# оставляет у народа приятные впечатления, но видно влияние того, что до сих пор есть люди, которые считают его закрытым языком для разработки под Windows. Java явно теряет позиции, скорее всего из-за того, что джависты распробовали более комфортный Kotlin. Прочие языки-заменители для неудобных аналогов тоже в хорошем положении: Dart, Swift. Ожидаемо широкие линии у функциональных языков: Elixir, Clojure, F#, Scala. Если программист всё-таки дорвался до функциональщины, говорят, пути назад нет. Хотя есть на графике и показатели, которые я объяснить не могу: например, почему широкая линия у Delphi. Ну и MATLAB опустили незаслуженно. Уж точно он не такой ужасный, как какой-нибудь Objective-C.
Там по ссылке дальше есть такой же график про базы данных и фреймворки. В целом очень согласуется с моими личными представлениями. Допустим, React и Nodejs перехайплены, у Svelte, ASPNET Core и Blazor одни из самых широких линий, а у jQuery — узкая.
#dev
Осенью с коллегой выступаем на DotNext. В прошлом году впервые побывал на такой мощной айтишной конфе, как участник, а вот теперь ещё и как спикер поеду.
Пройдёт в Москве 15-16 сентября. Рассказывать будем про применение DDD на практике — тема для замороченной энтерпрайз-разработки в больших корпорациях.
Вряд ли многие из вас ходят на дорогие айти конференции, даже онлайн. Но если кто-то будет — заходите к нам на доклад, задавайте вопросы.
https://dotnext.ru/
#dev
В Москве 3 июня пройдет VK Open — конференция открытых платформ. В данном случае под открытыми платформами подразумевается стек площадок для приложений и игр от самих VK и, возможно, ещё каких-то. Участие бесплатное, есть вариант онлайн.
Можно как угодно относиться к VK, но организовывать мероприятия они умеют. И хакатоны и митапы у них были, на моей памяти, всегда одни из лучших, а я много где побывал.
Но на самом деле этот пост — реклама — потому что там буду и я в сессии вопросов-ответов, рассказывать о своём опыте конкурсной разработки. Приходите, увидимся :)
#dev
Написал новую статью на Хабр. Она одновременно с сетованием на то, что разработчики упускают интересные возможности, и с рассказом о каких-то нюансах на основе моего многолетнего конкурсного опыта.
#dev
https://habr.com/ru/articles/729998/
В 1996 году шведский программист Даниэль Стенберг опубликовал первую версию консольной программы для работы с удалёнными ресурсами (URL). Точнее, технически это была не первая версия, но первая под новым названием — cURL.
Тогда, наверное, мало кто мог подумать, что обращаться по URL-адресам, отправлять запросы и скачивать файлы станет настолько востребованным. Сегодня cURL (если точнее, то libcurl) присутствует фактически на любом устройстве, подключённом к интернету, а неделю назад Стенберг отпраздновал 25-летие своего проекта.
На Хабре очень интересный перевод авторского пересказа событий за все эти годы. Даниэлю было 27 лет, когда он написал простенькую консольную утилиту, которой пользовался едва ли десяток людей. А сейчас ему 52, в программе уже 155 тысяч строк кода, а пользуются ей миллиарды (хоть даже и не знают об этом). За это время он женился, сменил кучу работ, завёл двоих детей, заслужил титул второго лучшего разработчика Швеции и даже косвенно поучаствовал в посадке зонда на Марс (о чём в его профиле на Гитхабе есть специальная плашка). Стенберг даже получал угрозы убийством из-за того, что его софт применялся хакерами в атаках и краже денег.
Вот как вышло — шалость, можно сказать, удалась. Простенький хобби-проект молодого студента стал одним из столпов, на которых зиждется информационная эра. Не сказать, что в cURL есть что-то особенное, просто так вышло, что именно его автор первым задумался о необходимости удобной коммуникации с серверами в сети. Не написал бы он, написал бы кто-нибудь другой. Что не умаляет его заслуг и аккуратного подхода к разработке и улучшению программы на протяжении стольких лет.
Кто знает, может быть, кто-нибудь из вас сейчас сидит и пишет маленький хобби-проект, которым через четверть века станет пользоваться весь мир?
#dev
Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области.
Когда-то давно я писал на ActionScript. Там была система типов, но вот десериализация JSON'ов по-умолчанию была в какой-то общий Object, к полям которого нужно было обращаться ["по_строковому_имени"]. В один момент мне потребовалось написать что-то на C#, который я совсем не знал, я стал гуглить, как десериализовать JSON, и с удивлением обнаружил кучу советов заранее объявить класс со всеми нужными полями и десериализовать в него.
"Какой ужас!", — подумал я тогда, — "Это же дико неудобно! А если я не знаю полей JSON? А если их много? Отвратительный язык!"
Теперь то я прекрасно понимаю, что JSON это контракт, и что правильная десериализация только такая и должна быть, и что в хорошем API в одном поле никогда не бывает данных принципиально разных типов, и так далее.
Нет, если вы набиваете вечерами пет-проект или сидите бессонную ночь на хакатоне, нет ничего плохого в том, чтобы взять простой язык с динамическими типами вроде JavaScript или Python, не требующий описывать данные. Но вот в энтерпрайзе, особенно когда над одним проектом работает много людей (а бывает это очень часто) — хорошее использование системы типов убережёт разработчиков от огромного количества ошибок, будет бить их по рукам, когда они пытаются сделать что-то не то, и будет подсказывать, когда они не уверены в чём-то.
С помощью статической типизации можно на уровне кода обозначить правила, по которым ведёт себя предметная область вашей программы в реальном мире. Разработчику не только будет сложно их нарушить, но он ещё и станет узнавать какие-то вещи, которые мог не знать раньше.
Например, если мы делаем медицинскую CRM, и больница заводит новых пациентов только тогда, когда знает их группу крови, мы можем объявить тип "Пациент" (или, если точнее, "Карта пациента") и запретить создавать экземпляры этого типа, не передав в конструктор группу крови (которая, в свою очередь, тоже является типом, вероятнее всего ValueObject'ом). Если новый программист пришёл в проект, он, во-первых, не сможет записать в БД некорректную карту пациента. Понятно, мы не учитываем случаи, когда новый программист переделывает модели предметной области — это будет хорошо видно на кодревью. А, во-вторых, даже если ему никто не сказал, что пациенты должны быть с группой крови, он узнает это из кода. И уже будет понимать, что в тех процессах реальной жизни, которые он описывает кодом, карта пациента создаётся только при наличии группы крови. А, значит, нужно искать какой-то способ сначала эту группу крови получить, и только потом создавать карту. Программирование моделирует реальный процесс.
В настоящей работе даже на языках с типами, конечно, без должного контроля можно написать что угодно. Нужна управленческая воля, компетентность руководства, понимание опасности техдолга, в идеале отдельные должности для архитекторов, опытные лиды и старшие разработчики. Но когда всё это есть, можно отсекать много проблем ещё на старте и проще погружать новичков.
#dev
Осознал, что синтаксис и устройство языка программирования могут добавлять информационный слой к обычному разговорному языку, на основе которого сделан этот язык программирования.
Например в C# можно вызвать list.Count, а можно list.Count(). Первое это свойство, оно хранится непосредственно в объекте списка и просто читается из памяти. Поэтому слово Count в данном случае — существительное. Второе — со скобками — это метод расширения для всех объектов, реализующих перечисление (IEnumerable), к которым относится и список. Вызов метода — это не чтение свойства, это указание компьютеру выполнить какую-то операцию или последовательность операций (и при этом иногда вернуть результат, иногда нет). Поэтому слово Count в данном случае — глагол. Хотя под капотом, если я правильно помню, когда метод Count() находит свойство Count или Length, он ничего не считает, а возвращает это свойство, но в общем случае всё равно его выполнение это последовательность каких-то операций. Да и в любом кастомном классе легко представить себе, допустим, свойство Fill, которое вернёт текущий цвет, и метод Fill(), который будет закрашивать новым цветом. В первом случае существительное, во втором глагол, хотя разница между ними только в скобках, которые имеют смысл только в контексте языка программирования.
#dev