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

Почему я люблю языки с сильной системой типов, проверяемой статическим анализом кода — хорошо написанная программа является своей собственной спецификацией и позволяет выражать через язык программирования законы существования предметной области. Когда-то давно я писал на 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

Я порешал немного задачи на leetcode и остался не слишком доволен сервисом. Leetcode — это онлайн-сайт с задачами по программированию. Даётся описание (какие данные приходят на вход, и что нужно получить). Можно отправить код на любом актуальном языке программирования, и ваше решение будет оценено по двум показателям: скорость и память. Что не понравилось в сервисе: 1. Встроенный редактор кода поленились делать нормальным, это по сути блокнот без каких-либо хинтов и проверок. Проще сразу писать в IDE, а потом копировать. Но это мелочь, куда серьёзнее второй пункт. 2. Система оценки, о которой я упомянул выше, крайне неточная. Разброс по времени бывает в 1.5-2 раза у одного и того же кода. И, наоборот, почти не показывает важную разницу между разными решениями. По памяти то же самое: цифры плюс минус одинаковые, как бы вы ни решали задачу. Это выражается в том, что легко словить результат типа "Ваше решение лучше, чем 33.33% остальных", причем, много раз подряд. Это значит, что в точности треть решений попадает в какой-то один кластер оценки (либо что решений отправлено очень мало, но сайт популярный, так что не знаю даже). При этом подобная оценка — единственный показатель успешности вашего решения, поэтому она важна, но при таком разбросе теряет смысл. Хотя сама идея, например, ежедневной новой задачи мне нравится — позволяет разминать мозги и держать себя в тонусе в некотором смысле. Впрочем, тут тоже есть нюанс: эффективное решение задач редко пересекается с правильным и реалистичным решением, которое требовалось бы от программиста в любом практическом сценарии. Допустим, вам нужно наполнить ведро водой. В обычной жизни вы отнесёте его в ванну, откроете кран и наполните. А вот подход на Leetcode заставляет использовать извращения типа "вытащить из холодильника бутылку воды и разрезать её над ведром". И вот в какой-то момент вы понимаете, что быстрее всего выбросить ведро в окно, потому что под окном глубокая лужа, оно там утонет и технически станет наполненным водой мгновенно. О реальной жизненной применимости такого решения, думаю, говорить не стоит. Но иногда буду решать. Сегодняшняя задача уровня Hard, такие дают за собеседованиях на middle и senior: поиск максимальной суммы прямоугольника внутри матрицы. #dev

Один из легальных способов для программистов бороться с жадностью корпораций — писать open source аналоги проприетарного софта. Да, к сожалению, мы всё ещё вынуждены покупать (или незаконно качать) Photoshop, After Effects, AutoCAD и даже Microsoft Office, до которых свободные аналоги пока не дотягивают. Но тот же Blender очень сильно подвинул баланс сил на рынке 3D-моделирования. Да, возможно те, кто когда-то учился на 3D Max, Cinema 4D или Maya, скорее всего, всё ещё на них остались, но вот новое поколение 3D-художников очень активно учится на Blender и делает в нём шедевральные вещи, абсолютно ничем не уступающие коммерческим гигантам. В близкой мне области тоже есть свежий пример: для экшен-камер GoPro долгое время единственным хорошим решением был платный и дорогой стабилизатор под названием ReelSteady. За софтину просят что-то около $200 единоразово, но только она могла дать стабилизацию на основе гироскопа, которая на три головы превосходила любые алгоритмы на основе анализа картинки. Однако, несколько лет назад вышел кривой и неудобный open source проект, а буквально в этом году, если я не ошибаюсь, другой разработчик допилил его до прямого и удобного. Называется GyroFlow: кроссплатформенный софт с открытым кодом, который тоже умеет стабилизировать картинку на основе гиро-данных, причём, с кучи разных камер, включая все современные модели GoPro. Он абсолютно бесплатный, выдаёт результат ничуть не хуже, чем ReelSteady, да ещё и работает быстрее и содержит больше настроек. Просто flawless victory, как по мне. Надеюсь, такого будет появляться всё больше. В конце-концов, комьюнити уже прогибает корпорации на выпуск вещей вроде VS Code. #dev

Написал большущую статью о том, как проходил AtomSkills. Это был очень интересный и необычный опыт, даже с учётом моих предыдущих поездок на хакатоны. Если вам интересна разработка и соревнования по программированию, велкам :) #dev https://vk.com/@denisnp-kak-my-vyigrali-sorevnovanie-dlya-stroitelei-i-svarschikov?v=4