В конце марта 2010 г. в Санкт-Петербурге пройдет первая в России конференция по Zend Framework.

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

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

Каждый предстоящий доклад возможно обсудить на форуме ZF-сообщества. Ваше мнение очень важно для авторов!

Планируемые доклады

Жизненный цикл предложений (proposals) в проекте Zend Framework
Александр Веремьев (Zend Technologies, Zend Framework Core команда)

Zend_Search_Lucene в деталях
Александр Веремьев (Zend Technologies, Zend Framework Core команда)

Zend Framework и производительность
Александр Махомет (создатель сообщества ZendFramework.ru)

Zend Framework и MVC, «толстая» модель
Александр Стешенко (Norada Corporation, PHP-разработчик)

ФотоСтрана.ru: Прототипирование с использованием ZF (история боевого применения Zend Framework в highload-проекте)
Леонид Жаворонков (ФотоСтрана.ru, тимлид)

Использование очередей сообщений в повседневных проектах
Денис Баклыков (Обновление, веб-разработчик)

Zend Framework и Doctrine
Степан Танасийчук (руководитель веб-студии stfalcon.com)

Zend Framework и мультиязычность
Степан Танасийчук (руководитель веб-студии stfalcon.com)

История проекта e-Штаб
Анатолий Ларин (e-Легион, веб-программист)

Что нового несет нам Zend Framework 2.0?
Надежда Блинова (Wizartech, веб-программист), Георгий Туревич (Wizartech, ведущий веб-программист)

Интеграция Zend Framework c Javascript-фрэймворками jQuery и Dojo Toolkit
Георгий Туревич (Wizartech, ведущий веб-программист)

Смело обсуждайте доклады и регистрируйтесь!

За последними новостями можно следить здесь:

RSS-канал: feeds.feedburner.com/zfconf

Twitter: @zfconf

Группа Вконтакте: vkontakte.ru/club14951507

К участию также приглашаются информационные и финансовые спонсоры.

После прочтения вот этого поста: Убираем дублирование при добавлении роутинга, об использовании констант в шаблонах Live Street, понял что такая архитектура вьевера не удобна не только мне. Хочу поделиться своими соображениями на этот счет.

Автор статьи правильно заметил, что при добавлении нового роута приходиться дублировать информацию. Но, на самом деле здесь происходит более «серьезное» дублирование, чем копипаст из config/config.route.php в Viewer.class.php — мы дублируем функционал по составлению пути — один раз это делает программист, разрабатывая модуль, второй раз это делает верстальщик, когда делает шаблон. Большее неудобство не в том, как мы доставим константу во Viewer, а именно в том факте, что верстальщику этими константами нужно пользоваться.

Если нам вдруг понадобиться изменить принцип роутинга, то придется перелапачивать весь шаблон, исправляя ошибки адресов. Имхо, если Router, решает какой Action должен отработать, пусть сам нам скажет, как к этому Action нужно обратиться. Тогда необходимость в константах во Viewer`e вообще отпадет сама собой.

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

А мораль из этого такова: Кто сеет - Тот и жнет. Иначе организационных проблем будет просто завал.

Спонсор поста:
“Экономная” мебель для офиса

Последний месяц ввиду производственной необходимости познакомился с этим движком намного теснее - разрабатывал три модуля под заказ - “Гараж”, “Объявления”, “JS Loader”. В процессе работы над модулями внес свою лепту в рост проекта и влился в общение разарботчиков на самом livestreet.ru. Написал три статьи с описанием своих хаков и доработок.

Представляю их вам.

Хак: Выполнение PHP кода на статических страницах

Заметка повествует о том, как выполнять PHP код на статических страницах (храня его в базе вместе с текстом). Хак достаточно просто и незамысловатый - достаточно добавить одну функцию в Event, который отвечает за показ страницы пользователю.

Читать оригинал.

P.S. В архитектуре движка LiveStreet: Event - это аналог Action в Zend Framework. А action`ом называется то, что в Zend называется Controller. По началу не привычно было в названиях ориентироваться 

Автоматическое составление сложных запросов в mapper`ах

Это статья познавательного характера. Здесь я просто рассказываю как выкрутился из ситуацией с составлением сложных SQL-запросов “на лету”, используя такой механизм библиотеки DbSimple как макроподстановки.

Суть проблемы.

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

Технически задача заключается в следующем — есть три таблицы: объявления, категории объявлений — отсюда мы получаем название категории, пользователи — отсюда мы «дергаем» логин пользователя. Необходимо реализовать выборку по следующим условиям:
— категория или массив категорий (дочерние),
— ID пользователя или логин,
— статус (опубликовано или нет — для администратора),
— актуально объявление или нет,
— минимальная и/или максимальная цена,
— есть привилегии или нет,
Учесть при этом составную сортировку (по одному или двум полям), а также не забывать, что результат фильтрации нужно показывать с разбивкой на страницы. Сложности в это все добавляет то, что логин пользователя тянется из другой таблицы, поэтому необходимо использовать HAVING, а не WHERE.

Решение проблемы: читаем здесь.

Модернизация модуля Message - жизнь после редиректа

Это яркий пример реализации функционала Zend FW в системных возможностях LS.

Описание проблемы.

Создавая новый модуль или экшн, очень часто прибегаю к использованию сообщений Message_AddNotice() и Message_AddError(). Штука очень симпатичная и удобная. Но. Всегда есть одно но. И заключается оно в том, что модуль выводит сообщения только на «текущей» странице. Если же где-то в экшене выполняется редирект, то наше сообщение теряется.

Почему это неудобно? Давайте посмотрим конкретный пример. Я разрабатываю модуль «Гараж». По адресу /garage/user_login можно увидеть список машин пользователя, если просматривающий пользователь = текущему авторизированному, то у каждого автомобиля есть ссылка «Удалить». Эта ссылка указывает на /garage/user_login/del/car_id, где происходит обработка удаления. За это отвечает EventDeleteCar() и именно здесь удобно сказать пользователю «Парень, твоя машина успешно удалена», ну или «Сорри, не получается». Для этого используем стандартное Message_AddNotice(), Message_AddError().

Но, мы не можем оставить пользователя на этой страничке, и в конце реализации event`а перекидываем его назад к списку с помощью func_header_location(). И все. Никакого сообщения пользователь не увидит!

Идея решения.

В Zend Framework есть action-плагин FlashMessenger, который для тех же целей использует сессию. Мы поступим аналогично.

Решение проблемы: описано здесь.

Live Street

Вообще, заниматься развитием Open Source - это очень увлекательное занятие. Жаль только времени получается отводить на это мало. Надеюсь, найду среди читателей своего блога коллег по мысли и деятельности  Завтра постараюсь выложить описание сделанных мною модулей.

Спонсоры поста:
Доставка цветов в Москве
Сетка арматурная

Идея пришла почти случайно, продумана не до конца. Выкладываю, что называется, “как есть”.

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

Качество прикола зависит от “прикольности” самой картинки и чувства юмора составляющего. Особенно интересно, когда на такие творчества попадают тесно общающиеся группы людей (одноклассники, одногруппники, коллеги по работе или просто соседи по дому).

Идея сервиса “ДляДрузей” состоит в следующем:

1. Пользователь указывает свой mail, под которым зарегистрирован “Вконтакте”.

2. Мы скачиваем список его друзей и выводим на экран.

3. Пользователь выбирает галочками тех друзей, которых он бы хотел добавить на рисунок.

4. Для каждого из выбранных пользователей мы скачиваем их аватарку и из полученных аватарок по шаблону делаем какой-нибудь рисунок (комикс, календарь, шарж - на что фантазии хватит). Можно делать тематические рисунки (к праздникам, например).

5. Естественно, ставим в углу свой Watermark.

Технических трудностей в реализации не должно быть. Гораздо сложнее будет продумать как креативно обрабатывать фотки (хотя начинать можно с обычных коллажей).  Самая большая проблема, как обычно в подобных задумках, “как монетизировать социальный трафик?”

Спонсор поста: Саундтреки из фильмов.

Сегодня Zend Developer Zone оповестила о выходе ZF 1.9. Сейчас переходить на новую версию нет времени, обязательно сделаю это на следующей неделе - тогда и поделюсь впечатлениями. Новый Zend ориентирован на PHP 5.3.0 (вышедшего месяц назад), но будет нормально работать и на более старых версиях PHP.

Изменения и нововведения коснулись:

1. Zend_Rest_Route, Zend_Rest_Controller и Zend_Controller_Plugin_PutHandler;

2. Zend_Feed_Reader;

3. Zend_Db_Table;

4. Zend_Date, Zend_Locale и Zend_Translate;

5. Zend_View_Helper_BaseUrl;

6. Zend_Test_PHPUnit_Db;

7. Zend_Dojo;

8. Zend_Pdf;

9. Zend_Log_Writer_Syslog;

Подробнее об этих и других “фичах”  - читаем здесь.

Padraic Brady опубликовал замечательную статью о том, как сделать свой собственный twitter клиент с использованием Zend`овских библиотек Zend_OAuth и Zend_Service_Twitter. Рекомендую к прочтению:

Writing A Simple Twitter Client Using the PHP Zend Framework’s OAuth Library (Zend_Oauth)

Если элементами массива могут быть массивы, то я использую следующую функцию:

function func_array_unique($array) {
    $result = array();
    // Идея в том, что если исходный массив
    // содержал совершенно одинаковые элементы,
    // md5(serialize($value)) будет для них одинаковым
    foreach($array as $value) {
        $result[md5(serialize($value))] = $value;
    }
    // Очищаем ключи массива
    return array_values($result);
}

Выручает частенько, может и вам кому пригодиться.

Спонсор поста: “Медсервис-М” - круглосуточная стоматологическая клиника в центре Москвы: демократичные цены и профессиональные специалисты.

Говоря простым языком, Issue Tracking — процесс учета/отслеживания/решения проблем, возникающих в программе, обработка запросов на изменение, неточности, улучшения и т. д. Наиболее важная часть этого процесса - Bug Tracking - подразумевает обработку ошибок и неточностей.

Из своего опыта работы с различными заказчиками выношу несколько полезных советов.

Совет #1. Issue Tracking - “работа для двоих” (заказчика и исполнителя).

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

Совет #2. Используйте специальные инструменты.

Таких, слава богу, создано очень много. Ознакомиться с полным (?) списком можно здесь - “Comparison of issue tracking systems“, заодно почитать о преимуществах и недостатках каждой.

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

В работе с заказчиком важно, чтобы баг-трекер был интуитивно понятен пользователю (заказчик не должен быть ни программистом, ни тестером, он вообще может слабо в компьютерах разбираться:)) и, что самое главное, доступен в сети. Поэтому локально установленный вам вряд ли поможет. Я остановился на таком варианте: http://www.assembla.com, которая дает возможность бесплатно вести публичный проект\ты. Если у вас в баг-трекере ничего серьезного не планируется держать, то это вполне подойдет.

Совет #3. Расставляйте приоритеты.

Отмечайте высоким приоритетом те баги и\или доработки, которые нужно закрыть срочно (в ближайшее время), и наоборот низким - то, что можно оставить на потом. При этом обязательно прислушивайтесь к заказчику! Вы смотрите на проект с точки зрения разработчика, поэтому некоторые моменты могут показаться вам не существенными (например, точки в отображении даты нужно заменить на слеши), а для заказчика они очень важны. Пусть это не имеет никакого основания - но ни в коем случае не игнорируйте такие вещи! Если заказчик поставил высокий приоритет, и вы с ним не согласны - объясните ему свою точку зрения и выслушайте его. Договоритесь - снижайте приоритет, не договоритесь - лучше закройте баг сразу.

Совет #4. Заносите в список багов даже те проблемы, которые тут же устраняете.

Для заказчика это не важно. А вот для процесса разработки может очень даже сгодиться. Тем более, что иногда проблема кажеться маленькой и не серьезной, а потом из нее начинает вылазить такое…

Совет #5. Разделяйте задачи.

Система Trac предлагает по умолчанию 3 вида тикетов (Type): defect, task, enhancement. На практике этого вполне достаточно для большинства проектов, и именно таким набором я пользуюсь. Уверен, не стоит объяснять какие тикеты для каких задач используются :).

Совет #7. Указывайте ревизии.

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

Спонсор поста: Боитесь стоматологов? Доверьтесь профессионалам! Стоматология в Москве - филиалом Американской стоматологической клиники (Сакраменто, Калифорния) - лучшие специалисты в своей области.

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

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

Могу сказать, что у такой формы ведения своего дела есть свои плюсы и минусы. Основные неудобства свзязаны с тем, что ФОП (физическое лицо предприниматель) это и фирма, и я сам в одном лице. А значит повышается требования к моей финансовой дисциплине - нужно постоянно следить за тем, чтобы финансы моей “фирмы” жили отдельно от моих личных. В связи с этим сделал две вещи:

1. “Назначил” сам себе заработную плату. По окончанию каждого месяца, буду переводить эту сумму себе на дебетовую карточку и пользоваться. Это будет обычные затраты моего “предприятия”. А прибыль (разница доходов и расходов) будет реинвестироваться в дело.

2. Начал вести учет финансов фирмы отдельно от моих личных.

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

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

Остановился я на AbilityCash. Программа удобная и интуитивно понятная. По функционалу стандартная: счета, доходы\расходы\переводы, валюты, отчеты и графики. Для учета личных финансов вполне подходит, а вот для учета работы предприятия не очень.. Все упирается в особенности ее предназначения.  Поэтому пришлось подставить свои костыли

Деньги на ведение деятельности

Поначалу, не подумав, начал все делать как обычно - открыл счета для учета всех видов разных “денег”, с которыми буду работать:

- касса (для учета наличных)

- расчетный счет в банке

- webmoney

- weblancer

- blogun

На всех счетах указал “входящий” остаток - на различных электорнных кошельках около 600 грн. Дальше прикинул, что на все регистрационные процедуры потратил порядка 340 грн, и не долго думая указал это как входящий остаток по счету “Касса”.

Затем создал статьи доходов и расходов. Получилось следующие:

Доходы

- Разработка ПО под заказ

- Продажа ПО собственного производства

- Продажа ПО по агентским договорам

- Техническое обслуживание и сопровождение проектов

- Консультационные услуги

Расходы

- Заработная плата

- Канцелярские расходы

- Консультационные услуги

- Материально-техническое обеспечение

- Налоги и др. платежи

- Оплата за РКО

- Реклама и маркетинг

- Юридическое сопровождение

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

Дело в том, что обычно предприятие начинается с уставного фонда. ФОП имеет право не формировать такового. Это удобно, но “расслабляет”. Если уже я решил отделить свои финансы от финансов фирмы, то должен точно знать, сколько денег влил в нее до тех пор пока не вышел на самоокупаемость. Поэтому отменил все действия и сделал следующие:

1. Ввел новую статью доходов “Внесение средств на ведение деятельности”.

2. Обнулил входящие остатки по всем открытым счетам.

3. Провел приходную операцию по этой статье на сумму 340 грн с зачислением на счет “Касса” и аналогичные приходные по всем видам открытых счетов.

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

Учет активов и пассивов

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

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

Все дело в том, что учет личных финансов ведется по кассовому методу - т.е. деньги пришли-ушли, мы так и записали. По такому же принципу отчитываются в налоговую ФОПы. Но на предприятии такое движение не всегда показательно. Опишу проблему такого подхода на конкретном примере: Предположим, у нас есть 10 контрактов на тех обслуживание сайтов по 600 грн в месяц каждый. Все клиенты проводят с нами расчет в конце месяца, скажем 25-28 числа. Если мы ведем учет по кассовому методу, то по отчетности до 25 числа наше предприятие еле сводит концы с концами, а  с 28 резко становиться богаче на 6000 грн.

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

Типичный пример - сегодня я открыл текущий счет в “Райфайзен Банк Аваль”. В сумме за открытие счета, корпоративную карточку, подключение к клиент-банк я должен заплатить 100 грн. Но я не платил наличкой, а договорился, что эта сумма будет списана с поступлений в течении месяца. Т.е. движения средст еще не было - 100 грн я ведь не отдал. Но подписав договор взял на себя обязательство сделать это в течении месяца. Согласитесь, без отображения этого в отчетах картина явно не полная

Исходя из этого, я отобразил в учете следующую операцию: оплату РКО со счета “Кредиторская задолженность” в сумме 100 грн.  Ability Cash позволяет при построение отчетов по оборотам указывать какие счета нужно учитывать, а какие нет. Это удобно, так как выделив все счета, я получаю описание экономического состояния. А сняв отметку со счетов “Дебиторская задолженность” и “Кредиторская задолженность”, получаю отчет по кассовому методу (т.е. только движение средств).

Первым в меньшей степени. Чаще всего в форме “недополученных доходов”.

Гораздо в большей степени - вторым. И лично у меня сейчас период критической нехватки времени. Поэтому терять его, наверное, еще хуже. Вообще, некоторые говорят, что для фрилансера Деньги = Время. Я всегда добавляю Деньги = Время*Профессионализм.

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

А у вы больше всего с какими проблемами встречаетесь?


Интересное в блогосфере:

• Блог о заработке в интернете. Seo, Smo и немного интернет-маркетинга.
• Биржа контента eTxT.ru предлагает вам уникальные возможности: «Копирайтинг с размещением» и «Мультизаказ».