Психика – довольно парадоксальная вещь, которая подчиняется иной логике, нежели к которой мы привыкли. Несмотря на то, что главная функция психики – это обеспечение выживания индивида, на основе «субъективного отражения объективной реальности», иногда она работает против этой цели. И я говорю сейчас не про экстремальные варианты, вроде появления сверхидеи о питании солнечным светом и не про религиозные суициды во благо вечной жизни. Нет, я говорю об… учёбе, саморазвитии и познании мира.

И это странно, ведь для выживания нужно понимать мироустройство. Но почему же погружение в изучение этого самого мироустройства приводит к обратному результату – ступору, постоянному избыточному планированию, стрессу и дезадаптации? Почему люди, обладающие выдающимися знаниями: ученые, исследователи, профессора – уходят в эзотерику и лженауку? Почему многие из тех, кто должен лучше других понимать этот мир, сталкиваются с таким регрессом и отказываются от своих знаний? И можно ли с этим что-либо сделать?

Я достаточно давно изучаю особенности психики и личности как IT-специалистов, так и людей «от головы» в целом. И про особенности их личности писал ряд статей (часть 1, часть 2, часть 3, часть 4). Но сейчас, когда выборка стала больше и количество наблюдений кратно возросло, мне хочется копнуть чуть глубже и посмотреть не просто на личностные особенности, а на механизмы формирования этих особенностей у людей, обладающих эрудицией, интеллектом и способностью к абстрактному мышлению на более высоком уровне, чем в «среднем по больнице».

В мире интеграций REST API на сегодняшний день занимает по праву свое почетное, королевское место. Сегодня мало какой проект или продукт обходится без стандартных HTTP-методов и документации к ним.

Но если для REST API уже всемирную славу приобрел Open API со своей Swagger-документацией, которая внедряется практически повсеместно и является по праву, так сказать, золотым стандартом, то для брокеров сообщений и, в целом для асинхронного взаимодействия, в большинстве случаев дела обстоят далеко не так однозначно.

В данной статье я хотел бы подробнее остановиться на довольно молодом типе спецификации для асинхронного взаимодействия - AsyncAPI, который, на мой взгляд, имеет огромный потенциал и все шансы на массовое применение в будущем.

На некоторых порталах, в том числе и здесь, уже косвенно поднималась тема AsyncAPI и вызывала у авторов, как правило, смешанные чувства. Описывали преимущества и недостатки, приводили некоторые примеры. Справедливо отметить, что AsyncAPI, конечно же, не идеален.

Но если посмотреть на это с другой стороны: удобно ли будет разработчику читать ТЗ и другую документацию касаемо разработки интеграции по асинхрону, слепленную из кусков текста, таблиц, рисунков, непонятных ссылок и т.д.? Одно дело, если разработчик находится на проекте с самого начала и знает все тонкости и может сам что-то додумать. Но если человек придет на проект уже через один, два или более лет после начала проекта и увидит тонны макулатуры, которую как-то нужно читать и анализировать, то вот тут начинаются трудные времена.

Продолжаем писать собственные плагины для Obsidian. Первую часть статьи можете найти здесь. В ней мы:

Выяснили, что можно писать плагины даже проще, чем это предлагает делать официальная документация

Написали три маленьких плагина, которые уже вовсю используются на продакшене лично мной

Грозились написать четвертый финальный босс-плагин

Вот и приступим.

Когда мидл-разработчик дорастает до сениора, его, как правило, мучает вопрос: как правильно писать приложение? Понятно, что когда он был джуном, ему давали совсем атомарные задачи, и он развлекался покрытием тестов или написанием контроллеров. Переход в мидлы знаменуется назначением на разработчика более абстрактных задач вроде реализации сервисов, репозиторной части или интеграции с внешними сервисами посредством клиентов. Но в какой-то момент мидл начинает задавать самому себе вопросы: как найти единственно правильный способ написать приложение с нуля?

Если Вы - мидл, и Вас стали мучать такие вопросы — поздравляю, Вы на верном пути. Ведь профессиональный рост не происходит с переводом на должность - новый сениор должен родиться, и это как раз муки такого рождения.

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

В начале карьеры мне тоже казалось, что каждый разработчик должен следовать строгим правилам и рекомендациям. Я думал, что чем больше знаний, тем лучше результат. В итоге, передо мной открывался целый мир идеальных паттернов, архитектур и сложных решений. Но со временем я понял: важно не только читать и понимать теорию, но и уметь применить её в реальной жизни. И что ещё важнее — делать, а не спорить.

В этой статье я расскажу о своих ошибках, которые я допустил, пытаясь быть слишком «правильным». Как я заморачивался с кэшированием, пытался сделать универсальные компоненты и топил проект в лишних сложностях. Эти ошибки научили меня одному: не всегда нужно гнаться за идеальностью.

Давайте посмотрим, как я заморачивался с вещами, которые в итоге только усложнили задачу, и что из этого получилось.

Всем привет, сегодня речь пойдет про Android TV. Мне обход именно на телевизоре показался самым проблемным и сложным. Так как дома имеется несколько лишенных ютуба телевизоров, а еще больше ожидают настройки у друзей и знакомых - решил собрать все найденные способы обхода блокировки.

Notion объявили, что уходят из России и 9 сентября блокируют аккаунты пользователей.

Пока не понятно до конца, касается ли это в том числе пользователей, которые используют бесплатный функционал.

Для любителей Ноушена это большая проблема, для любителей Обсидиана это возможность сказать: "Мы же вам говорили" и начать хвастаться своими кастомными обсидианами.

Я сам долгое время пользовался Ноушеном. Первое знакомство было умопомрачительно, захватывающе. Чего только стоят мои конспекты с футбольными тактиками, где я ковертировал видео с матчей и тренировок в гифки, а потом добавлял к конспектам.

Год назад перевёл все свои заметки в Обсидиан. Причина простая: Обсидиан может гораздо больше вещей, чем Notion.

О том, почему не стоит расстраиваться и даже наоборот, открыть большой, новый мир возможностей...

«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

С учетом стремительного прогресса в области технологий и возрастающей сложности программных приложений, овладение принципами системного проектирования становится критически важным для разработчиков, стремящихся создавать эффективные системы. Не имеет значения новичок вы или опытный специалист: освоение этих принципов позволит вам разрабатывать надежные и масштабируемые программные системы, отвечающие требованиям современных приложений.

Далее мы рассмотрим каждый из принципов более детально, чтобы понять их суть и способы применения в разработке приложений.

Мой маленький шажок на пути подготовки к написанию шахматного движка. Написание простейшей нейронной сети, выяснение, что это за зверь такой.

Удаленный режим работы и хобби, связанные с сидячим образом жизни, привели мою спину в неблагоприятное состояние. Трех и даже пяти сессий физической активности в неделю при отсутствии необходимости постоянно двигаться не достаточно для нормального функционирования.

Надо было что-то менять. Нейрохирург посоветовал завести собаку, чтобы не было возможности избежать прогулки хотя бы раз в день. Я же пошел другой дорогой, о которой хочу рассказать.

Революция в области искусственного интеллекта переформатирует все отрасли нашей жизни, с одной стороны обещая невероятные инновации, а с другой ー сталкивая нас с новыми вызовами. В безумном потоке изменений эффективная обработка данных становится приоритетом для приложений, на основе больших языковых моделей, генеративного ИИ и семантического поиска. В основе этих технологий лежат векторные представления (embeddings, дальше будем называть их Эмбеддинги), сложные представления данных, пронизанные критической семантической информацией.

Эти вектора, созданные LLMs, охватывают множество атрибутов или характеристик, что делает управление ими сложной задачей. В области искусственного интеллекта и машинного обучения эти характеристики представляют различные измерения данных, необходимые для обнаружения закономерностей, взаимосвязей и базовых структур. Для удовлетворения уникальных требований к обработке этих вложений необходима специализированная база данных. Векторные базы данных специально созданы для обеспечения оптимизированного хранения и запросов векторов, сокращая разрыв между традиционными базами данных и самостоятельными векторными индексами, а также предоставляя ИИ-системам инструменты, необходимые для успешной работы в этой среде нагруженной данными.

Если у вас есть большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема всей системы была всегда на 100% актуальной?».

Обычно, в компаниях есть свои практики формирования архитектурных схем и ведения документации, что частично решает поставленный вопрос. Но проблема такова, что часто схемы со временем начинают расходиться с реальностью: новые интеграции добавляются, а старые — уходят, а актуализация схем вручную происходит не всегда своевременно.

Чтобы решить проблему мы автоматизировали отрисовку схем опираясь на метаданные IT-систем. Мы создали отдельный микросервис, который этим занимается и назвали его «Architect». О том как это происходит и как работает Architect я расскажу в этой статье, а также дам несколько советов, которые помогут внедрить то же самое у вас в компании.

Меня зовут Валя Борисов, и я — аналитик в команде Ozon. Задача нашей команды — создавать инструменты для мониторинга и анализа скорости. 

Наши усилия направлены на то, чтобы в реальном времени следить за тем, как быстро работают наши сервисы и платформа. Благодаря инструментам, которые мы создаём и поддерживаем, команды разработки получают представление о том, как пользователи видят работу нашего сайта или приложения. Мы помогаем выявлять причины деградации скорости и определять узкие места в инфраструктуре.

Наши дашборды играют ключевую роль в предоставлении информации о скорости работы платформы. Вместе с командой аналитиков я занимаюсь созданием и поддержкой этой системы в Grafana. Мы стремимся делать ее не только информативной, но и быстрой, стабильной и удобной для всех пользователей. В этой статье я хочу поделиться методами и приемами, к которым мы пришли в процессе работы.

Оффтоп

Наш рассказ — это гид автостопщика, некое summary тех вещей, которых нам не хватало при знакомстве с Vault. В нем мы сделаем несколько остановок: поговорим в целом про управление секретами, о том, почему мы рекомендуем именно Vault; рассмотрим, как Vault работает; поделимся лайфхаками по работе с секретами и болью о том, чего нам не хватает в продукте.

Около двух лет назад вышла небольшая статья Kafka Streams — непростая жизнь в production, в которой я описывал сложности, с которыми наша команда столкнулась при попытке решить задачи проекта с помощью kafka-streams. Эксперимент вышел неудачным, и мы в итоге совсем отказались от этой технологии. Вместо нее решили попробовать Clickhouse (CH), и сейчас уже можно сказать, что эта база нам очень хорошо подошла и отлично решает почти все задачи, которые нам ставит бизнес. В этой статье я расскажу об особенностях использования CH.

Всем доброго дня ! Недавно я оценил, как же это классно: организовывать свою активность, через пространства, и спешу этим поделиться с вами.

Недавно я решил послушать на youtube, что говорят другие об организации своей активности. Подучиться, присмотреться и возможно внедрить. Мне попалось видео, где автор рассказывает, как организовать свои задачи используя концепцию PARA. Послушал, и ничего конечно же сам делать не стал.

Потом случилось так, что мой браузер захотел обновиться, а это желание у него возникает каждую неделю, и сижу я на Vivaldi (и да он бесплатный, лицензия BSD, а вот облако проприетарное и за денежку). Ребята пилят довольно бодро, постоянно выкатывают обновы.

И там появились пространства, ну и тут я  такой, оу – нужно посмотреть, разобраться зачем эту бесполезность прикрутили. И оказалось очень здорово. Я сел и на листке бумаги набросал свои пространства, вот что у меня получилось.