К примеру, хочется иметь в объекте модели поле, дата которого будет задаваться при сохранении объекта.

Казалось бы, вот такой код будет логичным:

class MyModel(models.Model):
    time = models.DateTimeField(default = datetime.now())

Однако,  в приведенном выше примере - все создаваемые объекты будут иметь дату создания в памяти класса MyModel.

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

class MyModel(models.Model):
     time = models.DateTimeField(default = datetime.now)

upd:
Как подсказывает товарищ overplumbum, можно добавить в конструктор models.DateTimeField() auto_now=True - http://ff.im/bQyQO

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

Для решения этой задачи наиболее адекватным инструментом мне показался CURL. За двадцать минут я написал 70 строк кода на питоне, и отправил сканер гулять по серверам. Информация начала литься в индекс, но счастья не случилось.  Сканер начал намертво зависать после нескольких минут работы.

Ошибка оказалась дурацкой и слегка неожиданной. В цикле обхода я для каждого запроса создавал новый объект PyCURL, и потом чистил его. Конечно,  это все накладные расходы, но в моей задаче мне на них был наплевать. Но не тут то было.  После создания многих экземпляров, при их чистке CURL вешает процесс.

Решение простое - создает один объект PyCURL, и работаем только с ним, через pycurl.setopt меняя параметры и много раз вызывая метод perform().

Пусть у нас есть несколько условий, которые могут выполнятся одновременно. И есть несколько ветвей алгоритма, которые нужно выполнить в зависимости от результатов проверок.

Для примера рассмотрим такую задачу. Мы разрабатываем веб-приложение с графическим интерфейсом, в котором можно рисовать прямоугольники. Размер прямоугольника можно менять “потянув” за край или угол. Нужно, в зависимости от положения мыши относительно прямоугольника, изменить курсор мыши так, чтобы пользователю было понятно, как можно изменить размер прямоугольника.

Читать запись полностью »

За последние несколько месяцев поток порно-спама перешел все мыслимые и не мыслимые границы. Akismet с ним не плохо справляется, но количество комментариев так велико, что мне уже лень очищать от них очередь спама.

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

Сделал небольшое дополнение для firefox, которое форматирует rss + дополнительные поля из jira в виде небольших карточек, удобных для печати.

Буду рад предложениям и замечаниям.

Задачка про базы данных, старая и не моя.

Имеется таблица, один из столбцов которой - уникальный целочисленный идентификатор. Каждый новый идентификатор получается инкрементом предыдущего значения (проще говоря - auto_increment в MySQL).

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

Небольшая иллюстрация:

| id | ...
| 1 | ...
| 2 | ...
| 3 | ...
| 5 | ...
| 7 | ...

Вчера потратил изрядно времени на восстановление работоспособности тестов, после перехода на новую версию PHPUnit - фреймворка для написания unit-тестов на php.

Изменение, которое попортило немало крови - смена интерфейса у мок-объектов, которые генерируются классом PHPUnit_Framework_MockObject_Mock. Если раньше им можно было пользоваться для генерации моков (например во вспомогагательных классах, для упрощения создания однотипных мок-объектов), то теперь наиболее корректным способом видится использование метода getMock() у TestCase. Разработчики изменили имя метода, проверяющего корректность мока с verify() на __phpunit_verify() (видимо verify() популярное название, и может пересекаться с методом тестируемого класса), тем самым поставив ручную проверку мока вне закона.

Другое изменение, доставившое много хлопот, связанно с backup / restore глобальных переменных между тестами. Разработчики PHPUnit внесли правки, чтобы обойти баг php, связанный с десериализацией объектов. К сожалению, новый код не рассматривает возможность, что суперглобальные массивы могут содержать скалярные величины. Конечно, в реальности такого быть не должно, но в нескольких тестах, проверяющих работу с POST и GET тестовые значения были скалярными.

Недавно начал читать SICP (Structure and Interpretation of Computer Programs) в русском переводе. Надо сказать весьма приятная книга, заставляет шевелиться мозги, что уже само по себе полезно. Найти pdf с русским переводом sicp можно здесь, а в блоге Сергея Хенкина - обсуждение решений задач из книги и множество полезных сопутсвующих материалов.

Первые главы навели меня на мысли о простой задачке на собеседовании:

В чем разница между:

// выполняем логическую операцию
function mOr($a, $b) {
    return $a || $b;
}

mOr([Операнд1], [Операнд2])

и

// и тут тоже выполняем логическую операцию
[Операнд1] || [Операнд2];

UPD: немного поправил условие задачи

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

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

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

У меня же появилась такая мысль: а почему в строке вызова дампера не указать фильтр в виде ["ИмяКласса", "ИмяМетода"]. В этом случае дампер вида vardump($myData, “MyClass”, “myMethod”) сработает только в случае, если в стеке вызовов присутствовал вызов метода myMethod класса MyClass.

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

Практически в каждой системе управления проектными задачами есть возможность задавать задаче компонент системы к которой она относится (во всяком случае в jira и trac точно есть :)). Недавно столкнулся с вопросом: а как правильно выбрать набор таких компонентов?

Решение, которое я сейчас использую может показаться очевидным и не оригинальным - в качестве компонентов выделяются большие куски функциональности, связанные по смыслу. Хорошим примером подобного разделения является устройство jira в Zend Framework. Как видно по ссылке - в ZF более 70 компонентов! И такое разделение на компоненты действительно удобно.

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

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

И наконец, компонентов можно сделать много! Если группа разработчиков большая, или количество задач очень велико - чем меньше “кучки”, в которые можно объединить все открытые задачи, тем проще этими задачами управлять. Представим, что у вас 300 открытых багов - если разбить систему на 20 компонентов - задач в каждом будет около 15 - их очень легко расставить по приоритетам и включать в итерацию разработки единым блоком.

Code coverage report - инструмент для изучения покрытия кода тестами, предоставляемый фреймворком phpUnit 3.x. phpUnit умеет предоставлять отчет в множестве форматов, таких как xml, html, и даже складывать полученные данные в БД. Таким образом эту информацию можно обрабатывать собственными силами или передавать в различные средства визуализации для построения графиков.

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

Однако, в моем случае использование code coverage report омрачилось тем, что в процесс генерации отчета постоянно прерывался ошибкой превышения допустимой памяти. Использование свежей версии 3.3, накатывание патчей, оптимизирующих работу phpUnit с памятью проблему не решили. После трассировки с выводом memory_usage проблему удалось локализовать: при построении отчета по конкретному файлу, phpUnit генерирует html-код прямо в памяти, после чего записывает весь файл целиком, а в проекте, отчет для которого я хотел построить, оказалось несколько файлов с 5-10 тысячами строк (конфигурация, константы и пр.).

Читать запись полностью »

В пятницу утром мой хороший знакомый прислал мне ссылку на занимательную статью The only 3 Milestones you will ever need, в которой изложена достаточно простая и, в тоже время, очень полезная идея об организации версий при agile-разработке.
«Разделите все задачи на 3 кучи:

1. Задачи, которые нужно выполнить к текущему релизу
2. Задачи, которые можно отложить до следующего релиза
3. Задачи, про которые не известно, когда их следует выполнять»

В проекте, над которым я сейчас работаю, принята именно такая организация задач в JIRA. Похожим образом устроена разработка Zend Framework.
Пока команда была небольшой острой необходимости в строгом соблюдении версий не было — задачи закрывались и объединялись в релизы постфактум. Однако последняя неделя стала для меня в этом вопросе переломной. Группа качества, занимающаяся проектом, удвоилась и просто затопила разработчиков сообщениями об ошибках. Число задач на моем JIRA dashboard перевалило за 50, и не было решительно никакой возможности понять, что же нужно сделать к надвигающемуся релизу. Статья о 3х вехах пришлась как нельзя кстати. Я разбросал задачи по версиям и реорганизовал свой рабочий стол.

Читать запись полностью »

Общаясь с разными разработчиками, я не однократно встречал абсолютно противоположные отзывы о использовании таких возможностей современных СУБД, как триггеры и хранимые процедуры. Одни отзывались о хранимых процедурах как о «серебряной пуле» при работе с базой данных, другие же, напротив, резко критиковали их.
Пообщавшись с людьми, высказывающими разные точки зрения, я постарался собрать все «за» и «против». Вот что у меня получилось:

Читать запись полностью »

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

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

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

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

Читать запись полностью »

Одной из типовых проблем при разработке приложений на php является отладка. Существует не мало отладчиков, в том числе неплохо интегрирующихся с IDE (к примеру Zend Debug). Работая в разных компаниях, делая freelance-проекты я несколько раз пытался ими воспользоваться, и каждый раз возвращался к знакомому каждому php-разработчику способу отладки - выводу отладочной информации прямо из скрипта.

Читать запись полностью »

Хоть я и не любитель всевозможных тестов и прочих сомнительных “мерилок”, все же и я заразился, охватившей ru_php эпидемии от mamba.ru, и вот результат: 364 бала

Тест, как заметили многие участники тестирования, сильно перегружен вопросами по unix, так что скорее это тест на php-разработчика юниксоида. В целом же вопросы составлены профессионально, с минимальным количеством разночтений и все подразумевают единственный верный набор “галочек”.

1. Возьмем две точки - время и место встречи (A0), и точку, ближайшую к месту назначения (A1) и определим время на преодоления расстояния между ними.
2. Вычтем из времени встречи найденный временной промежуток
   
3. Повторим шаги 1 и 2 для точки (A1) и следующей ближайшей к ней точки
   

1. Простота использования 1c-программистом
2. Возможность использования массивов структур для повышения скорости обмена за счет отправки пакетов с группами объектов
   
3. (Не особо важно, т.к использовалось мной только для тестов) Корректная работа сервиса с .NET-клиентами