Я давно пишу на Go, но раньше у меня был довольно плотный опыт во фронтенде. Поэтому, когда я захожу в терминальные интерфейсы, я всё ещё ожидаю какого-то базового UX — чтобы было понятно, что происходит, что можно нажимать, и что именно ты сейчас делаешь.
Но каждый раз, когда мне нужно было поработать с TUI — особенно в задачах, я чувствовал, как мой мозг вытекает через уши.
Этой весной, с 8 апреля по 23 мая, Хабр совместно с GitVerse запустил сезон Open source. Идея была простой: предложить IT-сообществу поделиться своими историями работы с открытым кодом.
За время сезона было опубликовано 80 статей, которые в совокупности набрали около полумиллиона просмотров, 2000 плюсов и 1500 комментариев. Авторы делились опытом — от первых робких коммитов в популярные репозитории до создания собственных проектов, изменивших жизнь тысяч разработчиков. А читатели, в свою очередь, поддерживали, хвалили, критиковали и даже рассказывали, как тот или иной проект изменил их работу или жизнь.
У вас есть мобильное устройство с процессором RISC-V? Вопрос странноватый, но ответ может быть сложнее, чем кажется. Например, архитектуру RISC-V использует чип безопасности в Google Pixel 6. Конечно, процессоры смартфонов в основном задействуют архитектуру ARM — созданную, кстати, по принципам архитектуры сокращенного набора команд (RISC, Reduced Instruction Set Computer). Зачем же здесь RISC-V? Далее мы рассмотрим этот вопрос и оценим, насколько сама архитектура готова к такому применению.
Во второй части сравнительного обзора продолжается анализ ведущих интернет-сканеров и OSINT-платформ. На этот раз внимание сосредоточено на Censys и FOFA — двух мощных инструментах, каждый из которых предлагает уникальные подходы к сбору и структурированию данных об открытых сервисах в интернете. В статье рассматриваются архитектура платформ, синтаксис запросов, охват портов, возможности поиска по сертификатам и телу веб-страниц, а также примеры реального применения.
После первой статьи про стандарты разработки и зарождение Open vAIR остался резонный вопрос: «А что там под капотом?». Отвечаем.
Эта платформа виртуализации создана для тех, кто хочет развернуть систему быстро, понять архитектуру без боли и не зависеть от чёрных ящиков с лицензией.
Внутри — модульный backend, изоляция через RabbitMQ, REST API и документация, которая обновляется вместе с кодом, а не спустя квартал.
В этой статье разберём, чем Open vAIR отличается от тяжёлых решений, что умеет прямо сейчас, какие модули в приоритете — и в каких сценариях он уже «заходит в прод».
За 13,5 лет я создал 12 опенсорс-проектов для платформы .NET и особое место среди них для меня занимает проект WebMarkupMin. Я не могу точно сказать, что мне больше всего нравится в нем: интересная исследовательская работа, лавры первопроходца на платформе .NET или не уходящая с годами актуальность.
В этой статье будет мало технических подробностей, потому что подобных статей о WebMarkupMin написано предостаточно. Здесь будет сделан акцент на разработке концепции опенсорс-проекта, его продвижении и взаимодействии с другими людьми.
Автор статьи — мобильный разработчик, который сам поднял инфраструктуру для стартапа на одной небольшой виртуалке. Вы узнаете, как он выбрал и внедрил werf, какие проблемы решал с помощью SOPS, как организовал хранение и шифрование секретов, и почему GitOps стал для него спасением.
Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией.
В нашем чате и у пользователей регулярно встает вопрос переезда в Gramax c других платформ. Переезд с Confluence и Notion мы сделали прямо в интерфейсе приложения, а с Yandex Wiki — отдельной утилитой. Нет, мы не поленились, просто заметили, что сообщество Yandex Wiki такое давно просит: пример №1 (367 голосов), пример №2 (874 голоса).
В этой статье расскажем, как воспользоваться утилитой и выгрузить всю свою документацию из Yandex Wiki в обычный Markdown.
Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.
Но из этих историй часто ускользает человеческая сторона: мы занимаемся опенсорсом не только для того, чтобы сделать решения с открытым кодом более облачными, не только потому, что это модно, но и потому, что это приносит пользу не только продукту, но и самим разработчикам‑контрибьюторам.
На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).
В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.
Здравствуйте, я загружаю много (как посмотреть) фото (и не только) в Wikimedia Commons. Вместе с Википедией, это важный сервис, особый: некоммерческий, тоже живет на донаты, без рекламы и платных аккаунтов, всё содержимое в свободных лицензиях. Базовый путь загрузки - через веб клиент, который сложный, это не в Фейсбук перетянуть фото. Экосистема, инфраструктура, комьюнити огромно, есть десяток инструментов загрузки. И внезапно, за вечер, я сделал, по моему мнению, один из лучших инструментов, о котором мечтал годами. Получилось так быстро потому что это скрипт для gThumb, который использует официальное SDK Pywikibot на Питоне, и библиотека для чтения/записи IPTC тегов - где указываются категории, категории это важно - Коммонс это не помойка, при загрузке и после ребята стараются систематизировать артефакты, у каждого файла может быть много категорий.
В предыдущей статье мы рассмотрели базовые принципы работы DI-контейнера CherryPick: архитектуру, компоненты (Scope, Module, Binding), и простые примеры использования на Dart/Flutter. Сегодня расскажу о новых возможностях.
Бывало ли у вас так, что вы придумали у себя в голове идеальное приложение, в котором есть все вам необходимое (ну или хотя бы какой‑то обязательный минимум)? Вот вы нашли приложение, которое должно решать те задачи, что вы себе придумали, но как только принялись его проверять в действии, пришли к выводу, что все совсем не так радостно.
Вот вы сказали себе: «Ну ладно, это же опенсорс! Значит можно попробовать что‑то с этим сделать своими силами. Заодно и внести посильный вклад в развитие этого продукта. Что может быть лучше?» Но реальность оказалась иной. Код для непрограммиста оказался довольно сложный, принятая разработчиками архитектура приложения также вызывает вопросы (конечно, скорее всего только у меня) и т. д.
К чему это я? Начну с небольшой предыстории.
Привет, Хабр!
Прежде чем я начну рассказ о своем проекте, хочу выразить огромную благодарность всем тем бесчисленным программистам, разработчикам и энтузиастам, которые на протяжении многих лет делились своим кодом, знаниями и опытом в интернете. Ваши открытые проекты, ответы на Stack Overflow, статьи, туториалы и обсуждения на форумах стали той самой питательной средой, на которой обучались большие языковые модели (LLM), включая и ту, что помогала мне. Без вашего вклада в общее дело, такие мощные ИИ‑ассистенты, которые сегодня так сильно облегчают и ускоряют разработку, были бы просто невозможны. Спасибасвам за то, что делаете мир разработки открытее и доступнее!
Исходный код проекта «Storog» полностью открыт и доступен на GitHub.
Я довольно давно искал менеджер заметок после того, как ушел Notion и заблокировал мой аккаунт. Я перепробовал довольно много всякого. Где-то меня не устраивал интерфейс, где-то глючная P2P-синхронизация, где-то отсутствие нативных приложений.
Сегодня расскажу про то что нашел для и себя и как это похостить.
- Зачем идете в горы вы?
Ведь Эльбрус и с самолета видно здорово!
Приветствую! Я Владислав Щапов и я обожаю манулов. А еще я разработчик в компании НИЦ ЦТ, которая разрабатывает операционную систему для российских процессоров Эльбрус. Одной из моих рабочих задач было провести тестирование статического анализатора PVS-Studio для проверки С и С++ кода на Эльбрусе. Эта задачка была непростой и очень напомнила мне восхождение на гору, когда за каждым пройденным испытанием сразу возникает какой-то новый вызов. Но манулы не сдаются!
Несомненно, появление концепции лайка открыло новую страницу в механизме feedback. Не только для крупных компаний, но и для мелких девчушек, которые гоняются за лайками от своих сверстников. Однако, в какой‑то момент времени, лайки стали тормозить развитие механизмов получения того самого feedback. Зачем что‑то выдумывать новое, если уже есть лайк, понятный даже макаке‑резус и регулярно повсеместно используемый? Концепция лайков противоречит количественной социологии? Да ну ее на фиг, эту социологию! Одним лайком сложно получить качественный feedback? Зато лайк это уже традиция — так еще наши прадеды делали, деды, отцы делали, и мы делать будем, и наши дети и правнуки, ну Вы поняли. В данной статье не только делается попытка поиска следующего за лайком механизма feedback. Но и приводится вместе с исходным кодом действующий компонент на React TypeScript. Если кому интересна тема поиска новых механизмов feedback, добро пожаловать под кат!
Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.
На таких объёмах нам важно быть эффективными — умеренно расходовать ресурсы сборочных ферм и при этом собирать проекты как можно быстрее, чтобы документаторы могли увидеть финальный результат без смены контекста на чай.
Со временем, скорость CLI заметно деградировала. С одной стороны, платформа прирастала полезными функциями, это увеличивало время обработки контента, с другой — размер документации вырос и для некоторых продуктов перевалил за тысячу файлов.
Больше всего от растущего времени сборки страдали технические писатели: для просмотра внесенных изменений им требовалось собирать документацию целиком и на больших проектах это стало приводить к ожиданию более 10 минут. С десятками тысяч правок документации ежедневно эти десятки минут складываются в человеко‑месяцы простоя, которые никому не идут на пользу. Поэтому мы приняли решение всё это основательно причесать.
Баги в коде — явление нередкое, но сегодня мы исследуем не просто ошибки, а настоящие космические баги! Что скрывает проект, созданный в недрах NASA? Готовьте свои шапочки из фольги!
В новом материале DevOps-инженер Максим Кульвинский делится подробным обзором RBAC Wizard — свежего Open Source-инструмента для визуализации и анализа системы доступов в кластере. Разберёмся, как быстро развернуть утилиту с помощью Helm, посмотрим на её возможности и ограничения, а также выясним, кому и в каких случаях она может реально облегчить жизнь.
