Отображение Google ВиО в Opera 10.00 Internal под Ubuntu Linux c черной темой

Я, конечно, понимаю, не у всех веб-дизайнеров есть возможность потестить свои творения на разных операционных системах (про разные браузеры я и не говорю — святая обязанность). Однако незнание законе не освобождает от ответственности. Незнающим говорю — есть такой замечательный сайт, благодаря которому вы можете увидеть свое творение под четырьмя операционными системами, под сотней браузеров (возможно, для некоторых сейчас произошло открытие, что браузеров более, чем один, а тем более операционных систем). Зовется он http://browsershots.org/.

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

Суть проблеммы в том, что они “забыли” задать цвет фона страницы и задать цвет шрифта и фона кнопок. Хотя про цвет кнопок виноваты скорее разработчики Opera. У них меняется цвет шрифта кнопки, в зависимости от темы, но остается цвет кнопки (что оказывается несовместимо со многими темами оформления, либо мешает корректному отображению). Похожая проблемма наблюдается в Mozilla Firefox, когда горе-верстальщики вспоминают-таки про шрифты, но напрочь забывают про цвет кнопки. В результате получается черный текст на черном фоне.

В связи с такой фигней я тему и прочее менять не намерен. Мое право.

P. S. Также начинающим верстальщикам настоятельно советую проверять код своего сайта на валидаторе: http://validator.w3.org/. Даже если везде все работает нормально, не факт, что вы не столкнетесь с выходом новой версии браузера, либо с нестандартной ситуацией (нестандартные настройки и т. п.).

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

Теперь про новый хостинг и его говнистости.

Хостинг бесплатный, со всеми вытекающими отсюда мутностями. Расположен на http://secure.eu.pn/. В целом, бесплатный хостинг с 200 Мб и 4 Гб трафика, а еще с PHP 4,5, MySQL должен быть чуть-чуть ущербным. Но меня все это вполне устраивает. Пришлось немного повозиться с настройкой WordPress, да и со своими скриптами, работоспособность коих еще не полностью восстановлена. Ниже обзор этого пресловутого тарифного плана:

1. PHP 4,5 на выбор;

2. MySQL (4, 5.1);

3. 200Mb места на диске;

4. 4Gb траффика;

5. 5 субдоменов (1 домен)

6. Пять штук мэйл-аккаунтов (но меня это не волнует, MX-запись изменена на гугл, он же всю почту и ловит), столько же алиасов.

Теперь говнистость:

1. Ограничение на размер файла в 500kb.

2. Отсутствие 404 страницы, т. е. редиректит на их рекламу (соответственно проблеммы с WordPress. Как пофиксить - ниже)

Так же следует быть внимательным со значениями переменных $_SERVER. Если домен надо, то $_SERVER['HTTP_HOST'], и никак иначе (настройки других серверов допускают другие варианты, хотя они корректными не являются).

Теперь про то, как подружить WordPress с этим хостингом. Суть ВордПресса такова, что страницы постов не существуют, но редирект в .htaccess позволяет это все корректно обрабатывать. У уважающих себя блоггеров адреса постов задаются в виде http://log.tsekhan.com/2009/04/content_manager_module_for_cms/. Здесь это вызовет переадресацию на рекламу хостинга. Чтобы обойти это и не потерять красоту ссылок, идем Settings -> Permalinks выбираем Common Settings и пишем что-то вроде /index.php/%year%/%monthnum%/%postname%/. Все, готово. Не забудьте только поставить 301-й редирект на старый адрес RSS-ленты. Её адрес теперь поменялся.

Теперь про .htaccess. Помучился я с настройко этого файла. Суть движка моего сайта такова: есть один обработчик (index.php), и файлы с содержимым (index.htm). Надо направить содержимое в обработчик. Раньше у меня это делалось строчкой RewriteRule .htm$ /index.php?$1. Даже если пользователь обращался к http://tsekhan.com/services/sites/, то сначала какими-то внутренними процессами это превращалось в http://tsekhan.com/services/sites/index.htm, а потом уже обрабатывалось в .htaccess. Здесь же index.htm не добавляется. Решилась проблемма добавлением строчки RewriteRule \/$ /index.php?$1.

Это я к чему пишу про особенности данного хостинга. Разработчики! Читайте стандарты! Иначе кросплатформенности не будет. Я извлек из этого большой урок. Все исключения надо обрабатывать, даже если этого не требуется на первый взгляд.

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

Обзор нового хостера следует.

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

1. Дизайнер делает шаблон сайта, куда прописываются места вставки блоков.
2. Блок представляет собой оформленную вставку с плагином (корзинка с количеством товара, лента новостей, блок просто форматированного текста, чат и т. д. и т. п.)
3. В место для вставки блоков (см. п. 1) можно вставить несколько блоков.
4. Мест для вставки блоков может быть несколько.
5. Каждый блок редактируется отдельно, своим редактором.
6. Дерево страниц хранится в виде иерархии директорий, со страницами index.html.
7. Движок обрабатывает запрос и подставляет из нужной папки страницу index.html, попутно подставляя в нее блоки, список файлов которых находится в конфигурационном файле в данной директории.
8. Файлы с содержимым блоков могут располагаться как в общей директории для блоков (общие блоки), так и в каждой конкретной директории (локальные блоки). К глобальным блокам можно отнести корзину, ленту новостей, ссылки и любой другой блок, который может быть актуален для нескольких страниц. К локальным можно отнести содержимое данной страницы, ссылки, актуальные только для данной страницы.

Проблеммы, которые мне необходимо решить:

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

Прощу прощения за мутное изъяснение, если что непонятно, либо трудно понятно — скажите, перепишу.

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

Так как первое от разработчика не зависит, то исправлять будем второе.

Я вообще поклонник идеального написания. Т. е. упростить все, что можно упростить.

Первое, что мы сделаем, это займёмся поиском причины тормозов.

Самая медленная часть компьютера — жесткий диск. И пусть даже они объединены в RAID-массив, это устройство остаётся главным тормозом. Чего стоят задержки в 3 милисекунды (в лучшем случае) для начала доступа к данным.

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

При чтении-записи в файлы самой распространённой ошибкой является чтение при помощи file(). Эта команда загоняет в оперативную память весь файл, независимо от того, что вам из файла нужно. Оптимально пользоваться для открытия командой вроде fopen(). Также используется технология блочного расположения информации. Т. е. информации располагается через строго определенные промежутки. Сначала идет информационая часть блока, а потом незанятая информация. Такая фича даёт возможность перейти к определённой строке не проходясь по всему файлу в поисках символов перехода на новую строку. Хотя для таких целей уже используют БД, которые обладают подобными возможностями.

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

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

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

И напоследок: отдавать приоритеты расходу ресурсов следует в таком порядке (чем дальше, тем больше стоит экономить):

1. Жесткий диск
2. БД (по сути жесткий диск вкупе с процессорным временем)
3. Процессорное время
4. Оперативная память

Отписывайтесь, где наврал, что упустил.

http://www.mikolka.info/i-have-a-blog

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

Сайт мой можно найти было лишь по целевому словосочетанию “создание сайтов” на 49-й странице выдачи, да и то только “в регионе Беларусь”. Я немножко подкрутил его, были заметны колебания, но не существенные. А заголовок титульной страницы у меня был “разработка сайтов, создание программ”. Словосочетание “разработка сайтов” тоже ходовое, но гораздо менее популярное, чем “создание сайтов”, и то, люди, искавшие разработку, почти все искали создание. В общем лоханулся. После изменения положения вещей сайт стал выдаваться в последней строке десятой страницы по вышеупомянутому запросу. Вот это по-нашему!

Кстати, мне пришла идея таким образом мониторить текущий PR сайта. Зная примерно в каком районе выдачи находится ваш сайт, можно предположить сколько вам гугл накапал PR’a. Только учтите, что рядомстоящие сайты тоже двигаются. Ну, хотя бы динамику определить можно. Этот рейтинг относительно моего сайта, например обновляется несколько раз в сутки. Это все-таки лучше, чем ап раз в несколько месяцев)

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

А еще и поисковикам угодить надо. В общем подумать есть над чем.

Ниже моя концепция сайтостроения.

Разрешенный технологии:

1. Флеш. Сейчас в диковину машины, на которых не установлен флеш-интерпретатор. Но ввиду гадостного поведения поисковиков, флеш можно использовать только в баннерах и в декоративных элнментах.
2. HTML. Сейчас все больше браузеров приходят к HTML 5. И все бы ничего, можно было бы начинать постепенный переход на последний стандарт, если бы не Internet Explorer. Он стареет и в ус не дует. Придется довольствоваться максимальным сходством с HTML 5. Напомню, что основное отличие от предыдущих стандартов в том, что все параметры отображения внесены в CSS.
3. JavaScript. Давным-давно минули те времена, когда не везде был включен яваскрипт. Раньше это делали, в основном из-за отсутствия интерпретатора яваскрипта (вспомните, сколько лет назад это было)) и из-за угрозы безопасности. Но и сейчас не все функции являются доступными для использования. Я сознательно запрещаю скриптам изменять размер окон, перемещать их, а также изменять текст в строке состояния. Также часто блокируются всплывающие окна (остался лишь вариант с открытием окон при определенных событиях. Щелчок, например, или закрытие окна).
4. Картинки. Стараюсь использовать GIF и PNG. Первый компактен, второй — наиболее актуален. Появилась даже PNG-анимация. По возможности нужно использовать SVG. Это формат векторных изображений, что говорит само за себя. К тому же мало весит и совместим со всеми основными браузерами.
5. PNG-фикс. Лучше всего использовать фикс с помощью CSS. Яваскрипт медленен, и к тому же его редко, но отключают. Вот пример фикса: .png1 { filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=’http://tsekhan.com/images/gradient.png’, sizingMethod=’scale’); background: url(http://tsekhan.com/images/clear.gif) !important;}
6. Все, что подгоняется под IE, нужно комментировать. Вот так: <![if gte IE 5.5]><![endif]–> Валидный код — залог того, что ваш код правильно отобразится в нынешних браузерах, и будет жить еще долго. Ведь не все браузеры обратно совместимы (т. е. с предыдущими версиями).

Вообще, игнорировать несовместимость можно, если таких браузеров осталось 2% и менее. Но Internet Explorer надо искоренять раньше. Он просто ужасен, в плане верстки под него.

Нельзя пока:

1. Сайты полностью на флеше. Не индексируются, долго грузятся, неудобны для работы в большинстве ситуаций.
2. HTML 5. На момент написания поста нет релизов браузеров, поддерживающих этот стандарт.

Нельзя в принципе:

1. Звук. Да, есть еще и такие монстры сайтостроения.

При верстке форм нужно учитывать, что Safari имеет некие глюки при отображении размеров элементов, и возможность растягавать textarea (как и Google Chrome, кстати).

Еще я стараюсь совмещать блочную верстку с версткой на таблицах. Верстать только на дивах или верстать только на таблицах — тупо.

Я верстаю только валидно. И так уже настрадался мир от невалидной верстки.

На сладкое браузеры под которые нужно верстать в обязательном порядке:

• IE
• Mozilla Firefox
• Opera
• Google Chrome (сделан на оперном движке, но имеет пару особенностей)
• Opera Mini
• Safari