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

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

Однако, важным является тот факт, что способных успешных менеджеров, а также желающих, готовых на достаточно большие усилия, чтобы стать успешным менеджером, было не так много. И пока организация производства могла обходиться таким количеством менеджеров, система более-менее работала. Это, по моим ощущениям, 60-70-е годы. А затем произошло следующее. Повышение потребности в квалифицированном труде позволило достаточно большому количеству людей подниматься вверх альтернативным путем. Не стремясь стать успешным менеджером ценой больших усилий. В ответ на это - появилась идея обучения регулярным образом, без существенных затрат собственной энергии, которая, в конце концов, вылилась в идею MBA. Теоретически там учат тех же самых успешных менеджеров на основе анализа опыта и методов. Но практически тех самых менеджеров, которые служили образцом - не получается, потому что составляющие самомотивации и самореализации в должной мере не присутствуют у всех обучающихся. Хотя тем, у кого он присутствует в силу личных склонностей, такое обучение безусловно помогает.

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

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

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

Ихв 90-х решение было найдено - Agile-технологии. Возникнув первоначально как протест против доведенных до абсурда процедур регламентации в виде XP, они с появлением SCRUM дали легкий и эффективный способ управления IT-проектами, обеспечивающий приемлемое качество и при этом сделавший управление IT-проектами доступным достаточно широкому кругу людей в отрасли без чрезмерных усилий по освоению. И этот способ завоевывал мир де-факто. При этом первоначальная цель XP - вытеснить за рамки IT процедурное администрирование и вообще классических управленцев - также была во многом достигнута за счет внедрения собственной, оригинальной терминологии и практик. В результате IT-шники получили возможность самостоятельно управлять своими проектами или, во всяком случае, обрекли менеджеров на разбор со спецификой отрасли. Хотя сами практики, если разобраться внимательнее, впитали в себя позитивный опыт “обычного” менеджмента который тоже интенсивно развивается.

После успеха де-факто началось признание де-юре. Артефактами этого являются SWEBOK 3 версии (2004) и PMBOK 4 версии (2008) в которых явно упоминаются agile- методологии и сделана оговорка, что структура самого документа повторяет стадии классической (водопадной) модели лишь по совпадению. PMBOK-4 читать особенно забавно - итеративность новые веяния вписаны в книгу явно на живую нитку, точки сшива и провалы целостности, возникшие из-за этого - видны. И этот процесс завершается сейчас понятийной сшивкой с менеджментом вне IT, которая необходима для Agile-управления IT-проектами в мегакорпорациях. Проявления этой сшивки - доклад Dan Rawsthorne. Scrum: the Big Picture на AgileDays-2012, в котором показана реализация в Agile “общепринятой” иерархии уровней Software Development - Product Development - Project Management - Portofolio Management. И доклад Джефа Сазерленда на SECR-2011, в котором правильный SCRUM позиционирован как высшая и последняя стадия CMMI-5.

Если же говорить о широких массах, то IT-шники относятся к управлению так же как к технологиям. Они знают, что серебряных пуль - нет. Они знают, что новые идеи могут давать много полезного, и за ними надо следить. И чтобы их использовать вовсе не обязательно углубляться в теорию - можно применять на практике и без этого. Хотя если интересно - то почему бы не разобраться в теории - это прикольно, полезно и поучительно. Но во всей теории разбираться - никакого времени не хватит. Поэтому новые идеи вспыхивают, оказавшись удачными - распространяются, становятся общеизвестными, в их ограничениях разбираются, после чего они осыпаются в багаже полезнымии практиками. Так же и в технологиях: вспыхивает функциональное программирование, F# и Haskel, обретает последователей, интенсивно развивается, а потом опадает новыми элементами в C# или занимает подобающую, хотя и неожиданную нишу как Erlang. И практики управления и технологии по пути могут обрастать евангелистами и ярыми сторонниками. А сам цикл от прихода до обретения места - стремителен, порядка полутора лет.

Как я уже говорил, оригинал управленческих практик часто приходит извне. Но попав в IT - он сильно изменяется. Например, Канбан в IT обернулся тремя практиками ведения проекта: доска, ограничения на ней, измерение скорости потока. Который сосуществует в сознании с “большим” Канбаном как методом оптимизации процессов. Схема формирования команды - стадии Storming-Forming-Norming-Performing тоже стали более простыми и формальными, скрестившись по пути с IT-командами. Поэтому многие говорят об отсутствии принципиально нового или искажении оригинальных, якобы правильных идей и процессов. Но это неправильно. Потому что реально процессы впитывают специфику IT-разработки. А еще - приобретают нужный уровень легкости и схематичности, который и обеспечивает их успешное применение в проектах.

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

Писать javascript в декларативном стиле гораздо удобнее:

• Возможность привязать конкретному html-блоку нужный javascript функционал
• Возможность писать javascript код наподобие css (к объекту привязывать свойства)
• Улучшить читаемость кода, перенеся логику, связанную с конкретными html-блоками, в отдельные файлы
• И много чего ещё. Попробуйте и сами все увидите.

Итак, приступим.

Для начала заведём 3 файла:

• index.html — файл, содержащий html блоки, которые и будем обрабатывать
• index.js — файл, содержащий функции инициализации привязанных к блокам функций
• init.js — файл, содержащий логику обработки привязанных блоков

Содержимое файла index.html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  <script type="text/javascript" src="init.js"></script>   <!-- Подключаем файл с набором функционала для блоков -->
  <script type="text/javascript" src="index.js"></script>  <!-- Подключаем файл c функцией-инициализатором -->
</head>

<style type="text/css">
div
{
    margin:30px;
    padding:10px;
    background: #ccc;
    border:solid 1px #666;
    font-family:arial;
    font-size:12px;
}
</style>

<body>

    <div class="b-block init_block1">  <!-- Первый блок -->
      Привет, ХабрЮзер)))
    </div>

    <div class="init_block2"> <!-- Второй блок -->
      А я говорю..привееет)))
    </div>    

</body>

</html>

Файл index.js:

/**
 * Функция, позволяющая навешивать обработчик события элементу
 * (по сути отношение к статье не имеет, добавлена просто для удобства)
 * @param object elem - элемент, к которому будем привязывать событие
 * @param string evType - тип события (например: "click","mouseover")
 * @param function call - функция-обработчик (можно анонимную)
 */
function addEvent(elem,evType,call)
{
     if(elem.addEventListener)
     {
        elem.addEventListener(evType, call, false);
     }
     else if(elem.attachEvent)
     {
        elem.attachEvent('on' + evType, call);
     }
}  

/**
 * Функция, обеспечивающая инициализацию функционала блоков
 */
function initStart()
{
     var arrayElem = document.getElementsByTagName('*');

     var arrayElemLength = arrayElem.length;

     for(var i=0;i<arrayElemLength;i++)
      {
            var attr = arrayElem[i].className;
            if(attr)
            {
                if(attr.indexOf('init_') !== -1)
                 {
                    var initText = attr.substr(attr.indexOf('init_'));

                    if (initObject[initText])
                    {
                       initObject[initText](arrayElem[i])
                    }

                 }
            }

      }
}

/* Как только страница загрузится, инициализируем наши функции для блоков */
addEvent(window,'load',initStart);

Файл init.js:

/**
 * Объект, содержащий функции для обработки привязанных блоков
 */
var initObject =
{
   /**
    * Привязываем к html-элементу, содержащему class "init_block1" функционал
    * @param object elem - сам html-объект (передаётся из функции-обработчика)
    */
   init_block1: function(elem)
   {
       elem.innerHTML += ' Опа...Отработала привязанная к блоку функция';
   },

   /**
    * Привязываем к html-элементу, содержащему class "init_block2" функционал
    * @param object elem - сам html-объект (передаётся из функции-обработчика)
    */
   init_block2: function(elem)
   {
       elem.innerHTML += ' Отработала и у этого блока. А теперь кликни тут';

       addEvent(elem,'click',function(){

           alert('Работает!');

       });

   }
}

Итак все подключили, теперь объясню.

Для того чтобы привязать определенную логику к какому-нибудь блоку на странице, необходимо в классе этого элемента указать метод объекта initObject.
В метод передаётся сам html-элемент (точнее ссылка на него), с ним вы можете делать всё, что угодно: привязать событие, передать данные в ajax, изменить свойство и т.д.

Таким нехитрым способом мы можем привязывать определенную логику нужным объектам на странице.

Стоит отметить, что функция initStart не совсем идеальна — есть что доработать.
Но это учебный пример, поэтому я не стал делать все «с иголочки», думаю, общая концепция и так понятна.

Как это работает, вы можете посмотреть здесь.
Скачать одним архивом пример.

(оригинал статьи опубликован здесь)

В статье о moment.js разгорелся горячий спор.

И я считаю, это достаточно серьёзный спор для того, чтобы у него была отдельная статья. Очень важно с этим моментом наконец разобраться. _{Если мы придём к обратному заявленному в статье решению – это, в конце концов, тоже будет важный ответ.}

Так расширять встроенные типы (String, Array, Number, …) в JS или не расширять?

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

Исторический взгляд

Что мы получим, если рассмотрим исторический процесс становления JavaScript? (это мой вольный взгляд по памяти на историю JS, вполне возможно в нём есть реальные отклонения от настоящего).

1. Появляется JavaScript и в нём прототипное наследование. И встроенные типы в нём тоже построены на прототипном наследовании. И ещё в нём есть неудобные операции с DOM. Это безэмоциальные факты.
2. JS используют для мелких скриптов, в которых не задумываются о наследовании и никаких вопросов соответственно не стоит
3. Браузеры развиваются, постепенно JS всё плотнее входит в веб-разработку и становится нужным писать на JavaScript более крупные вещи, чем раньше. Динамические языки ещё не так популярны, популярны: C++, PHP, Java
4. Из-за необходимости написания крупных вещей (и неудобства DOM в JS) появляются библиотеки с функциями-помощниками. Одна из них — Prototype.js. Поскольку о наследовании вопрос ещё не стоял и не задавался, авторы библиотеки по привычке подсовывают нужные методы в прототипы встроенных объектов и чувствуют себя совершенно спокойно. И разработчики тоже. Где-то в это же время разработчики начинают хотеть классы в JS (и ваш покорный слуга из их числа) и, откопав где-то копипасту с функцией extend или чем-то подобным, начинают её активно использовать. Прототипы это сложно, а классы – это знакомо и проверено временем. Так что это тоже происходит довольно безболезненно, поскольку классическое ООП нормально ложится на прототипное наследование
5. Незаметное событие: Те, кто использует Prototype.js в крупных проектах неожиданно замечают вкусный на вид оператор for-in, прикручивают его, но чуть позже начинают обнаруживать странные ошибки при проходах по массивам и объектам
6. Вина за эти ошибки интуитивно падает на JavaScript, эта информация расходится по интернетам, цикл for-in становится нерекомендуемым, все спокойны и рады. На фоне появляется Ajax, после нескольких попыток для него появляется работающая на тот момент кроссбраузерная копипаста, все вроде тоже довольны, но всё же как-то не хватает стандартизации.
7. Неожиданно появляется чуть больше людей, которые разобрались в прототипном наследовании и понимают, что то что происходит – не очень хорошо. Появляется и тут же популяризуется jQuery (к коду которого у меня никаких претензий, кроме нынешнего веса библиотеки — но так тоже сложилось исторически) (с удобным методом ajax, btw)
8. Адепты прототипного наследования выходят из нор и пытаются раскрыть другим программистам глаза на возможности, которые уже давно им доступны, но они их упускают. Библиотеки ещё весят мало, поэтому их иногда смешивают. Где-то здесь появляется конфликт JQuery и Prototype.js, выросший из проблемы с document.getElementByClassName, причина которой в расширении встроенного типа
9. Время идёт, разобравшихся в прототипном наследовании всё больше. С другой стороны подступает функциональщина, которой тоже удобно писать на JS, используя созданные in-the-place объекты
10. Появляется node.js, в котором отказываются от классического ООП и используют паттерн «модуль» из CommonJS, где отдельный файл содержит неймспейс с функциональщиной (или, нежелательно, ООП) внутри. Это шаг к отказу от ООП
11. Войны ООП vs прототипы/функциональщина
12. Сейчас мы здесь

Видно, что ошибки научили ещё не всех.

Логический взгляд

— Почему в JS не рекомендуется использовать оператор for-in?
— Неправильный ответ: потому что в перечисление могут попасть ненужные свойства и методы объекта
— Сомнительный ответ: не использовать для массивов, потому что для массивов не гарантировано сохранение порядка перебора (это правда, но это провис языка и/или движков браузеров и сейчас это меняется)
— Сомнительный ответ: в массив можно записать свойство не по индексу через a["woo"] = 23; и тогда оно попадёт в цикл. Да, можно, но зачем осознанно так делать?
— Правильный ответ: в перечисление могут попасть все не-enumerable свойства объекта, а в том числе все свойства из цепочки прототипов. Если у объекта длинная цепочка прототипов, то это будет происходить долго из-за её перебора. Для отделения свойств на верхнем уровне цепочки можно использовать hasOwnProperty, для определения, принадлежит ли свойство объекту.

— Да, но что если у нас есть простой объект без сложной цепочки, созданный прямо на месте? Вот так: {'a': 2, 'b': 3}? Тоже нельзя использовать for-in?
— Неправильный ответ: Да, нельзя. Это не рекомендуется.
— Сомнительный ответ: Эммм…
— Почти правильный ответ: Можно, он для этого и был прездназначен. Но есть одно «но». Программисты библиотеки, которую ты используешь, подсовывают в прототипы встроенных объектов свои методы и естественно не заботятся об enumerable: false. И эти методы могут попасть в перечисление. Безопаснее этим не пользоваться.

Эй, а почему вдруг безопаснее отгородить себя? Значит так и будет продолжаться? Это разве решение проблемы?

— Правильный ответ: Давно пора образумить этих программистов.

Практический взгляд

var a = [12, 14, 13, 6];
for (var i in a) { console.log(i, a[i]); }
> 0 12
> 1 14
> 2 13
> 3 6
Array.prototype.foo = function() { console.log('bar'); }
for (var i in a) { console.log(i, a[i]); }
> 0 12
> 1 14
> 2 13
> 3 6
> foo bar

for (var a in { 'a': 2, 'b': 3 }) { console.log(a); }
> a
> b
Object.prototype.foo = function() { };
for (var a in { 'a': 2, 'b': 3 }) { console.log(a); }
> a
> b
> foo

Array.prototype.forEach = function(...) { ... };
var matches = 'test'.match(/t/);
console.log( matches instanceof Array );
> true
for (var i in matches) console.log(i, matches[i]);
> 0 t
> index 0
> input test
> forEach function() { }

(за обнаружение последнего примера спасибо TheShock)

Где-то здесь появляется конфликт JQuery и Prototype.js, выросший из проблемы с document.getElementByClassName

JavaScript Гарден, глава «Великий прототип», последний раздел «Расширение встроенных прототипов». Мой там только перевод, этот документ писали опытные JS-программисты (хотя и там есть косяки. Но не в этом абзаце).

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

… По-моему как раз «соответствует всей идеологии JS» и «все JS фреймворки» – это религия. В языке есть дырки и одна из них – то, что можно расширять встроенные типы.

JQuery пользуется расширением прототипа собственного объекта – это вполне себе ок и как раз соответствует идеологии. А мы говорим о расширении встроенных типов — это две разные вещи. Встроенные типы по правилам any-типизированных языков должны быть закрыты для расширения. В JS у вас есть возможность их расширить и это сработало как неизвестное медленно-текущее вирусное заболевание. Заразились одни, не ощутили последствий, а через месяцы оказались заражены все вокруг.

Разумный взгляд

Вы помните чем кончается переопределение операторов в C++? Вы знаете, что не можете расширить встроенные классы Java? Вы пытаетесь отнаследоваться от str в Python? Нет. Так почему же вы это делаете в JS?

Сейчас мы живём в эру быстро сменяющихся версий браузеров, избавления от старых, и перехода на HTML5, так может и в JS стоит забыть некоторые первобытные страхи?

Когда можно

• Если вам нужно в своём личном скрипте обеспечить наличие метода, который будет в будущем имплементирован. При этом нужно, чтобы интерфейс который он возвращает также соответствовал спецификации
• Всё

Альтернативы

Да какие хотите (ок, все приведённые функции – в видимости какого-то своего объекта, не в глобальной):

• function trim(str) { return str.replace(...); } trim(" string to trim ");
• function trim() { return this.replace(...); } trim.call(" string to trim ");
• utils.trim(" string to trim ");
• var a = new ExtendedString(" string to trim "); a.trim();
• $.each([ 1, 2, 6, 6], …);

Статьи по теме

• Extending built-in native objects. Evil or not? by kangax/kangax (спасибо smashercosmo)
• What’s wrong with extending DOM? by kangax/kangax (спасибо smashercosmo)
• Javascript for…in with arrays @ SO
• Exploring JavaScript for...in loops

Тесты

В этом комментарии Zibx провёл тест по скорости двух способов: через расширение прототипа и отдельную функцию и работа через прототип чуть не показалась нам действительно значительно быстрее. Но к счастью Markel опроверг этот факт, создав соответствующий тест на jsperf.

Во время хакатона по Windows8 многим участникам пришла в голову «гениальная» идея писать код, не изучив документацию по WinRT и Windows8 API с примерами из SDK.

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

В SDK очень много примеров, но не обещаю делать обзор по всем. Мне совершенно не интересен DirectX, слабо интересны примеры на HTML-JS-CSS. Я буду писать о примерах на C#.

В этой статье я расскажу и покажу примеры API системы, для работы с настройками приложения, поиском, профилем пользователя.
На основе личного опыта использования Win, я могу сказать, что пользователю первое время тяжело разобраться с приложением, т.к. он не знает, где искать его настройки. Есть несколько панелек, где они могут быть. Это боковая панель (App settings) и верхняя-нижняя панель (AppBar)

Работа с настройками App settings

Проект App settings sample

В боковой панели можно и нужно разместить настройки вашего приложения.
Из опыта общения с юзерами телефонов на WP7, IPhone, Android я понял, что пользователь достаточно быстро привыкает к шаблонам поведения приложения на каждой платформе и интуитивно ищет настройки приложения там, где он их видел в других приложениях. Windows8 приучит пользователя искать настройки в боковой панели, а значит, разработчик должен свои настройки вынести именно туда.

Как их туда добавить?



Достаточно просто. А какие настройки там хранить — это уже дело разработчика. Цвет ли фона, личные данные и/или что-то еще…

Работа с App bar

То, что нельзя занести в App Settings (это не настройки, а, допустим, частые действия или, например, отправка фидбэка разработчикам), стоит занести в App Bar. Это верхняя или нижняя панель. Тем, кто использовал Windows Phone7, я думаю, объяснять этого не нужно. Чтобы появилась панель App Bar, необходимо вытащить ее из нижней или верхней частей экрана. В случаи использования мышки- правый клик. Выглядит эта панель в развернутом состоянии примерно так:



Хочу показать пример на HTML:

Продолжаем историю про генерацию DOCX средствами PHP. Первая часть статьи опубликована здесь.

Что нас ждет сегодня:

• Мы узнаем, как вставлять изображения в документ;
• Просветимся на счет English Metric Units;
• Сделаем задел на будущую генерацию Exel.

Ещё раз

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

А подход этот заключается в использовании наследования: класс генератор должен быть наследником ZipArchive. Послушайте, ну если не хотите Вы использовать наследование, установите PHP 5.4 и используйте traits, в конце концов! Этот подход несравненно лучше, чем работать постоянно через одно свойство:

$this->archive->open( … );
$this->archive->addFile( … );
$this->archive->close( .. );

Для чего вообще нужно генерить DOCX на PHP? Некоторые разработчики не понимают, зачем вообще это нужно. Я ориентировался на то, чтобы сделать возможность сохранить web-страницу в формате Word. Лично я использую свой класс для сохранения отчетов Яндекс.Метрики в формате DOCX. Меня спросили, зачем я разбивал текст на строки? Я это делал, предполагая, что текст является полем из БД, а перенос строки - новый абзац. В общем, не будем этого делать для ясности. Сделайте сами разбивку на абзацы. Кроме того, наш генератор должен иметь максимально удобный API. Я думаю, мне удалось его реализовать. API состоит всего из трех методов: конструктора, assign, create.

Ну что ж, поговорили - и хватит. Приступим.

Что нового

Во-первых, я существенно изменил код, используемый в первой части статьи, и оформил это всё в полноценную OpenSource библиотеку. Ссылки в конце. А сейчас по пунктам:

1. Класс OfficeDocument и WordDocument

Как мы уже поняли, в корне архива хранятся файлы, необходимые документу MS Office в целом. В папке word/ хранятся документы, необходимые документу MS Office Word непосредственно. Решение напрашивается само собой: сделать класс общий для документов MS Office, и класс-наследник для Word-документов непосредственно.

Сразу опишу структуру:

// Общий класс для создания генераторов MS Office документов
class OfficeDocument extends ZipArchive{

__construct($filename, $template_path = '/template/' );
protected function add_rels( $filename, $rels, $path = '' );
protected function pparse( $replace, $content );
}
// Класс для создания документов MS Word
class WordDocument extends OfficeDocument{

public function __construct( $filename, $template_path = '/template/' )

// Обращаю внимание, это метод API
public function assign( $content = '', $return = false );
public function create();
}

Зачем я это сделал? Это задел на будущее, в котором мы будем генерить файлы MS Excel классом XlsxDocument.
Давайте разберем внутренности.

2. Динамическое создание связей

Внутри docx-файла существуют файлы _rels/.xml и word/_rels/document.xml.rels. Они подключают файлы в документ. Если не
описать какой-либо файл в этих структурах, то он просто окажется лишним весом в docx-документе. Таким образом можно просто прятать инфу внутри docx. Мы же в конструкторах создадим массивы внутренних связей между XML-документами. Вот, например, связи для документа MS Office:

       // Описываем связи для документа MS Office
       $this->rels = array_merge( $this->rels, array(
         'rId3' => array(
           'http://schemas.openxmlformats.org/officeDocument/2006/relationships/
extended-properties',
           'docProps/app.xml' ),
         'rId2' => array(
           'http://schemas.openxmlformats.org/package/2006/relationships/metadata/
core-properties',
           'docProps/core.xml' ),
       ) );

Идентификатором подключаемого файла является запись “rIdN”. Файлы app.xml и core.xml являются статичными. Мы их просто будем упаковывать в архив методом add_rels, параллельно создавая XML-файл описания связей _rels.xml:

     // Генерация зависимостей
     protected function add_rels( $filename, $rels, $path = '' ){

       // Шапка XML
       $xmlstring = '';

       // Добавляем документы по описанным связям
       foreach( $rels as $rId => $params ){

         // Если указан путь к файлу, берем. Если нет, то берем из
репозитория
         $pathfile = empty( $params[2] ) ? $this->path . $path . $params[1]
: $params[2];

         // Добавляем документ в архив
         if( $this->addFile( $pathfile , $path . $params[1] ) === false )
           die('Не удалось добавить в архив ' . $path . $params[1] );

         // Прописываем в связях
         $xmlstring .= '';
       }

       $xmlstring .= '';

       // Добавляем в архив
       $this->addFromString( $path . $filename, $xmlstring );
}

Обращаю внимание, что add_rels описан в OfficeDocument, а используется в обоих классах: OfficeDocument и WordDocument, поскольку внутри .docx файла существует два документа _rels.xml, описывающих зависимости. Это выигрыш ООП подхода, который я предложил, и здесь не подойдет методология,
предложенная в комментариях.

В результате получаем такой типовой _rels:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships
xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId3"
Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/extended-properties"
Target="docProps/app.xml"/>
  <Relationship Id="rId2"
Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties"
Target="docProps/core.xml"/>
  <Relationship Id="rId1"
Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument"
Target="word/document.xml"/>
</Relationships>

Файл word/document.xml мы сгенерим и подключим динамически. Надеюсь, с динамическим созданием связей понятно. Теперь со вставкой изображения.

Учимся вставлять изображения

Сначала приведу XML-фрагмент, полученный экспериментальным методом, для вставки в document.xml, чтобы получить изображение в Word-документе:

<w:p w:rsidR="000E3348" w:rsidRDefault="00CD6FED">
  <w:r>
   <w:rPr>
    <w:noProof/>
    <w:lang w:eastAsia="ru-RU"/>
   </w:rPr>
   <w:drawing>
    <wp:inline distT="0" distB="0" distL="0" distR="0">
     <wp:extent cx="{WIDTH}" cy="{HEIGHT}"/>
     <wp:effectExtent l="19050" t="0" r="0" b="0"/>
     <wp:docPr id="2" name="Рисунок 2"/>
     <wp:cNvGraphicFramePr>
      <a:graphicFrameLocks
xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main"
noChangeAspect="1"/>
     </wp:cNvGraphicFramePr>
     <a:graphic
xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main">
      <a:graphicData
uri="http://schemas.openxmlformats.org/drawingml/2006/picture">
       <pic:pic
xmlns:pic="http://schemas.openxmlformats.org/drawingml/2006/picture">
        <pic:nvPicPr>
         <pic:cNvPr id="0" name="image.jpg"/>
        <pic:cNvPicPr/>
       </pic:nvPicPr>
       <pic:blipFill>
        <a:blip r:embed="{RID}">
         <a:extLst>
          <a:ext uri="{28A0092B-C50C-407E-A947-70E740481C1C}">
           <a14:useLocalDpi
xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main" val="0"/>
          </a:ext>
         </a:extLst>
        </a:blip>
        <a:stretch>
         <a:fillRect/>
        </a:stretch>
       </pic:blipFill>
       <pic:spPr>
        <a:xfrm>
         <a:off x="0" y="0"/>
         <a:ext cx="{WIDTH}" cy="{HEIGHT}"/>
        </a:xfrm>
        <a:prstGeom prst="rect">
         <a:avLst/>
        </a:prstGeom>
        <a:noFill/>
        <a:ln>
         <a:noFill/>
        </a:ln>
       </pic:spPr>
      </pic:pic>
     </a:graphicData>
    </a:graphic>
   </wp:inline>
  </w:drawing>
  </w:r>
</w:p>

Нам нужно будет заменить {RID} на идентификатор подключенного изображения, а также прописать {WIDTH} и {HEIGHT}.
За вставку изображения, как и за вставку текста отвечает один метод API - assign:

     public function assign( $content = '', $return = false ){

       // Проверяем, является ли $text файлом. Если да, то подключаем
изображение
       if( is_file( $content ) ){

         // Берем шаблон абзаца
         $block = file_get_contents( $this->path . 'image.xml' );

         list( $width, $height ) = getimagesize( $content );

         $rid = "rId" . count( $this->word_rels ) . 'i';
         $this->word_rels[$rid] = array(
           "http://schemas.openxmlformats.org/officeDocument/2006/relationships/image",
           "media/" . $content,

           // Указываем непосредственно путь к файлу
           $content
         );

         $xml = $this->pparse( array(
           '{WIDTH}' => $width * $this->px_emu,
           '{HEIGHT}' => $height * $this->px_emu,
           '{RID}' => $rid,
         ), $block );
       }
       else{

         // Берем шаблон абзаца
         $block = file_get_contents( $this->path . 'p.xml' );

         $xml = $this->pparse( array(
           '{TEXT}' => $content,
         ), $block );
       }

       // Если нам указали, что нужно возвратить XML, возвращаем
       if( $return )
         return $xml;
       else
         $this->content .= $xml;
     }

Кто умеет читать код, заметит, что в методе используется хитрая метрическая система. Называется она English Metric Units (EMU). Почитать об этом можно на английской википедии DrawingML). Кратко: можно получить EMU из px умножением на число. На википедии написано, что в одном point содержится 12700. Сколько содержится EMU в одном пикселе не указано, поэтому это пришлось экспериментально выяснить. Оказалось, если прописать размеры в пикселях, умноженные на 8625, картинка будет отображаться пиксель в пиксель.

Ну и конечно, подключаем непосредственно файл изображения в структуру связей:

         $rid = "rId" . count( $this->word_rels ) . 'i';
         $this->word_rels[$rid] = array(
           "http://schemas.openxmlformats.org/officeDocument/2006/relationships/image",
           "media/" . $content,

           // Указываем непосредственно путь к файлу
           $content
         );

В результате

В результате мы получили полноценную библиотеку. Теперь мы можем использовать её вот так:

// Подключаем класс
include 'PHPDocx_0.9.2.php';

// Создаем и пишем в файл. Деструктор закрывает
$w = new WordDocument( "Пример.docx" );

// Использование метода assign
/******************************
/
/ $w->assign( 'text' );
/ $w->assign( 'image.png' );
/ $xml = $w->assign( 'image.png', true );
/ $w->assign( $w->assign( 'image.png', true ) );
/
/******************************/

$w->assign('image.jpg');
$w->assign('Кто узнал эту женщину - тот настоящий знаток женской
красоты.');

$w->create();

Вот в принципе и всё.
В планах: генерация таблиц.
Ссылки:
PHPDocx на гитхабе.
Страница проекта PHPDocx.
Скачать исходники.

Рассмотрим некоторые части .Net Framework’a, выглядящие тривиальными, но вполне способными сделать ваш код более простым как в написании, так и в сопровождении.

Пишущие на .NET (а если вы этого не делаете, то зря читаете этот пост) наверняка время от времени используют для своих нужд структуру DateTime. Эта структура удобна для хранения дат, времени или даты/времени, относящихся к локальной временной зоне (или же к UTC).

Однако, бывают случаи, когда вам необходимо сохранить время в виде смещения, а не конвертировать его в локальное время. И вот здесь вам на помощь придёт структура, впервые появившаяся в .NET 3.5 — DateTimeOffset.

Проблема: парсинг DateTime может привести к конвертации в локальное время

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

2012-03-01 00:00:00-05:00

Такая запись говорит о том, что человек родился 1 марта 2012 года в неуказанное время (в конце концов, большая часть форм не требует от вас заполнения времени вашего рождения). Но поскольку экземпляр структуры DateTime был сериализован «в лоб», то он и содержит время, установленное в полночь, согласно своей временной зоне.

Итак, зная, что эта дата совместима с Восточной временной зоной (Eastern Time Zone), а мы находимся в Центральной временной зоне (Central Time Zone) мы парсим её так:

 // ясно что здесь выполняется чтение файла/потока/и т.п.
 var dateString = "2012-03-01 00:00:00-05:00";
 // парсим в DateTime
 var birthDay = DateTime.Parse(dateString);

Выглядит идеально, не так ли? Но тут кроется проблемка. Если мы проверим содержимое объекта DateTime на нашей локальной машине, где выставлена Центральная временная зона, то увидим вот что:

2012-02-29 11:00:00 PM

Что случилось? (Или как говорил один персонаж — Кто это сделал?) Да, метод DateTime.Parse() конвертировал дату в локальную временную зону поскольку оригинальная дата рождения хранилась с указанным смещением. Вам просто оказали услугу — конвертировали указанную дату и время в ваши локальные дату и время. Это не так и плохо, если бы речь не шла о дне рождения, которое с 1 марта переместилось на 29 февраля.

Конечно, мы можем созвониться с третьей стороной и попросить перестать включать время в строку с датой или же перестать высылать смещение вместе со временем (в этом случае она перестанет конвертироваться в локальное время, но будет отмечена как DateTimeKind.Unspecified).

Однако бывает, что у нас нет возможности таким образом изменить ситуацию.

Бывают случаи, когда вы хотите считывать дату и время со смещением, но не конвертировать его в локальную временную зону. И вот тут вам пригодится DateTimeOffset.

DateTimeOffset – хранит DateTime и Offset

Так что там про DateTimeOffset? Структура так же проста, как и её имя, DateTimeOffset это дата+время+смещение. Именно поэтому она представляет намного более точную точку во времени, поскольку включает информацию о смещении, по которому были установлены текущие дата и время.

По правде говоря, функциональность DateTime и DateTimeOffset во многом перекрывается, а поскольку у Microsoft есть руководство по выбору того или другого, то я рекомендую ознакомиться с ней в MSDN. Статья называется «Choosing Between DateTime, DateTimeOffset, and TimeZoneInfo».

В целом, вы можете использовать DateTime, если вы «прикреплены» к одной временной зоне или используете только универсальное время в формате UTC. Но если вы хотите использовать даты и время из разных временных зон, а также хотите сохранить информацию о смещении без конвертации в локальное время, то лучше использовать DateTimeOffset.

В структуре DateTimeOffset есть много таких же свойств, как и в структуре DateTime (Day, Month, Year, Hour, Minute, Second, и т.п.), потому здесь их я описывать не стану. Главное отличие состоит в нескольких новых свойствах:

DateTime

Возвращает DateTime без учёта смещения.

LocalDateTime

Возвращает конвертированный DateTime, с учётом смещения (т.е. в локальной временной зоне).

Offset

Возвращает смещение относительно UTC.

UtcDateTime

Возвращает DateTime как время UTC.

Свойство DateTime возвращает вам DateTime (не приведенное к локальной временной зоне), а свойство Offset имеет формат TimeSpan, представляющее смещение от времени UTC. Также есть свойства LocalDateTime и UtcDateTime, конвертирующие данный DateTimeOffset в DateTime для локальной временной зоны или UTC.

Также замечу, что свойства Now и UtcNow структуры DateTimeOffset возвращают не тип DateTime, а DateTimeOffsets с соответствующим смещением от UTC. Конечно, как и DateTime, DateTimeOffset обладает методами, оперирующими с датой/временем, возвращая тип DateTimeOffset вместо DateTime.

Так как нам всё это поможет в выше приведенном примере? Теперь мы знаем, что третья сторона высылает нам дату и время своей временной зоны, которое не нужно конвертировать в локальные дату/время. Поэтому можно использовать DateTimeOffset.Parse() (или TryParse()) и выбрать только дату:

 // ясно что здесь выполняется чтение файла/потока/и т.п.
 var dateString = "2012-03-01 00:00:00-05:00";

 // парсим день рождения как смещение даты/времени (без конвертирования в локальные даты/время)
 var dtOffset = DateTimeOffset.Parse(dateString);
 // теперь если нам надо сравнить результат с другими объектами типа локального DateTime
 // мы просто используем свойство Date для получения даты
 // без времени или смещения
 var theDay = dtOffset.Date;

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

Итоги

Хоть структура DateTime и является достаточно мощной в плане парсинга, манипулирования и сравнения дат/времени, она может доставить немало неприятных минут в работе с датами в формате разных временных зон. DateTimeOffset в этом случае проявляет себя куда более гибкой, поскольку использует смещение от UTC.

(оригинал статьи)

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

• На дворе 2012 год, а этот формат появился аж в 2007-м
• Генерить .docx несомненно проще, чем .doc, поскольку .docx = .zip, а
  .doc - бинарный файл
• Костыль с генерацией HTML и переименованием в doc не подойдет для
  более-менее уважающих себя проектов
• С помощью приведенного ниже метода мы с легкостью сгенерируем Excel, и
  вообще всё что угодно.

Структура файла

Возьмите ваш любой файл .docx и переименуйте
его в .zip, а затем откройте. И вы увидите структуру docx-файла. Да, да!
Это обычный zip-архив. Кратко скажу, что самое интересное для нас лежит в
папке word. Здесь-же в корне находятся общие настройки документа.
Самое же интересное для нас в папке word - файл document.xml, который
представляет из себя файл с содержимым Office Open XML. Именно он содержит
в себе непосредственно содержимое документа. Подробнее об этом формате
можно почитать на английской
Википедии.
В папке _rels находится файл document.xml.rels. Он нам
пригодится в будущем, чтобы описывать связи прикрепленных файлов внутри
документа. Может еще существовать папка media, если в вашем документе
присутствуют изображения. Имена остальных файлов вроде бы говорят за себя.

Учимся генерить .docx

Итак, как мы уже определились, .docx это просто обычный zip-архив, поэтому
решение напрашивается само собой: класс-генератор документов должен быть
наследником класса ZipArchive, который доступен “из коробки”. А остальное
- дело техники. Ниже приведен класс для создания пустого .docx-файла (не
забываем включить zlib и использовать кодировку UTF-8).

class Word extends ZipArchive{

     // Файлы для включения в архив
     private $files;

     // Путь к шаблону
     public $path;

     public function __construct($filename, $template_path = '/template/' ){

       // Путь к шаблону
       $this->path = dirname(__FILE__) . $template_path;

       // Если не получилось открыть файл, то жизнь бессмысленна.
       if ($this->open($filename, ZIPARCHIVE::CREATE) !== TRUE) {
         die("Unable to open <$filename>\n");
       }

       // Структура документа
       $this->files = array(
         "word/_rels/document.xml.rels",
         "word/theme/theme1.xml",
         "word/fontTable.xml",
         "word/settings.xml",
         "word/styles.xml",
         "word/document.xml",
         "word/stylesWithEffects.xml",
         "word/webSettings.xml",
         "_rels/.rels",
         "docProps/app.xml",
         "docProps/core.xml",
         "[Content_Types].xml" );

       // Добавляем каждый файл в цикле
       foreach( $this->files as $f )
         $this->addFile($this->path . $f , $f );
     }

     // Упаковываем архив
     public function create(){

       $this->close();
     }
}

$w = new Word( "Example.docx" );

$w->create();

Возле скрипта должен появиться файл Example.docx При этом не забываем
создать саму структуру файлов. Для её получения пользуемся пресловутым MS
Office и Winrar’ом. После сборки пробуем открыть в через MS Office. В
случае незначительных ошибок в XML, Word выдаст предупреждение, что в
документе содержатся ошибки, но и предложит их исправить. Если же документ
собран совсем неправильно, Word лишь ругнется и откажется открывать.

Вставляем текст

Для получения требуемого XML текста я использовал тот же подход ламера:
печатал текст в Word’е, извлекал внутренности и изучал. Вот какой XML у
меня получился для обычного абзаца:

<w:p w:rsidR="00BB20FC" w:rsidRPr="00357A74" w:rsidRDefault="00357A74"
w:rsidP="00BB20FC">
<w:pPr>
<w:jc w:val="left"/>
<w:rPr>
<w:sz w:val="28"/>
<w:lang w:val="en-US"/>
</w:rPr>
</w:pPr>
<w:r w:rsidRPr="00357A74">
<w:rPr>
<w:sz w:val="28"/>
<w:lang w:val="en-US"/>
</w:rPr>
<w:t>{TEXT}</w:t>
</w:r>
</w:p>

Нетрудно понять, что нужно изменить, чтобы получить требуемое
выравнивание и размер текста. В тег w:t вставляем наш текст, но без
переноса строк!
Вводим в наш класс метод assign, и генератор становится таким:

class Word extends ZipArchive{

     // Файлы для включения в архив
     private $files;

     // Путь к шаблону
     public $path;

     // Содержимое документа
     protected $content;

     public function __construct($filename, $template_path = '/template/' ){

       // Путь к шаблону
       $this->path = dirname(__FILE__) . $template_path;

       // Если не получилось открыть файл, то жизнь бессмысленна.
       if ($this->open($filename, ZIPARCHIVE::CREATE) !== TRUE) {
         die("Unable to open <$filename>\n");
       }

       // Структура документа
       $this->files = array(
         "word/_rels/document.xml.rels",
         "word/theme/theme1.xml",
         "word/fontTable.xml",
         "word/settings.xml",
         "word/styles.xml",
         "word/stylesWithEffects.xml",
         "word/webSettings.xml",
         "_rels/.rels",
         "docProps/app.xml",
         "docProps/core.xml",
         "[Content_Types].xml" );

       // Добавляем каждый файл в цикле
       foreach( $this->files as $f )
         $this->addFile($this->path . $f , $f );
     }

     // Регистрируем текст
     public function assign( $text = '' ){

       // Берем шаблон абзаца
       $p = file_get_contents( $this->path . 'p.xml' );

       // Нам нужно разбить текст по строкам
       $text_array = explode( "\n", $text );

       foreach( $text_array as $str )
         $this->content .= str_replace( '{TEXT}', $str, $p );
     }

     // Упаковываем архив
     public function create(){

       // Добавляем содержимое
       $this->addFromString("word/document.xml", str_replace( '{CONTENT}',
$this->content, file_get_contents( $this->path . "word/document.xml" ) ) );

       $this->close();
     }
}

$w = new Word( "Пример.docx" );

$w->assign('Пример текста.
Будущее не предопределено.');

$w->create();

Разбивку текста на строки я сделал для того, чтобы выделить в тексте
абзацы, предполагая, что в получаемом тексте перенос строки обозначает
новый абзац.
Вы, конечно же, вольны допилить код под Ваши нужды.
Вот в принципе и всё. В следующий раз мы научимся вставлять изображения.
Просто, не правда ли?

Весь код
с примером.

Домашняя страница библиотеки: webli.ru/phpdocx/

Лжец (The Liar)

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

Чрезмерная Инициализация (Excessive Setup)

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

Гигант (Giant)

Unit-тест, который хотя и тестирует приложение правильно, но растекается при этом на тысячи строк кода и содержит слишком много кейсов. Это может служить признаком того, что тестируемая система представляет из себя антипаттерн Всемогущий Объект (God Object).

Подделка (The Mockery)

Mocking можеть быть очень удобным и правильным. Но случается, что разработчики теряют чувство меры и используют его даже для тех частей системы, которые в принципе должны участвовать в тестировании. В этом случае unit-тест содержит так много mocks, заглушек (stubs) и фейков (fakes), что часть системы остается непротестированной.

Инспектор (The Inspector)

Unit-тест, который нарушает инкапсуляцию в попытке достичь 100% покрытия кода (code coverage) и при этом знает слишком много о тестируемой системе. При рефакторинге системы такой тест слишком часто ломается и требует исправлений.

Щедрые Остатки (Generous Leftovers)

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

Местный Герой (The Local Hero)

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

Крохобор (The Nitpicker)

Unit-тест, который проверяет весь результат работы, в то время как на самом деле важна только его малая часть. В результате приходится часто обновлять тест, чтобы отражать изменения в незначительных вещах. Типичен при тестировании веб-приложений.

Тайный Ловец (The Secret Catcher)

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

Уклонист (The Dodger)

Unit-тест, который тестирует множество второстепенных (и, как правило, простых) мелочей, но не тестирует основное поведение.

Крикун (The Loudmouth)

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

Жадный Ловец (The Greedy Catcher)

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

Любитель Порядка (The Sequencer)

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

Скрытая Зависимость (Hidden Dependency)

Близкий родственник Местного Героя. Это unit-тест, который требует, чтобы перед запуском были заполнены какие-то данные. Если эти данные отсутствуют, то тест падает, оставляя мало информации о причине проблемы и заставляя разработчика копаться в груде кода для того, чтобы определить какие данные и откуда должны были появиться.

Счётчик (The Enumerator)

Unit-тест, в котором все кейсы имеют плохие названия (например, test1, test2, test3). В результате назначение тест-кейса неясно и единственный способ понять, что сломалось — лезть в код теста и молиться, чтобы он оказался понятным.

Чужак (The Stranger)

Кейс, который не относится к unit-тесту, в котором он расположен. Он на самом деле тестирует совершенно другой объект, чаще всего объект, который используется основным тестируемым объектом. Также известен как Дальний Родственник.

Приверженец ОС (The Operating System Evangelist)

Unit-тест, который полагается на особенности определённой операционной системы. Хорошим примером будет тест, который ожидает перевода строки, принятого в Windows и ломающийся, когда выполняется под Linux.

Успех Любой Ценой (Success Against All Odds)

Тест, который был написан для того, чтобы пройти успешно, а не для того, чтобы сначала провалиться (принцип fail first). Побочным эффектом является недостаточно глубокое тестирование и успешное прохождение там, где правильный тест должен упасть.

«Заяц» (The Free Ride)

Вместо того, чтобы написать новый кейс-метод, просто добавляется новый assert к существующему кейсу.

Избранный (The One)

Комбинация нескольких анти-паттернов, в особенности «Зайца» и Гиганта. Такой unit-тест состоит из единственного метода, который тестирует всю функциональность объета. Типичным индикатором проблемы являтся название тестового метода по названию unit-теста и большое количество строк инициализации и assert-ов.

Подглядыватель (The Peeping Tom)

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

Тормоз (The Slow Poke)

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

Что такое литерал?

Литерал — это некоторое выражение, создающее объект.
Литералы появились не только в C++11, они были и в C++03. Например, есть литералы для создания символа, строки, вещественных чисел, и т.д.

'x';      // character
"some";   // c-style string
7.2f;     // float
74u;      // unsigned int
74l;      // long
0xF8;     // hexadecimal number

Все это литералы.
С понятием литералов, думаю, мы разобрались. Самое время вернуться к C++11.

Пользовательские литералы в C++11

Как уже было отмечено выше, новый стандарт предлагает средства для создания пользовательских литералов. Существует две категории пользовательских литералов: сырые литералы (raw) и литералы для встроенных типов (cooked).

Стоит, однако, заметить, что C++ позволяет создавать только литералы-суфиксы. Иными словами, создать литералы-префиксы (как, например, 0x), или префиксо-суфиксные (как “”) не получится.

Литералы для численных типов

Начнем с литералов для встроенных типов. Чтобы создать литерал для численных типов необходимо воспользоваться одной из двух сигнатур:

    // сигнатура литерала для целочисленных типов
    OutputType operator "" _suffix(unsigned long long);

    // сигнатура литерала для вещественных типов
    OutputType operator "" _suffix(long double);

Использование литерала будет осуществляется следующим образом:

    42_suffix;      // OutputType operator "" _suffix(unsigned long long);
    42.24_suffix;   // OutputType operator "" _suffix(long double);

Обратите внимание на сигнатуры:

• литерал для целых чисел в качестве аргумента принимает unsigned long long
• литерал для вещественных чисел в качестве аргумента принимает long double

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

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

    unsigned long long operator "" _min(unsigned long long minutes)
    {
        return minutes * 60;
    }

    // ...

    std::cout << 5_min << std::endl; // на экран выведится 300

Литералы для строковых типов

Для создания литерала этого типа, необходимо воспользоваться одной из следующих сигнатур:

    OutputType operator "" _suffix(const char* str, size_t size);
    OutputType operator "" _suffix(const wchar_t* str, size_t size);
    OutputType operator "" _suffix(const char16_t* str, size_t size);
    OutputType operator "" _suffix(const char32_t* str, size_t size);

Сигнатура выбирается в зависимости от типа строки:

    "1234"_suffix;   // operator "" _suffix(const char* str, size_t size);
    u8"1234"_suffix; // operator "" _suffix(const char* str, size_t size);
    L"1234"_suffix;  // operator "" _suffix(const wchar_t* str, size_t size);
    u"1234"_suffix;  // operator "" _suffix(const char16_t* str, size_t size);
    U"1234"_suffix;  // operator "" _suffix(const char32_t* str, size_t size);

Пример литерала преобразующего C-style строку в std::string приведен ниже.

    std::string operator "" s(const char* str, size_t size)
    {
        return std::string(str, size);
    }

    // ...

    std::cout << "some string"s.length() << std::endl;

Сырые литералы

Ну и наконец настало время сырого литерала. Сигнатура сырого литерала выглядит следующим образом:

    OutputType operator "" _suffix(const char* literalString);

Этот тип литералов приходит на помощь тогда, когда входное число надо разобрать посимвольно. Т.e. в этом случае число передается в оператор как строка. Если не совсем понятно, взгляните на приведенный ниже код:

    OutputType operator "" _x(unsigned long long);
    OutputType operator "" _y(const char*);

    1234_x;     // call: operator "" _x(1234);
    1234_y;     // call: operator "" _y("1234");

Используя данный тип литералов, можно написать литерал преобразующий двоичное число в десятичное. Например, вот так:

    unsigned long long operator "" _b(const char* str)
    {
        unsigned long long result = 0;
        size_t size = strlen(str);

        for (size_t i = 0; i < size; ++i)
        {
            assert(str[i] == '1' || str[i] == '0');
            result |= (str[i] - '0') << (size - i - 1);
        }

        return result;
    }

    // ...

    std::cout << 101100_b << std::endl; // выведет 44

Существует еще одна сигнатура для сырых литералов. Основана она на применении Variadic Template:

    template <char...>
        OutputType operator "" _b();

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

    template <char... bits>
        struct to_binary;

    template <char high_bit, char... bits>
        struct to_binary<high_bit, bits...>
        {
            static_assert(high_bit == '0' || high_bit == '1', "Not a binary value!");
            static const unsigned long long value =
                (high_bit - '0') << (sizeof...(bits)) | to_binary<bits...>::value;
        };

    template <char high_bit>
        struct to_binary<high_bit>
        {
            static_assert(high_bit == '0' || high_bit == '1', "Not a binary value!");
            static const unsigned long long value = (high_bit - '0');
        };

    template <char... bits>
        constexpr unsigned long long operator "" _b()
        {
            return to_binary<bits...>::value;
        }

    // ...

    int arr[1010_b]; // значение вычисляется во время компиляции
    std::cout << 101100_b << std::endl; // выведет 44

У внимательного читателя мог возникнуть вопрос: «А что если создать и сырой литерал, и литерал для числа с одним и тем же именем? Какой литерал компилятор применит?». Стандарт по этому поводу дает точный ответ и говорит о попытке компилятора применить литералы в следующем порядке:

• operator "" _x (unsigned long long) или operator "" _x (long double)`
• operator "" _x (const char* raw)
• operator "" _x <'c1', 'c2', ... 'cn'>

Полезно знать, что если определенный пользователем литерал совпадает с системным (например f), то выполнится системный.

    long operator "" f(long double value)
    {
        return long(value);
    }
    // ...
    std::cout << 42.7f << std::endl; // выведет 42.7

Выводы

Бьёрн Страуструп на конференции Going Native 2012 приводил полезный пример использования литералов. Мне кажется, он наглядно демонстрирует факт повышения читаемости кода, а также снижает вероятность ошибиться.

    Speed sp1 = 100m / 9.8s;    // very fast for a human
    Speed sp2 = 100m / 9.8s2;   // error (m/s2 is acceleration)
    Speed sp3 =  100 / 9.8s;    // error (speed is m/s and 100 has no unit)

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

• как повысить читаемость кода, так и понизить;
• как сыграть вам на руку, так и против вас.

p.s:
Пользовательские литералы поддерживаются компиляторами gcc 4.7 и clang 3.1.

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

Участники

Я буду тестировать четыре библиотеки: ZLibNet, #ZipLib, DotNetZip и ZipStorer. Теперь о каждой поподробней:

ZLibNet

Лицензия: Свободная
Размер: 35 кБ + 137 кБ(ZLib)
Эта библиотека представляет собой обёртку над широко известной сишной библиотекой ZLib. Так как большую часть составляет unmanaged код, то авторы обещают высокую производительность.
Пример кода для архивирования:

  Zipper zip = new Zipper();
  zip.ItemList.Add(inPath);
  zip.ZipFile = outPath;
  zip.PathInZip = enPathInZip.None;
  zip.Zip();

#ZipLib

Лицензия: Модифицированный GPL. Можно использовать в коммерческих проектах
Размер: 196 кБ
Библиотека полностью написана на C#. Заявлена поддержка так же GZip, Tar, BZip2 форматов.
Пример кода для архивирования:

  using (ZipOutputStream s = new ZipOutputStream(File.Create(outPath)))
  {
    s.UseZip64 = UseZip64.Off;
    if (level != -1)
      s.SetLevel(level);

    byte[] buffer = new byte[4096];
    ZipEntry entry = new ZipEntry(Path.GetFileName(inPath));
    s.PutNextEntry(entry);
    using (FileStream fs = File.OpenRead(inPath))
    {
      int sourceBytes;
      do
      {
        sourceBytes = fs.Read(buffer, 0, buffer.Length);
        s.Write(buffer, 0, sourceBytes);
      }
      while (sourceBytes > 0);
    }
    s.Finish();
    s.Close();
  }

  using (ZipFile zip = new ZipFile())
  {
    zip.CompressionLevel = compressionLevel;
    ZipEntry ze = zip.AddFile(inPath, “”);
    zip.Save(outPath);
  }

Лицензия: Ms-Pl
Размер: 33 кБ(исходник)
Строго говоря является не библиотекой, а отдельным классом, в следствии чего крайне просто интегрируется в проект, да и изменения в случае чего произвести будет несложно. Возможности крайне ограничены, но учитывая размер, на это можно закрыть глаза. Старая версия может работать в Silverlight.
Вот вкратце и всё, что можно сказать об испытуемых.
Пример кода для архивирования:

  ZipStorer zip = ZipStorer.Create(outPath, “About”);
  zip.AddFile(compressionLevel, inPath, inputFileName, “”);
  // Updates and closes the zip file
  zip.Close();

Тестирование

Тестирование будет проводиться следующим образом: делается 100 прогонов каждого метода, измеряется время, убираются 20 худших и 20 лучших времён, по остальным рассчитывается среднее. Платформа: основные тесты проводились на процессоре E8400(3.0GHz) с четырьмя гигабайтами DDRII памяти. Все четыре библиотеки тестируются в одной программе, которая логирует все свои действия и отписывает результаты в csv файл, который потом можно легко открыть в редакторе таблиц. IDE — VS2010. Использовался .net 4.0.

Архивирование

Тесты будут проводиться на 3х файлах: первый — большой текстовый файл, второй — база данных SQLite, и третий — книга «История государства Российского» Карамзина в формате pdf.
Для каждого файла проводятся два теста на первом будут тестироваться все библиотеки с настройками обеспечивающими максимальное быстродействие, на втором будет включено максимальное сжатие, к сожалению функцию уровня сжатия поддерживают только #ZipLib и DotNetZip, поэтому во втором этапе будут участвовать только они.

TXT файл.

Это текстовый файл размером в 9 373 180 байт. Документ по структуре — логи переписки по аське из квипа.

Итак, результаты с максимальной скоростью:



Итак, по скорости #ZipLib и zlibnet одинаковы, однако, вторая библиотека показывает куда лучший результат. Остальные библиотеки показывают серьёзное отставание по скорости. Теперь результаты теста на максимальное сжатие:



Тут результаты более ровные.

DB файл.

База данных, размером 19 407 754 байт. Содержимое базы — большое количество строк.



Тут результаты более ровные.

Ситуация идентична текстовому файлу, теперь результаты теста на максимальное сжатие:



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

PDF файл.

ПДФка с отсканированными страницами, размером 19 407 754 байт. Можно ожидать, что сжатие особого толка не даст, однако, давайте это проверим:



Разрывы по размеру оказались несущественны, однако же скорость отличается очень значительно. На этот раз в лидерах ZipStorer, что объяснимо — у него худшее сжатие. DotNetZip и #ZipLib показывают практически одинаковые результаты. Теперь результаты теста на максимальное сжатие:



Ситуация изменилась несильно, разве что, несколько увеличилась разница по времени.
Стоит отметить что изначально название файла содержало кириллицу и только ZipStorer достойно справилась с ним(для этого нужно было добавить строчку: zip.EncodeUTF8 = true), ZlibNet вообще отказалась с ним работать(выбрасывало исключение в котором говорилось что поддерживаются только ASCII символы в названии), а #ZipLib и DotNetZip упаковали странно: стандартный windows просмотрщик показывал пустой архив. Распаковка дала исходный файл, но в названии все кириллические символы были заменены.

Разархивирование.

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

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



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

Сравнение процессоров.

Теперь запущу тест на архивацию тестового файла ещё на двух компьютерах. Первый — годовалый чертырёхядерный i7-870(2.93GHz) 16Gb, и второй — трёхлетний ноутбук Dell 1525 T2370(1.73GHz) 2Gb.
Архивирование базы данных:



Результаты удивляют. Значительный прирост показала только DotNetZip. ZlibNet и ZipStorer показали двухкратный рост производительности при переходе от ноутбука к двухядерному процессору, но вот уже 4х ядерник особого прироста не дал, т.е. можно сделать вывод что они зависят скорее от частоты, чем от количества ядер. Но наиболее поразительным является результат #ZipLib — на i7-870 сжатие занимает больше времени чем на старом ноутбучном процессоре. Объяснить подобную разницу я затрудняюсь.
А вот результаты распаковки архива:



Тут ситуация тоже необычная: и #ZipLib и DotNetZip на i7-870 работают медленней, чем на E8400.
Напоследок, приведу скриншоты диспетчера задач во время работы приложения:



Тут красным выделен период работы ZLibNet, синим — #ZipLib, жёлтым — DotNetZip, и фиолетовым — ZipStorer. Хорошо заметно, что DotNetZip грузит оба ядра на полную катушку. Что и подтверждает результаты теста на сравние.

Итоги.

Тесты получились неоднозначными. У каждой из библиотек имеется свои плюсы и минусы. Лично для себя я выбрал DotNetZip, мне понравился её простой интерфейс и предсказуемый рост производительности относительно мощи процессора.
Исходный код можно посмотреть тут.