Видео от создателя Ruby On Rails и одного из первых сотрудников 37 Signals о том, что нужно делать, чтобы зарабатывать деньги в интернете (”The secret of making money online”). Видео я смотрел давно уже, но без слайдов. После того, как мне наш проджект менеджер прислал ссылку на это же видео, решил найти вариант со слайдами. Смотрим.
PS. DHH рассказывает, казалось бы, об очевидных вещах. Однако отнюдь не всем эти вещи приходят в голову без “толчка” со стороны.
26-го сентября, в субботу, в Киеве будет проведен BarCamp на тему языка Ruby и фреймворка Ruby On Rails. Место проведения зависит от количества желающих посетить данное мероприятие и на данный момент уточняется. Если не произойдет ничего особенного - я туда скорее всего поеду. Буду рад увидеть там читателей своего блога. ;)
Заходим, смотрим, регистрируемся.
Google Wave is a new tool for communication and collaboration on the web.
К этой цитате хочется добавить много-много-много всего, но лучше разработчиков вряд ли сейчас кто-то что-то сможет сказать. Поэтому смотрим видео, оставляем заявку на получение заветного аккаунта и… ждем… :)
PS. Видео просмотрел на одном дыхании - классная идея, классная реализация, классная презентация. Советую всем без исключения. Возможно, после выхода этого продукта вы откажетесь от использования всяких wiki и e-mail.
Чрезвычайно интересное видео выступления Боба Ипполито на PyCon 2009, в котором он рассказывает о современных системах хранения данных. Очень заинтересовала Cassandra и Column-Oriented Databases. Очень рекомендую посмотреть всем, кто занимается построением высокопроизводительных систем, которые оперируют большим количеством данных. У меня как раз такой случай, так что пойду изучать Cassandra, LucidDB и C-Store.
И самое приятное - всех с праздничком, с Днем Победы!
В сообществе симфонистов праздник - Фабьен наконец-то рассказал о том, что можно ожидать от следующей мажорной версии фреймворка:
В презентации это называлось Dependency Injection Container. Подробнее о том, что это такое можно узнать в википедии: IOC, Dependency Injection. Либо спросите знакомых Java EE программистов, они должны знать, что это такое. :) За примерами лучше, опять же, обращаться к Java: Pico Container Introduction (достаточно просто и понятно), Spring IOC-container. Вкратце - скармливаем контейнеру классы и зависимости между ними и можем строить новые обьекты, которые будут построены на этих зависимостях (если у вам один обьект зависит от двух других, то они будут в него автоматически вставлены - через конструктор, методы, свойства, etc.). На PHP я IOC-контейнера ни разу не видел (хотя они есть) и… Не знаю, насколько он будет действительно удобен и нужен. Будем смотреть.
Лучше смотреть презентацию - всё полностью переписано, много новых возможностей: шаблоны теперь не только file-based, но и memory-based (memcache, apc), database-based и т.д, появилось наследование шаблонов (привет, Django), все возможности предыдущих версий (типа partials, slots), думаю, останутся. Всё это будет приправлено отсутствием зависимостей от самой Symfony (как я понимаю, под “Independent library” они имеют ввиду именно это).
Коротко и ясно - “Rails Metal in Symfony”.
Кстати говоря, довольно интересен тот факт, что засуетились все только сейчас, а ведь это не первая презентация о возможностях, которые нам приподнесут в Symfony 2.0 - на Symfony Camp 2008 об этом уже говорили. :)
Под “скрытыми” записями сегодня будут пониматься “unapproved”-записи в таблице. Кому лень ходить по сылкам: иногда не все записи какой-нибудь таблицы нужно показывать пользователю, например - если я не хочу показывать некоторые посты в блоге. Обычно для этого я делаю поле, например, is_hidden, а затем выбираю все записи, где is_hidden = 0. Проблема состоит в том, что я обычный человек и могу забыть поставить нужное мне условие. Поэтому я хочу получить какое-нибудь простое, но очень эффективное решение такой проблемы. В ActiveRecord этим решением является default_scope. А я вам сегодня расскажу, как этого добиться в Doctrine.
Итак, представим, что у нас есть табличка Post:
Post:
actAs:
Timestampable: ~
columns:
title: { type: string(128), notnull: true }
text: { type: text, notnull: true }
is_hidden: { type: boolean, notnull: true, default: 0 }Самый простой, на первый взгляд, подход - переопределять PostTable::createQuery(), чтобы этот метод возвращал уже Query с нужным нам “WHERE is_hidden = 0″. К сожалению, не всегда это помогает. Например, при выборке постов для какой-либо категории через $category->Posts этот метод не сработает.
Есть гораздо более простой способ сделать то, что нам нужно - использовать listener-ы. В Doctrine есть довольно много событий, которые мы можем “слушать” и на которые мы можем реагировать. В данном случае нам подходит событие “preDqlSelect”, которое входит в группу “DQL Hooks“, и которое вызывается перед выполнением запроса на выборку записей. Как нам нужно прореагировать на событие: взять Doctrine_Query из Doctrine_Event и добавить в него дополнительные условия выборки.
Самый простой способ - переопределить метод preDqlSelect в самой записи:
class Post extends BasePost
{
public function preDqlSelect(Doctrine_Event $event)
{
$params = $event->getParams();
$event->getQuery()->addWhere("{$params['alias']}.is_hidden = 0");
}
}В первой строке метода мы получаем параметры запроса, из которых нам нужен alias - можете считать это обычным alias-ом таблицы из SQL (в данном случае это alias таблицы в DQL), т.е. при таком DQL:
FROM Post palias-ом будет “p”.
Во второй строке мы получаем текущую query и добавляем в неё условие “is_hidden = 0″.
Мы не можем использовать ->where(), т.к. этот метод сотрет все имеющиеся части WHERE в запросе. В то же время ->addWhere и ->andWhere ведут себя так же, как и ->where при отсутствии where-части запроса.
Собственно, вот и всё - тепер у нас будут выбираться только “видимые” посты.
Во второй части будет показано, как сделать созданный в этом посте код более реюзабельным, а также как сделать так, чтобы в backend-е посты показывались полностью.
Есть в Symfony такая штука, как генератор админки на основании описанных моделей. Подробно о самом генераторе админки лучше читать здесь (кстати, я не понял, а про propel:generate-module теперь в Symfony Book не рассказывается ничего, что ли?).
Я вчера столкнулся с багом, который ошибочно описал здесь, а затем правильно - здесь. Кто не хочет читать мой кривой английский - читаем дальше. Баг воспроизводится при наличии трех условий:
В этом случае вы получите вот это сообщение:
You don’t have the required permission to access this page.
Решение описано в первом моём тикете:
Нужно заменить в файле “<путь к библиотекам symfony>/lib/plugins/sfDoctrinePlugin/data/generator/sfDoctrineModule/admin/template/actions/actions.class.php” (это шаблоны для генератора админки Doctrine) эти строки:
if (!$this->getUser()->hasCredential($this->configuration->getCredentials($this->getActionName()))) { $this->forward(sfConfig::get('sf_secure_module'), sfConfig::get('sf_secure_action')); }на эти:
credentials = $this->configuration->getCredentials($this->getActionName()); if (!empty($credentials) && !$this->getUser()->hasCredential($credentials)) { $this->forward(sfConfig::get('sf_secure_module'), sfConfig::get('sf_secure_action')); }
Баг некритичный, так что можно, в принципе, от него не избавляться, а подождать, пока изменения внесут в главный репозиторий. Просто если встретите его - не удивляйтесь. Лично я долго не мог понять - почему у меня не работает is_secure: off.
Последнюю неделю работаю с Symfony 1.2 и Doctrine. Так вот, если раньше я хвалил Doctrine, то теперь… В общем, после нескольких дней работы с ней захотелось плеваться… На первый взгляд всё замечательно, но как только начинаешь копать глубже начинается ужас. Мне очень не хочется рассказывать про эти баги и недоделки (причина банальна - просто лень вспоминать, выискивать по истории icq/jabber о всех багах, которые я нашел). У меня было не очень хорошее впечатление о Propel, но, по крайней мере, когда я работал с ним, у меня была уверенность, что всё будет работать и ничего не сломается, если я что-то добавлю/изменю. С Doctrine такой уверенности лично у меня нет (хотя коллеги тут подсказывают, что всё наладится :)) - такое впечатление, что “еще чуть-чуть” - и все развалится. Это мнение исключительно субьективное, обьяснять я его не буду, если кто-то что-то желает узнать - прошу в icq/jabber, все контакты есть в сайдбаре моего блога.
Напоследок всё-же хочется привести пример одной из “недоделок”, которую при хорошем коде можно было бы легко исправить:
Имеем следующий код:
// Category has many Posts
$category = Doctrine::getTable('Category')->find(1);
$posts = $category->Posts;Задача состоит в том, чтобы в $posts были посты, отсортированным по какому-нибудь полю бд. Причем, естественно, хочется, чтобы посты были отсортированы не только про вот такой их выборке через LazyLoading, но и при Eager Loading, т.е.:
$category = Doctrine::getTable('Category')->createQuery('c')->leftJoin('c.Posts')->fetchOne(); // выборка всех данных одним запросом
$posts = $category->Posts; // запроса к бд не проиходитНа самом деле, про Eager Loading я с самого начала не думал, но, я думаю, со мной никто спорить не будет, что если сортировка должна быть в одном случае - она обязанна быть и во втором.
Так вот - эту проблему в доктрине приходится решать вручную для каждого поля, причем кешование данных тоже приходится хендлить самому.
При вызове свойства $category->Posts, будет вызываться метод $category->getPosts(), который мы и будем переопределять:
class Category extends BaseCategory
{
public function getPosts() // в идеале сюда должен передаваться параметр $load, но пока о нем забудем
{
return Doctrine::getTable('Post')
->createQuery()
->orderBy('column ASC')
->where('category_id = ?', $this->id)
->execute();
}
}Красиво? Как по мне - не очень, т.к. несмотря на наличие уже указанной связи - использовать её я не могу, приходится строить query заново.
Возможно, связью я воспользоваться могу, об этом нужно подумать… Пока писал пост пришла в голову идея, но проверять лень.
Запускаем. Пробуем:
$category = Doctrine::getTable('Category')->find(1);
$posts = $category->Posts;
$posts = $category->Posts;
$posts = $category->Posts;
$posts = $category->Posts;И что мы видим? 5 запросов к бд. Хмм. Убираем метод getPosts. Запускаем тот же код. В итоге - два запроса. Я, конечно, понимаю, что это я такой плохой и лентяй еще к тому же, но ведь можно было сделать подобное “кеширование” для связей автоматически (если кто знает, как это сделать - дайте знать, походя дофига времени по кодам доктрины я не нашел место, где это можно сделать). Ладно, сделаем “кеширование”:
public function getPosts()
{
if (!isset($this->_references['Posts']))
$this->_references['Posts'] = Doctrine::getTable('Post')
->createQuery()
->orderBy('column ASC')
->where('category_id = ?', $this->id)
->execute();
return $this->_references['Posts'];
}Запускаем уже запомнившийся нам код. Ну слава богу - два запроса.
На самом деле нужно еще кое-что переопределять (типа Category::loadReference), но я на это забил, т.к. вряд ли я буду вызывать этот метод вручную. А его вызов системой мне, вроде бы не встречался.
Ну, вроде более-менее готово. По крайней мере - можно пользоваться, а нам только это и нужно.
Теперь об Eager Loading. О нем я сам даже и не вспоминал, т.к. у меня не было ни одной идеи - как его реализовать (нужно было опять копаться в исходниках Doctrine, а это мне уже, порядком, поднадоело). Как вдруг, откуда ни возьмись, появился пост в блоге доктрины: Cookbook Recipe: Relation DQL Behavior. Советую прочесть его и комментарии (благо, их там немного). Вы увидите в комментариях и меня, говорящим спасибо за Eager Loading, а также указавшим на то, что в случае Lazy Loading-а решение не работает. На что мне ответили:
You’re right the above won’t work, but you shouldn’t ever be doing that :) You should always load your data through full DQL queries and avoid lazy loading data
Ага. Благодарю покорно. Зачем тогда вообще делать Lazy Loading, если его не нужно юзать. Может, мне банально удобнее написать $category->Posts и получить посты тогда, когда это реально нужно, а не при выборке категории. Да, я получу два запроса вместо одного, ну и что? Это не O(n), а я не привык оптимизировать то, что нормально работает и так.
И напоследок: на самом деле проблему вполне можно было бы решить путем наследования от класса связи и его расширения. Однако сделать это в Doctrine сне не судилось, т.к. в отношениях hasOne, hasMany намертво зашиты стандартные классы связей Doctrine, а жаль. Такие связи - это плохо, т.к. они статичны и не способствуют хорошему расширению системы. С другой стороны - не мне критиковать jwage, самбы я вряд ли сделал что-то подобное, по крайней мере сейчас.
PS. Долго думал, как назвать пост. Так и не придумал… :(
As a result of the EstDomains de-accreditation by ICANN, Directi will be taking over EstDomains’ Registrar operations…
http://www.directi.com/estbulktransfer/
Регистратором домена fxposter.org был EstDomains. До поры до времени я не особо интересовался регистратором, т.к. в панели управления доменами никаких сообщений по этому поводу не было. После получения письма (где-то в ноябре) по поводу “смены регистратора” я тоже не придал этому всему значения. Как оказалось - зря. Когда подошел срок завершения регистрации моего домена я зашел в панель управления и попытался добавить деньги себе на счет. Но не тут то было! Несмотря на то, что панель работала, сайт, на который меня редиректило при пополнении счета, не подавал признаков жизни. Подождал пару дней… но ничего не изменилось. Попытался перевести домен к другому регистратору - ничего. Т.е. перевод заказал уже две недели назад, но ничего не происходит до сих пор. В данный момент домен деактивирован, но восстановить я его не могу по причинам, описанным выше. Пока что перенес блог на другой домен (blog.fxposter.org), feed доступен по старому адресу (feeds.feedburner.com/fxposter), так что всё нормально, не считая того, что у blog.fxposter.org был PR4 + стабильный приток посетителей с Google и Yandex. Жаль…
До сих пор надеюсь на то, что домен удастся перенести к другому регистратору, либо выкупить сразу же после того, как он будет удален (подскажите, кстати, насколько это реально?).
PS. Сдал сессию, теперь “отдыхаю” (приходится работать, т.к. из-за универа не работал 3 недели). Сессия удачная, хотя я был уверен, что это будет самая плохая сессия за все 3 с половиной курса.
На днях попросили меня помочь написать функцию сортировки массива на JavaScript, чтобы сохранилась связь между ключами и их значениями, т.е. аналог asort() в PHP. Поверхностный поиск в Google ничего подобного найти не смог, поэтому родилась вот такая функция (принимает массив или хеш, на выходе - хеш):
function asort(arr, sort_function) {
if (sort_function == undefined)
sort_function = function(a, b) { return a - b }
var b = [];
for (var i in arr)
b.push([i, arr[i]]);
b.sort(function(a, b) { return sort_function(a[1], b[1]) });
c = {};
for (var i in b)
c[b[i][0]] = b[i][1];
return c;
}Примеры использования:
// сортировка по возрастанию
var h = asort([1, 10, 2, 5, 4]);
for(i in h)
alert(h[i]);
// сортировка по убыванию
var j = asort([1, 10, 2, 5, 4], function(a, b) { return b - a });
for(i in j)
alert(j[i]);PS. В JS я не спец, так что, возможно, всё сделано абсолютно неправильно :)
Последние комментарии