查找相似内容

Два года назад я писал, что поучаствовал в грантовой системе от Фонда Содействия Инновациям и получил 500к рублей на разработку нескольких NLP-алгоритмов для русского языка. Кратко: если у вас есть проект, который по каким-то признакам является научно-исследовательской работой, вы можете получить на него чуть-чуть денег просто так, в обмен на нужные бумажки. Схема рабочая и без обмана, но дьявол в деталях, сейчас расскажу. Вчера я закрыл всю отчётность, окончательно выполнив свои обязательства. Деньги получил гораздо раньше, и уже давно все потратил. В комментариях мне тогда говорили, что государственный фонд может бесконечно долго давить непонятной бюрократией, и потом трижды пожалеешь, что взял деньги. Это и верно, и нет. Скажем так: у меня были отдельные моменты, когда я задумывался, что лучше бы не стал в это вписываться. Но ретроспективно думаю вот что: в тот момент деньги были нужны, и, пожалуй, на этот риск идти стоило. А если вы начинающий специалист или вовсе студент, то вдвойне оправдано. В целом претензии у меня три: 1. Реальный результат работы никого не интересует. Отчётность важнее, чем то, делали ли вы проект, и есть ли у вас какое-то достижение. Я алгоритмы написал, как обещал, но, судя по всему, никто не смотрел ни код, ни репозитории, ни готовые проекты на базе этих алгоритмов. Абсолютно все замечания были по оформлению. Я должен был сдать последний этап 23 января, я сдал собственно саму работу, и вот всё это время до конца марта я закрывал документы. Настоящая значимость этих документов в десятки раз ниже, чем значимость проекта, но для завершения процесса нужны именно отчёты, а то, что вовремя проделана огромная работа и получен реальный результат, никого особо не волновало. Думаю, если бы я не писал алгоритмы, а составил только отчёт, это прокатило бы. 2. Отчётов нужна тьма, все они до боли бюрократичны и канцеляричны. Формы заполнения стандартизированы, и это полнейший ад. Дело даже не в объёме информации, хотя это тоже беда. Просто часть полей не подходят для конкретных случаев (например, нужно указать материал, из которого сделан продукт, а у меня компьютерная программа), а другая часть полей — бессмысленная абстракция, которая непонятно каким образом родилась в голове составителей. Что-то вроде: "Аргументируйте выбор способа решения задачи", "Аргументируйте выбор пути решения задачи", "Аргументируйте выбор метода решения задачи" — это три разных поля, и заполнять их нужно разными данными! 3. И самая жуть — по необъяснимой причине ваша научная работа на бумаге должна трансформироваться в приносящий деньги бизнес. По завершении работы вы должны пройти аккредитованный "преакселератор" и составить "бизнес-модель". Это шаблонный многостраничный документ, который вы заполняете заумно звучащей водой про анализ "рынка" и "конкурентные преимущества" по совершенно вымышленному продукту, который никогда не будет существовать, потому что в настоящем мире ни научные исследования, ни бизнес не работают таким чудовищно наивным и поверхностным образом. Отдельная часть этого документа — эксель таблица с частично заблокированными ячейками, куда вам нужно вбить цифры из воздуха так, чтобы показать "окупаемость". Никого особо не волнует, что для "окупаемости" нужно платить программисту 25 тысяч в месяц, а в первый день выпуска продукта продать его сразу тысячами единиц. В общем, отчёты описывают несуществующий мир, рождённый фантазией людей, которые некомпетентны ни в науке, ни в бизнесе, но умеют и любят причинять боль бумагой и ручкой. Sticks and stones. Однако, если принять эти странные правила игры и согласиться прорываться через заросли, то вы получите деньги и мотивацию закончить какой-нибудь собственный проект. С помощью этого гранта я добил кучу кода, который и так собирался сделать, получил три успешные статьи на Хабре и попадание в Программу Поощрения Авторов, а также реализовал несколько платных заказов в том числе на основе сделанных наработок. Кстати, факт существования реальных продаж не играл абсолютно никакой роли при составлении доказательства, что моя разработка может приносить деньги :) #dev

Много лет назад я делал игру ВКонтакте про домики. Одно общее изометрическое поле, где у каждого свой участок, на котором можно строить дом, выбирать его размеры, материалы, форму окон и крыши. И обставлять мебелью. Поле было квадратным 100 на 100, соответственно у каждого квартала был номер по одной оси X от 0 до 99 и по другой Y от 0 до 99. По какой-то причине мне тогда нужно было сохранить это в одном числе как идентификатор квартала, и я подумал, что изобрёл гениальный способ: A = X*100 + Y. Извлечь обратно тоже было легко: поделить A на 100 и округлить вниз, это получался X. А потом Y = A - X*100. Например, квартал с координатами 13-29, собственно, так и записывался: 1329. Важно, что это математические операции, а не строковые. Они и сами по себе быстрее выполняются программой, и позволяют, например, удобно отсортировать участки. Я считал себя очень умным, не зная тогда, что по сути изобрёл системы исчисления, и вообще подобный подход очень банален и прост. Мы куда чаще видим это в битовых масках, потому что и сама задача для двузначных свойств возникает чаще, и компьютер существенно быстрее работает с битами, но от того, какая там база системы исчисления, математический смысл не меняется. Если тебе надо записать в одно число несколько свойств, каждое из которых может быть в N значениях, то в это число должно влезать N*N*N... сколько там у тебя этих свойств. Ты пишешь первое свойство n1, потом прибавляешь n2*N, потом n3*N*N и так далее. Величины существуют в разных разрядах N-ричной системы исчисления, поэтому не пересекаются, и их можно разделить. Игра, кстати, поначалу хорошо набирала пользователей, а потом перестала. Я думал, что она не интересная, и закрыл проект. А сильно позже уже выяснилось, что был баг в коде регистрации игрока, из-за чего новые приходить не смогли начиная с какого-то момента. В том самом коде, который извлекал координаты квартала из его идентификатора, да. #dev

Позавчера начался крутой замес на GitHub, и вчера продолжался весь день. Есть такая очень популярная JS-библиотека Vue. Реально миллионы проектов в мире её юзают. У неё есть консольная утилита vue/cli, у которой несколько зависимостей. И автор одной из таких зависимостей встроил к себе в пакет код со скриншота. Там с помощью кодирования по принципу Base64 скрыто намерение проверить IP-адрес пользователя, и, если он из России или Беларуси, то стереть все файлы у него на компьютере, заменив их содержимое на символ ❤️. Такой вот протест. Сообщество довольно быстро это обнаружило. И — я редко видел такое единение душ — китайцы, американцы, турки, даже, кажется, один немец — куча иностранцев закидала этого разработчика ссаными тряпками (сам он из США). Все его попытки оправдаться заминусили, отправили жалобу в npm и оперативно удалили пакет, а самого автора обозначали не заслуживающим доверия. Вообще, open-source разработка это коммунизм. И люди, которые ей занимаются, нередко придерживаются космополитических и до некоторой степени анархических взглядов. Среди них есть противники государств в целом, как способа организации общества, и у них очень хорошие (хотя и несколько наивные) аргументы на этот счёт. Ну и они совершенно точно умеют отделять действия властей от действий и решений обычных граждан. А ещё разработчики в основном довольно умные люди, с логикой и критическим мышлением. Почему-то никто из американцев не испугался, что у репозитория ухудшится репутация за отказ саботировать русских. Даже наоборот: они резко критиковали деструктивные по отношению к обычным пользователям действия и заканселили чувака, который эти действия предпринял. То есть делали совершенно не то, что делают корпорации и крупные руководители в тех же странах. Представьте себе: обычные люди думают не так и хотят делать не то, что руководители. Кто бы мог подумать. #dev

Попробовали на работе предметно-ориентированное проектирование (Domain Driven Design). Это такой способ построения архитектуры, когда ты (чаще всего с помощью системы типов и ООП) описываешь физическую суть вещей, которые представлены в твоей программе. Например, если в программе есть объект "Книга", то её нужно снабдить свойствами, которые бывают у книг в реальности: число страниц, автор, язык, тип обложки и т.д. При этом данные свойства должны быть такими, чтобы присвоить им нереалистичные значения было нельзя. Допустим, число страниц не может быть отрицательным (и скорее всего в реальном мире не может быть нулём). При попытке установить отрицательное число страниц программа должна выбросить исключение. А совсем в идеальном случае -- не дать этого сделать программисту на уровне статического анализа кода. Описав все свойства книги, вы снабжаете её операциями, которые над ней можно сделать. Например, из книги можно вырвать страницу, и при этом число страниц уменьшается. Нет такого случая, когда можно вырвать страницу без изменения числа страниц. Вы строго программируете эту зависимость, делаете у книги метод "Вырвать страницу", а он уже уменьшает число. Кстати, свойство "Число страниц" при этом нельзя переназначить в уже созданной книге. Можно только создать книгу, передав в её конструктор (так называется в программировании функция создания объектов) заданное число страниц. Но поменять число страниц можно только специальными методами "Вырвать страницу" и "Вклеить страницу". С помощью этого подхода вы гарантируете, что ваши объекты всегда находятся в валидном состоянии -- то есть таком, которое возможно в реальной жизни с объектом, представленным программой. Плюсы подхода очевидны: меньше число ошибок. Код описывает сам себя, и программист, если не лезет внутрь объекта "Книга", вообще не сможет сделать с книгой ничего недопустимого. Минусы, думаю, тоже понятны: изначально проектировать сложнее, нужно учесть много нюансов, писать тесты. Время разработки изрядно растёт. Изменение требований даётся дороже: например, если каким-то образом в ваш книжный магазин поступят книги со страницами из кевлара, которые невозможно вырвать :) Но первый проект с этим подходом мы сдали хорошо, без багов. Лучше, чем многие предыдущие. #dev

Лигатура — это символ в типографике, образованный слиянием двух (или более) других символов. Например, в скандинавских языках есть символ Æ — он хранится и печатается как один символ, неразрывно, но, очевидно, образован совмещением букв A и E. В программировании тоже есть лигатуры. Если у вас мощная среда разработки и подходящий шрифт, то вы, как правило, можете их включить. И тогда ваш текстовый редактор будет отображать некоторые парные и тройные символы, как один. Например, последовательность -> может превратиться в символ →. Это нужно только для отображения, на содержимое настоящего текстового файла настройка никак не влияет, потому что компилятор или интерпретатор языка ждёт именно ->. Я категорический сторонник использования лигатур в IDE. Если вы никогда не пробовали, рекомендую включить и поработать с ними несколько дней, а может даже недель. Посмотрите на две конструкции ниже. Символы => и <= очень похожи между собой визуально, но при этом их суть принципиально разная. Включение лигатур позволяет отразить эту суть и избежать некоторых возможных ошибок (например, путаницу между >= и =>). #dev

Сопоставление с образцом (pattern matching) — сильный механизм языков программирования, который, к сожалению, встречается не так часто. Причём, как в коде разработчиков, так и в поддержке со стороны самого языка. Разработчики на функциональных языках используют этот механизм довольно часто, потому что у них вообще многое определяется статически через правильный подход к системе типов. Разработчики же на императивных языках очень любят огромные многоуровневые ветвления. Есть даже такое понятие «Спагетти-код» — раньше его применяли к коду, перегруженному операторами перехода, но в современном виде это скорее об избытке операторов условия. Pattern matching позволяет накладывать на объекты некоторый трафарет и смотреть, попадают ли они под него. Это не только выглядит лаконичнее и короче, чем дерево условий, но ещё и понятнее с точки зрения восприятия человеком: вот у нас заказ содержит более 10 элементов и при этом стоит более 1000 долларов, значит делаем на него скидку 10 центов. При этом трафарет работает как сортировщик монеток: самая маленькая проваливается в первый паз, следующая по размеру в следующий итд, применение условий идёт сверху вниз. Есть и неявный плюс: такой подход автоматически провоцирует разработчиков проводить проверку на null. Ведь null не может подходить под трафарет «содержит более 10 товаров». К счастью, в C# этот механизм в последних версиях активно развивают и совершенствуют. И это одно из многочисленных преимуществ C# над Java. #dev

Допустим, вы разработчик, и вам от пользователя приходит строка user-agent с описанием того, каким браузером он пользуется. В этой строке будет что-то типа такого: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 И вы хотите из неё узнать мажорную версию Chrome, то есть вытащить число 51. Что вы сделаете? Можно, конечно, написать свой парсер, но я уверен, многие воспользуются регулярными выражениями. Я бы воспользовался. Какое выражение сюда подходит? С виду кажется, что вот такое: /Chrome\/(\d\d)\./g Мы ищем слово Chrome и слэш, затем ловим в группу две цифры, после которых стоит точка. Так? По крайней мере, мышление достаточного количества разработчиков именно таково. Зачастую программистам не хватает умения отойти от техзадания на уровень вещественной сути того, с чем они работают. На самом деле число 51 это версия. Версия будет увеличиваться со временем. «Марти, где твоё четырёхмерное воображение?» Если уже прошло 50 версий, то и следующие 50 не за горами, число станет трёхзначным, регулярка или парсер, сделанные под двухзначные числа, перестанут работать. Трехзначная версия Chrome и Firefox приближается уже сейчас. И да, в них падает куча функций на сайтах, включая крупные корпорации: Yahoo, Bethesda, HBO и бог знает сколько сайтов поменьше. Чисто из-за цифры. Это уже назвали «Проблема сотой версии» по аналогии с «Проблемой 2000 года» (программисты записывали год двумя цифрами, 2000 стал неотличим от 1900). К чему это я? Полезно задумываться о физическом воплощении того, что вы представляете в своей программе. Ваш код должен описывать не столько требования заказчика, сколько законы, по которым существует этот объект в реальном мире. #dev

Увидел тут проект Doka Guide. Это такой ресурс, на котором авторы пытаются писать техническую документацию простым языком. В целом, идея не нова: "Объяснять что-то энциклопедичное человеческим языком, будто рассказываешь другу, а не читаешь лекцию". Это ещё Лурк использует — там многие вещи вполне себе содержат настоящие знания, но простыми словами. Пока есть вопросы к реализации, конечно. Например, я увидел в статье опечатку, но к системе не подключён никакой модуль исправлений (как на новостных сайтах — жмёшь Ctrl+Enter и отправляешь сразу ошибку редактору). То есть мне надо искать эту статью в репозитории, делать форк, оформлять пулреквест... Лениво. Структура местами странная. Статья о трёхслойной архитектуре в блоке JavaScript, хотя эта концепция не только не связана конкретно с JS, но он ещё и один из наименее удачных примеров её применения. Потому что вообще такие архитектурные паттерны для сложных энтерпрайз-разработок, как правило с сильной статической системой типов на каком-нибудь Java или C#. Осталось стойкое ощущение, что авторы знают только JS и фронтенд. Впрочем, я всё равно не понимаю, как с развитием проекта в одну кучу свалят документацию по всем популярным языкам. Тем не менее, инициатива отличная, и я желаю проекту хорошего будущего. Для начинающих фронтендеров там уже есть много ценного. Буду посматривать иногда, что там происходит. #dev

Какой язык программирования учить? У меня есть ответ. Каждый год один из крупнейших в мире порталов для разработчиков StackOverflow проводит опрос своих пользователей. В этом году его ещё не было, но я решил взять из результатов 2021 года два графика и объединить их. На графике расположены языки программирования в следующих координатах: - По горизонтали "Приятность". Мера того, как разработчики отзываются о своих чувствах по отношению к языку, сколько удовольствия он им доставляет, насколько им приятно на нём писать. Эта шкала в процентах, и опрос составлен так, что значение ниже 50% следует понимать как "язык скорее неприятный, чем приятный". - По вертикали "Популярность". Буквально, людей спрашивали, с какими технологиями они по факту работают в своих проектах. Чем больше голосов — тем чаще язык встречается. Здесь я провёл черту по матожиданию всей выборки, которое равно около 14%. Использовать в данном случае медиану мне кажется неправильным, потому что она сильно зависит от того, попал ли какой-то язык в опрос или нет. А очень много языков не попало. В целом субъективно я бы описал квадранты этого графика так: 1. Справа вверху популярные и приятные языки — можно смело брать и учить любой, и вообще они вверху списка на рассмотрение. Но следует понимать, что и другие люди могут хотеть в первую очередь выучить именно их, так что конкуренция на рынке труда будет высокой. 2. Слева вверху популярные, но менее приятные языки — в основном это устаревшие технологии, на которых очень много легаси. На мой взгляд, это надёжный вариант, чтобы найти высокооплачиваемую работу. Рынок не скоро сможет отказаться от них, а поддерживать кому-то надо. 3. Справа внизу приятные но менее популярные языки. Кажется, логично взять какой-то из них в качестве второго языка, на котором вы будете делать пет-проекты для личного удовольствия и саморазвития. Кстати, все функциональные языки попали сюда. И некоторые языки оттуда будут уходить наверх: например Go и Kotlin уже вырвались. Уверен, опрос текущего года покажет их подъём. 4. Ну и слева внизу Бездна Боли. У которой есть неожиданное дно: если язык не очень популярен, и люди его не любят, то вы, как специалист, будете чудовищно ценным в тех немногих местах, где язык всё-таки используют. Говорят, разработчики на COBOL получают фантастические деньги даже по меркам IT. Оба ещё живых разработчика на COBOL, да. Следует внести одну поправку: на графике отсутствует такой параметр, как "сложность". Она тоже, безусловно, влияет на выбор. Что более важно — она влияет и на положение языка по другим параметрам. Так, например, люди, которые попробовали относительно простые JavaScript и Python, могут на этом остановиться и не браться ни за какие другие языки. И такие люди будут отмечать JavaScript и Python как приятные, приносящие удовольствие. Я тоже когда-то любил JS. И даже любил PHP. Пока не попробовал Java. Потом я какое-то время был в восторге от неё, пока не попробовал C#, и сейчас считаю его лучшим языком. Вполне возможно, что через 5 лет я буду писать на Clojure и не понимать, как я мог так восторгаться ужасным C#. #dev

В этот романтический день поговорим о поэзии. Мне всегда нравилась теория стихосложения. Она приближала непонятный мне мир литературы к понятному мне миру математики. Эта любовь получила развитие и в программировании. Опубликовал вот статью об алгоритме вычисления силлабо-тонического стихотворного размера по строчке на русском языке. Задача интересная и не такая простая, как может показаться на первый взгляд. #dev https://habr.com/ru/post/651395/

Традиционно программисты считают, что энтерпрайз разработка это переусложнённая и бюрократизированная вещь, где вместо интересных задач на алгоритмы люди просто перекладывают JSON'ы избыточным способом. В этом мнении есть доля истины, но я уже третий год работаю в энтерпрайзе, а до этого как раз занимался всякими стартап-стайл «интересными» алгоритмами. И хочу со своей стороны защитить энтерпрайз. Основная фишка в том, что одну программу разрабатывают много людей. И часть этих людей друг друга никогда не увидят. Поэтому обычно задача сделать работающий код дополняется двумя пунктами: 1. Другой человек, который первый раз видит ваш код, должен как можно быстрее понять, что этот код делает. 2. Другой человек, который будет дописывать ваш код, должен иметь как можно меньше шансов допустить ошибку и всё сломать. Окей, в реальной жизни есть ещё и третий пункт: 3. Вы ограничены в выборе инструментов и подходов к разработке, потому что легаси / корпоративная архитектура / секретность / отсутствие нужной лицензии / приказ начальства и так далее, нужное подчеркнуть. И это напоминает челленджи, которые геймеры себе придумывают для усложнения и повышения интереса. Пройти игру с одним пистолетом? Протащить через все уровни фигурку садового гнома из первой главы? Ни разу не получить ни одного повреждения? При этом вы ещё и в момент этого прохождения транслируете обучающий стрим, а другой игрок, загрузив ваши сейвы с любого места, должен быть способен пройти дальше, даже если он не про-геймер. Решать такие задачи на самом деле очень интересно. И отлично качает скилл в программировании, не хуже, чем эти ваши алгоритмы. Попробуй с первого раза сделай foolproof архитектуру, ещё и понятную. Есть о чём подумать. #dev

前段时间一直被MajdataPlay的外键输入问题困扰：有玩家反映majplay会无征兆地出现拖判和吃音，但是内屏一切正常 因为我是第一次接触游戏开发，IO这方面也完全没经验 一开始我和bb本怀疑是线程调度的问题，即：IO线程时间片被其他线程挤占了，导致IO线程无法及时处理HID设备回报。为了验证这个猜想，我们尝试提高了IO线程的优先级，照旧 接下来我怀疑是我那套框架有问题：majplay是根据上一帧与这一帧的按键状态判断按键是不是"click"。为此我重写了这部分的实现，改进了IO线程与主线程之间的交互，问题照旧....... 到这里我已经怀疑这不是majplay的锅：IO线程没有任何异常，IO线程与主线程的交互没有问题，Note判定逻辑也没有问题，那就是设备确实没有回报给majplay或者设备发过来的回报中按键确实没有按下，但是大佬说hdd没有这种问题.....（人已经快崩溃了，这完全看不透也摸不着，因为我用单片机模拟玩家打高速纵连是完全没有问题的，我在家里用手台测试也没有问题） 到最后，bb本灵光一闪，说有没有可能是led刷新率过高，把按键控制板干爆炸了？我们让大佬把led刷新间隔从16ms改成100ms，吃音问题瞬间没有了，无语了 。。。。。。。。。。。。。。。。。。。。 adx是一个控制板同时管理按键和led，为什么我没有遇到吃音问题呢，因为我的手台不是adx的... #dev