Development - Страница 5

Adobe Dreamweaver CS3 vs Microsoft Expression Web 04/10/07

$Adobe Dreamweaver CS3 vs. Microsoft Expression Web\$

После нескольких месяцев параллельного использования Dreamweaver CS3 и MS Expression Web ответственно заявляю: Dreamweaver – мертв; Expression Web – жив. А Microsoft, соответственно, одержала еще одну победу! Напомню, что Adobe не так давно выпустила Dreamweaver CS3. Изменений и улучшений не много: интерфейс, шаблоны и расширения. Чего-то нового ждать не приходилось – версии Dreamweaver обновляются с завидной регулярностью, но все же обидно - все это мы уже видели еще в версии 6. И вот Microsoft выпустила Expression Web! Функции полностью копируют конкурента:

Режим редактирования WYSIWYG
Управление целым сайтом
Простое управление стилями
Создание шаблонов и страниц основанных на них.
Поддержка расширений и т.д.

Казалось бы, ни чего особенного, все это уже есть в продукте Adobe, но… Expression Web кажется более живым - именно живым! Стандартный и приятный интерфейс (похожий на интерфейс MS Office), понятные функции, а главное: современная работа со стилями! В настоящий момент, когда профессиональные страницы верстаются по стандартам XHTML, когда оптимизаторы и верстальщики манипулируют большим количеством стилей – грамотное и прозрачное управление ими крайне важно. Да и в MS Expression Web не все гладко, но удобство работы с ним отмечается сразу. Он какой-то в доску свой. Не даром MS так пестует свой UI.

Expression Web это один из продуктов новой линейки MS Expression для профессионального создании современных сайтов. Что станет с MS FronPage – скорее всего он останется WYSIWYG редактором для MS SharePoint. Expression Web напоминает переродившийся MS InterDev.

Политика MS брать чужие идеи и доводить их до ума снова работает. И меня поражает, как на протяжении такого долго времени MS удается проворачивать один и тот же фокус! Скажите кто-нибудь, в чем секрет MS? Почему она не костенеет?

Development | Комментарии [1]

Оптимизация больших PHP-приложений 05/07/07

Преждевременная оптимизация – корень всех бед.
– Дональд Кнут (Donald Knuth)

С другой стороны, мы не можем игнорировать эффективность.
– Йон Бентли (Jon Bentley)

Благодаря повсеместному распространению PHP5 (с его переработанным ОО ядром) у разработчиков появилась возможность и желание писать правильный ОО-код. У многих это даже превращается в самоцель. Книжек про паттерны и всех китов ООП написано много, приложения на PHP становятся огромными - берись и делай. Да и куда теперь без разделения логики, представления и доступа к данным. Получается, что с вопросами производительности разработчик сталкивается только в конце решения задачи в целом. И, как правило, ее начинает не хватать в сценариях по обработки тысячей записей.

Я хочу дать несколько полезных советов как писать более эффективный код в самом начале, помня, что PHP все же скриптовый процедурный язык. Советы я расцениваю ни как преждевременную оптимизацию, а как стандартную работающую рекомендацию уровня: «в С++ используйте префиксную форму инкремента». Большинство рекомендаций еще раз озвучивание общеизвестных вещей.

Общие рекоммендаци по оптимицации любых PHP:

Использовать стандартные функции и алгоритмы PHP, а не писать собственные алгоритмы (в PHP это прямо влияет на скорость.). Примеры:
1. Не перебирать ассоциативный массив руками если есть конструкция: foreach ($arr as $key => $val).
2. Не разбирать строки руками и не склеивать их если есть: implode/ join.
Использовать специальные библиотеки для работы с БД (например ) и прочим, а не писать собственные (cм. заключение). Это, как правило, эффективней и безопасней.

Специальные рекоммендаци по оптимицации бОльших PHP:

Если в цикле с тысячей итераций каждый раз объект создается заново ($obj = new Shape()) лучше вынести его создание на уровень выше, либо сделать его статическим, а в класс добавить метод сбрасывания содержимого.
Если функции передается больше 2-3 параметров или после создания объекта нужно установить множество внутренних полей следует обернуть необходимые данные в массив и разом передать функции/объекту:
```
$arr= array('FName' => $this->fName,
	    'LName' => $this->lName,
	    'Year' => $this->year)

$obj = new Person($arr);
```
Еще не проинициализированные переменные лучше устанавливать в false. Так их проще использовать в условных операторах.

Заключение

Здесь хочется еще раз остановиться на самых важных рекоммендация общего характера.

Только когда уверены на 200% что ваша библиотека/функции будут быстрее работать, с БД. И вам действительно необходим выигрыш производительности именно в этом месте – используйте свою разработку. Обязательно не забудьте использовать mysql_real_escape_string.
Не пытайтесь оптимизировать, то что как вам кажется работает медленно, но у вас нет точных тестовых результатов, либо данных профайлера.

Более подробно вопросы разработки больших систем с использованием ООП осещены в замечательной книге Джоржа Шлосснейгла "Профессиональное программирование на PHP" Вильямс, 2006 г.

Development | Комментарии [1]

Паттерны CSS 29/06/07

Каждый раз, когда мне нужно сверстать новую HTML-страницу (CSS-Layout, xHTML, кроссбраузность) я достаю старые наработки, удачные решения и специально сохраненные ссылки c примерами. Вспоминаю и отыскиваю подобные решения и приспосабливаю к новой задаче. В общем, трачу много времени на повторяющиеся действия. Я решил оформить список лучших решений – паттернов СSS (подобно паттернам ООП), которые помогут с нуля и быстро создать простую и правильную CSS и xHTML разметку. Также я решил включить в этот список несколько рекомендаций что точно не стоит делать – Антипаттернов. Итак.

html и body можно (нужно!?) использовать как собственные контейнеры которые вложены один в другой. Вопрос “а нужно ли?” – Каждый решает сам.
Доводы ЗА. Скорее всего, Вы и без этого напишите следующее:
```
<body>
	<div id="content">Содержимое сайта</div>
<body>
```
Все современные браузеры обрабатывают нормально.
Доводы ПРОТИВ. Даже самые современные средства разработки Adobe Dreamweaver CS3 и Microsoft Expression Web в визуальном редакторе не корректно отображают разрабатываемую страницу.
Если содержимое страницы должно располагаться по центру выставляем главному контейнеру выравнивание по центру и точно указываем ширину:
```
body {
/* или: #content {*/
	margin: 0 auto;
	/* или: 0 auto 0 auto */
	width: 760px;
}
```
Из главного контейнера часто полезно сделать “новый стакан” для вложенных плавающих элементов:
```
body {
/* или: #content {*/
	position:relative;
}
```
Доводы ЗА. Станет удобно абсолютно (“position: absolute”) позиционировать вложенные плавающие элементы, т.к. левый верхний угол контейнера теперь является левым верхним углом “нового стакана”, а не окна браузера.
Доводы ПРОТИВ. Нет смысла делать это, если главный контейнер располагается не по центру. Визуальные редакторы не правильно отображают вложенные абсолютно позиционированные элементы.
Помним: Не существует никакого Универсального Способа Трехколоночной Раскладки. Об это подробно написано в статье Пример верстки CSS Ивана Сагалаева. В КАЖДОМ ОТДЕЛЬНОМ СЛУЧАЕ нужно выбирать решение отталкиваясь от фона, размера колонок, и т. д!
При формировании CSS-раскладки да и вообще при высчитывании размеров блоков и элементов помним (CSS 2.1 Specification, Box model) правила расчета размера элементов следующие:
размер = границы + поля + отступ + ширина/высота или width = border-left + margin-left + padding-left + width + padding-right + margin-right + border-right
или
height = border-top + margin-top + padding-top + height + padding-bottom + margin-bottom + border–bottom.
НЕ ИСПОЛЬЗУЕМ width(height):100% если мы хотим добавлять отступы, поля или рамки!!!
Используем для форматирования меню – списки, а каждый элемент списка делаем плавающим (не используем display: inline; – появляются пробелы обрамляющие элемент):
```
ul#mainMenu{
	list-style:none;
	margin:0;
	padding:0;
}
	ul#mainMenu li {
		float:left;
		margin:0;
		padding:0;
	}
```
Доводы ЗА. Стандартный элегантный способ оформления меню. Большой плюс к оптимизации странице для поисковиков. Возможна реализация сложных - вложенных меню без использования Java Script. Огромное количество примеров.
“Схлопывание” float’ов лечим одним из двух способов:
```
/* Способ 1. (для IE установить width/height) */
#content {
	overflow:hidden;
}

/* Способ 2. */
#content {
	position:absolute;
	/* или */
	float:left;
}
```
Подробности: если элементы содержат вложенные блоки со стилем float: left | right, то они как бы "схлопываются". Вместе с сами блоком соответственно “схлопывается” и его фон, что так не желательно. Более подробно этот вопрос также освещен в статье "Раскладка в CSS: float" Ивана Сагалаева.
Используем один Background у всего сайта или у нескольких колонок сразу. Помним что стилю background-position можно задавать значения как в пикселях, так и в процентах.
Доводы ЗА. Существенно уменьшает сложность резки bg-картинок и упрощает как кодирование так и изменение в будущем.

Удвоение отступов float’ов в IE лечим кахом:

*html #col{
	/*уменьшаем отступ в 2 раза*/
	margin-left:1px;
};

За кадром

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