Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

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

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

После того, как я в третий раз скопировал этот механизм в очередной проект, я решил создать для себя (и других) сервис, который отдавал бы по запросу иконку в формате png для любого домена. Но ему не суждено было родиться, потому что я случайно наткнулся на аналогичную функциональность, реализованную гуглом. Достаточно набрать адрес www.google.com/s2/favicons?domain=habrahabr.ru и получишь сконверченую в PNG иконку этого домена. Решил, что многим это будет полезно — используйте :)

UPD: нашлись баги. конвертер не умеет работать с прозрачным фоном, а также грузит только те иконки, которые лежат в /favicon.ico, игнорируя мета-теги :( Так что мой сервис, видимо, появится :)

Решил поделиться недавно написанным кодом демона для видеохостинга.
Принцип демона прост. Демон смотрит в папку, куда загружаются видеофалы, и при появлении там новых, копирует в другую папку, запускает в фоне процесс конвертации, создает превьюшку, и копирует полученное видео в папку пользователя.

Задача — сделать профиль пользователя доступным через example.com/user/username и через пользовательский поддомен username.example.com. Задача простая и с помощью Zend Framework решается парой строк кода. Трудности начались тогда, когда я решил действия регистрации, подтверждения регистрации, востановления пароля и собственно входа/выхода поместить в тот же контроллер, который выводит профиль пользователя. Теперь возникла задача научить контроллер не воспринимать example.com/user/register как пользователя.

Часто использую usersrcipt в greasemonkey, так же сильно люблю jQuery — использую его во всех проектах.
Нашел небольшой сниппет для использования jQuery в скриптах для Greasemonkey

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

Сложность материала будет нарастать от начала к концу статьи, так что для профи первые части могут показаться скучными и банальными, но дальше будет намного интереснее :)

Ага, вот эти ребята, сейчас я покажу Вам магию ООП.

Читал про недавно вышедшею библиотеку для работы с SVG — Raphaël (хабратопики habrahabr.ru/blogs/webdev/41647 и habrahabr.ru/blogs/svg/42949). Где было указано, цитирую: «Так что связка Raphaël + jQuery будет давать огромные возможности для разработки».

Однако в библиотеке плагинов на Jquery я недавно нашел готовую разработку для работы с SVG (страница плагина).

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

Автор плагина Keith Wood. На его сайте, есть еще много чего интересного.

Raphaël — это небольшая JavaScript библиотека с простым синтаксисом для работы с векторными форматами: SVG и VML (для IE). Впрочем, как я успел заметить у разработчика возникают проблемы с VML (когда многие вещи в SVG делаются очень просто в VML не всегда есть простая альтернатива)

Raphaël — небольшая библиотека(20 килобайт) для построения векторной графики на веб-сайтах.

Она использует SVG и VML в качестве базы для создания графики. Учитывая то, что каждый созданный объект — DOM объект, то при помощи JavaScript обработчиков можно легко изменять их свойства и действия.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Как правило, реализация любой идеи начинается с обсуждения планов, графиков и прочих неотъемлемых компонентов серьёзного проекта. Впрочем, бывает и так, что люди без лишних разговоров просто делают то, что считают полезным, тем самым преподнося сюрприз окружающим. Один из примеров тому — практически полный перевод на русский язык цикла статей, входящих в курс Web Standards Curriculum, являющийся частью образовательного проекта Opera. Посему приглашаю всех заинтересованных в данных статьях, но не обладающих хорошими навыками владения английским языком, ознакомиться с русскоязычным вариантом. Уверен, что вы найдёте массу полезной информации, пригодной для использования в своих разработках и проектах.

Читать Web Standards Curriculum на русском

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

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

После заметки о Peppy я почти обрадовался — вот оно, счастье. Наконец появился движок CSS-селекторов, который делает тоже самое, что и jQuery, только быстрее. Сильно быстрее.

Радоваться было недолго, как только я посмотрел в код, то немного ужаснулся: он не соответствовал моим представлениям об исключительной производительности. Совсем не соответствовал. Точнее, немного удовлетворял, но не до конца. Поэтому сразу встал вопрос: а если быстрее?

Почему нельзя сделать быстрое мини-ядро для CSS-селекторов, которое обеспечит базовую функциональность для работы с DOM (ну, совсем базовую — просто выборку элементов, например)? И, самое главное, чтобы это работало не медленнее (в идеале, даже быстрее), чем нативные вызовы.

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

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

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

Много было про то написано, да не суть…

Озадачился следующей задумкой: перетаскиваемый слой с фиксированным положением на экране, страница скролица — слой остаётся на месте. Как известно данная задумка на ура воплощается в FF, Opera, Google Chrome, но вот IE интеллигентно послал мою задумку в свою мусорную корзинку — при скролинге передвинутый слой сползал вместе со страницей.

7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

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

Я решил выложить их в виде статьи, переработав и снабдив иллюстрациями и примечаниями.

Содержание:

1. Вступление
2. Сценарии гибели
   • Гибель ментальная, или HTML — новый ассемблер
   • Гибель физическая, или HTML — новый Turbo Pascal
3. Все ли так серьезно?
   • Ментальной гибели не будет, если web-технологии будут правильно поняты
   • Физической гибели не будет, если web-технологии будут развиваться
4. Заключение
5. Примечания

В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

Программы, работающие через Веб, все больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

Однако, по мере продвижения web-приложений, все больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

И, если эти технологии не будут поспевать за все более возрастающими требованиями, это приведет к их медленному закату…
 

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

Фильм основан на персонажах, которых ЕВА и ВАЛЛ-И видели на борту «Аксиомы». BURN-E это робот-сварщик, которого ЕВА и ВАЛЛ-И случайно оставили закрытым вне коробля, проникая внутрь после полёта около «Аксиомы».




Вот и свежий трейлер