21 марта Redis Ltd. объявила, что, начиная с Redis 7.4, ее «in-memory data store» будет выпускаться под несвободными лицензиями с доступным (source-available) исходным кодом. Новость малоприятная, но вполне ожидаемая. Необычно в этой ситуации обилие альтернатив для тех, кто хочет остаться со свободным ПО: есть как минимум четыре варианта замены, включая уже существующий форк под названием KeyDB и недавно анонсированный проект Valkey от Linux Foundation. Вопрос теперь в том, что предпочтут пользователи, провайдеры и создатели дистрибутивов Linux.

Согласно официальному сайту, chi — это легковесный, идиоматический и композируемый маршрутизатор для создания HTTP-сервисов на Go. Он на 100% совместим с net/http и довольно легок в обращении, однако его документация предназначена скорее для опытных разработчиков, чем для новичков, поэтому я решил написать серию статей, в ходе которых мы будем постепенно развивать и перерабатывать простейший CRUD, написанный на chi.

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

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

В статье мы разберем что такое „переусложнение“, дадим ему определение и на реальных примерах разберем во что это выражается и как с этим бороться.

Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных.

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

Под Новый Год мы с женой пересматриваем одну популярную магическую сагу — хочется знаете ли в жизни волшебства. В IT волшебства тоже хватает — от танцев с бубнами до самых современных технологий, принцип работы которых проще объяснить тёмной магией. Так, например, бытует мнение, что настройка service mesh — это магия, подвластная лишь волшебникам DevOps. Но у нас в Альфа-Банке разработчики исторически не маглы, а, как минимум, полукровки, поэтому имеют право приобщиться к волшебному миру.

В этой серии статей я хочу поделиться опытом изучения технологии service mesh, а именно Istio, на примере практической задачи, возникшей какое то время назад в одной из систем Альфа Банка, системным архитектором которой я являюсь.

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

Вторая статья будет посвящена нагрузочному тестированию и выводам об эффективности полученного решения.

Друзья, всем привет! Сегодня я хочу рассказать вам про самую простую и доступную для понимания нейросеть, которая создает изображения по вашему текстовому описанию. Она называется Fooocus и основана на знаменитой Stable Diffusion XL. Это идеальное решение в качестве вашей первой нейросети, и необходимый инструмент для любого дизайнера или контент мейкера.

Внутри много тяжелых изображений.

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

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

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

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

Итак, я зашел в раздел с постами и там увидел диаграмму (пик рилейтед).

А под ней ссылка на статью «Разработчики - в стойло, менеджеры в - башню из слоновой кости: создаем касту избранных в 4 шага».

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

Оформление заказа – один из последних шагов на пути клиента к покупке в интернет-магазине, и на этом шаге лучше не ставить ему палки в колеса.

Как сделать выбор адреса доставки, пункта выдачи заказов, даты и времени максимально удобным?

Разберем в этой статье. Как всегда, детально и с примерами.

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

Первые дни Crytek

Мои требования к идеальному движку:

• Желательно self-hosted — я пережил много закрытий сервисов, от narod.ru до google+ и точно знаю, что рано или поздно все протухает, поэтому надежнее всего держать контент у себя. Также посты могут удалять по каким-то фейковым жалобам или по DMCA, как это происходит на Medium и LiveJournal.
• Возможность подключения своего домена — мне нужен сайт-визитка со всеми проектами и ссылками в одном месте, где можно разместить портфолио, резюме, контакты.
• Минимум телодвижений и интерфейса — в идеале интерфейса CMS вообще не должно быть видно, админская панель не нужна, посты должны редактироваться, создаваться и просматриваться в одном месте.
• Полноценный WYSIWYG редактор — поддержка разметки Markdown и обработка её в реальном времени, подсветка кода, вставка картинок из буфера обмена.
• Нормальные комментарии — возможность оставлять анонимные комментарии и авторизовываться через максимум соц. сетей для персонифицированных комментариев.
• Минималистичный внешний вид — я не хочу заниматься версткой и темами, подходящее оформление должно быть из коробки.

Дисклеймер: