Disturbed

Здравствуйте, Владислав

У Вас в профиле ссылка на очень хорошую книжку Мартина Фаулера: martinfowler.com/books.html#eaa

Из неё про Active Record: martinfowler.com/eaaCatalog/activeRecord.html
Data Table Gateway: martinfowler.com/eaaCatalog/tableDataGateway.html
Data Mapper: martinfowler.com/eaaCatalog/dataMapper.html

Теперь немного рассуждений из личного опыта.

Привязка доменной модели к реляционной сложна исходя из следующих факторов:

* Гранулярность (доменная модель часто имеет большую детализацию)
* Наследование (нужно выразить в реляционной схеме данных)
* Идентичность (определяется равенством но коде и ID в БД)
* Ассоциации (один ко многим в коде выражается массивом, в схеме БД через внешние ключи)
* Навигация по данным (в коде — ссылки, в схеме БД joins)

В случае, если доменная модель сложна, и мы сталкиваемся со множеством перечисленных трудностей, то рекомендуется использовать Data Mapper. Это позволит доменным объектам не беспокоиться о существовании БД.

Если предметная область не слишком сложная, то может быть удобным добавить Persistence методы к классам доменной модели (Active Record). Это облегчит программистам процесс написания сервисного кода.

В случае, если доменная модель удобно ложится на реляционную схему, но мы всё равно хотим обособить SQL для соблюдения принципа персональной ответственности, то рекомендуется использовать Data Table Gateway

Это довольно общие слова. Если уточните вопрос, буду рад уточнить и ответ :)

Тестирование + документирование еще можно прикрутить. Ну и все это через continuous integration сервер какой-нибудь.
А тестовый сервер (ну или staging), я думаю, обязательно надо.

Стоит redmine — всё устраивает. Вообще странная политика — не хочу ставить redmine (что дело 5 минут), а написать свой — да пожалуйста. Если уж замахиваться — напиши лучше свой Megaplan :)

Всё нравится. Ещё один не нужен. Если что-то не нравится, можно написать к Jira/Redmine плагин.

прошу прощения за Ctrl + Enter :)

необходимо создать интерфейс:

interface IDecorable {
  /**
   * @return IDecorable
   */
  removeDecorator(IDecorable $decorator);
}

декорируемый обьект должен реализовать интерфейс с помощью заглушки:

  //....
  /**
   * @return IDecorable
   */
  removeDecorator(IDecorable $decorator) {
      return $this;
  }
  //...

а все декораторы могут наследоваться от абстрактного декоратора в котором будет вот такая реализация данного интерфейса:

  //....
  /**
   * @var IDecorator
   */
  private $decorableObject;
  /**
   * @return IDecorable
   */
  removeDecorator(IDecorable $decorator) {
    if($decorator == $this) {
      return $this->decorableObject;
    }
    $decorable = $this->decorableObject->removeDecorator($decorator);
    if($decorable != $this->decoratedObject) {
       $this->decoratedObject = $decorable;
    }
    return $this;
  }
  //...

Таким образом обьекты смогут использоваться следующим образом:

$decorated = $decorated->removeDecorator($decorated); 

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

$decorated = $decorated->removeDecorator($someOtherDecorator); 

Проблема не в карме, не в времени года, не в НЛО.
Проблема в хабросообществе — оно отупело… Да, да, именно отупело.

С Хабра ушли сотни хороших авторов. Причина: «мои статьи там не любят», «мне надоело поливание дерьмом», «слили карму, значит мои статьи им не нужны» и т.д.

А вот причина этих слов более интересна:
Хабр на 90% (а может и более) состоит из быдлокодеров с завышенной самооценкой. Им дали немного власти в виде анонимности и кармы. И они этой властью пользуются — «давят» всех кто умнее их.

Хорошие авторы не хотят писать статьи для общества, которое их не понимает.

Parse error: syntax error, unexpected '?' in /home/sildesign/domains/econportal.ru/public_html/fileloc.php on line 5

<script>alert()</script>

Warning: Division by zero in /home/sildesign/domains/econportal.ru/public_html/lib/content.functions.php(975): eval()'d code on line 33

Warning: Division by zero in /home/sildesign/domains/econportal.ru/public_html/lib/content.functions.php(975): eval()'d code on line 34

Warning: Division by zero in /home/sildesign/domains/econportal.ru/public_html/lib/content.functions.php(975): eval()'d code on line 62

ебаный стыд >_<

SELECT r.*
    FROM Records r
    INNER JOIN Record_Tag rt ON rt.record_id = r.id
    INNER JOIN Tag t ON t.id = rt.tag_id
    WHERE t.name IN ('tag1','tag2','tag3,...,'tagN')

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

Купил Kindle 3, читать художественную лит-ру более чем удобно. Что касается технической лит-ры, ее читать не столь комфортно, но все же можно приловчиться. Плюс на эл. книге есть всякие плюшки вроде словаря.

вас так волнует лишние 4 МБ?
если да, считайте тогда уж средневзвешенное с весами по веремени исполнения, возможно вы только выигрываете
и да, новая версия кода не всегда означает хорошая )

И с каких это пор использование nosql стало удобненьким?
Терпи. Напиши два запроса.

«Большие дяди» любят ZF

Посмотрите здесь
qualityassuranceinphpprojects.com/pages/tools.html

RTFM php-fpm.org/wiki/FAQ

Does the PHP-FPM to speed processing of requests?

No, it does not really change anything. However, if you use some of the special features, the performance of certain queries can be accelerated.

Я бы посоветовал однозначно Zend как швейцарский нож, которым можно вырезать любую нужную деталь достойного качества, но! Но наскоком разобраться будет не совсем просто, поэтому стоит начать с кухонного ножа, простейших легковесных аналогов типа CodeIgniter (хорошая дока, понятная структура, лёгкий переход с него на Zend). А что касается MVC, так это тренд, и реализована она практически во всех современных фреймворках.

Zend Framework — громоздкий, большой, медленный — но как пример постоения ООП систем — отлично подойдет. Куча примеров, огромное комьюнити.

xmarks.com

по цене они примерно одинаковы, разница в 1000-2000р (в зависимости от места покупки) в пользу Оптимуса. Самсунг продается уже с Андроидом 2.1, тогда как Оптимус придется обновлять, я покупал в МедиаМаркте с версией 1.6 и около недели ждал обновления.

Из субъективного мнения владельца Оптимуса: кому-то не нравится дизайн Оптимуса, неказистый и т.д. Лично мне не нравится, что нет места под стилус. В 2.1 версии слава богу поправили баг с набором сообщений — в 1.6 версии на Оптимусе мне приходилось по 15 минут править без стилуса свои смс, чтобы получающая сторона поняла, что я хотел сказать.

Экран чуть побольше, чем у Самсунга 320 на 480, в солнечный день даже на самой громкой яркости выглядит блекло, практически не видно, что на экране. Особо не старался, но вроде бы не царапается, особенно при использовании стилуса.

Не понравилась напиханность бесполезными для меня сервисами вроде Одноклассники, Вконтакте, Афиша, Спорт, Мамба, которые без рута никак не удалить.

Про батарею: в режиме поговорил-чуть-чуть посидел в инете работает 3-4 дня, но на 4 день начинает пищать насчет малого заряда. При полном использовании всех сервисов работает от 1 до 1.5 дней.

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

Еще в минус — пока находился на прошивке 1.6 приходилось перед синхронизацией с компьютером перезагружать телефон.

Гарнитура также в минус — вываливается из ушей, ощущение, что купил дешевые китайские наушники за 100р в переходе. Однако качество связи нормальное.

Знаменитый APNdroid работать отказался — точнее работал, но интернет не отключал. Поэтому пришлось руками вырезать apn точку и работать только через wi-fi, иначе поедается довольно много денег.

Кажется зло в НЕ использовании замечательной функции работы SMTP.
Пойду пробовать с включенным SMTP.