Выживает не самый сильный и не самый умный, а тот, кто лучше всех откликается на происходящие изменения Леон Меггинсон, перефразируя Чарльза Дарвина

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

Внимание меньшинству

Доступность как правило отличают от простого удобства (useability) в использовании, именно в том что система начинает учитывать людей с нарушениями:

1. Зрения (слепота, близорукость, дальтонизм) - решается синтетическим произношением, экраном Брэйля, сильным увеличением экрана
2. Слуха
3. Опорно-двигательной системы (вывих, паралич, квадриплегия, тремор) - решается вспомогательными технологиями ввода, большими областями для клика.
4. Восприятия (дислексия, перегрузка память и внимания) - необходима логическая и понятная структура сайта

Учитывая что таких людей 7-10% и именно им важней доступность электронных услуг (государственных, онлайн-магазинов), то продолжая прошлую тему о целостности общества, особенно важно что многие государства обязали свои инфоресурсы быть доступными (accessible). Уважающие себя компании аналогично занимаются этими вопросами. Парадоксально, но для доступного сайта достаточно сделать всё качественно. Это напрямую отразится на удобстве дизайна, SEO и скорости. Основы также лежат в машинной доступности данных, семантической вёрстке и правильном UI.

Автоматический анализ кода (static code analysis) очень полезен на больших проектах и он часто встраивается в серверы непрерывной интеграции. Некоторые IDE уже поставляются с простыми аналитическими инструментами, но первые всё-таки предпочтительней, потому что туда смотрит вся комманда. Всё что этот софт делает это периодически смотрит в систему версионирования (SVN) и строит график качества (и например запускает юнит-тесты). По сути это аналог комплекса упражнений для человека, поддерживающих хорошее здоровье и бъющих тревогу если возникает рак спагетти-кода.

Самые известные CI-серверы:

• Hudson и его бесплатный двойник Jenkins (на java, много модулей) → есть шаблон
• CruiseControl
• Atlassian Bamboo
• Jetbrains TeamCity
• BuildBot
  
• Xinc
  
• Arbit (включает в себя project management и bugtracker)

Статический анализ кода и его метрики

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

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

Размерные метрики

• NOP - число пакетов
• NOC - число классов → Число классов в пакете (Java =17, C++=19)
• NOM - число методов → Число методов в классе (Java = 7, C++ = 9)
• LOC - число строк → Ошибок/KLOC, Документации/KLOC
• IOp - число параметров входа/выхода
• IOg - число переменных вызываемых методом (классовых и глобальных, не локальных)
• IOvar = IOp + IOg
• CS - число атрибутов и методов. Может указывать на слишком большую ответственность одного класса
• NOO - число переписанных родительских методов в дочерних классах. Указывает на высокую или низкую абстракцию
• NOA - число новых методов в зависимости от глубины наследования

Метрики наследования

• ANDC - среднее число наследующих классов (Java = 0.41, C++ = 0.28)
• AHH - средняя высота иерархии (Java = 0.21, C++ = 0.13)
• MIF = число унаследованных но не перезаписанных методов / общее число методов, указывает на степень абстракции или специализации класса (значение от 0 до 1)
• PF - фактор наследования = число наследуемых методов / (число новых методов * число дочерних классов ), показывает насколько используются наследуемые методы (значение от 0 до 1)

Метрики сложности

• CF - фактор связанности двух классов (т.е. один класс вызывает или использует методы/свойства другого класса) = число вызовов / максимальное число вызовов (значение от 0 до 1)
• CALLS - число вызовов методов
• FANOUT- число (вызываемых ) классов → (fin+fout)2 * len
• Структурная сложность = CALLS 2
• Сложность данных SC = IOvar / (CALLS +1)
• Цикломатическая сложность CC = число решений / число строк (Java = 0.2, C++ = 0.25). Разные научные определения (Halstead, McCabe, McClure)
• Системная сложность: SYSC = SC + SD

Инструменты

Для php таких аналитических программ относительно мало — есть консольные узкоспециализированные программки:

• Depend - использует некоторые приведённые выше метрики для анализа сложности pdepend --overview-pyramid=out.svg my_project_name pdepend --jdepend-chart=out2.svg my_project_name
pdepend --jdepend-xml=out.xml my_project_name dependencies.php out.xml -o out3.svg
  
• Mess detector - ищет неиспользуемый код и сложные выражения phpmd my_project_name text phpmd.xml
  
• Code sniffer - проверяет названия методов и переменных согласно правилам из XML-файла настроек phpcs --standard=CodeREview --report-source my_project_name
  
• Dead code detector ищет невызываемый код
• Copy-paste detector
• phploc - оценивает размер
  phploc my_project_name
  
• PHPLint - проверяет синтаксис и генерирует документацию
• Analzer for Type Mismatches - ищет возможные ошибки с несовместимостью типов

Ещё есть чуть более общие PMD (на java) и phpsat, специализированные RIPS, RATS (как вариант Fortify360 + Jenkins), Yasca, Pixy и агрегаторы всего что только можно - PHPUnit,  PHPLint, Sonar

Динамический анализ кода

В отличие от статического анализа, здесь система должна работать. Причём нас на этом этапе заботят - скорость работы всей системы (и узкие места) и логическая безошибочность. Соответсвенно решается это

• Покрытие кода тестами (Statement, Branch, Path coverage)
  
• Граф скорости загрузки и использования памяти в зависимости от методов

Инструменты

• Selenium
• XDebug
  
• Zend Server
• KCachegrind, Webgrind, cachegrindvisualizer

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

PivotalTracker — один из таких инструментов, созданный специально для любителей scrum, соответсвенно он оперирует кучками задач (backlog, icebox и тд.). Но суть не в этом..

1. Не приходилось постоянно ходить в последнюю для просмотра описания и изменения статуса
2. Открытые табы (файлы) зависели бы от контекста, т.е. от решаемой в данный момент задачи
3. Сохранять список изменённых файлов в рамках задачи (на случай поиска дальнейшего дебага)
   

Теперь в Tools → Context можно сохранять табы, а в Tools → Task можно прочитать описание, открыть в браузере или переключиться на другую задачу. Success!

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

Балансировщик нагрузки

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

Используется повсеместно в средних и больших проектах

Распределённые вычисления

В этой модели источник рассылает запрос всем работникам. Каждый работник вычисляет местное значение и возвращает результат источнику. Последний объединяет результаты параллельного вычисления и возвращает клиенту.

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

Unit-тестирование это хорошо. Много хороших статей написано о том как прекрасно это взять класс и для него написать юнит-тест. Позавчера вот Андрей Солнцев даже про расширение к TDD рассказывал — BDD. А большинство программистов по прежнему не используют.. просто потому что сложно даже настроить. Вот попробуем это для php сделать.

Прежде всего понадобится свой локально установленный php — я поставил последнюю 5.3.3 thread safe x86 версию. До этого я пробовал всякие WAMP, XAMPP, Apache2triad, Денвер.. и отсюда все проблемы которые далее возникли.

Ставим PEAR запустив в консольном режиме php с гигантским файликом установки go-pear.php — я его положил в папку с установленным php. Если у вас уже есть старенький PEAR, то pear.bat upgrade обновит его.

Установщик сам всё подкачает и распакует. У меня правда вылазили deprecation-ошибки и ошибки винды "CGI / FastCGI has stopped working" из-за параллельно существовавшего старого Apache2Triad пака. Пришлось его удалить и поменять путь к php (прямо в диалоге установки)

Связываем PHPStorm

В детальном описании настройки всё идеально. А у меня при создании теста возникает ошибка об отсутствии файла E_WARNING: PHPUnit/Framework.php.

На форуме это объясняют путями к PEAR — IDE и у меня ругается при настройке путей к php на несовместимость с каким-то "оригинальным путём к php" который почему-то C:\php5\pear.. А всё потому что include_path не установлен из-за отсутсвия php.ini в C:\Windows. Копируем из установочной php-папки прототип php.ini, ставим туда правильную include_path переменную — теперь PHPStorm пути видит правильно.

Запускаем генерирование тестов и опять облом. Видимо PHPUnit новей чем PHPStorm 1.0, который всё ещё пытается включить файл который включать не стоит.

Обновляем IDE до 2.0 и вуаля - тесты генерируются! Но при запуске теста почему-то вылетает ошибка о нечитаемом файле. Лезем в Fileloader.php и закомментирываем exception и о чудо..

Теперь уже можно разбираться с тест-пакетами, синтаксисом..