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

Все бы хорошо, да вот на одном файле ffmpeg подвисал и не думал завершаться, а в момент завершения отваливался и php скрипт без видимых на то причин.

После долгих поисков решения данной проблемы, был найден код, который после небольшой переделки я готов представить на ваш суд :)

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

Как вы, наверное, замечали, прототипы могут быть представлены в разнообразных формах: от каких-то набросков на салфетке, до дизайна созданного в профессиональном пакете, который выглядит очень близко к желаемому результату. Несмотря на такое количество вариантов, мы можем выделить два основных типа прототипов: малодостоверные (Low fidelity) и высокодостоверные (High fidelity ). Малодостоверный прототип – это простое описание, набросок на рисовальной доске или скетч, которые приблизительно показывают кусочек пользовательского интерфейса. Пример такого прототипа представлен на рис. 1.


Рис. 1 – Пример малодостоверного прототипа, который демонстрирует форму входа в систему

В жизни каждого системного администратора рано или поздно наступает момент, когда глаз и рук уже не хватает уследить за всеми серверами, то там, то там возникают какие-то проблемы, а для решения их очень хочется узнать что же было «до этого». И именно здесь на выручку приходят они — вел
икие и ужасные системы мониторинга. Долгое время я пользовался Nagios, и до сих пор, при всём удобстве, иначе как монстрообразным назвать не могу. В итоге реально использовались лишь 10% возможностей этой прекрасной системы. Всё изменилось, когда я наткнулся на Munin — прекрасное решение для мониторинга небольших сетей.

На написание меня сподвигли пара топиков про теории мотивации X и Y.

В качестве предисловия

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

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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

Предположим у Вас есть сайт. Предположим вы его оптимизировали по самое «немогу», но всеравно хочеться больше.
Лично мне хотелось, но долгое время не получалось.
Когда я победил тормознутость базы кэшированием запросов, тормознутость блоков — кэшированием блоков, а целые страницы кэшировать я не мог…
Cайт конечно стал работать много быстрее, но начал тормозить уже… мемкэшед?

Знакомый HR попросил оценить вакансию «специалист по Интернет-технологиям» их конкурента.
Когда я начал вчитываться в текст данной вакансии волосы поднимались дыбом.

Должность: специалист по интернет-технологиям
Заработная плата: 35000 руб.
Компания: *******

Образование: высшее техническое, либо высшее — маркетинг
Видно, что специалист по HR не до конца понимает, какой именно сотрудник нужен.
У технаря один склад ума, а у маркетолога совсем другой, навыки тоже совершенно разные.

Я часто общаюсь с людьми на тему гибких методов разработки ПО, иногда пишу статьи про это (например, недавняя статья на хабре про Канбан в IT).
И я могу сказать, что основной аргумент, который люди приводят против этих методов, который останавливает многих даже от мыслей про Канбан, Scrum или XP — это якобы низкий уровень контроля за разработкой у этих методологий.
При этом некоторые воспринимают, как непрофессионализм, доводы о том, что уровень контроля не сильно-то зависит от методологии, да и вообще контроль в сфере разработки ПО — это по большому счету фикция.

Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

Продуктивность коллектива веб-студии напрямую зависит от удобства среды разработки. У нас сложилась стройная система организации работы с проектами, включающая в себя набор таких неотъемлемых компонентов, как IDE, SCM, PM-система, багтрекер и development-сервер. Этим постом я бы хотел начать цикл статей, посвященных настройке и использованию этих компонентов в нашей студии.

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

Идеи

1. Среда разработки должна быть единой для всех сайтов.
2. Девелоперы не должны тратить время на настройку каждый своей серверной части.
3. Работает ли над проектом один человек или несколько — контроль версий необходим.
4. Если рабочий каталог (IDE workspace) находится на сервере, то можно поработать и дома, не тратя время на повторную настройку окружения на домашнем десктопе или ноуте.

Болтаясь сегодня по интернету в поисках чего-нибудь интересненького, наткнулся на вот такой простой (и столь же замечательный в своей простоте) способ отыскать «неполадку» в верстке.

CSS

* { outline: 2px dotted red; }
* * { outline: 2px dotted green; }
* * * { outline: 2px dotted orange; }
* * * * { outline: 2px dotted blue; }
* * * * * { outline: 1px solid red; }
* * * * * * { outline: 1px solid green; }
* * * * * * * { outline: 1px solid orange; }
* * * * * * * * { outline: 1px solid blue; }


Цвет, тип и размер обводки каждый может выбрать по вкусу.

Поддержка браузерами:

К сожалению, в браузерах от Microsoft версий 6 и 7 (в 8-й — все окей) свойство outline не поддерживается. Для них, пожалуй, придется использовать border.