Хакеры в кино — сверхлюди, которые по щелчку мыши могут взломать автомобиль, запустить «киберракету» и вычислить юрлицо через командную строку. Сцены взлома сопровождаются звуковыми и визуальными эффектами, которые вызывают если не смех, то ироническую улыбку у всех, кто в теме. 

Меня зовут Артемий Богданов, я Chief Hacking Officer в Start X. Находил слабые места в приложениях Uber, Yahoo и ВКонтакте, участвовал в CTF и регулярно провожу пентесты. За годы работы убедился, что реальные кибератаки выглядят совсем не так красочно, как в кино. Никаких сирен и экранов с мигалками. 

Этой статьей я бы хотел развеять миф о всесильности хакеров и объяснить, как этот миф мешает внедрению культуры кибербезопасности в компаниях. 

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

Перенос данных из одного облачного хранилища в другое – сродни переезду. Для того чтобы он не стал пожаром, нужно подготовиться: оценить ваши потребности, возможности разных хранилищ и их ограничения. Вместе с DevOps-командой SimbirSoft рассмотрим несколько популярных сервисов, которые имеют дата-центры на территории страны – Yandex Cloud, VK Cloud Solutions, SberCloud – и разберем первые шаги по переезду. Статья может быть полезна тем, кто ищет площадку для переноса данных из другого облака или традиционной инфраструктуры.

Cистемный аналитик играет ключевую роль в проектировании приложений и построении интеграций. Одним из основных инструментов для этого является REST API и знание REST API — важный навык для системного аналитика. В этой статье мы представим 25 вопросов по REST API, которые помогут вам подготовиться к интервью на вакансию системного аналитика и прокачать свои навыки. Полезного чтения!

Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

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

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

На своих проектах мне несколько раз приходилось совмещать роли менеджера проекта и аналитика.

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

С другой, смешивать роли — не всегда самый лучший сценарий. Потому что из фокуса постоянно что-то выпадает, иногда не хватает времени и рук "на всё про всё".
И это влияет на качество результата.

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

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

Цель статьи: попытаться посмотреть на проект глазами аналитика и проджекта, найти точки соприкосновения этих двух ролей и дать вам пищу для самостоятельного ответа на вопрос: совмещение ролей аналитика и ПМ в одном проекте - это хорошо либо плохо?

Давайте для начала обозначим зоны ответственности аналитика и проектного менеджера...

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

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

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

Готовы? Тогда поехали!

Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?

В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.

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

Когда в коллегах согласья нет,
На лад проект их не пойдет,
И выйдет из него не profit, только cost.

Однажды Бэкендер, Фронтендер да Аналитик
Везти с тасками US взялись,
И вместе трое все в него впряглись;

Из кожи лезут вон, а US всё нет ходу!
Таски для них казались и легки:
Да Фронт рвется в Cloud-решения,
Бэк пятится назад, а Аналитик тянет в воду.

Кто виноват из них, кто прав, - судить не нам;
Да только UserStory и ныне там.

Уверен, многие узнали всем известную басню про трёх товарищей, которые пытаются затащить одну общую хотелку (некий воз). Только вот каждый тянет эту задачу в свою сторону, игнорируя усилия других. Сегодня я поделюсь с моими любимыми читателями примером, как сделать так, чтобы работа над задачей между тремя нашими героями шла дружно и эффективно.

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Введение

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

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.

Преамбула

Средства

Всякая вещь есть форма проявления беспредельного разнообразия.
Козьма Прутков

Введение в нотацию eEPC

Летом 2020 года GitHub позволила пользователям создавать персональные README-файлы и с их помощью кастомизировать свои профили. Сама платформа при создании подобного файла предлагает уже готовый шаблон, в который можно вписать свои данные. Но о какой кастомизации может идти речь, если у всех будут одинаково оформленные профили? За почти два года сообщество придумало множество различных способов выделиться и особенно оформить свою страницу на GitHub.

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

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

Когда-то давно в дебрях Интернета я случайно нарвался на  матрицу  компетенций программиста от Джозефа Сиджина, которая помогла мне правильно оценить свою стоимость на рынке труда и выработать пути по дальнейшему самосовершенствованию. Шло время, проекты в которых я участвовал, росли. Росли, росли и выросли до такого состояния, что в этих проектах потребовалось участие  не только программистов, но и аналитиков. Помня положительный эффект от матрицы Д. Сиджина, в какой-то момент  я решил найти такую же шкалу компетенций, но уже для аналитиков. И, что неудивительно, нашел.

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

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

Я и сама часто так делаю. Но обычно организаторы не любят смотреть на полдюжины черных квадратиков, которые на каждый второй вопрос говорят: «А-а-а, извините, повторите еще раз, пожалуйста». 

Цель honeypot в работе ЦМР — навлечь на себя атаку или несанкционированное исследование. Такое средство позволяет изучить стратегию злоумышленника и определить, каким образом могут быть нанесены удары по реально существующим объектам безопасности.

Рассмотрим же некоторые поближе и даже установим один из них!