Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

Привет, Хабровчане! Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.

Предисловие

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



На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.

Университеты, стремясь сохранить свою конкурентоспособность, постоянно задаются вопросом: «Как нам лучше всего подготовить студентов к реальному миру?» Вчера, в условиях индустриальной экономики, эффективным ответом на этот вопрос был перечень пользующихся спросом профессиональных навыков, которые университеты выявляли и прививали своим студентам. Однако сегодня, в условиях оцифровавшейся экономики, такого обучения, ориентированного на навыки, уже недостаточно. Поэтому лучшее, что университеты могут дать своим студентам сегодня – научить их учиться; заинтересовать их непрерывным процессом образования и самообразования.

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

Разумеется, никто не сможет сначала построить станцию и потом перенести несущую стену из-за того, что система вентиляции не сможет быть смонтирована в текущей конфигурации. Поэтому процессы реального мира всё больше уходят в «цифру». Как вам понравится комментарий к коммиту «Перенос капитальной стены на 2 метра севернее»? При проектировании и тестировании АЭС применяется полностью цифровой подход: создается информационная модель, к ней применяется классическая V-модель управления жизненным циклом. Таким образом, АЭС превращается в тиражируемый и полностью цифровой объект. Тестирование и запуск современных АЭС происходит в цифровом виде, и только после этого строители приступают к монтажу, используя всё те же цифровые модели.

Из этой статьи вы узнаете о том, что представляет собой современная информационная система, как происходит разработка и тестирование «капитальных» объектов на примере АЭС.


В основе материала — расшифровка доклада Вячеслава Аленькова, директора по системной инженерии и информационным технологиям инжиниринговой компании «Атомстройэкспорт» (ASE) с нашей декабрьской конференции Heisenbug 2017 Moscow.

Если вы ведете блог, то, возможно, вам знакомо чувство, когда взлелеянную, родившуюся в тяжелом труде статью никто не читает. И вы не можете понять причины. Кажется, и тема выбрана правильно. И стиль подобран адекватно. И слова использованы именно те, которые нужно! Статья написана интересно, и, бесспорно, должна быть полезной значительной части вашей ключевой аудитории…



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

— Последний вопрос нашей повестки. – зашуршала бумажками Светлана Владимировна. – Оценка удовлетворенности персонала. Татьяна, вам слово.

— Добрый день, коллеги. – поднялась со стула молодая, симпатичная девушка, новый HR-директор. – Как вы знаете, мы провели оценку удовлетворенности персонала, и результаты, к сожалению, неутешительные.

Татьяна выдержала театральную паузу, оглядывая всех присутствующих менеджеров – и топ, и не топ.

— Удовлетворенность стала ниже, по сравнению с прошлым годом. – видя, что реакции нет, сконфуженно продолжила Татьяна. – С этим нужно что-то делать. Я подготовила несколько предложений. Светлана Владимировна, можно озвучить?

— Начинается… — раздался тихий шепот с дальнего конца стола.

— Что, простите? – подняла бровь директор. – Я что, с разнорабочими разговариваю? Или с руководителями, которые радеют за благо предприятия? Марина, это вы сейчас сказали?

— Нет, не я. – возмутилась Марина, директор по качеству. – Вон, умник наш. Господин ИТ-директор. Сергей, отвлекись от телефона, что ты там все время делаешь?

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

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

Примечание: Материалы статьи опираются на исследования Е.Д. Авериной, Д.Б. Никуличевой, Э.В. Гуннемарка и П.Нейшна, пропущенные через призму моего восприятия и опыт изучения 3 иностранных языков.

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

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

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

Вопросы управления талантливыми сотрудниками актуальны для многих руководителей в сфере IT вне зависимости от конкретной специализации. Именно поэтому управление талантами мы выбрали в качестве первой темы нового цикла встреч, организованного Яндексом — Team Leader Meetup.

В преддверии встречи мы попросили участников панельной дискуссии, среди которых veged, gornal, yafinder, ответить на ряд вопросов, связанных с управлением талантливыми сотрудниками.

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

Другая проблема — размер компенсации. Конечно, в любой компании, равно как и в любом подразделении конкретной компании, общий объём средств, направляемых на компенсацию сотрудников, ограничен. Этот ограниченный объём ресурсов требуется распределять между участниками команды. Некоторые из них явно растут быстрее, чем другие. С этим связан наш второй вопрос: как правильно распределять ограниченный объём компенсации в командах с быстро растущими талантами?

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



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

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

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



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

Здравствуйте, уважаемое сообщество!

ИТ-инфраструктура всегда находится в динамике. Тысячи изменений происходят ежеминутно. Многие из них требуется регистрировать. Аудит систем является неотъемлемой частью информационной безопасности организаций. Контроль изменений позволяет предотвратить серьезные происшествия в дальнейшем.

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

Меня зовут Лена, я работаю тестировщиком в InfoWatch. Хочу поделиться впечатлениями от длительной летней командировки в Иннополисе. Знаю, что статей об этом необычном городе под Казанью уже немало, и надеюсь, что мой рассказ поможет вам увидеть его с новой стороны.


Шайба