Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.

Л.Кэрролл, «Приключения Алисы в стране чудес»

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



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

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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

• применимость процесса — когда имеет смысл его внедрять
• основные этапы процесса, активности, вовлеченные ресурсы и результаты
• планирование релизов: календарь, объем, параллельное выполнение
• некоторые проблемы доставки в релизах

Вкратце:

1. Защита сервисов и открытие портов по стуку криптографически стойким и не воспроизводимым Single Packet Authorization (SPA) с fwknop 2.6.9+.
2. Динамически настраиваемое обновление чёрных списков с All Cybercrime IP Feeds by FireHOL.
3. Полноценная поддержка ipset в cfnetwork.
4. Поддержка собственных чёрных списков.
5. Типичные варианты применения.

Часть 1	Часть 2	Часть 3	Часть 4

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

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

Будут рассмотрены: выражения-генераторы, генераторы списка, словаря и множества, вложенные генераторы (5 вариантов), работа с enumerate(), range().
А также: классификация и терминология, синтаксис, аналоги в виде циклов и примеры применения.

Я постарался рассмотреть тонкости и нюансы, которые освещаются далеко не во всех книгах и курсах, и, в том числе, отсутствуют в уже опубликованных на Habrahabr статьях на эту тему.

Оглавление:

1. Определения и классификация.
2. Синтаксис.
3. Аналоги в виде цикла for и в виде функций.
4. Выражения-генераторы.
5. Генерация стандартных коллекций.
6. Периодичность и частичный перебор.
7. Вложенные циклы и генераторы.
8. Использование range().
9. Приложение 1. Дополнительные примеры.
10. Приложение 2. Ссылки по теме.

За последние несколько лет гибкие методологии почти вытеснили традиционные способы разработки – полностью по принципам Agile сейчас работают две трети IT-компаний. Оправдались ли ожидания, какие возникают проблемы и куда всё движется? Предлагаем анализ существующего российского и зарубежного опыта работы по Agile и ответы на эти вопросы.

"Глупый учится на своих ошибках, умный на чужих".

Всем доброго дня. В этой статье я намереваюсь разобрать ошибки произошедшие и досконально описанные в топике Обратная сторона Agile. Это ни в коей мере не holywar, ни тем более какой-либо blame. Мне лишь интересно препарировать эти вопросы со стороны исследования и отчасти восстановить доброе имя SCRUM'a.

Содержание первой части:

1.1 — Создание виртуальной лаборатории (чтобы нам было где работать, я покажу как создать виртуальную сеть на вашем компьютере. Сеть будет состоять из 3х машин Linux ubuntu).
1.2 – Написание простого модуля в Linux. Введение в Netfilter и перехват трафика с его помощью. Объединяем все вместе, тестируем.
1.3 – Написание простого char device. Добавление виртуальной файловой системы — sysfs. Написание user interface. Объединяем все вместе, тестируем.

Содержание второй части:

Содержание первой части:


Содержание второй части:

2.1 — Введение во вторую часть. Смотрим на сеть и протоколы. Wireshark.
2.2 — Таблицы Firewall. Transport Layer. Структуры TCP, UDP. Расширяем Firewall.
2.3 — Расширяем функциональность. Обрабатываем данные в user space. libnetfilter_queue.
2.4 — Бонус. Изучаем реальную Buffer Overflow атаку и предотвращаем с помощью нашего Firewall'а.

Приветствую, тебя %хабраюзер%. Прочитал я тут статью на хабре «Экзамен для будущих «русских хакеров» в Московском Политехе». И мой мозг вошел в бесконечный цикл непонимания происходящего. То ли я сейчас заглянул на школофорум «хакеров», то ли действительно на хабр. Уж извините, с таким подходом текущему поколению вайтов просто некому будет заменить.

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

Если вам интересен отчасти и мой путь, добро пожаловать под кат.

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

В последнее время у нас на проекте остро стал вопрос о запуске Selenium тестов на заднем плане. Одно из правил в нашей команде гласит, что мы не комитим код, пока не прошли все авто-тесты. Для проекта нашего размера это вполне реально. Проекты у нас меняются каждые 2-3 месяца и обычно занимает от 5 до 15 минут прогнать все тесты. Операционная система, в которой мы работаем — Ubuntu, у всех по два монитора (спасибо заказчику). Поэтому, поглядывая на тесты, удобно поделать что-то еще. Поревьювить таски, например, или начать делать новую задачу. Главная проблема заключается в том, что во время прохождения тестов на компьютере ничего сделать невозможно. А именно, каждое действие веб-драйвера делает его окно активным. Таким образом, можно только нормально послушать музыку. В лучшем случае — почитать или посмотреть видео. А вот если печатать — то почти стопроцентно завалишь какой-нибудь тест. Из-за этой проблемы каждый team member тратил кучу драгоценного времени впустую. Так я начал инвистигейшн данной проблемы.

И так, предположим абстрактную ситуацию: у вас есть набор тестов написанный с помощью Selenium WebDriver. Он постоянно пополняется, обрастает новыми деталями и вам уже действительно невмоготу разбираться в логах, кучах XML, смотреть и думать, что полетело и почему. Чуточку ниже я попытаюсь дать ряд простых советов, для стабилизации своих Selenium тестов, а так же, расскажу о способах подружить Selenium с Jenkins CI и последствиях данной дружбы. Для тех, кто заинтересовался — прошу под кат.

Мы продолжаем рассказывать о процессах организации разработки в Positive Technologies. Ранее мы коснулись тем создания дистрибутивов продуктов, организации процесса хранения и лицензирования софта и реализации собственной системы Continuous Integration.

Сегодня речь пойдет о том, как мы используем инструмент Team Foundation Server (TFS) для организации workflow разработки.

В данной статье проведена систематизация требований к информационной безопасности (ИБ) АСУ ТП. Требования выбраны из доступных на настоящий момент стандартов, в первую очередь, из NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» и разрабатываемой новой редакции серии ISA/IEC 62443 «Security for Industrial Automation and Control Systems».

АСУ ТП взаимодействуют с объектами физического мира и обеспечивают защиту от аварий и катастроф. В англоязычной литературе АСУ ТП называют Industrial Control Systems (ICS) или Industrial Automation and Control Systems (IACS). В мире IT технологий их можно сравнить с Дон Кихотом, который остался верен простым, но не очень модным принципам в уже давно изменившемся мире.

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

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

Быть программистом — это призвание? Возможно. Мы в 1cloud решили выяснить, как сами программисты оценивают свои достижения, какие качества считают неотъемлемыми в своей работе (вне зависимости от выбранного языка и специализации) и какие советы дают начинающим разработчикам.

Привет, Geektimes! В продолжение темы наличных денег из разных частей света представляем вашему вниманию подборку монет регулярной чеканки. В поисках интересных экземпляров мы отправились в виртуальное кругосветное путешествие и посетили все «обитаемые» континенты.

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

Свой моногородок в Заполярье я в шутку зову Чернобылем*. Горнодобывающий завод занимает половину площади поселения и заставляет всё вокруг выглядеть и чувствовать себя вот так:



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

Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.

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

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

На примере нашего проекта я расскажу как мы отлично с этим справились и какие практики выработали.

С докладом на эту тему я выступил на SECR-2016, слайды приложены в конце статьи.

Суть проблемы

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

Долго ли коротко ли, но шестерни в очередной раз провернулись и linkmeup встал на ступень Tier 2. И несколько достаточной платёжоспособности энтерпрайзов проявили заинтересованность в организации связи между своими филиалами через сети linkmeup.

L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола — IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.

Вот и нашим клиентам вынь да положь L2.

Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно).

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

Мы же в этот раз сосредоточимся на MPLS L2VPN.