Сейчас, наверно, из каждого утюга звучат призывы про «войти в IT». Среди этих призывов часто звучит: «Стань тестировщиком, это самый простой способ сделать карьеру в IT». Я с этим не согласен, но это лишь мое сугубо личное мнение, основанное на личном опыте. На опыте, который по факту занимает… страшно сказать… 10 лет. Более 10 лет жизни и карьеры я посвятил миру тестирования. И я бы хотел поделиться некоторыми вещами.

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

В этой статье мы расскажем, как внешние приложения и сервисы могут взаимодействовать с DLP-системой InfoWatch Traffic Monitor (далее ТМ) через API. API-интерфейс в TM разработан уже давно, но в последний год интерес к нему со стороны сторонних разработчиков значительно вырос. Интеграторы и вендоры обычно хотят интегрировать DLP- системы с нуля в ИТ-ландшафт организации, импортозаместить прежние иностранные системы, расширить количество контролируемых DLP-системой каналов и аккумулировать информацию из нескольких систем в одной. Мы анализируем кросс-продуктовые сценарии и видим, что API является наиболее эффективным и современным средством решения подобных задач. Поэтому мы решили рассказать про наш API-интерфейс и продемонстрировать его работу на практических примерах.

Сценариев интеграции довольно много, поэтому мы рассмотрим самую популярную задачу - отправку событий из корпоративного мессенджера в DLP TM на контентный анализ. Для пущей сложности мы взяли самописный мессенджер Stack chat, а еще решили отправлять в DLP не только переписку, но и пересылаемые корпоративные файлы. Не секрет, что корпоративный мессенджер - это основное оперативное средство коммуникации любой динамичной организации. А благодаря своим интеграциям со средствами телефонии, сетевыми каталогами, CRM и корпоративными порталами, он же - канал утечки конфиденциальной информации.

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

Приветствую!

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

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

В последние десятилетия значительно выросла роль автоматизированных систем управления технологическим процессом (АСУ ТП). Также существенно выросло количество атак на данный сектор. Одним из известных примеров промышленных атак последних лет является атака на металлургический концерн BlueScope. Кибератака затронула производство и продажи. В ее ходе пострадали некоторые производственные процессы, другие были остановлены.

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

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

Таким образом, изучение аспектов безопасности стандарта, а также способов защиты от известных уязвимостей данной системы позволяет повысить уровень безопасности промышленных объектов.

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

Статья будет полезна аналитикам, Product Owner'ам, руководителям проектов и всем, кто так или иначе связан с работой по выявлению и документированию потребностей.

Каждую практику можно использовать независимо, а можно применять их все — как вам удобнее в конкретном проекте.

Итак, поехали!

Предисловие

Сейчас многие фреймворки имеют в своем арсенале CLI (Command Line Interface) и ангуляр – не исключение. Впервые с CLI-утилитами я столкнулся, когда пробовал EmberJS и тогда мне это показалось очень удобным инструментом, который довольно сильно экономил мое время. Но, к сожалению, из коробки CLI-утилиты подходят только для несложных, домашних проектов.

Использование их же в крупных production-проектах без допилки напильником почти невозможно. Поэтому на старте нашего проекта мы вынуждены были отказаться от его использования из-за особенностей нашей архитектуры. Почти год я периодически смотрел в сторону Angular CLI в плане его развития и огорчался, что мы не можем его использовать, так как это сделало бы вход в проект гораздо проще. Но в один прекрасный момент команда Angular выпустила @angular-devkit, который содержит в себе набор пакетов, используемых cli утилитой, и это дало нам возможность допилить Angular CLI под наши нужды. Репозиторий содержит на сегодняшний день с десяток пакетов, но в этой статье мы рассмотрим только те, которые относятся к schematics.

И вот что выяснилось:

Зачем переносить данные

Тема переноса (миграции) данных из Oracle в Postgres набирает обороты. В РФ количество запросов по переходу на Postgres на волне импортозамещения, сейчас больше, чем когда либо. Oracle — очень качественный, мощный и отлично документированный инструмент. Но вместе с тем очень дорогой в лицензировании и поддержке. Зачастую охватить все его возможности не получается в силу специфики использования. Ключевыми параметрами эксплуатации в нашем случае являются производительность системы, процент использования (утилизации) железа, простая тех. поддержка, а также дешевое и быстрое масштабирование — легкое развертывание новых баз.

Я решил изучить процесс миграции данных, изучая то, как реализовать пожелания конкретного заказчика, а также из практического любопытства, теперь я пробую перенести небольшую схему около 15 Гбайт с Oracle 11.2.0.4 на Linux Redhat 6.8 в Postgres 9.4 на Windows. Немного погрузившись в тему, я решил написать эту статью и рассмотреть процесс подробно. В отрыве от нашей специфики пост будет полезен интеграторам и DBA при планировании переноса данных/CUT.

Предыстория