Не так давно при разработке своего проекта возникла идея реализовать полноценные коллекции для хранения объектов одинакового типа, по удобству напоминающие List<Type> в C#.
Идея состоит в том, чтобы коллекции, содержащие объекты различных типов сами по себе различались, а не имели, скажем, один унифицированный тип Collection. Другими словами, коллекция объектов типа User это не то же что коллекция объектов Book. Естественно, первой мыслью было создание различных классов для коллекций (UserCollection, BookCollection, …). Но данных подход не обеспечивает нужной гибкости, плюс ко всему, нужно тратить время на объявление каждого подобного класса.
Немного поразмыслив, реализовал динамическое создание классов коллекций. Выглядит это так: пользователь создаёт коллекцию объектов типа Book, а нужный тип BookCollection создаётся (т.е. объявляется) автоматически.

Вот и продолжение первой части, много времени прошло, и вот… здесь я, как и обещал, расскажу поподробней об основных типах. Для начала пара замечаний, первая часть не прошла естественно без критики, так что вступление будет 'работой над ошибками'. В дальнейшем такие работы над ошибками буду вставлять регулярно, и надеюсь хабралюди этому посодействуют…

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

Тактика пропаганды нашей платформы

1. Мы миролюбивы и уважаем другие технологии;
2. Мы проводим различие между разработчиками конкурирующей платформы и ее пользователями;
3. Мы никогда не конкурировали с конкурирующей платформой (парадокс? да);
4. Мы помогаем пользователям конкурирующей платформы в битве за стандарты и открытое ПО вместе с нашими конкурентами;
5. Мы помогаем пользователям ПО, несовместимого с нашим;
6. Мы отдали в Open Source множество своих технологий.
7. Мы предоставили свою технологию для реализации ее на всех операционных системах;
8. Любовь к качеству во всем мы разделяем с нашими конкурентами;
9. Наши и ваши технологии велики, и мы уверены в будущем;
10. У нас общий дух пионеров Web2.0;
11. Нашими технологиями уже пользуются многие разработчики, которые оказывают влияние на развитие нашей платформы;
12. Творчество дизайнеров и продукты опенсорс-сообщества (в т. ч. пользователей Линукса) широко используются в наших решениях. Многие наши разработчики вышли из конкурирующего сообщества;
13. Книги приверженцев конкурирующей платформы популярны в нашей компании и среди наших пользователей. У нас изучают изучают их языки. Примечание: нужно рецензировать новые блоги авторитетных конкурентов и исследования по их технологии , даже если в них нет важного содержания;
14. Мы публично восхищаемся достижениями конкурирующей платформы и честно признаем ее преимущества;
15. Мы помогаем всем пользователям и разработчикам, независимо от того, согласны ли они с нашей концепцией;
16. Мы используем паттерны программирования, и не скрываем, что основной вклад в их развитие положен сообществом Open-Source;
17. Наши руководители, начальники отделов и многие частные разработчики пытались установить культурный и технический обмен с конкурирующей технологией;
18. О нашей сущности и сущности свободного мира, основных идеалах, которые мы разделяем с пользователями конкурирующей технологии, дают представление ключевые труды по программированию: Вирт, GoF, Хотя некоторые из этих книг принадлежат к направлению «социального протеста», они показывают веру в социальный прогресс в действии.

Первая часть: Памятка евангелиста-I.

Примечание: текст обеих частей отредактирован. Устранены двусмысленные формулировки и фрагменты, не относящееся к этике профессионального общения.

Сегодня хорошо отлаженная работа коллектива студии позволяет легко браться за реализацию проектов Заказчиков из соседних регионов. К примеру ваша студия работает активно в Днепропетровске, но при этом не составляет труда встречаться с заказчиками из соседних городов — Запорожья или Донецка. Профессионалы, они и в Африке смогут работать. При этом не всегда экономически обоснованно брать офис в аренду, так как сразу прибавляются расходы по покупке мебели, техники итд.

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

Задача

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

Каждая веб-студия имеет собственные приемы и «фишки» при работе с заказчиком, которые позволяют ей минимизировать риски при разработке интернет-проекта и снижать издержки на каждом этапе работы. По роду своей деятельности в Юмисофт я часто общаюсь с владельцами веб-студий, и вот сейчас у меня наконец дошли руки, чтобы поделиться некоторыми интересными рецептами, услышанными в неформальных беседах. Надеюсь, они будут вам полезны :)

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

Для всех любителей панорамной фотографии, картографии, гигантских рисунков и просто вселенского размера изображений открывается новый сервис фотохостинга.

PS: сервис на стадии тестирования, возможны глюки. Радуйтесь, gluck — это счастье!
PPS: новые фичи будут добавляться по запросу пользователей, но общий дизайн будет оставаться минималистичным.
PPPS: пока что ограничение на размер изображения — 100мб и 20000px в ширину. Объем аккаунта — 100мб

Сегодня довольно мало информации о протоколе AMQP (Advanced Message Queueing Protocol) и его применении, особенно на русском языке. А вообще это — замечательный, уже достаточно широко поддерживаемый открытый протокол для передачи сообщений между компонентами системы с низкой задержкой и на высокой скорости. При этом семантика обмена сообщениями настраивается под нужды конкретного проекта. Такие решения существовали и ранее, но это первый стандарт, для которого существует большое количество свободных реализаций.

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

Сегодня тема доставки информации в реальном времени является крайне актуальной (достаточно вспомнить хотя бы Twitter, Google Wave). И здесь системы передачи сообщений могут служить внутренним механизмом обмена данными, который обеспечивает доставку данных (изменений данных) клиентам.

Я не ставлю своей целью сегодня рассказать о том, как писать приложения для AMQP. Хочу лишь немного рассказать о том, что это совсем не страшно, не очень сложно, и действительно работает, хотя стандарт находится еще в развитии, выходят новые версии протокола, брокеров и т.п. Но это уже вполне production-quality. Расскажу лишь базовые советы, чтобы помочь “въехать” в протокол.

Что может быть лучше, чем описание девяти классных фишек App Engine? Разумеется, описание десяти. Участвуя в обсуждениях в группах, мы заметили, что некоторые возможности App Engine часто остаются незамеченными, так что мы выбрали чуть меньше, чем одиннадцать интересных фактов, которые, возможно, просто позволят вам писать программы по другому. Но довольно слов, смотрим первую фишку:

Выход ZF 1.8 порадовал нас несколькими новыми (а главное очень полезными) компонентами. В этой статье я хочу рассказать о практике использования Zend_Navigation для построения меню сайта, карты сайта, хлебных крошек. Особое внимание уделю использованию Zend_Navigation в связке с Zend_Acl.

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

Ревизия кода это действительно полезная, но в то же время и невероятно отпугивающая процедура. Эта статья подскажет, как избежать «кулачных боёв» при проведении ревизий.

Мы кратко рассмотрим, почему следует проводить ревизии кода, и сделаем упор на вопросе, как складываются при этом взаимоотношения участников процесса, в особенности в проектах с открытым исходным кодом. Действительно, отчасти open source привлекает (а порой наоборот отпугивает!) людей именно потому, что ваш код будут просматривать эксперты со всего земного шара. Мы также рассмотрим влияние, оказываемое некоторыми существующими технологиями на культуру ревизий кода, рассмотрим, чего можно достичь с их помощью, и как проводятся ревизии в других сферах деятельности. Мы также обозначим некоторые «подводные камни» ревизий, которые легко не заметить.

Продолжение, начало в Части 1

Я не встречал хорошего описания паттерна Dependency Injection применительно к PHP.

Недавно ребята из Symfony выпустили свой контейнер DI, снабдив его подробной и хорошей книжкой о том как работать с этим паттерном.

Я вспомнил еще об одной библиотеке для DI, Phemto. Ее автор, — Маркус Бэйкер, создатель SimpleTest. К сожалению на сайте содержится краткая и невнятная справка. тем не менее, проект развиавется, а внутри дистрибутива лежит статья с крайне хорошим объяснением про DI, ну и руководством конечно. Phemto, — очень миниатюрный проект, состоящий из трех не очень больших файлов.

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

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

Простой сервис для создания одноразовых страниц в Интернете.

"dinky" (англ.) – маленький, пустяковый.

Бывает необходимо опубликовать что-то онлайн, но доступа к своему сайту/блогу нет под рукой (или самого сайта/блога нет). Данный сервис решает эту проблему.

Другой пример – хочется поделиться с друзьями чем-то интересным, но 140 символов Твиттера для этого не хватает. Создаем страницу, пишем интересное и кидаем в твиттер ссылку на нее.

А еще часто бывает – хочется попробовать что-то в Javascript, но лень создавать новый файл, копировать правильный doctype, писать базовые стили и т. д. Создаем новую страницу через dinky page и там все пробуем.

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

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

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

Вношу свои 5 копеек в проблему скругления уголков. Хочу предложить метод, который не революционный, а просто несколько усовершенствует другой.

Многие знакомы с методом скругления уголков средствами CSS, который активно использует Гугл. Я лично познакомился с ним на сайте Шторкин.ру.

Метод сделан на чистом CSS, без картинок, без JS, полностью кроссбраузерный. Он спокойно тянется в ширину и высоту. Единственный его недостаток: отсутствие сглаженности (алиасинг). В принципе, все вполне поправимо.

Часто ли вы используете регулярные выражения? Задумываетесь ли вы о том, на сколько оправдано их использование? Каковы альтернативы, каковы возможности и ограничения? Какова цена применения регекспа?

Я уже давно и часто замечаю, что люди (особенно из мира Perl) склонны мистифицировать регулярные выражения, наделяя их (в своём сознании) универсальными сверх-способностями.

Настоящей статьёй, я призываю одуматься задуматься.

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

Обновленно:

• В конце статьи есть так же некоторая информация о том как можно отметить сие славное событие в Мюнхене.

Задача

Задача такая же как и в предыдущей статье, только применимо к MySQL.

Грабли

Хорошая новость ребята! В MySQL нет проблемы с рекурсивными триггерами! Разработчики MySQL просто тупо лочат изменяемую таблицу даже на уровне триггера, вот редиски. Но, собственно, нас может остановить только отключение электричества.
Есть небольшая лазейка, с… объединенными таблицами. Хотя я не нашел в документации подтверждения того, что это так специально было задумано, но и отрицания тоже не было. Правда есть вероятность того, что эту лазейку могут прикрыть, хотя я не вижу в этом смысла.
Увы, механизм триггеров в MySQL новый и довольно сырой, что накладывает некоторые ограничения на его использование, но все же его достаточно для решения нашей задачи.