Отлаживаю html-верстку чужого проекта, созданную до появления Firefox 3. В коде часто встречаются ошибочные конструкции вида:

<a href="#">
<div>Hello, bugs!</div>
</a>

CSS я из примера изъял, но и без него подобный код в Firefox 3 даст результат, который вряд ли понравится заказчику. Клик по такой ссылке приводит к появлению двух точек в левом нижнем и левом верхнем углу (это легко проверить на пустом документе):



Иногда такие конструкции ошибочно применяются для создания кнопок из ссылок. Firefox 2 по умолчанию эту ошибку прощает — а Firefox 3 уже нет. Чтобы избежать этой ошибки, не нужно помещать div внутрь тэга a, нужно вместо этого присвоить свойство display:block стилю самого тэга a. Блочные элементы (div) внутри строковых (а) — невалидны.

Update: в этом вопросе и сам Гугл не без греха (спасибо, uratsakidogi)

Т.к. Google Chrome умеет сохранять ярлыки к приложениям и запускать их без браузерной обвязки, решил сделать для себя небольшое приложеньице-калькулятор. Выглядит оно так:

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

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

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

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

<?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')
*     ));
*/

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

Я не буду вдаваться в подробности распределения нагрузки, а отпишу лишь основные правила при соблюдении которых Ваша CMS будет легко масштабироваться.

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

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

Введение

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

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

С появлением и развитием memcached-подобных систем в архитектурах веб-приложений появилось еще одно звено, а именно кеш-серверы. Обычно это машины с большим объемом оперативной памяти, в которой хранятся заранее подготовленные данные. Это могут быть результаты сложных запросов к БД или же отрендеренные динамические части страниц сайта. На самом деле, кеш, как и любая другая система, может использоваться как угодно, чтобы удовлетворить нужды приложения.

Подборочка ошибок начинающих PHP разработчиков…

Часто при составлении сайтов с каталогами нам приходится оперировать с однотипными карточками каталога. Рассмотрим пример:
У нас имеется каталог СТО которые оказывают различные услуги клиентам. Есть предопределенный список услуг, среди которых производится выбор. Список услуг представляет собой набор чекбоксов, если услуга оказывается то чекбокс помечается, в противоположном случае отметка не ставится. Предположим количество услуг в каталоге равняется десяти(просто для определенности).
Самым простым способом было бы хранение состояния каждого чекбокса в отдельном поле, однако при этом мы для каждой новой услуги(которая будет указываться на сайте и учавствовать в поиске) будем вынуждены расширять таблицу, и изменять поиск.
Но мы пойдем другим путем.

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



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

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

Я смотрю для общественности прошло незамеченным такое событие, как обновление Firebug-Lite до качественно нового уровня. Теперь мы имеем аналогичное FF FireBug средство в Opere, Safari и возрадуйтесь — в IE.

Наткнулся на очень интересный вариант решения очень популярной проблемы многих веб-мастеров — закругление блоков.
Для этого варианта закругления используются VML и CSS3.

Решение без картинок, работает во всех Internet Explorer’ах включая 5ый, в Firefox, в Safari, но к сожалению в старых версиях Opera не работает.

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

На помощь приходит замечательный скрипт «Masked Input Plugin», который позволяет назначить для каждой формы маску, по которой данные будут заполнятся.

Возможно Вы не совсем поняли, но лучше один раз увидеть, чем сто раз услышать.

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

Что и как и как много хранит MySQL?

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

Для затравки, интересная цитата из мануала по MySQL:
«Максимальный размер записи в MyISAM составляет 65534 байтов. Каждый BLOB или TEXT-столбец засчитывается здесь как 5-9 байтов.» — как это трактовать однозначно не понятно. НО ясно что много-примного столбцов в таблицу на засунешь. «Извращенистые программисты» — будьте аккуратны (66000 столбцов вы точно создать не сможете).

UPD: Если найдете ошибку, или я что-то где-то утаил — отпишитесь в комментах, с удовольствием добавлю.

UPD1 В первую очередь (и самый лучший вариант для новичков) прочитать ОФИЦИАЛЬНЫЙ МАНУАЛ dev.mysql.com/doc/refman/5.0/en/data-types.html (спасибо Psyh за прямую ссылку), а здесь вырезка для META обработчиков данных (как в лице программистов так и в лице машинной обработки).

UPD2 В принципе, все что написано ниже, можно прочитать по адресу www.mysql.ru/docs/man/Column_types.html (за ссылку «русского перевода», спасибо artuska).

UPD3 Еще одну неплохую ссылку предоставил 4all: newcontinent.ru/h/mysqlc (материал на русском)

UPD4 Цитата из комментов от egorF:
# 14«Как главный редактор русскоязычного перевода доки на MySQL, я рекомендую в него не заглядывать — он уже сказочно морально устарел.»

Здравствуйте уважаемые хабралюди, хабрасообщество и сочувствующие, на вас одна надежда.
Сей порыв связан с моим отчаяньем, ибо уже как 2 месяца выбираю CMS для студии. И о ужас! Ничего не могу найти достойного.
Суть следующая. Я среднестатистической руководитель проектов, среднестатистической российской региональной веб студии. До поры до времени сидели на своей CMS и худо бедно справлялись. А в один прекрасный день я понял, что она абсолютно не годится по ряду причин, не буду в них углубляться, но суть в том что система собрана на коленках и на что-то серьезное пускать ее – смерти подобно.
И тут настало время Ч. Время выбора достойной CMS, коммерческой или некоммерческой не важно.

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