Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

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

Системные метрики...

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

Как-то я посчитал, что 1 минута простоя hh.ru в будни днем затрагивает около 30 000 пользователей. Мы постоянно решаем задачу снижения количества инцидентов и их длительности. Снизить количество проблем мы можем правильной инфраструктурой, архитектурой приложения — это отдельная тема, ее мы пока не будем брать во внимание. Поговорим лучше о том, как быстро понять, что происходит в нашей инфраструктуре. Тут как раз нам и помогает мониторинг.

В этой статье на примере hh.ru я расскажу и покажу, как покрыть мониторингом все слои инфраструктуры:

• client-side метрики
• метрики с фронтендов (логи nginx)
• сеть (что можно добыть из TCP)
• приложение (логи)
• метрики базы данных (postgresql в нашем случае)
• операционная система (cpu usage тоже может пригодиться)

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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

Релиз OllyDbg 2.01 прошел незаметно и не был освещен на Хабре. Вместе с 2 версией автор выпустил дизассемблер по лицензии GPL v3. В конце октября была анонсирована будущая поддержка х64.

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

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

Продолжаем перевод набора правил безопасного криптопрограммирования от Жана-Филлипа Омассона…

Предотвращайте вмешательство компилятора в части кода, критическим образом влияющие на безопасность

Проблема

Некоторые компиляторы оптимизируют операции, которые они считают бесполезными.

Например, компилятор MS Visual C++ посчитал лишним оператор |memset| в следующем фрагменте кода реализации анонимной сети Tor:

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

Алгоритм подписи EdDSA

В отличие от RSA, где секретный и публичный ключ можно использовать непосредственно, здесь приходится использовать более сложную схему и вводить некоторый дополнительный объект. EdDSA концептуально реализует алгоритм DSA, распространяя его на случай кривых. В качестве подписи выступает пара чисел (R,S), для EdDSA каждое длиной 32 байта, итого длина подписи — 64 байта. Подписываются не сами данные, а хэш он них. В качестве хэш-функции используется SHA512. Далее малым буквами будут обозначаться числа, а большими буквами — соответствующая точка на кривой, полученная умножением числа на базовую точку B.

Если вы хотите научиться программировать первоклассные игры, вам просто необходимо изучить язык С++. Эта книга поможет вам освоить разработку игр с самых азов, независимо от того, есть ли у вас опыт программирования. Гораздо интересней учиться, когда обучение превращается в игру. Каждая глава книги описывает самостоятельный игровой проект. В заключительной главе вам предстоит написать сложную игру, которая объединяет все приемы программирования, рас-смотренные в предыдущих главах. Книга идеально подойдет для начинающего программиста, планирующего не только как следует освоить непростой язык С++, но и поупражняться в программировании игр. Цель данной книги — познакомить вас с языком С++ в контексте программирования игр. Хотя невозможно представить себе такую книгу, которая сделала бы вас мастером в двух столь объемных темах, как программирование игр и язык C++, это издание пригодится вам в качестве вводного курса.

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

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях 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? Это возможно и следует делать, и об этом пойдёт далее речь.

Приемы, описанные здесь, есть в официальной документации к модулю argparse (я использую Python 2.7), ничего нового я не изобрел, просто, попользовавшись ими некоторое время, убедился в их мощности. Они позволяют улучшить структуру программы и решить следующие задачи:

1. Вызов определенной функции в ответ на заданный параметр командной строки с лаконичной диспетчеризацией.
2. Инкапсуляция обработки и валидации введенных пользователем данных.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

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

В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам.

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

Привет, %username%!

Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.

Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многим хабровчанам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом. И pdf тут как тут.

Доброго времени суток, Хабрахабр. Сегодня на крыле принес еще один перевод я (pdf-ки гугловского стайл гайда выложены). Хотя, кто знает, если кто-то оценит сию работу — быть может появится и продолжение. Как-то днём одним, предложил мне мой широко известный в узких кругах коллега scraplesh почитать ресурс — The Hitchhiker’s Guide to Python! называемый. Ресурс этот понравился мне. Понравились советы выдаваемые там. Понравилась канва повествования и вообще понравилось направление мысли автора. А если что-то хорошо на Ваш вкус, то нужно передавать это из уст в уста:) Итак, решил я сделать перевод данного ресурса. Но не всё так сразу — сначала будет пробная статья «на отклик» хабрасообщества. Если уважаемым гикам понравится сия тематика и изложение — будем стараться выпускать новые части. На первый «отклик» я выбрал раздел — "Writing Great Code" и в нем два подпункта «Structure is Key» и «Modules». Откликнемся под катом.

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

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



За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.