I ran into a very practical problem after doing a lot of local work with AI agents. I had Codex projects, Claude Code projects, regular repositories edited with agents, drafts, pipelines, instructions, skills, artifacts, and several machines. At some point it became hard to tell where the current version of a project lived, which files were safe to push, where agent instructions belonged, and where source code had already been mixed with logs and intermediate output.

That is why I built AI Workspace System: a small set of shell scripts, conventions, and Markdown documentation that makes local AI-agent work predictable. It is not an IDE and not an agent orchestrator. It is a thin infrastructure layer around Git, GitHub, Codex, and Claude Code.

The core idea is simple: all projects should be visible from one list, instructions should follow one structure, sync should be safe by default, and machine-specific details should not live in the repository.

У меня MacBook Air M4, ПК под Ubuntu 24.04, консальные Claude Code и Codex (каждый хорош немного под свои задачи, как по мне). Я люблю Ubuntu, но вот в поездках Mac прям незаменим — с ним удобно работать, батарея живет достаточно долго, даже в самолете можно комфортно что-то тыкать тачпадом. При этом яблочную экосистему я не люблю, Ubuntu мне ближе и приятнее в использовании. Важный момент: я не программист, так что большая часть моих проектов — это всякая маркетинговая, менеджерская и редакторская штукенция. Поэтому у меня нет под это всё каких-то IDE и т.п. Конечно, разработчики и другие инженеры обычно работают с кодом, а потому просто коммият всё напрямую в гитхаб.

Но к делу. У меня постоянно запущено по 6-10 окон Claude и Codex в терминале и я заколебался проекты синхронизировать через Избранное телеграма — зипами. Плюс хочется, чтобы проекты нормально работали и в той, и в другой нейронке. То есть мне понадобилась какая-то система синхнонизации проектов между разными устройствами и разными нейронками.

Сегодня наконец собрался с силами и доделал такую — выложил ее под Apache 2.0 на гитхабе, можно пользоваться, форкать, дорабатывать и выражать своё «фи» в ишшьюсах и комментариях. Наверянка уже кто-то что-то такое себе делал и я просто изобретаю велосипед. Но что ж теперь поделать, я его уже переизобрел.

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

Всем привет. Мы в Ænix давно занимаемся Kubernetes-платформами, bare metal-инфраструктурой и Cozystack, поэтому тема блочного хранилища для Kubernetes у нас не теоретическая. Это та часть стека, где красивых абстракций быстро становится мало: надо переживать падения нод, понимать топологию, реплицировать данные, не ломать PVC, дружить с CSI и при этом оставаться предсказуемыми для операторов.

Сегодня хотим показать первый публичный результат этой работы — Blockstor 0.1.0.

Blockstor — это открытая система управления распределенным блочным хранилищем для Kubernetes. Она использует DRBD для репликации данных, совместима с REST API LINSTOR и написана на Go как самостоятельная clean-room реализация. Код распространяется под Apache 2.0.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

Когда ви-си загнулся окончательно, появилось немало статей с подборкой ресурсов, которые этот самый ви-си могут заменить. Если говорить грубо и прямо, то фактически, контент-маркетологи и разные сомнительные личности, убившие в свое время этот самый ви-си, стали составлять подборки площадок, на которые нога их брата еще особо не ступала. Один из таких ресурсов стал Хабр.

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

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. Если рынок не начнет смотреть на Kubernetes как на Linux Kernel, это заведет нас в тупик, и вот почему...

Четыре года мы развивали и улучшали werf 1.2, но теперь наконец‑то выпустили стабильную werf 2.0. Причина простая — последовательно накопилось множество улучшений (300+ релизов!), а кроме того, мы доработали новый движок развёртывания Nelm, и в werf 2.0 это единственный движок. Старый движок удалён. Nelm обратно совместим с Helm 3, поэтому никаких особых изменений в чартах не потребуется — они будут развёртываться так же, как и раньше.

В некоторых случаях у Nelm отличается поведение: например, у него более строгая валидация чартов, поэтому, хотя Nelm и доступен в werf 1.2, по умолчанию мы его включили только в werf 2.0.

Рассказываем, зачем мы сделали Nelm, что под капотом werf 2.0, как werf будет развиваться в будущем и как ее попробовать на своем проекте уже сейчас.

3 апреля на сайте InfoWorld вышла статья известного публициста на тему Open Source и юриста Matt Asay под названием «OpenTofu, возможно, демонстрирует нам, как не надо делать форк». Лидер-абзац в статье довольно жёсткий: 

Не согласны с лицензией? Просто сделайте форк проекта, но не выкидывайте его код — говорите, что он всегда был доступен публично. Сравните код и лицензию HashiCorp с версией OpenTofu.

Разберемся в этой истории последовательно — кто прав, кто виноват и чем всё закончилось.

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

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

Мы во «Фланте» любим Open Source — причем не только пишем свои открытые инструменты (werf, shell-operator, grafana-statusmap, сommunity-версия Deckhouse), но и активно участвуем в разработке различных проектов — участвуем в KEP’ах Kubernetes, в составе небольшой группы разрабатываем Dex, вносим вклад в Istio, передаем патчи и сведения о найденных багах в Cilium.

Поэтому мы решили написать несколько материалов о том, какие возможности для контрибьюторов предлагают известные в мире Open Source- и Free Software-организации. В этом материале мы рассмотрим Linux Foundation, его дочку — CNCF и европейское отделение Free Software Foundation. Сразу отметим, что участвовать в Open Source-проектах можно, даже не будучи программистом, — есть немало задач, связанных с продвижением, контентом, переводами, менеджментом. 

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.

Месяц назад компания «Экспресс 42» вместе с партнерами (одним из которых как раз был «Флант») выпустила подробный отчет на 75 страницах о состоянии DevOps в России. В этой статье мы бы хотели более подробно рассказать, какие инструменты и операционные системы компании используют для работы с инфраструктурой, как меняется их проникновение от года к году, как продвигается импортозамещение и что именно российские компании понимают под этим термином.

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

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

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.

Без правильной обратной связи в команде даже успешные компании могут недополучать до 22% выручки. К такому выводу пришли исследователи из Gallup и Workplace Medicine. Культура продуктивного фидбэка внедряется по двум направлениям: постоянное обучение сотрудников правилам обратной связи и организация системы обратной связи.

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

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

— Личная производительность может повыситься на 39%.

— Количество прогулов может снизиться на 41%, а текучка — на 59%.

— Эффективность руководителей может вырасти на 71%.

— Удовлетворенность клиентов — на 10%.

Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.

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

Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.

Это вторая часть материала о «синдроме самозванца». В ней мы вместе с Еленой Станковской, кандидатом психологических наук и практикующим консультантом разберем, почему возникает этот синдром, как с ним справиться и какие типы «самозванцев» выделяют ученые. Основа статьи — международные исследования и многолетний практический опыт Елены.

Синдром самозванца. Часть 1: что это, как его распознать и надо ли идти к психологу