Всем доброго времени! Наткнулся я не так давно на вот такое изображение:
И решил порассуждать не тему того, а плоха ли такая ситуация и как вообще бывает, как идет разработка backend и frontend в вещах которыми я занимался, возможно кому то будет интересно, а кому то захочется подискутировать со мной)
Во первых о понятиях, что такое "Бекенд" и "Фронтенд", я работал с разными разработчиками и даже студиями и понял что иногда эти понятия отличаются у разных людей (особенно когда речь идет о том как HR их понимает), по этому поясню что я в них вкладываю:
Frontend - "передний конец", это весь визуал который видит человек пользуясь программным обеспечением, а так же скрипты которые исполняются на стороне (на устройстве) пользователя.
на примере сайта, это его верстка, а так же javascript который перелистывает слайды, раскрывает выплывающие окна и т.д.
Backend - "задний конец", это всё что исполняется "под капотом" программы, в случае сайта это на сервере, в случае какой то настольной программы, внутрипрограмные механизмы, например обращающиеся к каким то функциям операционной системы и производя какие то расчеты и действия
на примере сайта, это его серверная часть, механизмы которые к примеру работают с базой данных, получают из неё пост для страницы на которой находится пользователь, и к примеру комментарии для этого поста и т.д.
А теперь как раз о том, что разрабатывается первее и почему.
Возьмём вебсайт, вы например хотите что бы вам сделали интернет магазин, обычно этапы разработки выглядят так:
- Создание и утверждение дизайна
- Верстка дизайна
- Подключение к верстке т.н. "Движка" или cms или "системы управления контентом", или же что очень редко и индивидуально, написания этой самой системы с нуля в порядке индивидуальной разработки и внедрения её в вёрстку.
т.е. по сути тут выходит что разработка Бекенда идёт после Фронтенда - и получается что как будто то что показано в меме это естественный ход событий и ни каких вопросов это не может вызывать?
Стоит сказать что последовательность работ которую я описал, это обычно усреденная разработка, где люди не сильно запаиваются составлением подробных ТЗ. По ней выходит то что когда готов дизайн, и на основе него вёрстка, это всё передается программисту работающему над Бэекендом, и он сразу видит, что и где ему нужно будет подключать и в каком виде: "Здесь у нас поиск, с возможностью сортировки и выбору диапазона дат постов", "Тут мы выводим чат, который обновляется каждые пару секунд" и т.д. Программист сразу визуально видит какие данные в какие элементы интерфейса ему нужно выводить, от чего ему более понятен план работ, по тому что он "визуален".
Но предположим что сроки разработки сжаты, и требуется что бы разработка обоих частей проходила одновременно, в таком случае необходимо очень точное техническое задание, где будет подробно прописано то как будет работать бэекенд, какова будет структура базы данных, какие данные при каких обстоятельствах будут из неё извлекаться, каким образом обрабатываться, в каком виде перезаписываться обратно и в какой части условного ещё не созданного даже в виде дизайна интерфейса отображаться.
Это довольно фантастический план, так как обычно не бывает заказчиков которые чётко знают как должен выглядеть их сервис\сайт\по и даже не всегда представляют себе точный его функционал.
Это всё зачастую формируется как раз во время разработки и утверждения дизайна, и по этому программист который с самого старта одновременно с дизайном начал разрабатывать свой бекенд, чаще всего обречен по ходу появления дизайна и вёрстки вносить коррективы в свою работу, а иногда даже переписывать её часть.
Но есть например аспекты которые можно на мой взгляд проработать и без дизайна, например структуру базы данных и её таблиц, создать какие то общие функции, провести базовую настройку движка или фреймфорка с которым будет работа.
Но всё же когда дизайн утверждён и верстка окончена и принята заказчиком, это уже гарантирует стабильность разработки. (при условии конечно если заказчику не взбредёт в голову что то на ходу изменять, но такие вещи должны быть учтены в договоре и проходить за дополнительную оплату)
Примерно то же самое происходит и при разработке приложения для телефона.
Программисту всегда проще подключать бекенд к чему то готовому, чем прорабатывать так называемые API (простым языком объясняя это точки доступа через которые интерфейс получает данные из бекенда) почти в слепую или по скупому ТЗ (я просто ещё не видел по настоящему подробных ТЗ за исключением тех которые в своей педантично душной манере составлял).
По этому становится очевидно что это вполне себе нормальная ситуация, когда Фронтенд давно готов, на него можно посмотреть, потыкать, а Бекенд ещё только подключается, а то ещё и вовсе в стадии разработки.
Но есть один сценарий когда бекенд идёт первее фронтенда - это когда разрабатывается какое то техническое программное обеспечение у которого изначально вовсе нет интерфейса, например какой нибудь локальный сервер - пишется собственно сама програмина, а её настройка и в целом взаимодействие с ней происходит через терминал\консоль\командную строку.
В данном случае интерфейс появляется уже после того как ПО было разработано, зачастую таким программным обеспечением можно пользоваться и без интерфейса через всё тот же терминал, отправляя команды которые ты вводишь в него вручную (прям как хакер из кинофильма), а графический интерфейс создаётся уже потом(иногда очень сильно потом) просто для удобства пользователя и отображает все стандартные и часто используемые опции (для более тонких настроек за частую используется всё равно командная строка) и по сути графический интерфейс, отправляет те же самые команды что вы бы вводили в терминал, просто делает это по нажатию на кнопочки.
На этом всё, надеюсь кому то было интересно почитать эти возможно сумбурные рассуждения, сейчас попробую выловить все грамматические ошибки в этом опусе, перед тем как нажать кнопку "опубликовать пост"😅
Она - автор нового развлекательного проекта "Капибара". Проект уже успел наделать шуму. И по большей части благодаря комьюнити. Как все началось? Это история для сериала. У айтишницы было две работы, ипотека и колоссальная нагрузка. Сломаться, устать можно по "щелчку Таноса". Отдыхала глазами на "Пикабу". Читала, постила. Пока политика сайта не пошла вразрез с ее личными убеждениями. Дальше был вихрь.
- Это название выбрали пользователи. Сначала устраивали мозговой штурм. Потом голосовали в два этапа за понравившиеся варианты. Потом откатывались, чтобы обоснование сделать: почему тот вариант, а не другой. В целом, это полностью инициатива самих участников. Когда задала финальный вопрос: «Название «Капибара» всех устраивает?», больше 500 человек ответили: «Да!»
- А где проводили это голосование?
- В чате. Он создался в первые секунды жизни идеи. Там есть специальный топик: выбираем имя для проекта. В нем и провели голосование буквально через 3-4 дня после его создания. 24 июля обновился «Пикабу». В этот же день мною был создан тот самый пост, тут же был создан чат и все понеслось…
Капибара - герой мемов
О причинах популярности капибар (ссылка на материал в Тинькофф журнал)
- Все-таки изначально идею предложили вы? Это связано с модой на капибар?
- Идея названия – полностью пользовательская. Я изначально дала только рабочее название Vortex. Нужно было заводить репозиторий, называть документы, папки. В общем, я автор только служебного названия. Но я не взяла на себя ответственность, что так будет называться весь проект. А Vortex потому, что у меня сложился такой ассоциативный ряд. Как «Капибара» началась вихреобразно, так все и понеслось.
- Вихреообразно – имеете ввиду, что началось все эмоционально?
Мы как-то очень неожиданно, очень импульсивно стартовали. Когда вышло обновление на «Пикабу», то от меня был всего один эмоциональный пост
- Стоп. Ольга, что за пост, с которого все началось?
Я написала «С этим «Пикабу» все понятно, если никто не начнет делать новый, то это начну делать я»
Триггером стал выход обновления на «Пикабу». Отмена отображения минусов. То есть в «горячее» с прошлого обновления стали попадать посты с отрицательным рейтингом. Это оказалось не багом: они что-то сделали с алгоритмами и не будут «чинить» рейтинговую систему, а будут маскировать продвигаемые посты под видимость обычных.
Я поняла, что того, что я любила на «Пикабу», больше не будет. Я была не согласна с тем, что нет альтернативы. Мол, есть «Пикабу», он единственный, терпите. Альтернатива нужна! Тогда еще не было известно ни про «Вомбат» ни про другие новые проекты.
Когда я создавала этот эмоциональный пост, думала, что впишусь в какую-нибудь команду разработчиков. О том, что я возглавлю, я даже не подозревала.
А, да, на «Пикабу» мой профиль забанили за упоминание «Капибары». Моему аккаунту было 8 лет и больше 100 000 рейтинга. Это не топ, но очень неплохие цифры для «Пикабу».
— Вы создали пост и получили обратную связь от пользователей?
- Да, посыпались комментарии: «Фронтенд-разработчик у тебя есть! Я разработчик с четырнадцатилетним опытом – я с тобой!»
Я создала отдельный чат в телеграм: ну пусть будет, и ушла работать.
Через два часа возвращаюсь, а в чате 3,5 тысячи человек
Ольга получила сильную поддержку сообщества
Я включила людям топики, темы они создавали сами, какие-то голосования начали вести. Посмотрев на это, я поняла, что надо стартовать разработку прямо сейчас, потому что люди уже начали голосованием выбирать базу данных, языки программирования и прочие технические вещи. Но это не те вещи, которые выбираются голосованием…
- То есть в чатах народ взял власть в свои руки?
- Абсолютно. Но оно пошло не в том направлении, в каком имело хоть какие-то шансы развиться. Поэтому к вечеру следующего дня я написала, каких именно компетенций нужны специалисты.
Мне ответили: «Давайте не будет как с народным Авито!» «Народное Авито» — это проект «Мой торг», тоже проект пикабушников, которые решили создать свой «Авито». Один из ребят из той команды сказал мне: «Блин, мы за полгода ни строчки кода не написали. Давай здесь не будет также…»
Про энтузиазм и конфликты
- Проект, абсолютно построенный на UGC – это, наверное, какой-то идеал, к которому вы стремитесь?
- Есть огромная разница, между тем как строить проект и как им пользоваться. Как им пользоваться — не вопрос. Мы все делаем для того, чтобы это была UGC-платформа с минимальным вмешательством со стороны администрации. То есть это действительно полностью власть пользователей. Люди сами решают, какой контент годный, что будет в тренде, что будет в топе, а чему нужно утонуть в минусах. Это полностью их вотчина.
Но при постройке самого проекта, при создании архитектуры, кодовой базы, дизайна такая демократия невозможна.
- А вы не думаете, что проекты, созданные на эмоциях, долго не живут?
Если в проекте только одна эмоция – я полностью согласна. Но «Капибара» разогналась до достаточно приличной скорости. Ее притормозить просто так не получится. У проекта колоссальная поддержка коммьюнити. Идея жива. Продукт людям нужен.
Даже если меня завтра собьёт автобус – «Капибар» легко восстановить, потому что исходники в открытом доступе.
У команды есть доступы, и базы данных «Капибары» могут поднять на соседнем домене. Я диверсифицировала риски.
- Что «Капибар» сегодня из себя представляет?
- Это платформа с честной регуляцией и алгоритмами, прозрачной рейтинговой системой, саморегуляцией контента пользователей и приятной площадкой для авторов.
Получается – основные отличия «Капибары» как UGC -платформы от сотен других соцсетей в том, что человек настраивает не только свою ленту – игнором тегов, подписками на теги, но и он влияет на то, что в трендах. У «Капибара» нет информационного пузыря. Здесь ценится то, что ты делаешь и пишешь.
Ленты «Тренды, Топ и Авторское» — это отдельные ленты, на которые ты не подписывался. Подписка — отдельная лента. Каждый человек влияет своими оценками на то, что попадает в тренды.
- Какие цифры у «Капибары» сейчас?
На сегодня Капибара — это 1 890 зарегистрированных верифицированных пользователей, постов за все время – 3 550, комментариев – 24 000.
Незарегистрированных пользователей мы еще не особо умеем считать. Пока здесь надежда на Google метрики, Яндекс-аналитику и Similarweb. Он, кстати, говорит, что у нас 192 000 посетителей за месяц.
- Для вас это больше цифры?
- Сложно сказать. Наверное, большие.
- Вы говорите, что 1, 8 тысяч зарегистрированных пользователей. Но если сравнивать с подписчиками какого-нибудь крупного паблика – это не очень большая цифра
- Капибар вышла в публичный доступ 1 января. Это отдельный сайт без раскрутки. Получается, что для проекта, который в доступе чуть больше 2 месяцев – это очень хороший показатель.
Саму разработку мы начинали летом. В ноябре вышли в закрытый альфа тест. Туда можно было заходить по приглашениям. Человек заходил со всеми дисклеймерами: понимал, что это тест, понимал, что еще куча багов. Но, таким образом, мы авторов запускали.
— Команда капибар. Кто это?
- Динамический состав команды. Часть разработчиков пришла со старта. Часть после. Часть присоединилась недавно. Это высококвалифицированные специалисты. С коммерческим опытом работы больше четырех лет. Я не могла позволить себе взять команду джунов. Потому что это оттягивало бы ресурс остальных разработчиков.
Все спецы очень высокого грейда. Все это истинные герои и энтузиасты. Идейные люди. Очень самостоятельные. С комплексным видением с умением цельно видеть весь продукт и проект. Что редкое качество.
- Сколько денег потратили на запуск проекта?
- Честно — не считала. Расходы на регистрации доменов, ботов для упрощения модерации в канале, инфраструктуру – это все совершенно не сравнимые цифры с тем, сколько бы я потратила на разработку, если проект был бы коммерческий.
-???
- Можно посмотреть на HeadHunter среднюю зарплату разработчиков. У нас 10 человек – костяк команды, а в целом в команде разработки было до 40 человек.
У нас динамический характер команды. Если бы все эти люди были на зарплате, то на проект уже бы потратили восьмизначные суммы.
(От автора)Чтобы посчитать возможные затраты на проект, я возьму среднюю зарплату программиста middle уровня в РФ – 120 000 рублей (hh. ru). Костяк команды «Капибара» — 10 человек. В итоге, ежемесячно на проект Ольга тратила бы 1, 2 млн. рублей. Учитывая, что с момента разработки прошло уже больше 7 месяцев, то затраты составили бы около 10 млн. руб только на постоянных участников проекта, не считая тех, кто нерегулярно привлекается к задачам.
«Капибара» едет на энтузиазме. Люди горят идеей, чтобы этот проект был. Чтобы существовала альтернатива. Поэтому open source код и затраты только на инфраструктуру (облачные сервера).
- Понимаю – проект молодой. Но были ли конфликты с пользователями?
- Да, конфликты случаются. Связано в первую очередь с тем, что «Капибара» – пока без политики. И мы об этом рассказывали до старта проекта, и повторяли не раз. Это записано в правилах и повторяется самими пользователями.
У некоторых были ожидания, что проект станет местом, где можно обсуждать и двигать свои политические идеи. Те, которые не проходят модерацию на «Пикабу».
Я не готова рисковать проектом, который могут «роскомнадзорнуть» за чье-то высказывание. И я не хочу, чтобы «Капибара» превращалась в агитплощадку. Потому что это очень непростая тема, на которую даже близкие люди могут переругаться. А на огромном сайте…
Конечно, есть не согласные с этим.
«Капибара» делалась как обитель авторского контента. Того, которому не придется сражаться за доступ к читателю пробиваясь через «баяны» и рекламу десятков тысяч телеграм-каналов. У всех были свои ожидания, и есть люди, которые ждали, что там будет свобода вообще во всем.
Отмечу, что мы ограничены законодательством всех стран технического контакта. Большинство пользователей из России, а значит, надо соблюдать закон РФ. Это мы делаем в добровольном порядке. Мы соблюдаем закон.
Главный фейл и инсайт Ольги в этом вихре "Капибара" я по-традиции опубликовал в своем телеграм-канале "Стас смотрит рекламу"
Про несогласие с отсутствием альтернативы на рынке
- «Капибар», «Вомбат», «Пипмай», есть, думаю, еще ряд проектов, о которых пока мы не знаем. Почему вдруг люди начали делать подобные проекты. В чем причина?
- Я думаю, несогласие с отсутствием альтернативы. В воздухе висит такое: «Хочешь альтернативу? Иди на «Reddit». Там англоязычные люди из далекого зарубежья и их посты тебе не «откликаются». Это не про тебя. Да, есть «Yaplakal. com» – там своя специфика. Есть «Fishki. net» – но это не замена «Пикабу».
- В чем отличия?
- По функционалу, по темам, по аудитории, по специфике.
- А чем аудитория отличается?
- Я взяла агрегированные данные. Читала немало постов на тему, почему это не аналог, но сама эту аналитику не проводила. Если вкратце – это не замена. Все аналогичные проекты, о которых говорили выше, стартовали, чтобы у людей был выбор
- У проекта есть бизнес-цель или это пока хобби?
Это точно не хобби. Это уже слишком серьезно.
Но цели «зашибать» там миллионы мы не ставили. Если финансово взлетит, то, конечно, отказываться от денег не будем. Цель минимум — вывести проект на «самоподдержание».
- А в целом, сколько времени у вас отнимает работа над «Капибарой»?
- Все свободное время. У меня стандартная восьмичасовая пятидневка. А «Капибар» это уже не просто «поработать». Я ею живу! У меня каждое утро начинается с «Капибар». Появляется минута на обеде – «Капибар». Свободный вечер – «Капибар».
- Как сейчас продвигается проект?
- SЕО продвижение. Страницы "Капибары" очень хорошо индексируются google и Яндексом. Ну, и конечно, сарафанное радио. Сообщество рассказывает о «Капибаре». Плюс, у нас есть страницы в ВК, откуда приходят люди. Но если верить Similarweb, то основное количество людей идет через Телеграм. Люди делятся статьями, пересылают их, рассказывают о них. Плюс у нас регулярные публикации на других ресурсах.
Например, первая статья на Хабре удачно выстрелила, есть статьи на vc, на tenchat, на реддите.
- То есть пока вы не заходите в такие инструменты как Яндекс. Директ и т. д.?
- Пока нет такой необходимости. Для этого нам нужно SEO ядро. Человек, который умеет это делать, чтобы не сливать бюджет.
«Все! Не могу больше…»
- Возвращаясь к Пикабу. Есть мнение из комментариев к одному моему интервью, что клонов у этого сайта десятки. Что можете ответить на это?
Могу ответить: «Пожалуйста, не бросайте начатое. Альтернативы — это прекрасно. Свободный рынок – это двигатель развития, прогресса. Нам нужно разнообразие. Чем больше создается таких площадок, тем выше шанс, что через 10-15 лет кто-то из нас будет еще существовать».
- То есть вы говорите о том, что если крупные площадки закроются, то вся масса пользователей останется без контента?
- Нет, без контента, конечно же, не останется. Но вопрос в качестве этого контента. Быстро, легко, смешно, листай-листай-листай… Посмотрите на рилсы в Инстаграме*, на клипы в ВК, перепосты «хохотачей» с Одноклассников, сотни тысяч телеграм-каналов с мемами. «Пикабу» взял тот же ориентир. Площадок с качественным авторским контентом все меньше.
- Есть еще мнение конспирологическое. Якобы за созданием «Вомбата» и «Капибар» стоит один человек. И якобы это сайд-проекты «Пикабу».
- Впервые слышу такое мнение. «Вомбаты» и «Капибары» в коллабе. Мы поддерживаем друг друга. У нас совместные активности и конкурсы. Тот же «Анонимный Дед мороз» или конкурс на 14 февраля. У них под тегом – #любовьморковь , у нас #расскажи мне о любви. И призы были совместные. Хлопнули по лапкам и помогаем в развитии друг другу.
Нет, никто не из администрации «Пикабу». Мы все — бывшие пользователи «Пикабу».
- Ольга, когда хотелось бросить проект? Ну, вот: «Все, не могу больше…»
«Капибара» началась, когда в моей жизни было одновременно две работы, и я только-только влезла в ипотеку. Представляете уровень нагрузки?! И тут появляется третья бесплатная работа — «Капибара».
Она забирает время и деньги. Конечно, я была близка к выгоранию! И, например, через месяц руки уже опускались!
Взяла выходные. Провела их как нормальные люди и снизила нагрузку. Тут мне очень помогли модераторы, команда проекта, активисты чата. Они взяли на себя многое из того, чем занималась я. И за чатом смотрели, и обновления сами выкатывали, и конкурсы сами проводили, и различные мероприятия/игры для поддержания активности пользователей, и объявления раскидывали, и с текстами помогали, и авторов звали. Стало проще.
- Ваша большая нагрузка была угрозой проекту?
- Это сложно назвать угрозой. Потому что я заложила очень сильный фундамент в «Капибару». У нее высокая автономность. Даже если бы я выпала на 3 месяца из проекта, то я сделала в команде высокую ставку на самоорганизованность.
- Что это значит?
- Каждый понимает, что он делает. И делает, не спрашивая разрешения. У нас есть функциональные требования и общее понимание того, во что целимся. В виде прототипа — тот же «Пикабу». И мне не нужно расписывать людям в деталях: сделай так или так. Команда высокопрофессиональная и на высоком уровне организованности.
Даже если все пропадет по щелчку Таноса – исходники находятся в открытом доступе. Кто-нибудь обязательно возьмет и продолжит…
*Meta – запрещенная на территории РФ организация
Мы проговорили с Ольгой несколько часов. Материала много. Она высококлассный специалист и не попросить ее поделиться лайфхаками было бы глупо. Она поделилась: как использует нейросети в работе над проектом. Нейронки пишут код, ищут ошибки, забирают рутину. Но, это уже вторая часть интервью, которая выйдет позже. Проанонсирую в своем канале: Стас смотрит рекламу
🌟 Обновления на Капибаре: Новый уровень взаимодействия и контента! 🌟
Здравствуйте, уважаемые Капибарины и Капибарышни, а также все заинтересованные и мимо проходящие.
Сегодня важный день, ведь на сайте впервые выходят официальные новости проекта и в них мы хотим рассказать, что было сделано за последнюю пару недель!
📸 Изображения
Картинки в постах - это так привычно, что кажется само собой разумеющимся. Однако, чтоб добавить возможность загрузки изображений на сайт, команде разработки пришлось знатно потрудиться :)
Для максимальной скорости и эффективности выгрузки изображений из любой точки Земли мы внедрили на сайт CDN - Content Delivery Network. Эта система позволяет оптимизировать загрузку, распределяя ваши картинки по серверам, что минимизирует задержки и ускоряет отображение.
Также была реализована функция проверки размера изображений и их сжатие. Это гарантирует, что слишком большая фотография не заставит сайт лагать или работать медленнее. Мы понимаем, что такое решение может расстроить фотографов и тех капибаринов, которым важно разглядеть все мельчайшие детали в первозданном виде. Однако покуда наш сайт молод и мал, к сожалению, это наиболее оптимальное решение для обеспечения его работоспособности.
На наш сайт помимо обычных картинок вы можете загружать и гифки (.apng, .gif, .webp) размером до 5 Мб. Каждое загруженное изображение конвертируется на стороне бэкенда в webp для оптимального отображения и снижения нагрузки на инфраструктуру.
Для не прогружающихся картинок - из-за плохого интернета, проблем на сайте или в браузере - мы добавили плейсхолдер - специальную рамку, которая рисуется вместо проблемного изображения.
Ограничение количества медиа в комментариях. Введено ограничение на количество медиафайлов в комментариях до двух изображений, чтоб не перегружать интерфейс и не удлинять сверх меры комментарий. При попытке добавить третью картинку сайт предложит создать отдельный пост.
🤖 Бот для Верификации через Telegram.
Для упрощения процесса верификации профилей через Telegram был создан специальный бот. Он позволяет пользователям верифицировать свои аккаунты всего в три клика.
Для бота верификации добавлена поддержка создания Docker-образов в среде GitLab-CI.
Это означает, что процесс развертывания и обновления бота теперь может быть полностью автоматизирован с использованием Docker-контейнеров. Внедрение GitLab-CI обеспечивает непрерывную интеграцию и доставку (CI/CD).
💭 Комментарии
Почти одновременно с началом альфа-теста была завершена разработка дерева комментариев. Мы реализовали сами комментарии а так же систему управления их вложенностью - это значит, что когда ветка уходит вправо на 4 (для телефонов) или 9 уровней (для компьютеров), новые комментарии оказываются снова слева , однако теперь с гиперссылкой на родительский комментарий. Это улучшает визуальное восприятие длинных веток и предотвращает излишнее дробление обсуждения.
Заложен первый камень в защиту сайта от ботов. Была реализована верификация пользователей через телеграм и ограничение на комментирование, голосование и создание постов для тех, кто её не прошёл. Такая система позволит усложнить жизнь ботоводам, ведь завести 100500 почт намного легче чем 100500 телеграм-аккаунтов. От того, что они у нас массово зарегистрируются, особого вреда не будет, а вот от того, что они будут клепать «нужные» посты, бурстить / топить «нужные» комментарии / посты — вред очевиден (Если этого не сделать, будет как на Пикабу сейчас)
Для живых, пока еще неверифицированных пользователей, мы реализовали интуитивно понятные всплывающие сообщения о необходимости подтверждения аккаунта при попытках комментирования, голосования или создания постов. Это улучшает пользовательский опыт, предоставляя чёткие инструкции о необходимости верификации для полного доступа к функционалу платформы.
Индикация новых и непрочитанных комментариев. Сейчас ведётся активная работа над системой визуальной индикации, которая будет выделять новые и непрочитанные комментарии в ленте ответов. Это значительно упростит отслеживание активности в дискуссиях и поможет пользователям не упустить важные моменты обсуждения.
🏷️ Теги
Фильтрация по тегам. Разработали ленту постов с поиском по одному или нескольким тегам. В нее можно перейти как с бокового меню(вкладка «Теги»), так и напрямую из поста кликнув по тегу. В открывшейся вкладке вы можете добавить дополнительные теги по которым будет осуществляться поиск постов.
Пока только на бэкенде, но уже сделали API отдающее список популярных тегов для быстрого выбора тегов на странице поиска по тегам.
Установили лимит в 10 тегов на пост, исключая специальные теги, такие как «Своё», «Авторское» и «Телеграм». Это предотвращает перегрузку постов избыточным количеством тегов и способствует более точной категоризации контента.
Специализированные Теги «Своё» и «Авторское». Ведётся разработка нового блока в интерфейсе создания поста для выбора этих специальных тегов, включая подсказки, которые объясняют их значение. Тег «Своё» предназначен для контента, созданного пользователем лично или имеющего к нему прямое отношение. Тег «Авторское» применяется к контенту, в который пользователь вложил своё время, старания и творческие усилия
👁️ Лента «Просмотренное»
На бэкенде реализован API для управления и вывода просмотренных постов. Это означает, что теперь у нас есть бэкенд-структура, которая способна обрабатывать и передавать данные о просмотренных пользователями постах. Однако, эта функциональность пока что не интегрирована в пользовательский интерфейс и доступна только на уровне сервера.
Также на бэкенде начата работа над механизмом скрытия просмотренных постов из ленты. Эта функция также пока не реализована, но находится в активной разработке
🔥 Лента «Тренды»
За последнее время мы также сделали ленту «Тренды», в которую попадают положительно оцененные пользователями посты.
В данный момент алгоритм выходы в Тренды следующий: рейтинг поста больше 25 и более 80% плюсов. Сортировка в ленте осуществляется на основе двух ключевых параметров: процента положительных оценок и времени публикации поста.
Хотя лента «Тренды»(как и «Новое» и «Топ») визуально кажется бесконечной, посты на самом деле подгружаются постранично (пагинация). Это означает, что контент из бэкенда на фронтенд отдаётся не одновременно, а порциями. Введено ограничение в 20 постов на страницу для лент. Это решение позволяет ускорить загрузку контента и снизить нагрузку на базу данных.
Существующий алгоритм сортировки в ленте «Тренды» не является финальным, и мы планируем продолжить экспериментировать для определения наиболее оптимальных критериев сортировки. Как минимум, следующим шагом добавим влияние наличия тегов «Своё» и «Авторское» на упрощение выхода поста в Тренды. После добавления функционала скрытия постов продолжим искать наилучший алгоритм.
🖋️ Редактор постов
Добавлено ограничение по количеству символов в заголовках постов на Капибаре. Это необходимо для более красивых URL-адресов и менее загруженного внешнего вида сайта.
Ещё теперь можно загружать видео, правда пока что только с YouTube и Coub. В ближайшем будущем возможно расширение функционала возможностью добавления видео с других платформ, например из ВКонтакта. К сожалению, прямая загрузка видео на сайт пока невозможна ввиду ограниченного бюджета проекта. т. к. стоимость хранения и обработки зависит в том числе от количества просмотров.
👤 Профиль пользователя
Наконец-то можно поставить свою аватарку! Также близится к своему завершению доработка функции «О себе» - вы сможете написать какую-то фразу в своём профиле, которая будет видна остальным пользователям… Вернее, написать вы можете уже сейчас, просто пока что информация не сохранится. Но это скоро починим
Помимо этого, была исправлена ошибка 404, которая возникала при попытке доступа к страницам профилей пользователей.
И, наконец, важное изменение в создании профиля - нами была введена проверка на уникальность имени пользователя, игнорирующая регистр букв. Это означает, что имена типа "kapibar" и "KaPiBaR" теперь считаются идентичными с точки зрения системы.
🔨 Прочие Улучшения
Вёрстка. Исправлена вёрстка для обеспечения корректного отображения сайта на экранах с шириной 800 пикселей.
Были отрисованы новая иконка сайта и аватар по-умолчанию, спрототипированы страницы для удалённых по разным причинам постов.
Внедрено ограничение на количество запросов на логин, сброс пароля и регистрацию на уровне API. Эта мера безопасности направлена на борьбу с DDoS-атаками и другими видами злоупотреблений, повышая стабильность и безопасность платформы.
Определение темы. Теперь сайт автоматически подхватывает тему, установленную на устройстве.
Проведена работа по исправлению ошибок в русском языке на различных страницах сайта. Граммар-наци ликуют.
Устранено более 150 мелких и значительных ошибок, обнаруженных отважными авторам - альфа-тестировщиками и сообщенных через систему репортов.
🪲 Баги.
Мы понимаем, что вам важно видеть, какие баги есть и какие из найденных вами багов мы уже пофиксили.
Часто мелкие баги быстрее исправить «налету», чем добавлять в таски, описывать, пересылать и уведомлять. И поэтому сейчас мы работаем над автоматизацией, чтобы каждый найденный вами баг не остался без обратной связи от команды.
Вы присылаете баг-репорты в Телеграм-бота. Они все хранятся в сервисном телеграм-канале, мы их видим.
На прошлой неделе мы прикрутили автоматическое создание задач по баг-репортам на нашей доске в таск-трекере. И прямо сейчас работаем над обратным процессом. Т. е., когда задача отмечается как выполненная, будет отправляться уведомление обратно в Телеграм с обновленным статусом.
Также есть баг-репорты, которые не являются багами. Например, когда проблема не на сайте, а в куках пользователя. В таких случаях разработчик будет писать комментарий к задаче с инструкцией, что нужно сделать, чтобы проблема прошла, а бот будет отправлять этот комментарий пользователю.
🙏 Объявляется благодарность всем нашим авторам - альфа-тестировщикам!
Мы не можем упустить возможность выразить нашу глубокую благодарность всем альфа-тестировщикам, которые помогли и помогают нам обнаружить и устранить баги на нашей платформе. Ваша обратная связь была неоценимой, и мы благодарны за каждый отправленный вами баг-репорт! Ребята, вы - лучшие :)
🌟 А также Особая благодарность десяти самым активным тестировщикам:
Мы постоянно работаем над улучшением Капибары и ценим вашу обратную связь. Записывайтесь на альфа-тест, в данный момент набираем не только авторов но и активных комментаторов.
Сижу в купе ночного поезда Петербург-Москва. Жду отправления. Залипаю в телефоне.
Через какое-то время в купе заходят мои попутчики - мать с двумя детьми. Пятилетним малышом и девочкой-подростком, на вид лет двенадцати.
Мама очень стесняется и все время одергивает детей. Особенно девочку.
- Мам, а когда можно будет кипятку набрать?
- Кира, сядь и посиди спокойно.
- Мам, я залезу на верхнюю полку?
- Кира, сядь и подожди, пока тронемся.
- Мам, а что в этих коробках на столе? Можно я свою открою?
- Кира! Ничего не трогай. Сядь, пожалуйста и ничего не делай, пока поезд не поедет!
Сижу, не вмешиваюсь, но мысленно жалею девочку. Живой ребенок, любознательный. А тут сплошные запреты. Что за мама такая строгая?
Но тут Кира, к этому моменту угрюмо уткнувшаяся в телефон, спрашивает:
- Мам! Скажи свой номер! Тут ввести надо, чтобы к вайфаю подключиться…
- Так, Кира. - Строго обрывает её мать. - Давай ты спокойно посидишь пять минут, пока поезд не тронется? Давай ты ничего и никуда не будешь вводить? Ты мне в Крыму уже на семнадцать тысяч в интернете посидела…
Большинству пользователей известно, почему возник Вомбат. На этом я не стану заострять внимание.
А хочу обратить внимание на сложность разработки подобных сайтов. Даже на уровне MVP (минимально жизнеспособный продукт).
Даже если есть готовые наработки, то в любом случае надо продумать: модель, то есть схему базы данных, дизайн веб-морды, общее взаимодействие, то есть бизнес-модель,...
Независимо от всего разрабатываю своего бобра (это скорее будет что-то вроде Хабра, а не очередной аналог Пикабу). И уже раз десять сносил БД из-за невозможности внести изменения (миграции). Ну, может я такой рукожоп и просто не знаю как правильно сделать. 🤷♂️
Нужно продумать внешний вид сайта. Тут сильно помогает такой инструмент как Figma. Да, дизайнеры Figm-ой занимаются. 🙃После пары настроек пользоваться одно удовольствие. Но мало задизайнить. Надо это ещё и в код перенести. А это уже вёрстка. Довольно нудное занятие.
В общем, чего хотел сказать, захотите сделать свой Пикабу с блекджеком и плюхами, то готовьтесь к тому, что заебётесь...
В первой главе мы с вами узнали, как и где создавались первые "шахматные автоматы", которые были всего лишь имитаторами программируемых шахматных роботов. Сегодня знакомство с первыми настоящими шахматными алгоритмами и программами.
*** Глава 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 полуходов? Все это, конечно, можно сделать, посвятив этому процессу месяц или два, но это уже всё сделано до нас.
Этой весной моя коллекция мохнатых арахнидов наконец то разбавилась первым чешуйчатым шнурком, милейшим метром (ну, почти метром - 90см на сегодняшний) шипящего тактильного удовольствия. Пауки - это, конечно, здорово, но яд и очень немаленькие зубки явственно намекали, что давать их на руки для съемки будет проблематично, а поснимать хотелось. И вот, первая змея. На работе она вызвала небольшую панику и море любопытства (благо, смена попалась без выезда и я спокойно отсидел ее в помещении, со зверенышем, пригревшимся у меня на груди).
Та самая прелесть на прогулке у дома.
Шло время, змея перекочевала из маленького контейнера в большой, но разве матовая пластиковая коробка будет радовать глаз? На горизонте маячили террариум и день рождения, удачно дополнившие друг друга. Понятное дело, взять простой аквариум и накидать туда "всякого" - не наш метод. Гулять - так гулять, и я договорился с Викторией из зоомагазина BioBOX об оформлении террариума (можете кричать, что это реклама, всё куплено и вообще, но люди, на чьих сверчках я поднял три! поколения богомолов, не могут работать плохо (для тех, кто не в теме: у сверчков часто встречается какой-то вирус, который не вредит им, но выкашивает богомолов на раз-два, так что кормление ими крайне НЕ рекомендуется, как рискованное)).
- "Хочу вот так, только чтобы большой, как я, а может даже пошире" - уверенно, но не очень внятно обозначил я свои хотелки, потыкав для надежности пальцем в пару уже оформленных терров.
Вот в такую красоту я радостно тыкал пальцем и твердил "хочу, красивое!"
Шло время, в магазин приехал сам террариум, потом я ждал очереди и вот, наконец то, неделю назад моя прелесть оказалась дома. Да, его ждут перестановки (как минимум надо купить тумбу и убрать его с пола), скорее всего поставить в другую комнату, но главное, главное что он приехал!
Общий план
Теперь дома есть не только змейс, но и кусок искусственной скалы, с несколькими укрытиями и парочкой вмурованных коряг. В правом дальнем углу термоковрик, прогревающий пещеру, наверху лампа-обогреватель, подогревающая площадку, заодно и освещает террариум вечерами.
Слева влажная камера. Воздух в квартире достаточно сухой и, хоть полозы не самые требовательные к влаге змеи, я решил, что лишнее убежище, где можно продышаться, не помешает. Высыхает оно, кстати, очень быстро. Воду дважды в день заливаю.
Влажка. Сверху мини-лужа для воды, которая по словам производителя потихоньку проникает через поры в глине и дополнительно увлажняет укрытие.
Центральный камень, он же кормовой стол. Абсолютно натуральный булыжник, на который выкладывается мышиная заморозка. Так меньше риска, что вместе с едой змея заглотит и частички субстрата (разные щепки и т.д).
Высокоэстетичный череп. Ну блин, это мой первый террариум и первая змея. Конечно у нее в доме должен быть череп, как иначе то!
С таким оформлением в Питер ехать надо
Змеи любят забраться куда-нибудь поглубже, там свернуться поплотнее и максимально не отсвечивать, а раз так, то надо им обеспечить возможность отдохнуть с комфортом. По этому при оформлении в сам "ландшафт" было заложены две пещеры-укрытия, одна с подогревом у дна, другая ближе к вентиляционной решетке, с возможностью остыть в жарки летний день.
Пещера с обогревом
Прохладная зона
Кроме того, сам террариум получился очень фактурный и объемный, с множеством выступов и неровностей, искусственными растениями. Змея оценила. В первый день вытянулась шнурком во всю длину под потолком террариума, на второй день облюбовала пещеру, еще раз я видел ее спрятавшейся за "лианами" на коряге.
Иногда прячется тут, обвив ветви коряги
Часто греется в нижней пещере
А иногда просто гуляет
Или ждет, когда ее покормят
Кстати, если у вас возникли вопросы по последней фотографии: "что со змеёй", "почему такие мутные глаза", "она заболела" и т.д. Она в полном порядке, просто когда делались эти фотографии Бибра (дал же сын имечко) готовилась к линьке. При этом змея бледнеет, взгляд становится мутным, через несколько дней всё возвращается в норму и вот тут неопытного кипера ждет сюрприз. В первый раз я перерыл весь садок в поиске выполза (шкуры змеи после линьки) - нету. Но змея то уже нормального цвета, значит полиняла! Неужели съела? Спросил на форуме - нет, не едят змеи свою шкуру. Куда делся? Непонятно. И только к вечеру я узнал, что за 1-2 дня до линьки цвет возвращается в норму и это сигнал, что в любой момент можно ожидать начала процесса. Собственно, ночью Бибра этим и занялась, утром меня встречала вот такая картина:
90 сантиметров шкуры одним чулком - один из признаков, что змея здорова
А вот и обновленная хозяйка, успешно перелинявшая и ожидающая завтрак. 2 недели диеты, как никак. Есть то хочется!
P.S> А раз хочется, не грех и накормить. По традиции вк и ютуб.
Я ведь полез в керамику не из-за чайников и посуды. Глина мне нравится как пластичный и природный материал, с которым пусть и сложно, но очень приятно работать. А создавать мне всегда хотелось скульптуру и необычные предметы интерьера. Правда пошёл я к своей цели не самым коротким путём, а через стандартную для керамиста схему из чайников, кружек и всякой мелкой сувенирки. Однако, несмотря на все "повороты не туда" на этом пути, периодически я возвращаюсь к основной цели и пробую сделать что-то эдакое.
Вот, например, давно планировал собрать часы и наконец-то сделал прототип. Косяков напорол массу, но полезного опыта приобрёл ещё больше.
Лепил из дикой глины. Катал пласты и собирал из них основную форму, а на неё уже клеил детали. Обжигал на 1020 градусов. Мне так понравились высолы, открывшиеся на поверхности черепка после обжига, что решил их ничем не покрывать. Циферблат нещадно повело, поэтому задуманная схема его крепления пошла лесом, пришлось подключать орко-вандальные технологии. Электронный механизм в таких часах я использовал первый и последний раз. Очень сильно он удешевляет работу во всех смыслах слова. Поэтому теперь буду использовать только механику. Проконсультировавшись со знающими людьми, решил выкупать старые советские механизмы после ремонта.
В ближайших планах повторить эти часики, но уже немного в другой конструкции с простым заводным механизмом, а дальше, если будут заказы на такие изделия, брать серьёзные механизмы от морских часов.
Спасибо всем, кто дочитал пост до конца!
А часы эти стоят теперь в мастерской и напоминают мне, что время идёт и тратить его на неинтересные проекты не стоит.)
Уважаемые альфа-тестеры, от команды разработки хотелось бы сказать вам всем и каждому большое спасибо! За то, что не только замечаете недочеты, но и сообщаете о них!
А теперь немного суровой статистики, сгенерированной напрямую из нашей базы данных.
Вот так мы, альфа-тестеры, выглядим на карте.
За 10 дней альфа-теста было создано 338 постов, из них 251 опубликован, 62 удалено и 25 лежат в черновиках.
77 авторов написали эти самые 251 пост, к которым 96 комментаторов оставили 1080 комментариев.
Все эти посты суммарно были просмотрены 2420 раз (уникальные просмотры)
В целом мы больше на позитиве, и поставили 3570 оценок постам, из которых подавляющее большинство - плюсы. Минусов в районе 250 оценок
Намного меньше мы оценивали комментарии, всего 955 оценок и, опять же, большинство из них плюсы
Следующие графики показывают то же самое, но с разбиением по дням
Одна из частых ошибок молодых программистов — экономия времени на чтении. Читают текст недостаточно внимательно, не понимают, что требуется, как именно должен быть оформлен результат — и создают вообще не ту программу, тратя кучу времени.
Читать нужно раз 5. Даже если там 2 строчки — 5 раз хотя бы. Тогда шансов так ошибиться гораздо меньше.
Все началось с рабочей задачи по реализации весьма специфичной 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. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.
Вот поступил человек на курсы по программированию. И что-то не идёт оно, ничего не понятно. Остальные такие умные! Всё схватывают, всё успевают.
А он сидит и думает: «Ну всё, я тупой».
Но если догадаться поспрашивать этих успешных людей, вдруг выясняется:
- один 4 года до этого сам учился в свободное время
- другой уже работал программистом, просто был перерыв
- третий прямо сейчас работает, просто пришёл за бумажкой — и то, говорит, тяжеловато что-то
- и один на группу реально способный
ну, то есть до этого особенно не занимался, но с детства быстро любую область осваивает, куче вещей обучился быстро. Хотя это так-то тоже помогающий опыт.
В общем, у всех бэкграунд какой-то оказывается, как правило, и очень редко одарённость.
Комментарии