Если самым популярным вопросом о работе архитекторов является «Кто такие архитекторы и чем они занимаются?», то второй по популярности причиной провала архитектурной практики после «Не сошлись в видении с руководством» является отсутствие нормального инструмента. Под этим инструментом подразумеваются Enterprise Architecture Tool, которых на рынке представлено огромное множество, примерно такое же, как и различных framework и методологий архитектуры.

Кстати говоря о framework»ах, если выбор такого стоит остро и кроме TOGAF ничего не попадается, рекомендую книгу «The Practice of Enterprise Architecture» Святослава Котусева, которую я упоминал в публикации на тему навыков архитекторов.

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

Первое и золотое правило в выборе инструмента, и EA Tool в частности:

Fools with tools are still fools.

Дисклеймер: если ты продвинутый разработчик с Х годами опыта, пожалуйста, закрой эту статью. Здесь ты не найдешь абсолютно ничего полезного для себя.

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

В этой статье я расскажу о том, как сделать первый коммит на GitHub, и как делать последующие. Только мой опыт и сочетание консоли и фич IntelliJ Idea + у меня mac os, поэтому здесь именно про него (важно для установки).

Погнали.

Уже два года я работаю системным аналитиком в крупной телеком-компании, которая развивает IT-направление. 

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

Рассказываю инсайды закрытого проекта от HeadHunter: джуниоры по-дешевке всем и пусть никто не уйдет обиженным. Кроме самих новичков, которые заплатят 100к+ за возможность получить первую работу и будут получать зарплату 36к.

Кроме моей основной любви к инфре и виртуализации, давно увлекаюсь темой product менеджмента периодически почитываю соотвествующие материалы, но заметил что уже достаточно долгое время пост Владислава Носковца с примерами тестовых заданий на позицию Product manager висит в топе выдачи (на Гугле, на Яндексе так вообще портал в ад октрывается), а новых, что‑то не появляется. Да и не особо легко найти примеры структурированных решений.

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

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

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

Привет, Хабр! Меня зовут Любовь Кулева, я руководитель отдела разработки и методологии Учебного центра IBS. Каждый год в нашем центре сотни сотрудников проходят сертификацию навыков. Собрав статистику по итогам 2023 года, мы выяснили, что сертификацию успешно сдает лишь каждый третий системный аналитик. Да-да, вы не ослышались: это значит, что две трети специалистов в первый раз заваливают экзамен. Очевидно, что многие просто не замечают пробелов в собственных знаниях или не знают, какие именно компетенции следует подтянуть в первую очередь. Эта статья — дорожная карта для любого системного аналитика, желающего расти в профессии.

Всем привет, я — Сергей Бобрецов, CTO в Wildberries. 

Сегодня Wildberries — самый большой маркетплейс в России и мы так часто заняты повседневным хайлоадом, что не всегда успеваем рассказать что за всем этим стоит: какие технологии и решения под капотом, как мы справляемся с адом черной пятницы и ужасами киберпонедельника.

Стоит начать с того, что основным генератором прогресса в WB с самого начала и по сей день является фактор роста. По бизнес-метрикам мы растем примерно х2 каждый год уже много лет, а по техническим (количестуву запросов / транзакций / трафику / объему данных и т. д.) — рост может быть даже быстрее, и это создает множество вызовов: технических, архитектурных и организационных. 

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

Сегодня я хочу рассказать немного про нашу инфраструктуру.

Предисловие

Эта статья ー вторая часть материала об интеграции информационных систем (ИС) и самых распространённых стилях и технологиях интеграции. 

Задача этой статьи только одна - попробовать уложить принципы SOLID на понятных «бытовых» примерах, а уже потом посмотреть, как оно может работать на практике - в коде.

Итак, SOLID - это 5 принципов, которые используются при разработке приложений. На каждый принцип по букве:

1. S — Single Responsibility Principle (Принцип единственной ответственности)

Определение: Каждый класс должен выполнять только одну задачу.

Пример из жизни:

Например, мы купили шкаф для одежды. 

Объектно Ориентированное Проектирование

Давайте признаемся: подавляющее большинство пишет Java код, используя JetBrains IntelliJ IDEA Ultimate. Да, это отличная IDE. Для нее есть большое количество расширений, среда очень тесно интегрируется с Spring Framework и знает его особенности.

Тогда зачем пробовать что‑то другое?

Привет, Хабр! Меня зовут Константин Шибков, я Java‑разработчик в CDEK.

В какой‑то мере все Java‑разработчики стали заложниками IDEA. Она так привычна, что нет желания пробовать другое. Ведь всё такое удобное и знакомое за столько лет использования.

Но если у вас есть трудности с доступом к Ultimate версии, а Community вариант не достаточно функционален — самое время попробовать современную альтернативу — Visual Studio Code.

В статье делюсь опытом подготовки среды разработки и изучения вопроса: «А можно ли перейти на VSCode?».

Системный аналитик. Краткий гайд по профессии. Часть 1.

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

Что стоит почитать Product Manager'у в 2023 году? Составил подборку из 10 полезных книг, которые должны быть в библиотеке как начинающего, так и опытного продакта. Для тех у кого совсем мало времени по каждой книге прикрепил ссылку на краткое содержание.

Это руководство посвящено написанию чистого и удобного кода на JavaScript и TypeScript. Мы рассмотрим лучшие практики работы с функциями, переменными и методами, чтобы ваш код был не только эффективным, но и понятным как вам, так и другим разработчикам. Статья будет полезна для новичков, которые хотят улучшить свои навыки кодирования.

Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg - в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров – Go.

Проведя в ИТ большую часть жизни, в основном как руководитель ИТ-проектов (на моём счёту их уже 26, почти все связаны с внедрением ERP-систем), я накопил некоторый опыт управления, которым хотел бы поделиться в своих статьях на Habr. Надеюсь, мои истории будут полезны начинающим проектным менеджерам и тимлидам, заинтересуют зрелых руководителей или хотя бы развеселят сообщество. Аналитикам, программистам, инженерам и т.д. эта статья, скорее всего, не будет интересна.

Как и многие руководители проектов, я мечтаю об инструменте, который бы позволял мне легко и непринуждённо планировать проектные работы на горизонте всего проекта, а также на месяц и на неделю, мониторить выполнение работ, управлять ресурсами, сроками, пользоваться удобными дашбордами, быстро формировать отчёты для руководства (а не рисовать картинки в Share Point) и т.д. Мечты, мечты… В большинстве проектов мне был доступен MS Project и MS Excel. Ну хотя бы так.

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

В своих проектах я часто использую два плана-графика: верхнеуровневый (для проектов длительностью до шести месяцев среднеуровневый) и детальный на ближайшую неделю. Почему два? На мой взгляд, детальный план-график проект на всю его длительность делать сложно, а зачастую и вредно. Слишком много неопределённости на старте проекта и много чего меняется в его ходе. И если у вас нет команды планировщиков (а в ИТ я их не встречал), то всё нужно будет делать самому, и постоянная актуализация детального плана-графика «съест» всё время руководителя проекта. Поэтому такие расписания лучше делать верхнеуровневыми до конца проекта и среднеуровневыми на ближайшие два месяца, с длительностью задачи на нижнем уровне иерархии не менее 5 рабочих дней.

С другой стороны, на ближайшую неделю нужен точный план-график либо реестр задач с конкретными исполнителями и сроками.

Рассмотрим такие планы-графики на моём любимом кейсе – проекте «засунуть слона в холодильник». Могу, конечно, ошибаться, но на простых и весёлых примерах всегда проще и интереснее объяснять методику.

Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).

В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций.