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

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

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

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

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

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

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

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

Университет Ватерлоо при поддержке Google организовал состязание по спортивному программированию ботов для игры стратегии реального времени Galcon. С виду игра очень простая - есть планеты и корабли (на планетах или в полёте) надо захватить или преобладать на всей карте. Бот можно написать на большинстве популярных языков - C#, Java, Python, C++, Scala, PHP - для этого надо скачать "starter package", запустить у себя из консоли эмулятор и тренироваться покуда не будет Совершенство которое можно залить на сайт.

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

Итак некоторые общие стратегии