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

Проблема очевидна. Нужен способ облегчить работу с префиксами.

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

В предыдущей статье на примере создания объектной модели простого сайта производились одиночные загрузки сущностей из базы данных по их идентификаторам конструкцией Object::Create($id), при этом мы знали, у какой сущности (чаще всего класса), какой идентификатор, так как сами создавали эти сущности и в крайнем случаи могли просто заглянуть в базу данных. На практике загружать сущности по идентификатору проблематично, если нас интересуют сущности, о существовании которых можно только догадываться, то есть, не имея информации об их идентификаторах. Более того существует необходимость загружать несколько сущностей разом, отвечающих некоторым условиям.

В магазине, например, мы не выбираем товар по его серийному номеру или штрих-коду, не зная при этом, что он означает – мы смотрим на свойства товара интересующие нас. На главной странице сайта, опять же для примера, необходимо выводить последние новости, что сводится к выборке из базы данных (объектной модели данных) 10 объектов класса «Новость» с сортировкой по дате их создания. Для осуществления подобных запросов необходим гибкий способ описания условий выборки сущностей – условий поиска с учетом особенностей объектной модели. На основе условия необходимо создавать SQL код для непосредственной выборки из БД идентификаторов сущностей удовлетворяющих условию, имеем идентификаторы – имеем сущности.

Продолжаем тему объектной модели данных. В этой части речь пойдет о модуле Data, являющимся, по сути, ORM системой. Для наглядности работы модуля Data c его помощью будет создано содержимое простого сайта. Предыдущая статья: Архитектура CMS. Модель данных. Часть 1.

Модуль Data состоит из классов Data, Object, Multy, Query и набора классов Cond*. Сам модуль – это статический класс Data, остальные классы используются для представления структур данных, с которыми он работает. Для представления сущностей в программном коде используется класс Object. Не важно, какого типа сущность – класс данных, объект данных или связь между ними – для всех Object. Класс Multy используется для ассоциации с набором сущностей, в частности, для представления множественных свойств. Классы Query и Cond* необходимы для осуществления поиска по объектной модели (в базе данных) с учетом гибких условий.

Система управления содержимым (CMS) обязана предоставить гибкие всеохватывающие функциональные возможности для управления содержимым сайта, облегчить работу администратора-конфигуратора и способствовать созданию удобного в использовании сайта. Содержимым сайта можно назвать новости, размещенные на нём, а также статьи, комментарии, фотографии. Содержимым также являются целые структуры информации: новостные ленты, каталоги, форумы, блоги. Обобщенно: содержимое – это данные, размещенные на сайте.

CMS может просто передавать данные по запросу клиентскому приложению, например сетевой программе, flash-клипу или AJAX-приложению. Но чаще всего, CMS предоставляет клиенту уже подготовленные для отображения данные в HTML формате. В этом случаи, для обеспечения доступности, легкости восприятия и удобства пользования содержимым, выполняется стилизация и объединение его с элементами оформления (темы, шаблоны), навигации (меню, ссылки) и управления (формы и ссылки тоже), и всем этим тоже нужно управлять.

Идея

Окружающий мир воспринимается нами объектным, мы мыслим «объектами», в наших умах выстраивается объектная модель мира. Поэтому нам не составит труда создать объектную модель содержимого сайта и управлять ею. Новости, товар в каталоге, сообщения на форуме и сами форумы, и все другое можно представить в виде объектов. Устанавливая связи между объектами, можно создавать структуры данных любой сложности, от добавления комментариев к статьям до создания социальных сетей и более.

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

Как показывает независимое исследование, около 67 процентов Web-разработчиков на Хабрахабре пишут свои CMS. За свою жизнь ваш покорный слуга написал около пяти-шести CMS-велосипедов, и в процессе работы была с жадностью перерыта масса информации о структуре и принципах работы других CMS, а также придумано несколько своих. Мир CMS полон разнообразных модулей, расширений, компонентов, компонент, плагинов. О том, как разработчики CMS позволяют расширять функционал, и какие термины для этого используются, я и хочу рассказать. Сразу предупреждаю, что нижеследующая информация может и запутать, поэтому термины, которые в контексте разных CMS имеют разные значения, несут в скобках номер, указывающий на то или иное значение. Некоторые принципы, изложенные здесь, могут заставить сморщиться кого-либо. В списке, в основном, перечислен функционал, расширяющий систему. Синтаксис, используемый в примерах, в большинстве случаев выдуман.
Надеюсь, список поможет с организацией принципов работы собственных CMS, подкинет идею или просто заинтересует. Те, кому скучно, могут попробовать угадать, какая именно CMS имелась в виду в каждом конкретном случае (дабы избежать холивара, названия CMS в самом списке не используются, да и в конкретных случах термины могут содержать несколько иное значение).

Есть много разных движков на PHP, от достаточно простых, до очень тяжеловесных и громоздих, включающих практически все.

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

Навеяло вчерашним ночным разговором в асе с одним недопрограммистом. Узнав, что я использую в своих проектах codeigniter, он усомнился в моем профессионализме… И, насколько я понимаю, это не только его мнение, многие не признают framework’и, и скажу вам, что это не от большого ума! Взять например windows-программистов, почему им некто не советует писать на чистом паскале, вместо Delphi, и как так получилось что си-шники используют visual studio? Сегодня я расскажу тебе о пользе php- framework’ов, на примере любимого мною codeigniter’а, выделю основные достоинства такого метода программирования, расскажу о том, насколько легко его изучить, и покажу где почитать подробнее.

Думаю, никому не надо рассказывать, что такое ЧПУ. В интернетах хватает евангелистов-фетишистов, ратующих за человеко-понятность в урлах.

При желании, ознакомиться с основной идеей можно, например, в Википедии.

Я же попробую уточнить и несколько доосмыслить эту идею.

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Вы наконец-то можете сделать кое-что со своим старым LCD монитором, который завалялся у Вас в гараже. Превратите его в шпионский монитор! Для всех вокруг он будет выглядеть просто белым экраном, но не для Вас, потому что у Вас будут специальные «волшебные» очки.

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

Многие программисты почему-то считают, что исключения и ошибки — это одно и то же. Кто-то постоянно кидает exception, кто-то через errorHandler превращает ошибки в исключения. Некоторые пытаются увеличить производительность, используя исключения. Но, на самом деле, exception и ошибки — это совершенно разные механизмы. Не надо одним механизмом заменять другой. Они созданы для разных целей.

Когда появился php5 с исключениями, а затем ZendFramework, который всегда кидает исключения — я не мог понять: чем же exception лучше моего любимого trigger_error()? Долго думал, обсуждал с коллегами и разобрался в этом вопросе. Теперь я чётко знаю, где использовать trigger_error(), а где throw new Exception().

В чём же принципиальная разница между ними?

Задача

В общем, сложилась такая ситуация, что на предоставленном для проекта хостинге, версия PHP была 5.2, а сам проект написан под 5.3. Наверняка все, кто работает с PHP, знают, что в версии 5.3 появилась возможность доступа к имени класса, полученного с помощью позднего статического связывания.

Тема пришла из далекого детства, когда я только начинал программировать, разбирал особенности PHP. На тот момент меня удивляла такая несправедливость: c сессией можно было работать как с обычным ассоциативным массивом($_SESSION), а для кукисов необходимо было использовать функцию setcookie(). Потом я уже поднабрался опыта и понял зачем это сделано именно так.
Время идет и PHP не стоит на месте, в нем появилась такая прекрасная вещь как SPL, одна из возможностей которой — обращение к объекту как к массиву, т.е. реализация ArrayAccess интерфейса.
И вот сейчас я вспомнил о своей детской идее, о массиве $_COOKIE, и реализовал ее:

<?php
/*
достаточно этой строчки чтобы создать куку как на стороне сервера так и клиента
*/
$_COOKIE['lang'] = 'ru'; 

Реализацию можно посмотреть под катом

Привет, Хабражитель!

Многие люди мечтают научиться писать программы, игры, но не получается по многим причинам. Я, изначально, не хотел ничего писать потому что не было интересной платформы, и я был еще слишком маленьким. Потом все изменилось. Наступила новая эра в телефонной индустрии – появился iPhone. Я сразу, как о нем услышал, загорелся желанием его приобрести. Платформа сразу понравилась, кнопок и стилуса нет – самое то для игр.
Программы я начал писать в ноябре 2009, если их можно назвать программами :). Многие спрашивают как я учился – на видео-уроках с YouTube, а как еще? Читать непонятные уроки по iPhone SDK? В тот момент я загорелся идеей учить таких же как я – начал записывать видео на YouTube новым для меня темам.
Если интересно: http://bit.ly/pdyoutube. Потом все пошло и поехало, сам стал лучше программировать и запоминалось все намного лучше. Не буду писать очень длинное вступление – перейдем к самому интересному.

Всегда хотел делать игры, но на пустом Xcode не очень удобно и понятно. Стал выбирать платформу (фреймворк) для разработки игр под iPhone, iPad. Мой выбор остановился на Cocos2D. Многие спросят почему – он очень простой в использовании, очень! Он еще и бесплатный и часто обновляемый!

Вместо предисловия

Прошло уже 17 лет с тех пор, как вышла легендарная книга Банды Четырех, посвященная Паттернам проектирования (Design patterns). Несмотря на столь солидный срок, тяжело оспорить актуальность описанных в ней методик. Паттерны проектирования живут и развиваются. Их применяют, обсуждают, ругают и хвалят. К сожалению, для многих они до сих пор остаются излишней абстракцией.

Обсуждая разные вопросы программирования с коллегами как в жизни, так и на различных ресурсах, довольно часто приходится объяснять важность того или иного паттерна. Так и родилась идея на конкретных примерах показать, насколько их использование может облегчить жизнь программиста. Даже если речь идет о такой платформе, как iOS.

Данную статью хочу приурочить к одновременно выходу второй версии моего приложения Word Wizard и взятию новой отметки в $200 000 в Apple AppStore. Далее я постараюсь поделиться своим опытом и мыслями об образовательном рынке, а также рассказать свою историю успеха. Надеюсь что эта информация будет полезна многим независимым разработчикам. Для тех же кто создает образовательные продукты на платформе iOS моя статья даст возможность оценить рынок приложений в этой сфере.



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

Вчера разработанное нами приложение Coin Keeper заняло третье место в топе платных приложений русского AppStore.

Интересно то, что мы разрабатывали его не на привычном Objective C, а на C#, используя фреймворки Monotouch и Monodroid.

Внутри я бы хотел рассказать про архитектуру приложения, хитрости и удачные моменты. Кроме того я раздам 5 промокодов, тому кто сможет дать ценные комментарии по проекту.

Предыстория

Воодушевившись тем, что в недавном времени затарился i девайсами решил научится таки под них программировать. Конечно, в выбранном мной пути web разработчика это мало чем поможет, но мне всегда были интересны новые языки.

Первое на что упал мой взгляд- это виртуальная школа iTunesU. Здесь я нашел лекции курса CS 193P которые ведут разработчики эпл для студентов Стэнфордского университета. Лекции достаточно хорошо охватывают базовые особенности языка и нативных фрэймворков, однако есть одно НО– лекции на английском и никакого перевода к ним нету. Для меня лично проблем это не вызвало, потому что Aple по всей видимости выбирает на эти лекции только кандидатов с хорошо поставленной речью, и прожитые в США 8 месяцев дали мне возможность смотреть лекции в оригинале и учится у «носителей языка» (шучу-шуткую).

Так как каждый год выходит новая версия Xcode, а лекции стэнфорда в которых рассматривается именно текущая версия становятся доступны с опозданием в семестр, я решил написать серию статей, которые будут идти по практической части (!) данного курса. Так как я слушал лекции осени 2010 для меня будет практическт полезным написать программу в xcode 4.2 который был изначально разработан под 3ю версию. Здесь я не буду углублятся в особенности ObjC а буду давать голую практику.

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

Ни для кого не секрет, что бета-тестирование на смартфонах — довольно трудоемкий процесс, а уж на iPhone — и подавно. Все дело в его многоступенчатости: сперва пользователю нужно найти UDID своего устройства, затем отправить его разработчикам. Только после этих действий со стороны юзера его аппарат вносится в список зарегистрированных девайсов, а уж потом собирается рабочая версия и отсылается ему на почту письмо с просьбой об установке.

Почитав интервью создателей знаменитого бестселлера “Cut the Rope”, в котором утверждается, что на создание веревки ими было потрачено больше всего времени, я не поверил, что написать «алгоритм движения тяжелой нити» действительно так сложно, и для этого надо чуть ли не самим писать физический движок. Погуглив, готового ответа я не нашел, и решил попробовать сделать самостоятельно нечто подобное на cocos2D + Box2D.
За основу были взяты правила:

1. Цепь делать лучше с помощью прямоугольных тел, соединенных Revolute Joint’ами;
2. Чем тяжелее объекты составляющие цепь – тем она стабильнее;
3. Количество итераций при шаге – чем больше, тем лучше (мне хватило 3-х);
4. Очень помогает, если каждый кусочек цепи, помимо Revolute Joint’а соединить Distance Joint’ом.