IT-стандарты *

За последние два года Go-сообщество выросло на 55% — с 3 млн до 4,7 млн разработчиков. Многие пришли в Go из других языков или только начинают свой путь в программировании. Без понимания идиоматики и ключевых особенностей языка даже опытные специалисты нередко сталкиваются с медленным кодом, дедлоками и утечками памяти.

Так что сегодня разберём, как организовывать пакеты, обрабатывать ошибки, безопасно работать с горутинами и каналами, оптимизировать аллокации и профилировать «горячие» участки через pprof. Советы одинаково пригодятся и опытным Golang-разработчикам, и тем, кто только начинает свой путь в Go.

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

Функционально проект реализует систему сбора и анализа вакансий с агрегаторов вроде HeadHunter. Но гораздо важнее не то, какие задачи решает система, а то — как именно она это делает. Этот проект — прежде всего о структуре, архитектуре и принципах.

Основные используемые технологии: Python 3.13, FastAPI, Nginx, Uvicorn, PostgreSQL, Alembic, Celery, Redis, Pytest, FileBeat, LogStash, ElasticSearch, Kibana, Prometheus, Grafana, Docker, Docker Compose.

Спросил свою 3070ti «Как думаешь, что важнее – процесс или результат?», а он мне отвечает, чтобы я сам выбирал. И зачем эти нейросети, если они даже не могут выбрать, что для меня важнее и лучше…

В первой части гайда RuStore по доставке фичей мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей, Александр Котельников, разобрали подготовительные этапы, которые закладывают прочный фундамент для всей разработки: от Kick-off и архитектурного планирования до Technical Design и тестовой стратегии.

PTTJS - plain text table javascript, формат разработанный из личной необходимости и острой нужды.

Главная цель формата PTTJS - получить текстовый формат таблиц, который позволяет хранить более сложные таблицы, нежели существующие форматы, но при этом сохранять читаемость и текстовую основу.

Уже написаны JS библиотека с парсером и сериализатором, а также Obsidian плагин.

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

Полтора года назад мы в RuStore собрали новую команду, чтобы с нуля разработать собственное платёжное решение. Тогда всё началось с одной фичи. Казалось бы, «просто запилить», чего тут сложного. Но на деле это обернулось целым кварталом разработки, бесконечными доделками и болью на финальном этапе интеграции. Тогда мы столкнулись с типичным набором проблем — от отсутствия документации и слабой декомпозиции до невозможности предсказать сроки. Да, в конечном итоге всё как-то заработало, но по ощущениям исключительно на энтузиазме.

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

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

Оценивать ли время на выполнение задач в IT? А может быть просто пойти и начать делать? А может быть можно оценить объем задач, а не время? И что же вообще нужно и можно оценить? 

В этой статья я рассказываю про 4 метода оценивания задач в IT — от угадывания до хороших и честных расчётов.

Предисловие

Цель этой статьи - объединить и кратко изложить все базовые архитектурные подходы: их терминологию, концепции и отличительные черты. Собрать всё воедино, чтобы можно было относительно быстро вникнуть в основы.

Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.

Однако по мере проработки деталей стало очевидно: чтобы обсуждать структуру приложения предметно и аргументированно, необходимо сначала заложить общую теоретическую основу, чтобы читатель понимал, о чем речь.
Так родилась идея вынести базовые концепции архитектуры и проектирования в отдельную публикацию — не перегружать материал сразу всем, а построить серию объёмных, но логично связанных статей.

Всем привет! Меня зовут Анастасия Калиничева, я являюсь специалистом по информационной безопасности и ярым любителем поискать смысл в законодательстве о персональных данных (ПДн). Про оборотные штрафы написано уже много материалов, но в процессе анализа поправок невозможно обойтись без структурированного «разложить все по полочкам» и, конечно же, личного мнения о нововведениях. Делюсь с вами аналитикой на тему ужесточения ответственности за правонарушения в сфере законодательства РФ о ПДн.

В мире IT разработки программного обеспечения и управления проектами термин «эстимейт» или «оценка» означает наше лучшее “предсказание” о том, что и за какое время можно сделать. Это не точное предсказание, а скорее ориентир, который помогает принимать решения и планировать работу на проекте.

Но в каких ситуациях оценки действительно имеют значение?
Давайте подробнее разберемся…

Go предлагает уникальный и прямолинейный подход к обработке ошибок, отличающийся от try-catch в других языках. Он основан на явной проверке возвращаемых значений, что требует больших проверок, но ведет к более надежному коду. Рассмотрим основы, современные инструменты пакета errors и лучшие практики.

В этой статье я хотел бы рассмотреть вышедший буквально на днях стандарт NIST 800–61r3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management» (Рекомендации и соображения по реагированию на инциденты для управления рисками в сфере кибербезопасности). Замененный стандарт 800–61r2, выпущенный в далеком 2012 году, был полностью переработан и текущая версия существенно отличается по структуре и подходу к вопросу реагирования на компьютерные инциденты.

AI меняет не только процессы, но и профессии. Полгода назад для того, чтобы запустить MVP продукта, нужен был не только product owner, но и команда разработчиков. Сегодня прототип может сделать один человек без команды, используя только AI. Вы все еще относитесь к этому со скепсисом, но это уже так.

Меня зовут Сергей Спиренков, я евангелист в KODE и CEO собственных проектов. Последние месяцы я провел внутри этой трансформации — собирая продукты в одиночку, без строчек кода руками, с помощью AI и нового подхода к разработке. В статье поделюсь мнением, как изменится профессия product owner и что ждет разработчиков. И главное: расскажу про AI-инструменты, с помощью которых сам делаю MVP продуктов.

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

Это не новость, но вопрос всплывает достаточно часто, поэтому я считаю, что проблему нужно объяснить кратко. Люди, и я в том числе, обычно говорят, что время POSIX, также известное как время Unix — это количество of секунд, прошедших с эпохи Unix, то есть с 00:00:00 1970-01-01.

Но это не так. Точнее, не так в смысле, подразумеваемом большинством. Например, сейчас у меня на часах 2024-12-25, 18:51:26 UTC. Время POSIX равно 1735152686. Прошло 1735152713 секунд с эпохи POSIX. Число времени POSIX на двадцать семь секунд меньше.

Причина в том, что время POSIX вычисляется в IEEE 1003.1 из Coordinated Universal Time. Стандарт предполагает, что каждый день — это ровно 86400 секунд. Цитата:

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

Почти двадцать лет я занимался ИТ-инфраструктурой в крупном промышленном холдинге. Руководил командами, проектами, модернизировал, строил, автоматизировал — одним словом, жил управлением ИТ. Под контролем было свыше 20.000 автоматизированных рабочих мест, десятки филиалов, бюджеты, проекты, аудиты. Но все же был ограничен ИТ-инфраструктурой.

Потом — осознанная пауза примерно на год. Захотелось остановиться, переосмыслить, докачать стратегические и управленческие скиллы. Изучал материалы MBA, CISO, CISA — не для галочки, а чтобы по-настоящему понять, как быть не просто ИТ-менеджером, а ИТ-лидером.

После этого появилась возможность вернуться в ИТ и перейти  на уровень выше. Я стал региональным CIO крупной госкомпании, отвечал за ИТ в шести регионах РФ с 25 000 АРМ, выстраивал процессы, внедрял ERP, взаимодействовал с головным офисом, командой и подрядчиками.

А потом — переезд в Европу. И новый старт.

Идея была простая: продолжить карьеру в том же духе — ИТ-руководитель, трансформация, стратегическое развитие. Но на практике всё оказалось сложнее. Языковой барьер, о котором вроде бы знал, оказался серьёзнее, чем думал. Языковые курсы помогли, но вот управленческого словаря, уверенности в локальной терминологии и понимания местной специфики — не хватало. Всё приходилось изучать с нуля.

 Первая ступень: IT Service Request Manager