Большинству пользователей известно, почему возник Вомбат. На этом я не стану заострять внимание.
А хочу обратить внимание на сложность разработки подобных сайтов. Даже на уровне MVP (минимально жизнеспособный продукт).
Даже если есть готовые наработки, то в любом случае надо продумать: модель, то есть схему базы данных, дизайн веб-морды, общее взаимодействие, то есть бизнес-модель,...
Независимо от всего разрабатываю своего бобра (это скорее будет что-то вроде Хабра, а не очередной аналог Пикабу). И уже раз десять сносил БД из-за невозможности внести изменения (миграции). Ну, может я такой рукожоп и просто не знаю как правильно сделать. 🤷♂️
Нужно продумать внешний вид сайта. Тут сильно помогает такой инструмент как Figma. Да, дизайнеры Figm-ой занимаются. 🙃После пары настроек пользоваться одно удовольствие. Но мало задизайнить. Надо это ещё и в код перенести. А это уже вёрстка. Довольно нудное занятие.
В общем, чего хотел сказать, захотите сделать свой Пикабу с блекджеком и плюхами, то готовьтесь к тому, что заебётесь...
Театралам предлагаю флэшмоб. Если кто пойдет на спектакль с Безруковым, когда он выйдет на сцену заорать на весь зал: "Берем кредиты мы в совкомбанке!" Заебал уже!
Вся эта история с уголовкой за кальян из кулича - это какой-то концентрат ебанины, в котором сошлось вообще всё: и несовершенный закон, и религиозный популизм, и культура хайпа. И это ровно тот же механизм, который работает с блокировками РКН, с законом Яровой, с принудительным Махом: размытая норма, монополия на интерпретацию, отсутствие обратной связи - и на выходе произвольное наказание. Не нужен злой умысел, достаточно закона, который позволяет наказывать за чужую обиду, и системы, в которой никто не спрашивают - а соразмерно ли.
Давайте честно - девушка сделала это ради внимания. Ну а ради чего ещё? С обычным Нарезным никто бы ничего не выкладывал, потому что всем плевать на батон(глобально). Кулич выбран специально, в пасхальную неделю, с чётким расчётом на бурление в комментах. Мотивация прозрачная, тут даже спорить глупо. Но хайп ради хайпа - это не преступление, блядь. Интернет наполовину состоит из провокаций. Блогеры жрут кактусы, лижут унитазы в самолётах, творят такую дичь что глаза на лоб лезут - и ничего, живут себе спокойно. А тут девка воткнула трубку в сдобный хлеб - и ей светит реальный срок. Разница не в уровне тупости поступка. Она в том, что этот конкретный вид тупости задел группу людей, которую государство почему-то решило охранять отдельным пунктом уголовного кодекса.
Кулич - это не икона. Не мощи. Не литургический предмет типа просфоры (хлеб для причастия). Это сдобная выпечка, которая лежит в любой Пятёрочке на полке между батонами и рогаликами. Ни в один перечень предметов культа он не входит. Да, его освящают в церкви вместе с яйцами и прочей едой. Но освящение пищи - это благословение, а не превращение её в предмет культа. Освящённый кулич после этого спокойно режут ножом, едят с чаем, он черствеет, его выбрасывают или скармливают птицам. Никто не хранит его как святыню, никто не относится к нему как к сакральному объекту. Это праздничная еда, которую можно купить в любом супермаркете, и производят её на тех же заводах, что и обычный хлеб. Но статья 148 УК РФ - "оскорбление религиозных чувств верующих" - сформулирована настолько размыто, что под неё при желании можно подтянуть вообще что угодно. Достаточно найти людей, которые обиделись. А "оскорбление чувств" - это нихуя не юридическая категория, это чистая субъективщина. Один верующий глянет и махнёт рукой, другой побежит строчить заявление в полицию. И закон автоматически встаёт на сторону того, кто обиделся. Сам факт обиды - уже основание для уголовного дела.
А теперь давайте вспомним, что у нас написано в Конституции. Статья 14: "Российская Федерация - светское государство. Никакая религия не может устанавливаться в качестве государственной или обязательной." Статья 19: государство гарантирует равенство прав независимо от отношения к религии. Статья 29: каждому гарантируется свобода мысли и слова. Три статьи основного закона страны - и все три летят в пизду, когда дело касается чьих-то религиозных переживаний. Светское государство уголовно преследует гражданку за то, что она нехорошо обошлась с выпечкой. Потому что эта выпечка кому-то религиозно дорога.
Раз уж речь про чувства верующих - допустим, некоего христианина оскорбляет то, что представители другой конфессии совершают публичный намаз посреди городских улиц. Массовая молитва на проезжей части, парализованное движение, перекрытые дороги - и это происходит регулярно, открыто, демонстративно. В самом исламе публичный намаз в неположенном месте, создающий препятствия другим людям, считается неправильным поступком. Это фактически нарушает принцип светскости государства, создаёт реальные проблемы городской инфраструктуре и выглядит как провокация ничуть не меньше, чем трубка в куличе. Чувства этого христианина по 148-й тоже должны охраняться. Но почему-то за перекрытые улицы никто уголовных дел не заводит, никого не тащат в суд, и ни одного заявления рассмотрено не будет. Получается, закон защищает не "религиозные чувства верующих" вообще, а чувства строго определённых верующих в строго определённых ситуациях.
И тут вылезает ещё один момент, который все старательно не замечают. Закона об оскорблении чувств неверующих не существует. Атеистов, агностиков, просто людей которым до религии нет дела - их чувства государство не охраняет вообще никак. Я, например, агностик. Моя позиция - ничего не доказано в полной мере, ни существование бога, ни его отсутствие. И мои чувства по этому поводу не охраняются ничем. Если кто-то публично оскорбит мои убеждения - мне у кого защиты искать? Получается, одна группа граждан защищена больше другой просто потому, что назвала свои переживания "религиозными чувствами". Это прямой удар по принципу равенства перед законом, который прописан в той же самой Конституции. Основной закон говорит одно, а уголовный кодекс - ровно противоположное. "Это не баг - это фича."
Погоня за хайпом - да, реальная проблема, кто бы спорил. Люди ради лайков вытворяют всё более безумные вещи и вообще не включают мозги. Раньше пиздеца было не меньше, просто не было смартфонов и инстаграма - теперь у каждого дурака в кармане камера и выход на миллионную аудиторию. Но это проблема культуры, а не уголовного кодекса. Хочешь - считай её поступок тупым, безвкусным, провокационным. Хочешь - напиши ей в комменты что она дура. Отпишись. Осуди. Социальное порицание - нормальный, живой механизм, он работает. А когда за трубку в сдобе государство грозит годом тюрьмы - это уже не про мораль и не про защиту чьих-то ценностей.
Никто, блядь, не пострадал. Ни один верующий не получил ни царапины. Храм стоит на месте. Чужое имущество цело. Единственное что случилось - кто-то увидел фотку в интернете и решил что получил "колоссальные нравственные страдания". И государство в ответ говорит: ваша обида стоит года чужой свободы. Когда закон измеряет тяжесть преступления степенью чьей-то обидчивости...
У самого метро мне встречается замечательная пара: отец и сын.
Папа высокий. Среднего возраста. Вид предельно суровый: широкие плечи, квадратная нижняя челюсть, стрижка под ноль. Мрачный взгляд исподлобья. Треники с обвислыми коленками, кроссовки, рыжая куртка из кожзама. Подсознательно хочется обойти человека стороной.
Мальчику на вид лет 5.
-... Вадик, - на ходу терпеливо втолковывает папа сыну, - нельзя на всех подряд залупаться. С людьми надо быть дружелюбным...
Был у меня один шеф, всегда свежий Жып, нормальный такой дом, солидная строительная фирма, и яхта в Барселонском порту.
За всяческие успехи по работе просто выворачивал карман, и отдавал что с собой есть. Мне лично перепадало и 70 и 100 и 250 евро.
За косяки никто сильно не страдал, но ништяков лишался. Терпел даже тех кто напивался на работе, хз почему.
Я к нему в целом равнодушно относился, но были те кто уважал его пиздец.
Утром на разборе полётов ставится задача и всех развозят по объектам. В тот день поехали в парикмахерскую, провалилась канализация под ней, бизнес встал и нужно за один день всё исправить.
Траншея метров 8 в длину, метр шириной и два в глубину. На пятерых очень много работы, технику туда не загнать, роем вручную.
Шеф приехал перед обедом, стало ясно что пиздец близок.
Притащил коммерческого директора, архитектора и ещё парочку галстуков.
Как он бегал с мешками, толкал тачку с землёй быстрее всех и подбадривал нас как мог, бутеры из ближайшего бара и пиво, перекуры короткие.
Часов в 11 вечера поужинали в соседнем баре, каждому по сотке наличными, кто не уместился к транспорте что был в наличии домой отправил на такси. Плюс выходной на следующий день.
Сам он вышел из низов, как выяснилось, и как же я его зауважал за отношение к своему делу. Такой никогда не пропадёт. Честь ему и хвала.
Сегодня пришла девушка, с ней - ребенок, пацан лет 5.
У девушки проблема - некоторое время назад ей въехали в задницу (речь идет про ДТП), въехала другая девушка, договорились порешать без ГАИ, обменялись телефонами... на следующий день девушка позвонила по номеру... а такого абонента нету. Но машину-то нужно ремонтировать! И за свои деньги ремонтировать неохота...
Объясняю - тут делать что-то вообще бесполезно. ГАИ не вызывали, извещение о ДТП не составляли, кто в нее въехал - вообще не знает...
Пожалуйста, снимайте свои рюкзаки в общественном транспорте. Я бы ещё мог понять если маршрутка полупустая была, но утром, когда едешь на работу в забитой маршрутке/тралике - это полный пиздец. Ну подержите его в руках ну, никто ваш драгоценный портфель не спиздит. Заебало уже
Китайская компания Beijing Linyi Yunchuan Energy Technology не только придумали, спроектировали и сделали, но и испытали ветряк необычной конструкции:
Его величество S2000 (фото от Global Times)
Идея проста. Обычные наземные ветряки страдают от непостоянства (как по скорости, так и по направлению) ветров вблизи поверхности земли, а очень высокую мачту не сделать. При это на больших высотах ветра не только более постоянны по скорости и направлению, но и намного сильнее, что позволяет снять с них больше мощности.
Установка наполнена гелием, внутри этой конструкции 12 генераторов. Номинальная мощность - 3 МВт, что сравнимо с наземными, а вот размеры в длину 60 метров, ширину и высоту по 40 метров. Удержание, передача электроэнергии на землю и управление организовано по системе тросов. Ещё один из плюсов - мобильность и простота в обслуживании (просто его спускают на землю или корабль в море и творят что хотят). Для обычных ветряков работать приходится на высоте в сотни метров.
Красавец, не правда ли? (фоточка от People's Daily/X)
Форма аэростата чем-то напоминает турбовентиляторный двигатель самолёта. Естественно такое решение тщательно просчитывалось и задача ещё больше увеличить скорость воздушного потока на винты генераторов.
А теперь удивляйтесь - высота на которую он поднимается составляет 2 километра (что отражено в названии). Подъём на такую высоту занял всего полчаса. Во время тестового запуска в городе Ибине, провинция Сычуань, установка поставила в электросеть города 385 кВт*ч электроэнергии.
На данный момент контора уже начала мелкосерийное производство и подписала договора с несколькими прибрежными городами и высотными регионами.
Всем доброго времени! Наткнулся я не так давно на вот такое изображение:
И решил порассуждать не тему того, а плоха ли такая ситуация и как вообще бывает, как идет разработка backend и frontend в вещах которыми я занимался, возможно кому то будет интересно, а кому то захочется подискутировать со мной)
Во первых о понятиях, что такое "Бекенд" и "Фронтенд", я работал с разными разработчиками и даже студиями и понял что иногда эти понятия отличаются у разных людей (особенно когда речь идет о том как HR их понимает), по этому поясню что я в них вкладываю:
Frontend - "передний конец", это весь визуал который видит человек пользуясь программным обеспечением, а так же скрипты которые исполняются на стороне (на устройстве) пользователя.
на примере сайта, это его верстка, а так же javascript который перелистывает слайды, раскрывает выплывающие окна и т.д.
Backend - "задний конец", это всё что исполняется "под капотом" программы, в случае сайта это на сервере, в случае какой то настольной программы, внутрипрограмные механизмы, например обращающиеся к каким то функциям операционной системы и производя какие то расчеты и действия
на примере сайта, это его серверная часть, механизмы которые к примеру работают с базой данных, получают из неё пост для страницы на которой находится пользователь, и к примеру комментарии для этого поста и т.д.
А теперь как раз о том, что разрабатывается первее и почему.
Возьмём вебсайт, вы например хотите что бы вам сделали интернет магазин, обычно этапы разработки выглядят так:
- Создание и утверждение дизайна
- Верстка дизайна
- Подключение к верстке т.н. "Движка" или cms или "системы управления контентом", или же что очень редко и индивидуально, написания этой самой системы с нуля в порядке индивидуальной разработки и внедрения её в вёрстку.
т.е. по сути тут выходит что разработка Бекенда идёт после Фронтенда - и получается что как будто то что показано в меме это естественный ход событий и ни каких вопросов это не может вызывать?
Стоит сказать что последовательность работ которую я описал, это обычно усреденная разработка, где люди не сильно запаиваются составлением подробных ТЗ. По ней выходит то что когда готов дизайн, и на основе него вёрстка, это всё передается программисту работающему над Бэекендом, и он сразу видит, что и где ему нужно будет подключать и в каком виде: "Здесь у нас поиск, с возможностью сортировки и выбору диапазона дат постов", "Тут мы выводим чат, который обновляется каждые пару секунд" и т.д. Программист сразу визуально видит какие данные в какие элементы интерфейса ему нужно выводить, от чего ему более понятен план работ, по тому что он "визуален".
Но предположим что сроки разработки сжаты, и требуется что бы разработка обоих частей проходила одновременно, в таком случае необходимо очень точное техническое задание, где будет подробно прописано то как будет работать бэекенд, какова будет структура базы данных, какие данные при каких обстоятельствах будут из неё извлекаться, каким образом обрабатываться, в каком виде перезаписываться обратно и в какой части условного ещё не созданного даже в виде дизайна интерфейса отображаться.
Это довольно фантастический план, так как обычно не бывает заказчиков которые чётко знают как должен выглядеть их сервис\сайт\по и даже не всегда представляют себе точный его функционал.
Это всё зачастую формируется как раз во время разработки и утверждения дизайна, и по этому программист который с самого старта одновременно с дизайном начал разрабатывать свой бекенд, чаще всего обречен по ходу появления дизайна и вёрстки вносить коррективы в свою работу, а иногда даже переписывать её часть.
Но есть например аспекты которые можно на мой взгляд проработать и без дизайна, например структуру базы данных и её таблиц, создать какие то общие функции, провести базовую настройку движка или фреймфорка с которым будет работа.
Но всё же когда дизайн утверждён и верстка окончена и принята заказчиком, это уже гарантирует стабильность разработки. (при условии конечно если заказчику не взбредёт в голову что то на ходу изменять, но такие вещи должны быть учтены в договоре и проходить за дополнительную оплату)
Примерно то же самое происходит и при разработке приложения для телефона.
Программисту всегда проще подключать бекенд к чему то готовому, чем прорабатывать так называемые API (простым языком объясняя это точки доступа через которые интерфейс получает данные из бекенда) почти в слепую или по скупому ТЗ (я просто ещё не видел по настоящему подробных ТЗ за исключением тех которые в своей педантично душной манере составлял).
По этому становится очевидно что это вполне себе нормальная ситуация, когда Фронтенд давно готов, на него можно посмотреть, потыкать, а Бекенд ещё только подключается, а то ещё и вовсе в стадии разработки.
Но есть один сценарий когда бекенд идёт первее фронтенда - это когда разрабатывается какое то техническое программное обеспечение у которого изначально вовсе нет интерфейса, например какой нибудь локальный сервер - пишется собственно сама програмина, а её настройка и в целом взаимодействие с ней происходит через терминал\консоль\командную строку.
В данном случае интерфейс появляется уже после того как ПО было разработано, зачастую таким программным обеспечением можно пользоваться и без интерфейса через всё тот же терминал, отправляя команды которые ты вводишь в него вручную (прям как хакер из кинофильма), а графический интерфейс создаётся уже потом(иногда очень сильно потом) просто для удобства пользователя и отображает все стандартные и часто используемые опции (для более тонких настроек за частую используется всё равно командная строка) и по сути графический интерфейс, отправляет те же самые команды что вы бы вводили в терминал, просто делает это по нажатию на кнопочки.
На этом всё, надеюсь кому то было интересно почитать эти возможно сумбурные рассуждения, сейчас попробую выловить все грамматические ошибки в этом опусе, перед тем как нажать кнопку "опубликовать пост"😅
В первой главе мы с вами узнали, как и где создавались первые "шахматные автоматы", которые были всего лишь имитаторами программируемых шахматных роботов. Сегодня знакомство с первыми настоящими шахматными алгоритмами и программами.
*** Глава 2. Как роботы научились играть в шахматы ***
Чтение советской и американской прессы 70-х годов прошлого XX-го века оставляет приятное послевкусие.
Конечно, нельзя было говорить о дружбе между СССР и США, но отношения явно улучшились по сравнению с послевоенными годами.
В американской прессе мелькают сообщения о смягчении давления американской бюрократии на Коммунистическую партию США. В частности, в 1973 году федеральный окружной суд в Аризоне постановил, что большая часть закона против американских коммунистов неконституционна, и Аризона должна допустить КП США к участию в голосовании на всеобщих выборах ("Блавис против Болина").
В советской прессе насмешки над убогим мещанским западным (в основном американским) образом жизни продолжались (в духе Михаила Задорнова "ну, тупые"). Но при этом явно начала изменяться эмоциональная окраска этих насмешек. Злая язвительная сатира потихоньку менялась на добродушный юмор с весёлыми приколами.
Вот мы читаем сообщение о нищем, который обитает на богатой парижской помойке. Ничего особо интересного в этом факте нет. Не было никакого секрета в том, что на этом Западе нищих огромное количество, как блох на бродячей собаке. Но именно в этом нищем была интересная изюминка. На своём плакате, ниже стандартного объявления "подайте плиз, кто сколько может жертве холокоста, бюрократии и бездушия", нищий сделал странную и наглую приписку "доллары США не принимаю".
Не знаю, придумал журналист эту хохму, или реально зафиксировал нечто подобное, но эта короткая заметка порождает у читателей множество мыслей, начиная от надежд, что долларовая долговая пирамида скоро рухнет до желания дать нищему полезный совет: "бери, дурачок, что дают, потом ненужное выбросишь".
Учёные экономисты по обе стороны океана начинают осторожно высказывать идеи о возможности "конвергенции" капитализма и социализма. При этом, в США должны усилиться социальные гарантии для трудящихся, а в СССР для "деловых людей" должны быть предоставлены возможности для полезных экономических частных инициатив (типа строительства личных дач и не только).
Самое главное, что в такой атмосфере о прямом военном конфликте не могло быть и речи. Решались вопросы о возможностях сотрудничества в разных областях.
В 1972 году в Москве председатель Совета министров СССР Алексей Косыгин и президент США Ричард Никсон подписывают "Соглашение о сотрудничестве в исследовании и использовании космического пространства в мирных целях". В 1975 году в рамках этого соглашения был реализован совместный полёт советского и американского пилотируемых космических кораблей со стыковкой на орбите (знаменитый проект "Союз - Аполлон").
Вот в таких условиях мирной конкуренции и делового сотрудничества СССР и США с явным желанием обеих сторон уйти от прямых военных столкновений в 1974 году состоялось грандиозное событие для всех любителей шахмат и прикладного программирования: первый в мире чемпионат мира среди шахматных программ.
Состоялось это мероприятие в Стокгольме во время конгресса ИФИП (IFIP, International Federation for Information Processing).
Лидерами в области шахматного программирования были американцы. В США было 50 действующих шахматных программ, во всем остальном мире (Европа + СССР) около 20. Также в США уже был богатый опыт проведения внутренних чемпионатов. Последний чемпионат США стал отборочным к первому чемпионату мира. Лучшими оказались программы: "Чесс-4.0", "Теч-2", "Хаос" и "Острич". Они и представляли США на этом турнире.
Что же касается нашей страны, то у нас в боевом режиме была единственная программа "Каисса" и ещё несколько программ в стадиях подготовки и перспективной разработки. Именно "Каисса" и представляла СССР на этом турнире. По итогам турнира "Каисса" заняла первое место и завоевала золотую медаль весом 110 грамм.
После окончания турнира "Каисса" в виде бонусного трека сыграла дополнительную товарищескую партию с лучшей американской программой "Чесс-4.0". После долгой и упорной борьбы партия завершилась вничью.
Насколько сильно играли лучшие компьютерные программы в 1974 году? Мне представляется, если бы они играли в сегодняшних (2025 год) турнирах для людей, например, на популярном шахматном сайте "ЛиЧесс", то изначально показывали бы рейтинг в диапазоне 1800-2000 в блице с контролем 5+0. Для сравнения сегодняшние лучшие гроссмейстеры показывают здесь рейтинги 3000+ или, как минимум, около того. А если бы обсчитывали рейтинги современных лучших компьютерных программ типа "Стокфиш" и "АльфаЗирро" при их играх с людьми, то мы увидели бы рейтинги 4000+ или даже 5000+. Короче, эти современные роботы били бы всех людей без малейших шансов для последних. Примечание. При условии взаимной честной игры, но это уже совсем другая тема.
После первого чемпионата разработчики упорно работали над усовершенствованием своих программ.
В 1977 году состоялся второй чемпионат мира среди компьютерных программ в канадском городе Торонто.
Наша "Каисса" приняла участие и в этом чемпионате. Уже в первом туре чемпионка преподнесла неожиданный сюрприз для всех, включая зрителей, своих разработчиков и присутствовавших на турнире гроссмейстеров и мастеров.
Позиция из партии: "Duchess" - "Каисса", Торонто, 1977. Тур: 1.
"Каисса" до этого игравшая неплохо в этой чуть лучшей позиции вдруг делает ряд странных ходов, начиная отсюда: 29. … а5?
30. g4 Фe6
31. Лc6 a4?
32. Ф:а4 Лd6
33. Л:d6 Ф:d6
34. Фа8+
Здесь все ожидали естественного хода 34. … Крg7
Но "Каисса" вдруг ставит под бой ладью 34. … Лe8 и затем постепенно проигрывает без каких-либо шансов.
После партии, когда Каиссу спросили, в чем дело, она объяснила, что ход 34. ... Крg7 гораздо хуже, чем сделанный ею ход 34. ... Лe8.
В доказательство "Каисса" показала такой вариант:
34. ... Крg7 35.Фf8+! Крxf8 36. Сh6+ Сg7 37. Лc8+
"Каисса" демонстрирует вариант, которые не увидели даже гроссмейстеры
37. … Фd8 38. Л:d8+ Лe8 39. Л:e8X.
Специалисты, среди них были гроссмейстеры Ботвинник, Эдуард Ласкер, Ганс Берлинер, канадский международный мастер Леон Пиасетский эту комбинацию не обнаружили и объясняли народу этот заскок Каиссы "несовершенством шахматных программ".
В конечном результате турнира Каисса разделила 2—3 места с программой Duchess. Победила в чемпионате программа "Чесс-4.0".
До сих пор идут диспуты, а увидела бы программа Duchess во время партии этот выигрывающий ход 35.Фf8+
Далеко не факт, учитывая, ограниченность времени на обдумывание в турнирной партии.
В любом случае, если ход 34. ... Лe8 объективно сильнее (т.к. затягивал поражение на много ходов), то никто не будет спорить, что практических шансов больше у скромного хода 34. ... Крg7
Мне стало любопытно, а как бы в критической позиции пошла бы современная программа: 34. ... Лe8 или 34. ... Крg7 - ?
Я задал этот вопрос "Стокфишу" и получил ответ: 34. ... Лe8
Вот так!
Такие тонкие психологические моменты не понимали шахматные программы в 1977-м году, не понимают их они и сейчас, в 2025-м.
Возьмем этот факт на заметку, он нам пригодится для дальнейших рассуждений.
А как вообще роботы научились играть в шахматы? Точнее говоря, кто был их первым учителем?
Вообще говоря, много умнейших людей брались за эту интереснейшую проблему и решали её с разной степенью успеха.
Традиционно считается, что самым первым шахматным программистом в мире был Алан Тьюринг. В 1951 году он написал алгоритм Turochamp, с помощью которого машина могла бы играть в шахматы. Самое забавное, что это был чисто теоретический труд. У Алана не было компьютера, чтобы проверить свою программу на практике.
Тем не менее, его идеи были использованы другими учёными, а идеи тех, в свою очередь, новыми учёными, и вот, что мы имеем в сухом остатке.
Попробуем набросать примерный алгоритм игры в шахматы.
Что нам нужно сделать? Написать программу, которая умеет находить сильнейший ход в любой позиции.
Немного подумав, почитав разных полезных статей, становится ясно, что тут есть 2 принципиальных краеугольных камня.
Функция, которая оценивает позицию (оценочная функция).
Функция, которая как-то умеет определять максимальную глубину просмотра.
Давайте, попробуем набросать функцию, которая оценивает позицию.
Для простоты пока сделаем глубину просмотра равную одному полуходу и анализировать будем начальную позицию.
Примечание. Пусть будет 0.1 балл за одно свободное поле под атакой.
Премия за очередь хода. Пусть пока будет 0. Не уверен, что это вообще хорошая идея.
Проверку на мат проводим. Вообще, вряд ли кому-то будет мат в начальной позиции или после первого полухода. Но проверять надо.
Оценка позиции = Белые - Черные = (38.2+18)-(38.2+18) = 56.2-56.2 = 0
Теперь нам надо подобным образом оценить все позиции после всех возможных ходов.
Оценка позиции после 1-го хода белых
Ход Баллы
a3 0.0
a4 0.2
b3 0.2
b4 0.2
c3 0.2
c4 0.3
d3 0.6
d4 0.7
e3 0.9
e4 0.9
f3 0.0
f4 0.1
g3 0.2
g4 0.2
h3 0.0
h4 0.2
Кa3 0.1
Кc3 0.3
Кf3 0.3
Кh3 0.1
Получается следующий результат. Если применять данную оценочную функцию и использовать глубину расчета на 1 полуход, то в данной позиции получаются лучшие ходы: e3 или е4.
Теперь мы можем уточнить оценку начальной позиции. Если изначально она была равна 0, то после первого полухода стала равной 0.9.
Разумеется, если мы посмотрим чуть глубже (т.е. оценим все позиции после всех возможных 2-х полуходов), то оценка начальной позиции опять изменится. Наверное, она опять станет равной 0, например, после 1. e4 e6.
А если посмотреть немного глубже, хотя бы на 20 полуходов? Все это, конечно, можно сделать, посвятив этому процессу месяц или два, но это уже всё сделано до нас.
Обратился ко мне родственник - попал в ДТП, причем вообще незаслуженно. Стоял первым на светофоре, на перекрестке, как обычно - один летел на желтый прямо, второй торопился повернуть налево - одна кегля влетела в авто родственника.
Попросил найти ему на время, пока авто в ремонте, какую-нибудь жоповозку. Пофигу какую, лишь бы каталась - детей в школу по пути на работу забросить, на обратном пути до дома - забрать детей из школы. В магазин пару раз в неделю за продуктами съездить.
Ладно, обратился к товарищу - у него стоит Мурзик 1990-х годов, пару лет назад откапиталил его. Товарищ не против дать авто покататься на время. Родственник посмотрел - физию скривил. Не, двигло 5 литров - не прокормить. Признаться, я б сам отказался от такого авто - он реально здоровый! По нынешним временам хрен где запаркуешься!
Обратился к другому знакомому - у него вообще стоит 3 япошки 80-х годов, все в идеальном состоянии. Ищет, покупает, ремонтирует... а потом стоят они у него на участке под навесом. Не ожидал, что он согласится дать кому-то покататься такое сокровище - но для меня пошел на жертву:
- Выбирай любую!
Родственник приехал, посмотрел... не, правый руль его не устраивает. Да, меня когда-то тоже смущал правый руль, но проверено - привыкаешь быстро.
Задумался я, как бы помочь родственнику... и вспомнил про соседа, чья Нива на газоне стоит - когда публиковал на Пикабу фотки с кривой парковкой одной местной дамочки, почти каждый на нее внимание обратил.
- О, - думаю. - Лишен прав он еще, как минимум, на год - на месяц вполне может дать машину!
Переговорил с соседом - он не против. Все равно стоит, ржавеет. А так хоть кататься будет.
- Что за машину? - спрашиваю.
- Дай книгу с автографом - да и хватит!
Вообще прелестно! Позвонил родственнику, родственник приехал посмотреть машину.
- А чего, - говорит, - на летней резине?
- Зимняя резина в гараже, ключи - в бардачке.
- Не, это ж колеса придется таскать, менять...
Тут я начинаю закипать, спрашиваю у соседа:
- А что - в гараже у тебя еще одна машина стоит?
- Нет, пустой гараж.
И тут у меня рука к кобуре дернулась. Чудом обоих не положил! Да вы, ребята, охуели? Одному машину даром дают покататься - он недоволен, что колеса придется менять. У второго пустой гараж, водилки забрали за пьянку, но машина с лета на газоне во дворе стоит!
Родственнику указал в сторону каршеринга, соседу сообщил, что если утром авто еще будет стоять на газоне - вечером его увезет эвакуатор. И пошел домой, нервы поправить солянкой и стопочкой.
Интересно, это только у нас, в Челябинске, в воздух охуин подмешивают, или везде так?
Пришла пора продлевать разрешения на хранение и ношение оружия. Ну я как путёвый сходил пописать в баночку за 2 тыщщи, потом посидел в дурацкой муниципальной поликлинике ещё за 2 тысячи... честно говоря - полная профанация. Вообще непонятно, что они таким образом оценивают, но таки справку дали. Ладно. Засылаю документы в госуслуги. И вот сегодня звонит телефон. В воскресенье, ага. Это, говорит, из ОЛРР вас тревожат. Вы когда собираетесь акт от участкового нести?
Я говорю, типа ваще не собираюсь. На портале Госуслуги написан полный и исчерпывающий список документов, какие я, как гражданин, обязан вам подать.
Но, говорит женщина-росгвардеец, вы должны передать акт участковому, а потом приложить к заявлениям.
Неа, говорю. Я не должен. Это вы должны выписать участковому приказ (хотя это разные ведомства ващет), он мне позвонит, мы договоримся, когда нам обоим норм и после этого он придёт и составит акт осмотра.
- Ну вы передать ему можете?
- Ну нет канеш. Это мне надо искать его, договариваться о встрече и передавать. А это не входит в мои обязанности. Вы ему сами наберите и отправьте этот приказ.
Долгое молчание... потом вздох...
- Вы размеры сейфа помните?
Прошлый раз, когда продлял, тоже неприятненько получилось. У нас в Балашихе (ну точнее в мкр.Заря) ОЛРР работает по хуйски. Т.е. нельзя просто взять и записаться через ГУ. Надо чота там очень устать подпрыгивая. Вощем обычно я приезжаю туда примерно в 7 утра, занимаю очередь и спокойно сплю в машине до 10 утра, когда начинается приём. А поскольку у моей жены также имеется личное оружие, то подгадали так, чтобы одной кучей всё продлять. А поскольку у нас на тот момент ещё и дети мелкие были, получается, чтобы заехать в ОЛРР надо выписать домой тёщу, тогда я занимаю в 7 утра очередь, а жена приезжает к 10. Мы всё подали, значит... день получения... а тут как раз ОЛРР передали из МВД в Росгвардию. И как раз этот день - день Росгвардии. Какое-то там февраля. Приезжаем, сидим в очереди... эти рогатые твари неспешно лазают там, поздравляя друг друга... Очередь не двигается вообще. Т.е. за полтора часа не принято ни одного человека. Короче, плюнул, уехал. Написал жалобу на имя Золотова. Через две недели звонит майорка из ОЛРР, типа "Бугаев, ты охуел шоле, жаловаться?"
А чо, говорю, мне больше делать нехуй шоле, сидеть под дверями, как консьержу? У меня так-то рабочий день...
Ну, говорит, ладно. Меня тут ебут, приезжай, забирай свои бумажки!
- Нееее. Я теперь ещё долго во вторник и четверг (условно) не смогу отпроситься (сам у себя)... да тёща опять же... Не знаю даже, что и делать!
- АААААААААААаааааААААААААааааааааааааАААААААААААААА, но меня же ЕБУТ!!!
- Ну штош... это же не меня!
- Ладно, когда удобно будет приехать? Завтра сможешь?
- Вы же завтра не работаете?
- Ну мы же на месте. Приезжайте.
- Но я смогу только около полпервого...
- Блин, у нас обед... ну ладно, приезжайте.
В итоге, приехали и за 10 минут получили всё.
Вот вопрос. Какого хуя, простите? Ну неужели сложно просто работать? Они же там не за бесплатно сидят? Какая то зарплата есть, льготная пенсия... ну не нравится работа - ну уходи с неё. Нахера людям жизнь-то портить?
Все что написано ниже, это жизненный опыт и оценочное суждение автора, всплывшие из глубин сознания после приема лошадиной дозы ноотропов.
Если вы "программист 1С" или сочувствующий, прошу вас не читать далее.
Если вы все-таки прочитаете, отнеситесь с пониманием к деду, закинувшемуся таблетками.
Будет мат.
Я предупреждал.
Ненавижу, блядь, “программистов 1С”.
В ИТ-сообществе это каста отверженных. “Программисты 1С” не пишут программы, модули, сервисы, ничего из того, что пишут нормальные люди, они делают “обработки”.
С “программистом 1С” нельзя поговорить как с нормальным человеком, они не могут ответить нормально на вопрос: “где бабло которое нам должны?”. Они скажут свое пафосное “проводки по дебиторской задолженности на 62 счету в периодическом регистре сведений”. Они с тобой разговаривают как с говном. Чтобы подняться до их уровня нужно знать, что такое проводка, периодический регистр сведений, дебиторская задолженность и 62 счет. Это как минимум.
Больше пафоса было только у людей, у которых на стене под стеклом висела гордая бумажка “MBA”. Когда я финдиректору сказал, что надо бы провести нормализацию таблицы поставщиков, негоже в одной строке писать номер клиента и его название, она мне прям так и сказала: “Ты говно, а я MBA”.
Зато бухи очень любят программистов 1С и молятся на них, а нас, обычных айтишников, вхуй не ставят. Потому что нам не нравится их запросы: “Сделайте большую кнопку, чтобы было все хорошо”, а им не нравится наши ответы: “Это не баг, а фича” и они сразу бегут жаловаться руководству.
Впрочем, я отвлекся.
Мой первый опыт взаимодействия “программистом 1С” был, когда мне было 22, а ему 34. Главбух поставил мне задачу разобраться, почему проводка формируется 7 минут. Я сперва не понял, почему главбух со мной разговаривает про водку, но не подал виду.
Затем я подошел к серьезному мужчине с проблемой и он сходу послал меня нахуй, показав “сертификат разработчика 1С”. Я человек не гордый, нахуй не пошел, а попросил его открыть код, который вершится при нажатии на кнопку. Так получилось, что я был его начальником, и ему пришлось показать.
То, что я там увидел, меня повергло в шок, волосы на голове (а тогда они еще были) зашевелились как море на картинах Айвазовского. Там было три вложенных цикла. В первом цикле искался номер счета, во втором цикле искался контрагент из трех сотен, в третьем цикле искался счет из нескольких тысяч, на который нужно было сослаться в счет-фактуре. То есть в циклах около трехсот тысяч раз происходило открытие документа, происходила сверка его номера, а не тот ли это документ? Работа этих циклов и занимала семь минут.
Нервно сглотнув я поинтересовался, нет ли встроенных функций поиска в замечательном 1С? На что был послан второй раз. Но я опять не пошел, а позаимствовал увлекательную желтую книжку с цифрами "7.7", которая стояла на полке. Он не мог ее не дать, потому что это было собственностью компании. На выходных меня ждало погружение в эльфийский язык, благо рядом оказался грамотный толмач. Нужные функции были найдены, «программист 1С» убрал циклы, проводка стала выполняться мгновенно. Через неделю он уволился с формулировкой: «будет мне всякое говно указывать, как работу работать».
На его место пришла девушка 27 лет отроду. Она имела прекрасное резюме. Как потом выяснилось, все что в нем было, был чистой воды пиздежь, но я ее не собеседовал, с меня взятки гладки. Ее на собеседовании почти завалил гендир, спросив «критерий Найквиста», но пожалел ее налившиеся слезами глаза. От девочки была в восторге вся бухгалтерия. Да и мы, пока не прилетела задача, над которой надо было думать. А именно: составить «нормальный» отчет с дебиторской задолженностью по контрагентам. У девушки не получалось. Отчет был, но данные в нем не соответствовали реальности.
Я впервые попытался поговорить с девушкой на профессиональные темы, затронув в том числе SQL, упомянутый у нее в резюме. На что девушка сказала, что у нее АЖ ТРИ “сертификата программиста 1С” и чтоб я к ней со своей хуйней не лез. Иногда, она отвечала на мои вопросы с солидным временным лагом, но чаще говорила, что такое сделать невозможно. Я открывал желтую книжку с цифрами "7.7" и показывал, что имею в виду, но через пару дней получал ответ, что это все невозможно. Ну нет, так нет, задача-то никуда не девалась, пришлось лезть в базу мимо 1С. Но суть не в этом. Как-то она пошла пить чай в бухгалтерию, а на ее экране остался тред с форума программистов 1С на несколько сотен сообщений, которой она и создала и в котором жаловалась на меня, что я к ней придираюсь и заставляю отвечать на вопросы, не достойные “программиста 1С”. Нет я не садился за ее комп, я просто запомнил url и с интересом почитал. Заодно нашел все те вопросы, на которые она не могла ответить по несколько дней, где ей разжевывали ответы, попутно поясняя, что я гандон. Я человек не гордый, зарегился и навалил им говна по самый капюшон. Тред увеличился до тысячи сообщений, девушка обиделась, пожаловалась и ее перевели в бухгалтерию, и мы больше не пересекались.
Тут нужно отметить, что затем пришел мальчик Саша, с которым мы поговорили на одном языке и сделали все задачи. Мальчик Саша не был “программистом 1С”, он был разработчиком, который умеет писать на 1С. Это две большие разницы. Он не показывал свои сертификаты, но думаю они у него были. Через два года мальчик Саша сказал без обиняков: "в 1С я видел все ваши зарплаты, мне не к чему здесь стремиться, я ухожу писать на SAP". Это был мужской поступок.
Все пересечения с “программистами 1С” тяжелыми шрамами легли на моей психике и больше я с ними не пересекался. До прошлого года. В прошлом году одна контора решила подключиться к нашему API из 1C. Ну все думаю, пизда рулю. Так оно и вышло. Ты им факты, а они тебе: у нас такая функция в 1С, ничего не можем сделать. Ну не можете, так не можете.
Все бы так и похерилось на задворках моей памяти, если бы вчера в наш уютный бложик не пришел «Архитектор 1С». Волосы на моей жопе вновь зашевелились.
Чувак, к тому, чем ты занимаешься, приписывать шильдик «1С» - это зашквар, для айтишника это значит что ты гуманойд, непись, который не может ничего за рамками “1С”. Не порти о себе впечатление при знакомстве таким образом. Я искренне верю что ты не таков!
P.S. Все, что написано выше, написано под воздействием ноотропных веществ и не имеет никакого отношения к моей текущей реальности и, надеюсь, к вашей тоже. Аминь.
Несколько дней назад, когда стояла жара под 30 даже ночью, соответственно, окна открыты, проснулся ночью от криков под окном.
Закурил, пошел посмотреть, что происходит. Парень и девушка. Девушка верещит:
Д: да, я еблась с ним! И что? Ты сам сказал - ебись с кем хочешь! Давай, пиздани мне, ты же хочешь пиздануть!
Не знаю, сколько времени она выпрашивала - не засекал, но у меня успел закипеть чайник, я успел выпить половину чашки кофе, а девушка все верещала:
- Ну давай, пиздани мне! Пиздани же мне!
Парень держался. Девушка, устав выпрашивать, набросилась на него с кулаками, молотила его, пока я вторую половину чашки кофе не допил.
И что бы вы думали? В итоге парень ей пизданул! Нормально так зарядил - девушка сальто в воздухе сделала. Отлежалась, встала на ноги и снова набросилась на парня с кулаками:
- Да как у тебя рука на меня поднялась????
Чем закончилось - я не досматривал, пошел дальше спать. Но утром крови на асфальте не было.
Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.
Кроме того, у панели было предусмотрено несколько настраиваемых режимов работы, которые переключались по запросу пользователя, что требовало массового управления маршрутами потоков данных внутри системы.
В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.
В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.
И что, получилась просто еще одна реактивная библиотека?
Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.
Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.
Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.
Ключевая идея: поведение системы описывается как композиция независимых возможностей, которые одновременно определяют тип, реализацию и правила взаимодействия.
Transferum предоставляет четыре слоя абстракции:
Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.
Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.
Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:
Определяют TypeScript-интерфейс трансфера на этапе компиляции.
Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
Обеспечивают совместимость в билдерах без приведений типов.
Один набор флагов — три потребителя. Это единый источник истины для всей системы.
Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:
Transfer
// гомогенный трансфер: T -> [ Transfer ] -> T
Или вот так:
Transfer
// гетерогенный трансфер: TInput -> [ Transfer ] -> TOutput
Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:
const pushChannel: Transfer;
const converter: Transfer;
// содержат методы push(), subscribe()
const manualBuffer: Transfer;
// содержит методы push(), pull(), trigger()
// trigger() в данном случае нужен, чтобы сделать запушенное значение
// доступным для чтения через pull()
const pollingProxy: Transfer
// содержит методы pull(), subscribe(), trigger(), activate(), deactivate(), toggle()
// может быть связан с pullable-источником благодаря поддержке поллинга
Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:
Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.
2. Мосты не знают конкретных реализаций
Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.
3. Значение undefined никогда не распространяется
В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.
Связывание трансферов
Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:
Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.
Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».
Поддержка backpressure
Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.
Локальная обработка ошибок
Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.
А теперь — к примерам использования
Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:
А вот как можно организовать динамический роутинг:
import {
createPushStoredChannelTransfer,
createBridgeMultiSelector,
createBridgeSelector,
createPassBridge,
} from 'transferum';
// Вариант 1. Выбор одного реципиента
const commandRouter = createBridgeSelector({
bridges: {
light: createPassBridge({ source: commandChannel, target: lightController, activated: false }),
thermostat: createPassBridge({ source: commandChannel, target: thermostatController, activated: false }),
lock: createPassBridge({ source: commandChannel, target: lockController, activated: false }),
},
initialKey: 'thermostat', // выбор по умолчанию
activated: true,
owned: true,
});
commandRouter.select('lock'); // выберем другой вариант
// Вариант 2. Выбор нескольких реципиентов
const loggersRouter = createBridgeMultiSelector({
bridges: {
prometheus: createPassBridge({ source: metricsChannel, target: prometheusWriter, activated: false }),
elk: createPassBridge({ source: metricsChannel, target: elkWriter, activated: false }),
sentry: createPassBridge({ source: metricsChannel, target: sentryWriter, activated: false }),
},
initialKeys: ['prometheus', 'elk'], // будут активированы по умолчанию
activated: true,
owned: true,
});
loggersRouter.check('elk'); // теперь выбраны все три
loggersRouter.uncheck('prometheus'); // выбраны elk, sentry
loggersRouter.select(['prometheus', 'sentry']); // выбраны prometheus, sentry
А вот пример c организацией игровой механики:
import {
createDebounceTransfer,
createConvertTransfer,
createMapOperator,
createBridgeSelector,
createPassBridge,
linkTransfers,
} from 'transferum';
// Источник: debounce нажатий клавиш (16ms ~ 1 кадр при 60 FPS)
const rawInputSource = createDebounceTransfer({ delay: 16 });
// Конвертер: KeyboardEvent -> код клавиши
const inputConverter = createConvertTransfer({
operator: createMapOperator((event) => event.code),
});
// Целевые системы-потребители пользовательских событий
const carSystem = { push: (cmd: string) => console.log(🚗 Car executing: ${cmd}) };
const planeSystem = { push: (cmd: string) => console.log(✈️ Plane executing: ${cmd}) };
const menuSystem = { push: (cmd: string) => console.log(📋 Menu processing: ${cmd}) };
// Роутер: динамическое переключение между игровыми контекстами
const gameplayRouter = createBridgeSelector({
bridges: {
driving: createPassBridge({ source: inputConverter, target: carSystem }),
flying: createPassBridge({ source: inputConverter, target: planeSystem }),
ui: createPassBridge({ source: inputConverter, target: menuSystem }),
},
initialKey: 'driving', // игрок начинает в машине
activated: true,
});
// Связывание источника с конвертером с автовыбором стратегии
linkTransfers(rawInputSource, inputConverter);
// Демонстрация:
// Игрок в машине нажимает "W"
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: 🚗 Car: KeyW
// ==================
// Переключаемся на самолёт
gameplayRouter.select('flying');
// Та же клавиша теперь управляет самолётом
rawInputSource.push(new KeyboardEvent('keydown', { code: 'KeyW' }));
// Через 16ms: ✈️ Plane: KeyW
Когда имеет смысл попробовать Transferum
Библиотека подойдет для:
TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.
Результаты и планы
Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.
Буду рад, если вы заглянете в репозиторий, попробуете библиотеку в деле и поделитесь замечаниями — обратная связь поможет сделать Transferum лучше.
P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.
Комментарии