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

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

Так давайте же начнем с самого контракта.

Фиксированная цена, время и объем обязательств

Такие контракты фиксируют сразу три магических фактора — деньги, время и объем обязательств. Являются ли цена и сроки проблемой для agile команд? Ну, не должны быть. На самом деле, таймбоксинг (timeboxing) — это обычная практика. Ограничение бюджета только помогает таймбоксингу лучше работать.

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

Я встречал в сети много tutorial'ов по установке своего сервера git как на gitweb, так и на webdav, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной :)

Однажды на просторах Хабра встретил плагин FormNavigate (требующий у пользователя подтверждения на закрытие вкладки или переход по ссылке, когда данные в форме заполнены, а-ля gmail), а однажды потребовалось его даже применить.

Но тот вид в котором плагин был меня не устроил и я позволил себе немного его переписать.

Так, например, мне неудобно было выбирать те ссылки, на которых следует отлавливать подтверждения, а наоборот требовалось указывать ссылки на которые действие плагина не будет распространяться. Тут продвинутые разработчики начнут меня закидывать помидорами, что я не знаю правильную работу селекторов в jQuery. Но это не так, сами можете проверить как работает прошлая версия плагина, например, для: $('a:not([class~="ajax"])') (предложенный автором прошлого топика $('a:[class!="ajax"]') вообще вытворяла чудеса).

Небольшой отчет o конференции AgileDays Екатеринбург ‘2010, я уже публиковал. Теперь ScrumTrek выложили слайды презентаций и видео докладов.

Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

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

Вчера в топике «Модификация изображений для сайта, или какие бывают превьюшки» в комментариях diGreez предложил, как мне показалось, очень интересный способ организации превьюшек изображений. Реализовал на PHP функцию, которая занимается созданием таких превьюшек.
Функция документирована комментариями.

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

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html. Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. :)

1. Постановка задачи

Дано
Debian-сервер «из коробки» (установлен из дистрибутива)

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

• Ограничить возможность обзора файловой системы определенной папкой для пользователя проекта.
• Ограничить возможность запуска бинарников пользователями
• Ограничить возможность открытия портов на сервере (нужно как-то по другому сформулировать)
• Автоматизировать добавление пользователя в систему: создание папки, конфига apache, пользователей mysql или postgres

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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

Скажу сразу: слово «инцидент» взято в кавычки, т.к. на самом деле никакого инцидента не было. Это была «стабильная» работа форточек...

После прочтения топика «Учим ПК разговаривать», я сразу-же попробовал festival.
И был приятно удивлен!
Голос достаточно ровный, иногда только нужно подредактировать слова с двумя основами — фестиваль ставил в них одно ударение, а нужно два — просто написать слово через дефиз.
Еще если слова не оказывается в словаре, фестиваль может поставить ударение не там — тогда нужно явно указывать его с помощью знака плюс (+) перед ударной гласной.

Поигравшись, за несколько недель у меня накопилось несколько разных интересных скриптов. Я настроил через cron разговор с 8 до 10 вечера каждый час в 00 минут — общую информацию:
1) Дату, время
2) Температуру на процессоре/винчестере
3) Заряд батареи (в процентах и даже остаток (не спрашивайте зачем) в миллиамперах)
4) Проверка почты
5) Температуру на улице (актуальную)

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

Здравствуйте, многоуважаемые хабрачеловеки!

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



(Флеш-приложение 1. Интровертный мир одного из наших сотрудников. Можно кликнуть и поиграть, а потом продолжить чтение. Можно и наоборот — сначала прочитать, а потом поиграть.)

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

Мы в достаточной степени успешны. Однако на первое место мы всегда ставим не работу с клиентом даже, а внимание к сотруднику. Можно потерять клиента, но потерять сотрудника, пусть самого незначительного, человека, который работает с настойчивостью гика, нельзя, никак нельзя. Скажем так: если вдруг клиент попросит нас расстаться с сотрудником, который ему не нравится (а такие прецеденты были), мы предпочтём расстаться с клиентом, сколь много бы он ни башлял.

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

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

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Пространное и многословное вступление

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

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

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

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

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации