Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.



1. первый инструмент — top

Консольная команда top- удобный системный монитор, простой в использовании, с помощью которой выводится список работающих в системе процессов, информации о этих процессах. Данная команда в реальном времени сортирует их по нагрузке на процессор, инструмент предустановлен во многих системах UNIX.

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

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

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

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.

Предисловие

Как-то в гостях мне в руки попалась головоломка, в которой из 25 одинаковых фигурок требовалось собрать куб. Я провозился с ней почти весь вечер, и как можно догадаться, абсолютно безрезультатно. Тем не менее, я не мог сдаться просто так.

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

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

Схема отработки аварии первого уровня в «Мультикарте»

Есть такой миф, что у нас отказоустойчивых инфраструктур у крупных компаний не было примерно до 2007 года. Мол, именно тогда начали появляться документы DRP (аварийного восстановления), выделяться отделы риск-менеджмента и так далее.

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

А теперь поехали развеивать другие мифы про DRP и непрерывности. Ну и заодно расскажу про наш последний проект — аварийные планы «Мультикарты», то есть той системы, через которую идут все ваши оплаты картами в России.

Ну и, конечно, истории былинных провалов.

Рад представить дополнение оригинального списка из 300 потрясающих бесплатных сервисов. Автор оригинальной статьи Ali Mese добавил ещё +100 новых сервисов, которые помогут найти все — от источников вдохновения и редакторов фотографий до создания опросов и бесплатных иконок.

И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные веб-сайты

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly: Конструктор веб-сайтов.
• Layers: Создание сайтов на WordPress (new).
• Bootstrap Zero: Самая большая коллекция бесплатных шаблонов Bootstrap (new).
• Landing Harbor:  Продвижение мобильного приложения c помощью бесплатного лендинга (new).

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Вот уже в четвертый раз в Москве прошла конференция, посвященная информационной безопасности — ZeroNights 2014.



Как и в прошлом году, для того, чтобы попасть на ZeroNights, нужно было либо купить билет на мероприятие, либо выиграть его в HackQuest. О HackQuest мы объявляли на Хабре, и, как и ожидалось, задания оказались достаточно высокой сложности. Вместо отведенных 24 часов на каждое задание, некоторые висели по трое суток без решения, зато с кучей подсказок. Как вам, например, взламывать программу, написанную на языке Limbo, которая выполняется в эмуляторе ОС Inferno, или написать прошивку для устройства на языке Verilog, которое подключено в качестве человека посередине между двумя другими устройствами, которые передают зашифрованные данные друг-другу? На 5 из 8 заданий участники опубликовали райтапы, с которыми вы можете ознакомиться чуть ниже.

Конференция проводилась два дня: 13 и 14 ноября. Одновременно можно было посещать два трека, в которых читались доклады, либо же участвовать в воркшопах, в которых рассказывали и показывали крутые технические трюки, и, таким образом, учили вас. Также, все два дня работал Hardware Village — стенд с радио, RFID, NFC и проводным оборудованием для проведения атак.
Помимо основной программы, были еще Fast Track — короткие 15-минутные доклады обо всем и Defensive Track — 20-минутые доклады о безопасности в какой-либо среде.
Воркшопы были на самые разные темы: от how-to по инструментам и стандартным небезопасным настройкам роутеров, до взлома ключа AES-128-ECB через показания потребленной электроэнергии.

Наша новая статья представляет собой список рекомендаций и советов. Из неё вы узнаете:

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

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

Как облегчить процесс тестирования?

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

• Набор интеллект-карт на все случаи жизни: test insane, ministry of testing
• Эвристики, мнемоники: I SLICED UP FUN (моя любимая), COP FLUNG GUN, SFDPOT, LONG FUN CUP

2. Скриншоты, логи и видео — лучшие аргументы тестировщика!
К сожалению, с логами «общения» с сервером зачастую не всё так гладко, как с клиентскими логами. Обычно они добавляются скорее для удобства разработчика при отладке работы с сервером, чем для работы тестировщика.

Материалы этого поста задержались с выходом в свет на 4 месяца. Мы — молодая команда разработчиков, и только учимся нарушать dead-лайны, но кажется, что получается уже неплохо. Предыстория в этой статье, где мы и обещали выложить продолжение. Рассказ пойдёт о том, как же наше приложение работает (или не работает, решать читателю).

Какое приложение? Мы — команда проекта Viewaide (бывший EyeDoc) и пишем софт, который при помощи веб-камеры определяет параметры усталости глаз и выводит уведомления, задача которых снизить риск ухудшения зрения вследствие долгой работы у монитора. Чем 100 раз услышать, лучше 1 раз увидеть.



Скачать и попробовать можно по этой ссылке, как говорится, “бесплатно, без смс”. Кроме софта, у нас имеется ещё и часть web-сервиса, но обо всём по порядку.

Недавно Владимир Подольский vpodolskiy, аналитик в департаменте по работе с образованием IBS, закончил обучение по специализации Data Science на Coursera. Это набор из 9 курсеровских курсов от Университета Джонса Хопкинса + дипломная работа, успешное завершение которых дает право на сертификат. Для нашего блога на Хабре он написал подробный пост о своей учебе. Для удобства мы разбили его на 2 части. Добавим, что Владимир  стал еще и редактором проекта по переводу специализации Data Science на русский язык, который весной запустили IBS и ABBYY LS.

Часть 1. О специальности Data Science в общих чертах. Курсы: Инструменты анализа данных (программирование на R); Предварительная обработка данных; Документирование процесса обработки данных.

Привет, Хабр!

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

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

В 2014, сразу после того как DJI (китайский Google в области дроностроения) представили пакет средств для разработки (SDK), прошла первая олимпиада по разработке софта для дронов. Победители получили 100 000 юаней (около 900 000 руб). О первых трех местах — под катом.

В 2015 стартовала вторая олимпиада для программистов уже со всего мира. Итоги ее мы узнаем в конце лета.

Есть несколько проектов, которые, используя SDK от DJI, выпустили очень востребованные и коммерчески успешные программы для дронов.

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

А может быть вы хотите сделать 3d-скан горы Маттерхорн (4478м)?

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

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

О том, что он может и об основах его использования я и расскажу.

На YouTube появились записи выступлений с Positive Hack Days V — несколько десятков докладов по практической безопасности на русском и английском языках. В 2015 году на форуме говорили не только о хардкорных методах взлома, но и о «нетехнических» атаках. Многим запомнился доклад Криса Хаднаги (Chris Hadnagy), который для получения информации использует особенности человеческой психики и не верит в технический прогресс: «Пока вы ищите уязвимости нулевого дня, мы просто поднимаем трубку телефона и узнаем ваши секреты». В этом материале мы расскажем несколько историй и наблюдений из практики 42-летнего американца.

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

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

Passwords, passwords never change...
Почти каждый пользователь сети Интернет имеет хотя бы один аккаунт или хотя бы однажды оставлял свои данные в различных службах. Почтовые сервисы, социальные сети, облачные хранилища, онлайн-игры и многое другое, – в одном Facebook уже более 1 млрд учетных данных. Естественно, что, имея большую аудиторию, компании стараются обеспечивать хорошую защищенность своих серверов и сервисов. Однако, если пользователи не прилагают усилий к защите своих аккаунтов и вообще не соблюдают минимальных мер информационной безопасности, все усилия извне могут оказаться напрасны.

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.

Социальные сети (Twitter, Facebook, LinkedIn) — пожалуй, самая популярная бесплатная доступная широкой общественности площадка для высказывания мыслей по разным поводам. Миллионы твитов (постов) ежедневно — там кроется огромное количество информации. В частности, Twitter широко используется компаниями и обычными людьми для описания состояния дел, продвижения продуктов или услуг. Twitter также является прекрасным источником данных для проведения интеллектуального анализа текстов: начиная с логики поведения, событий, тональности высказываний и заканчивая предсказанием трендов на рынке ценных бумаг. Там кроется огромный массив информации для интеллектуального и контекстуального анализа текстов.

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

Реализация на R с применением twitteR, dplyr, stringr, ggplot2, tm, SnowballC, qdap и wordcloud. Перед применением нужно установить и загрузить эти пакеты, используя команды install.packages() и library().

Лето только начинается, но это не повод прекращать учиться. Предлагаем вам ознакомиться с очередной порцией знаний в рамках проекта «Лекции Техносферы». Цель курса — ознакомить студентов с актуальными методологиями тестирования и обеспечения качества современных веб-приложений. Курс позволит слушателям получить достаточные знания для овладения и применения на практике эффективных приемов построения процесса тестирования и обеспечения качества.

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

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.