С момента публикации концепции Twelve-Factor App значительно изменилось то, как мы создаём, упаковываем и развёртываем приложения. Контейнеры, Kubernetes и облачные технологии стали основными технологиями, которые позволяют нам создавать переносимые, масштабируемые и надёжные приложения. Тем не менее 12 факторов, сформулированных в концепции, всё ещё актуальны в современном технологическом стеке.

Перевели статью, в которой описывается методология Twelve-Factor App и применение её концепций в контексте контейнеров и Kubernetes.

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

В начале августа некоторые интернет операторы и провайдеры начали блокировку протокола WireGuard в РФ по его рукопожатию.

Лично испытывал блокировку у Мегафон и Теле2, но не заметил у Ростелеком. VPN по-прежнему работал через последнего.

Очень не хотелось отказываться от Wireguard в пользу прокси-серверов в духе VLESS+TLS-Vision, в виду того, что все наши пользователи уже сильно привыкли именно к Wireguard.
Поэтому вариант с кардинальной сменой клиентского софта не рассматривался.

Поскольку трафик Wireguard блокируется только на зарубежные адреса было принято решение добавить еще один хоп в систему, а начальное подключение осуществлять к серверу в РФ.

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

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

Разработка корпоративных приложений со сложной бизнес-логикой всегда несет за собой немалые затраты. Причём львиная доля затрат приходится не на саму разработку, а на поддержку кода приложения: добавление нового функционала, поиск и исправление допущенных ошибок, рефакторинг и т.п. Мне как разработчику ПО всегда хотелось найти “серебряную пулю” для вопросов, возникающих при конструировании кода приложений, как написать потенциально сложное приложение, чтобы его было поддерживать как можно легче и дешевле. В этой статье хочу поделиться практическими знаниями о проектировании архитектуры кода программного обеспечения, полученными из опыта.

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

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

Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.

Всем привет,

Я последние несколько лет очень часто сталкиваюсь с проектами по адаптации под 152-ФЗ и он мне честно порядком надоел. Поэтому, прочитав опять весь закон, все комментарии различных ведомств и трактовки уважаемых людей, а также проанализировав ряд решений, которые прошли успешно аудит, я кажется, нашел простой технический вариант как сделать ваш web-site, API или приложение, соответствующее закону о персональных данных 152-ФЗ в разрезе требования о сборе пнд на территории России. Я даже автоматизировал развертывание этой штуки и это занимает не больше 10-ти минут. Давайте обсудим применимость данного подхода?

Я и мои коллеги всегда склоняем своих клиентов полностью автоматизировать процесс деплоя. Автоматизация помогает сократить количество конфликтов и задержек, которые возникают в процессе между "завершением" работы над программой и введением в эксплуатацию. Дэйв Фарли (Dave Farley) и Джез Хамбл (Jez Humble) заканчивают книгу "Непрерывная доставка" (Continuous Delivery) на эту тему. Она основывается на множестве идей, которые в целом связаны с непрерывной интеграцией и подталкивают к возможности быстро пустить софт в работу. Глава о сине-зеленом деплое привлекла мое внимание, потому что это один из малоиспользуемых методов, и я решил кратко его осветить.

D3.js (или просто D3) это JavaScript-библиотека для обработки и визуализации данных. Она предоставляет удобные утилиты для обработки и загрузки массивов данных и создания DOM-элементов. Эта заметка описывает работу с основными методами библиотеки, она подойдёт для изучения основ библиотеки и погружения в её логику и возможности.

Для понимания статьи пригодятся знания JS, HTML и CSS.