Используя symfony с ORM Doctrine, возникла необходимость проверки e-mail'a в форме, но обычного sfValidatorEmail не достаточно, т.к. если в модели данных Doctrine поле email объявлено с валидатором «email: true» оно проверяется самой Doctrine на наличие MX-записи домена и если ее нет — выбрасывает эксепшн. Согласитесь, это не красиво(: Пользователь вводит регистрационные данные и фейковый почтовый адрес, удовлетворяющий шаблону, и получает в ответ «500 Inernal Server Error».

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

Встречаем Fugue Icons 1.4.1 (лицензия, скачать)

Fugue Icons 1.2.5

Да-да, теперь это не "1000 замечательных иконок для веб страниц" а целых 1,263 иконок. Многие иконки были перерисованы и много добавилось новых. Появились такие востребованные иконки как user или иконки элементов интерфейса: «button, checkbox, slider» и т.д. В общем обновление шикарное, хотя до сих пор нету таких иконок как cut, copy и paste. Иконки по прежнему распространяются по лицензии Creative Commons Attribution 3.0 license а для вопросов: «Зачем кнопка purchase?» читаем это.

Прямая ссылка — 4,9Мб
Набор разработчика 7,6Мб
Пред просмотр — 1980px × 2263px 1,4Мб
Сайт

P.S. Предыдущий пост был написан давно и я решил написать новый чтобы привлечь внимание этому сету, а не использовал UPD.

UPD: Фугия снова обновилась. Теперь версия 1.2.5, вот изменения:

• Обновлена <application_table>
• Обновлена <document_excel_table> и <document_table>
• Добавлена <door_open>
• Добавлена <feed_document>
• Обновлена <folder_open_table>
• Обновлена <inbox_table>
• Обновлена <mail_open_table>
• Добавлена <server*>
• Обновлена <table*> and <tables*>
• Добавлена <traffic_light*>

Следите за обновлениями топика

Сервис userfly даёт возможность визуально посмотреть, что и как делал пользователь на вашей странице.
Пока все это в разработке и видимо еще много чего нужно сделать, но основу уже можно попробывать

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

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

Людям нужны мнения других людей о… о их поступках, деяниях, мыслях. Конкретизирую на банальном примере — допустим Вы сняли клип. Вы показали его друзьям, родственникам, и? И все… слишком маленькая аудитория получается. Ваши дальнейшие действия? Правильно, выкладываете клип в интернет и дальше уже выслушиваете мнения других (посторонних) людей. Пример номер два — Вы хотите, что либо сотворить (например «стартап», в котором люди смогут высказывать свои мнения по поводу чего-либо) опять же, вы не решаетесь незамедлительно приступать к реализации, так как Вам нужно послушать мнения других людей. И еще миллион примеров можно привести, где людям требуется услышать (увидеть, прочитать) мнение других людей. Очень много в жизни (в том числе и в интернете) крутиться вокруг мнений. Даже, когда Вы написали классный модуль к jQuery и выкладываете его, в его «выкладке» на 70% нужно сказать спасибо желанию человека услышать мнение об этом плагине. И так стартап…

Некоторые статьи вызывают оживлённые дискусии с сотнями коментариев, ветки которых занимают по два экрана на 1280х1024.

Например, вот на этом снимке экрана легко запутаться в уровнях коментариев.

Мне хотелось чтобы дерево коментариев было оснащено такими вертикальными линиями с минусиками к которым мы привыкли во многих современных редакторах. И я это сделал на выходных.

Сравните со снимком экрана после.

На хабре часто обсуждаются принципы работы MySQL. Данный хабратопик посвящен механизмам блокировок, используемым в MySQL. Топик поможет начинающим изучать MySQL и, в некоторой степени, опытным хабралюдям.

Механизм блокирования в MySQL

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

Существуют моменты когда необходимо предоставить пользователям выбор цвета какой либо вещи. Есть несколько способов выхода из этой ситуации.

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

В профиле наиболее активных пользователей Хабра появился блок отражающий интерес человека к определённым авторам публикаций. Чем больше ник — тем больше интерес (всё как в стандартном облаке тегов).


Одновременно с этой замечательной штуковиной претерпел изменения блок «Профиль внимания». Помимо укороченного названия (раньше оно было столь длинно, что я его даже не смог запомнить) был усовершенствован алгоритм построения.

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

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

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

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

Думаю у многих возникала необходимость хранить файлы, связанные с записью в таблице. Это может быть картинка к новости, аватар, загруженный пользователем файл — да все, что угодно. Обычно в этому случае поступают просто — файл ложится в файловую систему, а ссылка на него — в запись БД.
Но у такого классического похода множество недостатков:

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

Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы:

Привет.

Наверное, многие из вас пользовались стандартными javascript-виджетами, написанными как безвестными разработчиками, так и крепкими профессионалами, так и гуру. Есть великолепные коллекции виджетов, поставляемых в качестве плагинов к известным фреймворкам (вроде jQuery, Prototype JS, YUI), так и целые фреймворки, акцентирующие свое внимание на создании виджетов, вроде Ext JS или qooXdoo.

Но что, если вы не хотите использовать достаточно объемный фреймворк для создания простого диалогового окна, или хотите разобраться в том, как создаются такие виджеты, или даже разрабатываете собственный фреймворк?

Об этом и пойдет речь в сегодняшнем посте — как сделать простейшее диалоговое окно и alert средствами чистого javascript, без применения каких-либо фреймворков.

В этом посте речь пойдет о работе РНР5 с multibyte строками посредством preg_*() функций.

Заметил интересное положение дел, вобщем-то давным давно описанное в интернете, но актуальное и по сей день (вопрос всплыл всвязи с недавним постом про trim()).

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

Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

Это вторая часть перевода. Начинать прочтение лучше с первой.

Итак, после применения описанных в первой части методов, мы можем прекратить волноваться? К сожалению, нет. То, какие расширения файла будут переданы транслятору PHP, будет зависеть от конфигурации сервера. Разработчик часто не знает и не контролирует конфигурацию веб-сервера. Мы видели веб-серверы, с такой конфигурацией, что файлы .html и .js выполнялись как php. Некоторые веб-приложения могут потребовать, чтобы файлы .gif или .jpeg интерпретировались PHP (это часто случается, когда изображения, например графы и диаграммы, динамически строятся на сервере самим PHP).

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

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

Различные веб-приложения позволяют пользователям загружать файлы. Форумы позволяют пользователям загружать «аватары». Фотогалереи позволяют загружать фотографии. Социальные сети предоставляют возможности по загрузке изображений, видео, и т.д. Блоги позволяют загружать опять же аватарки и/или изображения.

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

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

Site Helper(SH) – тулза для помощи верстальщикам, а также хороший инструмент для общения верстальщик-программер-руководитель, а так же руководитель-клиент «не отходя от сайта» незаметно для обычных пользователей и в реальном режиме времени.

Наверное, каждый, кто хотя бы разверстал пиксель в пиксель под каждый браузер, сталкивался с ситуацией, когда что-то едет, не совпадают высоты ширины блоков… ситуация знакомая.
Тут может спасти PixelPerfect или сетка разметки на js или SH ;)

Ещё очень распространенная ситуация, когда заказчик или тестер нашел баг и не может понятно объяснить, где он находится. Ну, или заказчик решил добавить блок баннеров и также не может внятно объяснить, что и куда.

длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный код в тэге <pre> заползает на правую колонку

Чинится очень просто:

pre {
    white-space: pre-wrap; /* Последние Opera, Firefox, Safari, Chrome*/
    white-space: -o-pre-wrap; /* Старая Opera (8?) */
    word-wrap: break-word; /* IE 5.5+ */
}

А тем временем, баг с широкими картинками был исправлен в CSS самого Хабра. Теперь нет нужды в UserCSS.

Обновлено: Баг исправлен. Рад видеть, что мои замечания не пропадают даром.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3, 4 и 5.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей и тэгировании кэшей.

Сегодняшний пост завершает эту серию, в нём обзорно мы поговорим о технических “мелочах”:

• анализ статистики memcached;
• отладка memcached;
• “RPC” с помощью memcached.

Полный текст всех разделов в виде одной большой PDF-ки можно скачать и посмотреть здесь (в разделе “Материалы”).