Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?

Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.

Django — самый популярный Python web-framework. За больше чем 10 лет оброс огромным слоем возможностей. Среди них можно выделить — Django Admin — это готовый CRUDL интерфейс с поиском, фильтрами и хитрыми настройками.

Каждый раз стартуя проект на Django, удивляюсь насколько круто иметь админку — web интерфейс просмотра данных. Да еще и бесплатно.

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

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

Заводим трактор: переезжаем с QMake на CMake?

По дороге заглянем на улицу "Кросс компиляторщиков", в сквер "Систем сборки" и посидим в баре "Управления зависимостями". Заодно увидим тех, кто использует Qt в embedded linux.

Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.

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

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

При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19. 

Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее. 

Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов. 

Всем привет! Мы продолжаем разбирать наши решения. Сегодня расскажем о том, как, используя генератор Material for MkDocs, можно создать несложный, но удобный статический сайт с документацией (и не только!).

А ещё как встроить его в CI/CD для автосборки и автопубликации (мы используем Gitlab CI, о чём подробно рассказывалось в предыдущем туториале), а также как использовать плагины к генератору чтобы, к примеру, создавался не только сайт, но и его pdf-представление.

Добро пожаловать под кат!

Привет, Хабр.

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

В этой статье будет показано как создать Rust бэкэнд, который использует MongoDB, документо-ориентированную БД, для хранения данных и Redis для кэширования, ограничения количества HTTP запросов и нотификаций пользователя. Для большей наглядности созданное приложение также будет предоставлять REST API. В итоге будет получена следующая архитектура:

MongoDB является хранилищем, в то время как Redis используется для следующего:

• кэш (включая изображения)
• ограничение количества HTTP запросов
• нотификации с использованием паттерна publish-subscribe

Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.

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

Но что такое пользовательская история?

Чтобы ответить на этот вопрос, давайте разделим это понятие на части:

Представьте ситуацию: впереди выходные, а у вас есть достаточно нагруженная малинка и вы — ради эксперимента — хотите посмотреть, что ML умеет на мощностях RPi, но не хотите слишком перегружать машину, даже всей облегчённой версией TF. Что можно сделать? Мы уже писали о классификации мусора с помощью RPi, а сегодня, к старту курса о глубоком и машинном обучении, делимся переводом руководства, автор которого приводит простейший пример работы с необходимым минимумом TFLite. Выводы делаются моделью менее чем за секунду, при этом не нужно устанавливать весь пакет TensorFlow; используется только tflite_runtime, поддерживающий класс Interpreter.

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

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

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

Подобно печенью, которое остается на тарелке несъеденным, возможно, в Scrum вносится слишком много необдуманных замен, которые влияют на успех затеи. 

Давайте рассмотрим некоторые подмены, которые могут повлиять на вашу успешную Scrum-среду.

Linux старается оптимизировать использование памяти, занимая свободное место кэшем. Если память никак не используется, то это память, потраченная впустую.

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

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

Причина этого исключительно в том, что оперативная память используется на полную мощность, и других симптомов, кроме случайного эпизодического увеличения задержек, может и не быть. Такая же картина может наблюдаться, если жесткий диск не справляется с чтением и записью. Влияние может быть и на такие компоненты операционной системы как сетевая карта / iptables / ebtables / iproute2 — вместо реальной причины вы видите проблемы в сетевой задержке. В этой статье обсудим это подробнее и посмотрим, как минимизировать воздействие на систему.

Сегодня мы рассмотрим сбор и визуализацию метрик производительности Red Hat Enterprise Linux 8 с помощью инструментов Performance Co-Pilot (PCP), Grafana и Bpftrace, а также новые возможности по контролю производительности, которые появились в веб-консоли RHEL 8.4.

Привет, Хабр! Меня зовут Сергей, я работаю IT Head в компании Quadcode. Сегодня хотел бы рассказать о том, как я решил проблему с хранением паролей в открытом виде в коде одного из моих pet-проектов. Думаю, это знакомая для многих ситуация. Знакомая — и неприятная.

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

Всем приветы. А вы писали новый сервер с нуля? Какие технологии использовали? А рассматривали какие-либо варианты кроме старого доброго REST ? А что есть еще что-то ? С такими вопросами я когда-то пришел к своему лиду.  Да, для меня было открытием, что можно использовать не только REST для обмена сообщениями между сервером и клиентом. Ах да, конечно я знал про SOAP, но использовать его уж очень не хотелось. Оказалось, что можно попробовать использовать Thrift или например gRPC. От Thrift пришлось отказаться по ряду причин, которые не сильно важны в данной статье. Кстати, возможно Thrift это именно то что вам нужно. 

Так что же такое gRPC и в чем его отличие от, уже ставшего классическим, REST? Лучше ли gRPC? Может gRPC это снова хипстерская технология, которую все скоро забудут?

   Не для кого ни секрет, что REST доминирует в современном мире API, особенно, когда речь идет о веб-приложениях и инфраструктурах, на основе микросервисов. Мало кто даже вспомнит, про то что микросервисы могут общаться по другому. Это наверное самый популярный ответ на собеседовании. Да если добавить еще feign клиента из Spring, то получается совсем красота и минимальные трудо затраты. Но для определенного набора сценариев использования, модель gRPC начала играть небольшую, но важную роль. Давайте попробуем разобраться, когда же нам стоит использовать REST, а когда gRPC.

В разгар карантина мы с друзьями решили записать подкаст, для души, желательно бесплатно, и обязательно удаленно: они в Ростове, я в Лос-Анджелесе. Совсем бесплатно не вышло, но за полгода мы набрали солидный набор приемов и инструментов для максимально простого и дешевого старта, которыми спешу поделиться.

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

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

Из цикла "Микросервисы или смерть"

Решаемая проблема: монолитное приложение на Node.js раньше, в развернутом состоянии, занимало 0.2 Гб всего. Теперь же, разбитое на 33 микросервиса, занимает 33 * 0.1 = 3.3 Гб. Можно ли избежать подобной издержки? -- можно! В статье мы избавимся от лишнего веса.