Мы в Perfect Solutions на прошлой неделе написали сотое по счету API. За все это время, ценой граблей, костылей, велосипедов и рефакторинга, мы поняли, что выработали отличную стратегию «как писать API и прекратить боль и страдание».

Этот пост о версировании, поддержке, багфиксинге и полном цикле жизни API.

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

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

• «Нам важен готовый продукт — плевать на плохой код»
• «Нам важен поддерживаемый продукт — пусть это и будет долго»

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

В статье речь будет идти о systemd, который вошел в Debian 8 jessie. Я пишу о Debian, потому что пользуюсь именно им. Пишу о systemd не потому что его фанат, но некоторые вещи меня действительно радуют.

Так почему же больше не нужны supervisord и forever?

Мы привыкли делить мир вокруг нас напополам: на добро и зло, на быстро и медленно, на размерено и взмыленно. Так же разделяется экономика: на плановую и рыночную. Так же разделяется программирование: на императивное и деклоративное. И так же разделяется управление: на планое и ситуационное…

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

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

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

Приближается 26 октября 2014 года — день, когда в 2 часа ночи в большинстве регионов России в очередной (и как снова обещано в последний) раз часы буду переведены на час назад. Кроме того, в некоторых регионах происходит смена часового пояса. Ознакомиться подробно где и что меняется можно в Федеральном законе от 21.07.2014 № 248-ФЗ «О внесении изменений в Федеральный закон „Об исчислении времени“.

В этом посте я хочу акцентироваться на вопросе приведения в актуальное состояние данных о часовых поясах в Debian.

 

В рамках одного из моих проектов, я провел небольшое исследование — как медленный интерфейс влияет на поведение пользователя?

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

Эксперимент проводился довольно просто, по принципу A/B тестирования. Аудитория A работала с сервисом «быстро», так как они и работает. А у аудитории B при отдаче каждой страницы был сделан sleep на 700 миллисекунд.

В сырцах разных авторов видел я разные варианты вечного цикла. Чаще всего мне встречались следующие:

while (true) {
...
}

и

for (;;) {
...
}

Поскольку каждый защищал “свой вечный цикл” как родного, я решил разобраться. Кто же пишет более оптимальный код.

Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

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

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

Привет, %username%! Несколько лет назад я познакомился с замечательным фреймворком Yii и с тех пор как только у меня появляется возможность вести проект на нем — я дерусь берусь за нее.

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

Gii «Из коробки» генерирует достаточно функциональный код, часто когда нужно создать мелкую фичу приходится очень мало менять. Но что если нам нужно больше возможностей? К примеру добавить поддержку нескольких языков, или изменит стиль генерируемого кода?
Есть 2 способа расширения: Изменять существующие шаблоны и создавать свои генераторы (ну или использовать уже готовые соответственно). На базе этих возможностей были созданы достаточно интересные продукты для комфортной работы с авто генерацией кода.

Мы часто экспериментируем с архитектурой, кодом, производительностью. Постоянно добавляем новый функционал. Мы постепенно обвязываем Yii своей “архитектурной” прослойкой — шардинг, работа с временно недоступными данными, разнообразные кеши и многое другое. Да, плод нашей работы, когда он будет заврешен, пойдет в Open Source.

Задача применяемой у нас Непрерывной Интеграции (Continuous Integration, CI) — не тестирование. Задача CI — обезопасится от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры. Также мы защищаемся от “плохого кода”, часто повторяющихся багов, “кривых” merge.

Для своего CI мы используем Jenkins под Debian. Время на развертку CI я затратил 12 часов — до полностью рабочего состояния. На поддержку CI я не трачу ни минуты в день — я не пишу тесты на каждую мелочь, не практикую TDD. Тем не менее, CI работает и спасает нас от глупых ошибок.

“Давайте будем внимательней”/”Давайте не делать ошибок” — взывал я к разработчикам, но это помогало лишь временно и то не на все 100%. Людям свойственно ошибаться, забывать, совершать оплошности. Нет, я не изобрел “серебряную пулю” для web-проектов и даже маленьку пульку для Yii — я придумал как стабилизировать свое приложение. Ваше приложение отличается от моего и мои методы у Вас могут не работать, да и не должны — я же делал их не для Вашего приложения, если мои методы работаю у Вас — примите это как чудо или как везение. Зато идея такого CI будет работать везде. Всего лишь идея.

Добрый день хабр.
После моей статьи о test.it прошла вечность неделя. И как я не планировал растянуть этот срок хотя бы на месяц, но пришло время для новой публикации.
Картинка для привлечения внимания:

С того времени библиотека (во многом благодаря хабравчанам) обросла новым функционалом.
А ввиду того, что синтаксис, приведённый в прошлой статье, в текущей версии работает не полностью, откладывать эту статью ещё на 3 недели у меня нету права.

Кто не любит много слов — Сайт на котором можно увидеть код в действии, GitHub, Wiki

Это позволяет избежать CSRF/XSRF-атак (подделки межсайтовых запросов).

Рассмотрим следующий пример: допустим у Google есть URL вида gmail.com/json?action=inbox, который возвращает 50 первых сообщений вашего почтового ящика в формате JSON. Злоумышленник, чей сайт находятся на другом домене, не может выполнить AJAX запрос, обратившись по данному URL, чтобы получить данные, ввиду same origin policy (правило ограничения домена). Но ничто не мешает злоумышленнику включить вышеуказанный URL на свою страницу с помощью тега .


Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

Так уж исторически сложилось, что связка pptpd + pppd — довольно популярное решение для раздачи интернета в локальных сетях, во многом благодаря наличию клиента pptp в windows начиная с 98 «из коробки». Более того, этот клиент поддерживает протокол шифрования MPPE который начиная с windows 2000 включен для новых соединений по умолчанию.
pppd радостно идет нам навстречу, также поддерживая этот протокол, но делает это весьма своеобразно:

Введение

На сервере доступа в качестве pptp-сервера стоял проверенный Poptop последней стабильной версии (1.3.4). И все бы ничего, да вот только после повышения скоростей на тарифах производительность cервера начала проседать под увеличившейся нагрузкой. Причем очень значительно, так как этот pptp-сервер работает в режиме пользователя, а не ядра. Постоянные копирования пакетов и непосредственно с этим связанные операции переключения контекста, на выполнение которой также расходуются вычислительные ресурсы, вызвали серьезную деградацию производительности сервера при увеличившемся объеме передаваемого трафика. Необходимо было действовать.

mysqlnd — расширение PHP, которое является драйвером для работы с MySQL по умолчанию в PHP 5.4. Оно работает напрямую с MySQL сервером, а значит, MySQL клиент, а также оверхед на работу с ним, больше не требуется!

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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