По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

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

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

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

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

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

Выражения — это краеугольный камень PHP. Почти все, что вы пишете в PHP, является выражением. Самое простое и точное определение выражения — «все что угодно, имеющее значение». (с сайта php.net)

UPD: Статья только о том, как МОЖНО делать в некоторых случаях, когда это оправданно. В большинстве случаях (и тем более повсеместно) описанную практику применять не стоит ни в коем случае, так как она сильно усложняет код. Цель статьи — расказать о возможностях языка, не более того.

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

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

Конечно, позже состояние дел изменилось — появились эффекты для динамических интерфейсов, поддерживаемые такими JS-библиотеками, как Prototype, Scriptaculous, Moo, YUI, MochiKit (и этот список можно продолжить). Сейчас самое время (через 4 года) вспомнить технику CSS Sprites и посмотреть, сможем ли мы добавить в неё «немного динамики».

Часто ли вам приходилось сожалеть о том, что в PHP нет перечислений как таковых?

Да, кто-то обходился конвенцией именования и получалось нечто вроде:

define( 'COLOR_RED', 'F00' );
define( 'COLOR_GREEN', '0F0' );
define( 'COLOR_BLUE', '00F' );

Или нечто вроде:

// данную переменную ЗАПРЕЩЕНО модифицировать
$colors = array(
    'red' => 'F00',
    'green' => '0F0',
    'blue' => '00F',
);

Но оба подхода имеют существенные недостатки:

• В первом случае члены перечисления не образуют явной группировки
• Во втором случае есть риск что переменная будет изменена
• И в обоих этих случаях мы не можем делать проверку на тип переменной (type hinting)

Под катом предлагаю решение без вышеописанных недостатков…

Как я уже писал, я начал читать книгу «jQuery in Action» (авторы Bear Bibeault и Yehuda Katz). В данной серии статей (а я планирую довести дело до конца) я буду выкладывать самые интересные моменты из каждой главы этой книги. Это будут основные идеи, примеры или и то и другое вместе :-)

Существует куча платных\бесплатных визуальных редакторов на любой вкус и цвет. Но что, если они работают не во всех браузерах, Вас не устраивает дизайн или функциональность, или просто душа лежит к написанию своего собственного? Ответ на вопрос, как это сделать —

<?php

/**
* Пример реализации Generic-класса
*
* Возможности:
* 1. Осуществляет доступ к параметрам класса через методы get* set* (accessors/mutators)
*     Пример: $object->setName('Dima'); $object->getName();
*     При изменении стандартного поведения метода (добавление дополнительной логики)
*     можно просто определить его в классе при этом не изменяя интерфейс класса.
* 2. Поддерживает встроенную валидацию данных с возможностью использовать или заранее
*     определенные типы данных (numeric, string, email, date и др.)
*     или регулярные выражения.
* 3. Имплементирует паттерн Lazy initialization для инициализации объектов.
*     Позволяет загружать параметры объекта из БД (например) не сразу при инициализации,
*     а только при первом запросе.
*
* Видимые недостатки:
* 1. Отсутствует возможность использовать автокомплит в IDE, так как методы явно не определены
*
* Плюсы:
* 1. Позволяет избежать дублирования кода при определении однотипных методов set и get
* 2. Сокращает код классов и централизует управление параметрами
* 3. При необходимости можно расширить функциональность. Например, добавив callback функции
*     или принудительную фильтрацию данных.
* 4. Избавляет от рутинных обязанностей проверки входящих данных, тем самым
*     обеспечивая некоторый уровень безопасности.
*     Это совсем не дает 100% гарантии — не стоит забывать об этом.
* 5. Не вносит коррективы в интерфейс классов. Можно легко сочетать обычные классы и классы
*     наследующие GenericObject без видимых различий для клиентов класса. При необходимости
*     можно легко отказаться от использования просто переопределив все гетеры и сетеры.
* 6. Упрощает работу с классами, предоставляя удобный и естественный способ
*     инициализации объектов:
*     $obj1 = new Class(123);
*     $obj2 = new Class(array(
*         'param1' => 'value1',
*         'param2' => 'value2')
*     ));
*/

Доброго времени суток.
Это мой первый серьезный пост на Хабре, так что критика приветствуется.
Сегодня я расскажу о написании плагина для JavaScript-библиотеки MooTools на примере модального всплывающего окна.

Предисловие

В этом руководстве Вы узнаете, как построить простую систему по архитектуре MVC (Model-View-Controller, Модель-Отображение-Контроллер) на PHP 5.1 с использованием возможностей библиотеки SPL (Standard PHP Library, Стандартная Библиотека PHP).

Как-то я видел забавный дизайн с обезьяной, позади которой очень занимательный фон который динамически менялся при изменении размера окна брузера.

Это достигалось за счет движения нескольких параллельных слоев.

Данная статья рассматривает одну из проблем хранения PHP-сессий в memcached: отсутствие их блокировки.

Введение

Ни для кого не секрет, что одним из самых популярных способов повышения производительности сайта является использование memcached. Об этом неоднократно говорили и приводили многочисленные примеры. Самый простой способ сделать это — использовать memcached для хранения сессий PHP. Для этого нет необходимости переписывать весь код, достаточно нескольких простых действий. Я не буду рассказывать, почему надо хранить сессии в memcached. Я расскажу о том, почему хранение сессий в memcached опасно.

Возникло странное вечернее желание написать и описать те программы, которые я использую повседневно для вёрстки/правки и написания всего, что связано с веб-проектами. Хотелось, помимо стандартного перечня, вкратце описать, что то или иное «это-самое» делает, и почему я использую именно его. Возможно, кому-то будет полезно.

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

Большинство современных обзоров jQuery делают упор на дизайнеров и неопытных разработчиков. Я попытаюсь объяснить, почему она также нужна и опытным программистам.

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…

Даже такой скучной штукой, как облако тегов, можно развеселить и привлечь к себе на блог читателей. Так решил некий Roy Tanck и написал плагин к WordPress, который назвал — WP-Cumulus. Суть плагина в том, чтобы выводить облако тегов, но делать это немного в непривычной форме.

Наша маленькая но очень гордая компания взяла на обучение нового человека. Мы хотим сделать его матерым жаваскриптером. Воспитание и обучение легло целиком на мои плечи поскольку опыта по JS у меня больше прочих.

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

На практике работа этого человека будет состоять в поддержку оптимизации и развитии толстого JS-клиента. Т.е. там необходимы знания дома, объектной модели жаваскрипта и подобных штук.

А посему вопрос — что можно посоветовать почитать дабы человек мог быстро въехать в продвинутый жаваскрипт? По большому счету требуется передать именно саму идею реализации богатых клиентов на нем. Про подводные камни и всякие несуразности я думаю смогу что-то рассказать исходя из своего опыта.

Как-то изучая портфолио одной хорошей украинской студии, Psyho, нашел очень интересный проект.



builder-club.com — социальная строительная сеть, выполненая на высоком профессиональном уровне. Я бы поставил ее в один ряд с такими тематическими сетями, как LookAtMe, Habrahabr, Autokadabra и Dribbler.

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

Я сам не имею отношения к строительству, но сайт — пример того, как можно (нужно? :) создавать тематические социальные медиа. Кроме того, некоторые статьи (как одна из последних — "Японский сад камней — философия, назначение, устройство") действительно интересно читать :-).

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