查找相似内容

Написал новую статью на Хабр. Она одновременно с сетованием на то, что разработчики упускают интересные возможности, и с рассказом о каких-то нюансах на основе моего многолетнего конкурсного опыта. #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

Как вы уже знаете, я участвую в конкурсе "Код Петербурга", где нужно сделать какие-то программные продукты, используя API различных городских сервисов. KudaGo взяли у некоторых разработчиков интервью, попросив ответить на распространённые вопросы типа "Нужен ли айтишнику технический склад ума?" и "Правда ли, что айтишники — закрытые интроверты?". Я тоже поотвечал, и даже, пожалуй, слишком многословно на фоне других отвечающих. Вот, собственно, сама статья: https://kudago.com/all/news/top-glupyih-vopros-dlya/ #dev

Пришло уведомление от Whoosh: "Годовая подписка за 990р". Захожу в приложение, а там её нет. Стандартные недельная и месячная. Пишу в саппорт: так и так, прорекламировали — предоставляйте. Посоветовали обновить приложение — и правда, подписка появилась. Если бы я не поленился в саппорт написать, у них могло бы быть на одного платного клиента меньше. Это хорошая задачка на архитектуру и проектирование приложений: такие элементы нужно отрисовывать динамически по данным из БД. Создаётся абстрактный компонент, у которого есть свойства типа title, subtitle, caption, рисуются стили. При необходимости данные меняются на сервере, и все пользователи получают новый список. А тут, вероятно, захардкожено в клиенте. Нехорошо. #dev

Мой новый любимый тип задач на собеседованиях: даём кандидату кусок кода и просим провести ревью. Во-первых, это из тех задач, которые нельзя строго либо решить, либо не решить. Разные кандидаты находят разное количество ошибок, оценка получается более гибкой. Во-вторых, проверяется сразу несколько компетенций: и работа с базами данных, и многопоточность, и оптимизация, и кодстайл и куча всего ещё. Увидит ли кандидат ошибку в SQL? Сделает ли необязательное, но ценное замечание по именованию переменных? А может даже даст комментарий на тему архитектуры? Ещё и софтскиллы сразу проверяются: каким способом человек сообщает о чужих ошибках. Но нашу задачку я вам не покажу. Вдруг будете у нас собеседование проходить, хехе ) Ещё из недавнего: соискатель указал в резюме английский B2 и особо подчеркнул, что очень силён в алгоритмах. Я скинул ему скриншот ниже и попросил объяснить задание и поразмышлять над решением. К сожалению, и задание и решение в итоге объяснял я. Кстати, кто занимается разработкой, можете под спойлерами предложить свои варианты. Вообще, проведение собеседований помогает хорошо бороться с синдромом самозванца. У меня прям сильный был, пока я на постоянную работу не пошёл. Сейчас тоже есть (думаю, все разработчики этим страдают, кроме самых плохих: у них эффект Даннинга-Крюгера), но меньше. #dev

#dev https://substack.com/redirect/4af1baf3-a4d7-48d1-9592-5ea0971a056a?j=eyJ1IjoiNHowa3gifQ.QnwKDJ1CRSD1ToSPhPzIWMi45g-Rid7OgDj8cqSear0 Sounds good but please DO NOT USE upper cases. It is not only about PEP8 but more about consistency and cognitive load. We solve this problem by writing down the dimensions in the docstrings and also include the math expressions there. But it is already obvious that writing down the dimensions in the var names makes things much easier.