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

Целых две недели ничего не писал, потому что была большая загрузка по работе. Только недавно вернулся с 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

Впервые сделал крупный проект (под NDA, так что не расскажу, какой) на облачных функциях. Впечатления противоречивые. Изначально программисты арендовали компьютер в датацентре: или целиком или кусочек. На нём теоретически можно делать что угодно, но для запуска своих программ нужно было настроить операционную систему, безопасность и авторизацию, установить нужные исполнительные модули, программы для удобства деплоя, мониторинг нагрузки итд. Поэтому появились сервисы, которые это всё делают за тебя, а тебе дают буквально окно, куда можно написать свой код и запускать его удалённо на чужой машине. Конкретно я пользовался решением от Яндекса, чей протокол скопирован напрямую с Amazon Web Services. Причём, в документации не только открыто об этом говорится, но ещё и в некоторых местах перенаправляют на доки от Amazon. И SDK предлагают тоже использовать амазоновский. До санкций я бы сказал, что это не так плохо — можно использовать что-то привычное тем, кто уже работал с Amazon. Но сейчас привязка к американскому сервису выглядит скорее жирным минусом. Не знаю, есть ли у Яндекса ресурсы на какое-то серьёзное разделение. Судя по состоянию документации и платформы в целом — нет. Yandex Cloud кажется системой, которая активно развивалась несколько лет назад, а сейчас подзаброшена. Среда выполнения .NET отстаёт от актуальной на две версии (3.1 вместо 6, четвёртой версии не существует). Изначально мой проект был написан как обычное контейнеризированное приложение на .NET 6, а потом я переводил его на функции. Пришлось пройтись по всему коду и переписать несовместимые куски с C#10 на C#8, это было не слишком приятно. Документации фактически нет, а там, где есть, много путаницы. В примерах написано одно, по факту другое: например в функцию вместо объекта Request приходит просто строка, а разбирать её надо самому. Авторизацию я нашёл только на Stackoverflow. Интересно, что адекватных доков про неё не было ни у Яндекса, ни у Amazon. Функция выполняется и выгружается, поэтому ваша программа не должна рассчитывать на наличие постоянно живущего процесса. Мне пришлось вытащить из неё большой словарь, который грузится при старте, и положить уже подготовленные данные из него в Object Storage — это такое горячее файловое хранилище, там же рядом с функциями. Справедливости ради, работает это всё быстрее, чем я думал. Удалось запихнуть в функции даже сравнительно большой проект с кучей классов, создающий при запуске несколько десятков объектов и производящий загрузку из сети с декомпрессией. Другой важный плюс — бесплатная квота довольно внушительная: миллион вызовов и 10Гб*часов оперативной памяти в месяц. Для пет проекта вы сможете вообще не покупать сервер. Но если сервер у вас всё-таки есть, деплой вы уже настроили, то удобнее будет, конечно, делать как привычно. И гибкости больше. #dev

Тут уже несколько дней народ играется с генерацией музыки по текстовому описанию. Идея такая же, как с картинками: ты пишешь фразу, тебе нейросетка по ней создаёт трек. На деле реализовано чуть более топорно: текстовый препроцессор разбирает фразу и ищет контекстную близость до слов из специального списка тегов. Ну, например, он считает слово "weed" (трава, конопля) близким к жанру "reggie", вот и подставляет. Эти теги передаются в облачный API сервиса Mubert (да, никакого опенсорса на этот раз), и оно выдаёт трек. Я попробовал тоже. По примерам из статей я уже было подумал, что окончательно решена проблема "не подобрать трек для нового видео". Но увы. Результат на деле (а не в рекламе) такой же не впечатляющий, как и с картинками. Эта штука сносно генерирует всякие эмбиенты и другие спокойные треки, но на более сложных жанрах сразу загибается и очень сильно недокручивает и темп, и агрессию и разнообразие музыкальных фраз. Я после часа попыток не смог сделать ничего для быстрого интенсивного полёта дрона, только для плавного и медленного. Ну и очень часто неправильно улавливает контекст, даже даже открыто писать, что примерно ты от неё хочешь (вот как с треком Помпеи — вообще мимо, слишком спокойная и не грустная мелодия). Первые два трека сгенерировал @wooferclaw. Он не хейтер ML, в отличие от меня, поэтому у него больше терпения и, вероятно, он смог дольше перебирать варианты. Но всё равно на мой взгляд какой-то намёк на правильную идею есть, а развития совсем нет. Музыканты, можете выдохнуть. #dev

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

Свершилось. Сегодня Экосистема городских сервисов совместно с VK Mini Apps подвели итоги конкурса, в котором я участвовал, и писал вам об этом. Мой музейный кликер оценили не только вы в комментариях, но и члены жюри: я занял первое место во втором этапе (по правилам можно занять призовое место только в одном, даже если подавался в два). Очень рад :) Люблю наш город, люблю конкурсы по программированию, ну и, разумеется, люблю выигрывать, чего греха таить :) Работы интересные, список всех победителей можно посмотреть вот тут. До шорт-листа дошли всего 42 проекта, так что на самом деле при внимательном и аккуратном отношении шансы попасть в список из 20 призёров были хорошие. Участвуйте в конкурсах тоже. Это полезно для прокачки скилла, даже если вы не получите приз. Но если получите — ещё и приятно :) P.S. Постоял рядом с CEO VK, думал попросить включить мне новый дизайн, но постеснялся. #dev