О первом днепропетровском коворкинг-центре читаем на хабре.
Коворкинг (англ. Co-working, совместно работающие) — это модель работы, заключающаяся в том, что вместо того, чтобы работать дома, люди (часто фрилансеры) снимают общее помещение, оставаясь независимыми и свободными, но не испытывая при этом недостатка в общении, работая вместе, делясь идеями и помогая друг другу.
16 февраля 2009 года в рамках серии открытых лекций для университетов Украины, состоится открытый мастер-класс ведущего эксперта компании Exigen Services по Java EE-технологиям на тему:
«Стек технологий Java EE 5: что? зачем? почем?»В настоящее время платформа Java Enterprise Edition является одним из наиболее используемых промышленных стандартов разработки распределённых бизнес-приложений. В ее состав входят множество технологий, каждая из которых имеет свою четко очерченную область применения, и разработчику, столкнувшемуся с необходимостью решения той или иной задачи, актуально понимание, что предлагает Java EE 5 для его нужд.
В рамках мастер-класса будет дан обзор стека технологий Java EE, который позволит слушателям получить целостное представление о платформе Java EE, как о наборе рабочих инструментов, использование которых, в зависимости от выбора, позволяет оптимизировать различные характеристики создаваемых приложений.
Данное занятие ориентировано на студентов старших курсов и молодых разработчиков ПО, обладающих базовыми знаниями языка Java и интересующихся технологиями Java EE и их использованием.
В программе:
- место той или иной технологии в архитектуре;
- узкие места стыков технологий;
- где используется стек Java EE 5?
- проще или сложнее?
Семинар пройдет 16 февраля в 13:00 по адресу Днепропетровск, ул. Козакова, 18, 14 корпус ДНУ, аудитория 108
Вход на мастер-класс – свободный.
Я, скорее всего, пойду. Надеюсь, что там будет что-то интересное.
что нужно - нужно разработать алгоритм позиционной игры неограниченной во времени и перевести стратегию на язык формул
Интересно, насколько корректно спросить у заказчика, что он выкурил? :)))
Смотрим, учимся и наслаждаемся.
PS. Несмотря на название - полезно отнюдь не только для “рубистов” (интересно, как адептов ruby называют на русском?).
PPS. Пора дизайн блога менять - видео не влазит. В FF3 смотреть можно, но если у вас с этим проблемы - идем на сайт RubyConf 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-е посты показывались полностью.
Собственно, сабж.
Не спрашивайте - почему и из-за чего. Сам виноват. :)
Но ничего! Что не делается - то к лучшему. Теперь у меня будет больше свободного времени, которое я с удовольствием потрачу на себя. В планах:
Если у вас есть какие-то пожелания насчет блога (например, хотите увидеть статью по какой-нибудь тематике) - пишите в комментах!
PS. Хотя, надеюсь, в скором времени для меня найдется работа.
И лучшее этому подтверждение:
Life sucks…
Представим ситуацию: вы используете какую-то библиотеку, доступную вам в исходных кодах. Вы находите баг в библиотеке. Пусть он будет не очень критичным, но довольно сильно мешающим. Каковы ваши действия? Лично я вижу 5 вариантов (по жизни приходилось сталкиваться со всеми):
На самом деле меня интересует вопрос - как часто вы прибегаете к варианту №5? Лично я гораздо чаще вижу “а, хрен с ними со всеми, щас пофиксим по быстрому и всё” (№4) и “да ну его нафиг, ковыряться самим в этих исходниках, щас сделаем тикет, пусть разработчики смотрят” (№3), “млять, ну что же эта за херовая программа, но, блин, деваться некуда…” (№2).
Последние комментарии