victorgr

Google Doctype — это открытая энциклопедия и справочкая библиотека, написанная веб-разработчиками для веб-разработчиков. Она включает в себя материалы по безопасности веб-приложений, работой с JavaScript DOM, трюки и хитрости работы с CSS и многое другое.
Справочный раздел состоит из пополняющейся библиотеки элементов для проверки кросс-браузерной и кросс-платформенной совместимости.

http://code.google.com/doctype/

Интересный способ хранения данных в браузере пользователя без использования cookies придумал Томас Фрэнк (Thomas Frank).

Данные сохраняются в свойстве window.name, и это позволяет хранить до 2 Мб данных при переходах между страницами.

По-русски об этом можно прочитать вот здесь: http://xhtml.ru/2008/05/14/sessvars/

Возникает вопрос о сохранности данных при открытии страницы в новой вкладке или окне. На что автор отвечает в комментариях, что сейчас он ведёт работу над этим. Данные в таком случае будут передаваться через свойство window.opener. Однако, поведение этого свойства отличается в различных браузерах.

Многие разработчики активно обсуждают интересный способ сжатия JavaScript-файлов, придуманный Jacob Seidelin. Кратко, способ заключается вот в чём: JavaScript кодируется в PNG-картинку. Каждый пиксел PNG-8 может закодировать 1 байт, а PNG-24 — целых 3 байта. На целевую страницу вставляется сама картинка и небольшой скриптик, который эту картинку будет обрабатывать. С помощью элемента Canvas, этот скрипт попиксельно проходится по загруженной картинке и декодирует из неё JavaScript.

Смысл всего этого действа в том, что PNG-сжатие для картинки превосходит GZIP-сжатие, которым можно сжать .js-файлы. По крайней мере так предполагается.

Конечно, вряд ли можно считать это готовым решением, но как интересный proof of concept годится.

Однако я в этом сразу же увидел несколько иное применение: стеганография! Теперь, когда у JavaScript-а на странице есть возможность попиксельного анализа изображения, то никаких препятсвий для этого нет :).

Зачем инструмент стеганографии на веб-странице? А зачем он на локальном компьютере? Для тех же целей.

Это ведь надо было сделать такой браузер, который бы доставлял столько проблем!

Я про IE6.

Верстаю шаблон сайта, valid xhtml1.0 strict с доктайпом. Проверялся только в Firefox2. После этого прекрасно отобразился в Opera, Konqueror, Safari и даже IE7. И только в IE6 — проблемы! (привет прозрачным png и некоторым странным проблемам с div-ами!). А ведь я ещё не подключал JavaScript...

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

Да, и я обязательно поставлю на сайте панельку предлагающую посетителю обновить свой браузер!

Посмотрел скринкасты о Ruby on Rails...

Это вообще чёрная магия какая-то!

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

Представить, что всё это действительно будет работать, пока сложно. Вот оно — наше светлое будущее!

Теперь, когда я узнал о такой вещи как ORM, прихожу к выводу, что писать самому SQL — просто банально неправильно. Как писать правильно, кстати, я до сих пор не знаю. Но что сырой SQL — это не совсем то, что нужно в современном веб–программировании, очень хорошо чувствую.

Собственно, why do I think so?

ORM даёт независимость от используемой БД! Да. Не просто универсальную обёртку к mysql_connect, а настоящую независимость! Конечно, в таком случае для используемой ORM должен быть реализован драйвер к БД, но это не проблема.

ORM позволяет сосредоточиться на реализации функциональности, а не на написании запросов SQL.

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

В общем, я в раздумьях. ORM — вещь классная и нужная, но... Что у нас есть реально и приятно рабочего? Под PHP — Doctrine, под Python — SQLObject, SQLAlchemy...

Перевод на русский язык отличной статьи Joel Spolsky о стандартах, браузерах, IE8, в современном вебе — Марсианские наушники.

Одним из интереснейших событий в веб-девелопменте в недавнее время стало для меня открытие таких вещей как HAML и ORM.

И если про ORM и так все знают, а тем, кто не знает — в двух словах не расскажешь, то HAML — это отдельный, очень красивый стройный и законченный шаблонизатор.

Изначально он появился в мире Ruby и существовал для него, однако потом был... Был создан аналог для PHP. Для Python я такого, к сожалению, не нашёл. Нашёл только одного гражданина в ЖЖ, который планировал портировать HAML и на питон. Однако прошло уже несколько лет, а результата не видно.

HAML — это XHTML Abstraction Markup Language. Язык разметки, который просто ясно и чисто описывает структуру XHTML-документа. Вложенность тегов в нём описывается самым ясным способом — отступами. В общем, стоит увидеть самостоятельно пример XHTML-кода и эквивалентного кода, описанного HAML (pHAML — PHP HAML):

( Читать далее... )

Вот такая красота.

Блог с отличными постами про ExtJS.

Особенно понравилось пошаговое создание простой формы на ExtJS.

Разбираюсь с Django. Всё не могу понять: это overengineering или нет?

Программирование на пэхапэ более похоже на борьбу с самим пэхапэ, чем на решение задачи.

Так уж получается, что прежде чем написать реальную строку кода, приходится выполнять множество ерунды, только бы PHP заработал как нужно: выключить magic_quotes, выключить вывод ошибок, выключить register_globals, установить режим вывода сообщений об ошибке, установить внутреннюю кодирвку и так далее.

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

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

21.1.3. Testing if a File is Readable
The static method Zend_Loader::isReadable($pathname) returns TRUE if a file at the specified pathname exists and is readable, FALSE otherwise.
Example 21.3. Example of isReadable() method

if (Zend_Loader::isReadable($filename)) {
    // do something with $filename
}

Всё отличие статического метода класса от функции is_readable() в том, что встроенная функция не ищет файл в include_path, а версия фреймворка — ищет. Вы представляете, если мы над каждой встроенной функцией будем лепить обёртки да ещё и в виде классов?

Похоже на заговор с производителями процессоров.

В общем, хватит с меня. Хватит 5569 функций в глобальной области видимости. Хватит этой неявности и нелогичности. Точка.
Чемоданы собраны, я перехожу. На Python.

Увидел у Bolk.

Интересная штучка нашлась! MicroID. Чем-то смахивает на OpenID, но гораздо проще как по реализации, так и по функциональности.

Кратко суть такова: MicroID позволяет проверить, действительно ли пользователь владеет страницей, адрес которой вводит. Собственно, Google, Yandex и Yahoo в своих веб-мастерских разделах и так проводили подобную аутенфикацию, прося разместить определённый файл в корне сайта. Но здесь ещё немного иначе.

На сайте, который хочет проверить принадлежность пользователя к определённой странице, устанавливается форма с двумя полями: email и URL. Пользовател вводит запрашиваемую информацию, после чего этот сайт обращается по введённому URL и ищет там специальный meta-тег microid, в котором лежит нечто вроде “mailto+http:sha1:ca94387152e8ea62fee73c45c4bae79e54543485”. Это, как можно догадаться, sha1-хеш от email и URL. Сайт, проводящий аутенфикацию, делает такой же хеш из введённых данных и сравнивает. Если совпадает — значит пользователь действительно владеет указанной страницей.

Подробное описание и спецификацию можно найти здесь: microid.org.

Интересно получается.

Заново устанавливал Firefox в своей новой Kubuntu и пришлось сделать этакую перепись расширений, ради которых, собственно, мне Firefox и нужен. По большей части — это расширения для веб-разработки. Firefox я использую именно для этих целей, лучшего браузера пока не видел. Во всём остальном пользуюсь Opera.

Opera — это как Мерседес S-класса. Чистый удобный салон, приятная обивка, запах, блеск, нежный шёпот двигателя...

Но если тебе нужен рёв мотора, гаечные ключи и измазанные в моторном масле руки — это Firefox.

( Итак, расширения, которыми пользуюсь я. )

Что я упустил из виду? Какие полезные расширения для веб-девелопминга?

Не думал писать об этом сегодня, но ситуация так сложилась, что нужно зафиксировать некоторые мысли на эту тему. А тема — сбор и анализ статистики в веб–движке.

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

Один из самых простых и популярных способов сбора статистики посещений на сайте — это использование внешней системы статистики (Google Analytics, HotLog, счётчики).

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

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

И здесь есть два варианта сбора статистики:

1. Анализатор логов веб–сервера.
2. Счётчик, встраиваемый в исполняемые сайтом скрипты.

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

( Читать далее... )

Особым ценителям капч:


Да они издеваются!

Принципы, на которые следует опираться, при разработке веб-движка Rahwalod.

1. Всегда и везде (кроме URI) использование Unicode.

2. В URI используется только ASCII.

3. Любой документ может иметь один и только один URI.

4. Медиаконтент (изображения, видео, звук) и прикреплённые файлы — это неотъемлимая часть документа, должна соблюдаться ссылочная целостность.

5. Отделение содержания от представления (семантической разметкой, CSS, XHTML).
Один и тот же контент может иметь множество представлений: XHTML, RSS, PDF, TXT и проч.

6. Всюду использовать только User-Friendly URI (ЧПУ).
Адреса документов должны быть максимально краткими, ёмкими, отражающие суть документа, по возможности — его название. В адресе должно быть как можно меньше технических деталей, необходимых для работы движка. В идеале — их быть не должно.

Интересный факт услышал в Google TechTalk: “Для почти 70% пользователей интернета английский язык не является родным.”

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

В своём посте Кроссплатформеность vs. Платформо-специфичные фичи я размышлял на тему, стоит ли задаваться целью создать максимально кроссплатформенный код (под платформой здесь я понимаю веб-сервер, СУБД и язык программирования), либо же имеет смысл единоразово поставить её в список системных требований и писать, опираясь на неё.

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

Я не против этого. Гораздо лучше, когда программа работает и с MySQL и с PostgreSQL, чем когда она работает только с PostgreSQL, а тебе нужно её запустить с MySQL. Но в своей жизни мне доводилось работать только с MySQL и пока я не вижу повода знакомиться с другими СУБД.

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

О выборе языка программирования я уже писал.

В итоге, что у нас получается?

Apache2 с модулями mod_rewrite, mod_setenvif, mod_deflate, mod_headers и включенным .htaccess; PHP5.2 и MySQL 5 (InnoDB).

Движок не будет противиться переносу на другую платформу в случае необходимости и код будет писаться максимально дружественный к этому, но всё же никакой встроенной кросс- СУБД и серверности не будет. Потому что мне она не нужна.

Капчафилам:



http://belnetmon.livejournal.com/537262.htm

D2 61 95 F3 вроде бы :)