Веб-разработка *

Пока все обсуждают HTML5 я тут пошевелил извилинами и придумал, в общем-то, тривиальную, но полезную концепцию и решение всех ваших проблем с языками разметки. Оно работает уже сейчас в Mozilla, WebKit и Opera.

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

Зато на это способен XML. Теоретически xhtml2 как раз и является воплощением идей модульности и расширяемости. Но есть одна проблема: все равно вам требуется ждать, пока браузеры начнут его поддерживать. Я сейчас возьму на себя смелость сказать следующее: браузер вообще не должен учиться новому языку разметки и разработчики не должны ждать, пока он ему научится. Все что должен уметь браузер — это обрабатывать xml, css и Javascript.

Концепция проста: полностью разделить структуру документа, представление и поведение. Это именно то, что уже сегодня можно сделать используя соответственно xml, css и Javascript. Сценарий выглядит следующим образом:

1. Браузер парсит xml-документ
2. Браузер парсит css-стили, которые говорят как должны выглядеть элементы, и применяет стили к документу
3. js-движок браузера выполняет Javascript, в котором описано, как должен вести себя каждый элемент страницы.

Обратите внимание, что без стилей браузер не знает, что делать с элементом <strong> например. А без описания поведения js-скриптом браузер не знает как себя вести, когда пользователь щелкает по ссылке. Этот подход можно, наверное, назвать DSRB — Document Structure-Representation-Behavior.

А теперь я покажу вам, собственно, страницу, сделанную описанным выше образом, работает в Mozilla, WebKit и Opera (в Опере есть небольшой непонятный глюк с заголовком) — посмотрите в исходный код обязательно. Недостаток данного подхода состоит в том, что браузеры не хотят выполнять Javascript, если они думают, что перед ними XML-документ. По этой причине мне пришлось указать пространство имен xhtml и избегать стандартных элементов HTML, чтобы браузеры не определяли для них дефолтные стили и поведение. Если браузеры начнут поддерживать Javascript для XML-документов, проблема будет решена.

В чем преимущество?

Сообразительные читатели уже догадались, что таким вот способом реализовать HTML5 можно уже хоть сегодня. При этом вы можете добавить в документ нужный вам доктайп или написать свой собственный DTD. Без доктайпа документ будет представлять из себя well-formed XML, что тоже неплохо.

В будущем, если идея приживется, полагаю, появится множество в чем-то схожих языков разметки. 2-3 из них, видимо, будут самыми популярными. Но, самое главное, что DSRB позволит создавать языки разметки, которые начнут работать в браузерах сразу же.

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

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

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

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

HTML 5 — это грядущее обновление гипертекстового языка разметки, основного способа создания контента для размещения его во всемирной паутине. Разработка HTML остановилась в 1999 году, на версии HTML 4.01 и с тех пор web-содержимое изменилось так, что текущие спецификации HTML перестали соответствовать сегодняшним требованиям.

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

Это статья нашего гостя Jacob Gube, web-разработчика и дизайнера, автора Six Revisions — блога о web-разработке и дизайне.

Введение

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

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

Я с интеренсом наблюдаю за развитием проекта webbynode. Разработчики обещают создать «cloud computing решение для разработчиков».
Вот только некоторые из «приятных особенностей» данного проекта:

• VPS хостинг на основе Xen.
• Ориентация на хостинг приложений и оптимизированный под это интерфейс управления.
• Технология «ReadyStack», позволяющая быстро развертывать готовые решения для популярных фреймворков. Прямо сейчас есть решения для RoR, Django, и LAMP.
• Высокая доступность, благодаря использованию многих датацентров.

Я зарегестрировался в программе для бета-тестеров, и вскоре мне пришло приглашение со всей необходимой для входа информацией.
После логина открылась удобная web-консоль для управления развернутым VPS.

15-16 декабря в конференц-центре «Авиа-Плаза» в Москве прошла конференция «РИТ: Клиентские технологии». Я в ней принимала участие, поэтому решила поделиться своими впечатлениями.

«Совершенный 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-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Сегодня пришло письмо от нового техдира. Ему не нравится как мы используем Жиру, поэтому он предлагает следующее:

По работе с Жирой:

1. Вводятся следующие понятия:
sub-task - подзадача,
versions - версии продукта, привязанные к определенной дате, это наше внутреннее обозначение, номер версии = год+неделя, т.е. 0852 - версия 2008 года, 52-я неделя
components - компоненты системы, это как колеса, двигатель, кузов у автомобиля
estimated time - исходная оценка, т.е. предварительная оценка времени на выполнение задачи

2. До начала работы над задачей - провести предварительную оценку требуемого времени и зафиксировать эту оценку в поле "Estimated time - Исходная оценка" - (в режиме редактирования) - это обязательное требование. Кто: Project Leader или Developer.

3. Непосредственно перед началом работы над задачей необходимо установить дату предполагаемого окончания работы "Срок исполнения" (в режиме редактирования), с учетом текущей даты и "Исходной оценки" - это обязательное требование. Кто: Developer

4. Components - фиксируется список компонентов системы, список дополняется/изменяется по необходимости. Кто: Project Leader

5. Versions -
Следующие задачи: выполненные, в работе, имеющие предварительную оценку открытые - интегрируются в Версии Продукта. Примерный график выпуска версий - один раз в две недели. Кто: Management+Project Leader - это обязательное требование.

Хорошего дня,

 

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

Вид доработанного файлового менеджера

Приветствую Хабр.
По мотивам cайта, сделанного сами знаете кем :)
В свое время увидел, такой эффект – слева сайта находятся ссылки, при клике на которые контентная область сайта плавно перемещается к указанному идентификатору. Эффект запомнился — решил повторить.
Для реализации плавного перемещения взял JQuery.

Дмитрий Робсман работает в главном офисе Microsoft в Редмонде уже 12 лет. Он был первым разработчиком в команде ASP.NET. Был менеджером в команде динамических языков (DLR, IronPython, IronRuby) и в команде Visual Studio, где работал еще и над C#, VB.NET и F#. Среди его известных личных проектов — веб-сервер Cassini, полностью написанный на управляемом коде, и ASP.NET RSS Toolkit.

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

На днях, читая рассылку по Zend Frameworks я заметил тему одного разработчика о реализации системы плагинов без модификации некоторого стандартного ядра. Подобную задачу приходится решать достаточно часто и во многих случаях — например, вряд ли хоть какая-то CMS-система обходится без механизма плагинов. Конечно же, разработчики таких популярных CMS систем, как Drupal или Wordpress уже решили для себя эту задачу, разработав собственную архитектуру подключения плагинов на лету без затрагивания функционала ядра. Однако аналогичная задача, мне кажется, все же из категории «вечных» и не все решения могут быть применены в каждом конкретном случае.

С аналогичными проблемами сталкиваются не только веб-разработчики, она актуальна и при проектировании компонентных десктопных приложений и сложных систем. И некоторые успешные решения вполне можно подсмотреть и позаимствовать с таких разработок. В данном случае я говорю об архитектуре Signal/Slot, которая реализована в библиотеке Qt (подробное описание) и применяется там для коммуникации между компонентами. Аналогичный функционал очень был бы полезен и в веб-разработках, в данном случае — в РНР проектах.

Намедни задумался над вопросом хранения изображений. Альтернативы две: в файловой системе и в базе данных. Это я, кстати, про изображения для веб-проектов.

Почитал литературу. Как оказалось, но не было особо удивительным, у хранения файлов как файлов есть ряд преимуществ:

Введение

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

В первую очередь, это связано с тем, что реляционные базы не приспособлены к хранению иерархических структур (как, например, XML-файлы), структура реляционных таблиц представляет из себя простые списки. Иерархические же данные имеют связь «родитель-наследники», которая не реализована в реляционной структуре.

Тем не менее, задача «хранить деревья в базе данных» рано или поздно возникает перед любым разработчиком.

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

Appcelerator, Inc, известные своим SDK для разработыки «rich web pages» представили новую, полностью открытую платформу для построения RIA под названием Titanium.
Платформа базируется на ряде популярных продуктов:

• WebKit
• Chromium
• Gears
• GTK+
• JQuery
• Appcelerator SDK
• NSIS
• Ruby

3 имеющиеся в наличии демки выглядят достаточно приятно.

Под катом — официальное релиз-видео.

Известен следующий баг «народного» браузера — картинки в формате .png, содержащие участки с альфа-прозрачностью отображаются неправильно. А именно — область этих участков заливается серым цветом (спасибо dreamhelg за лаконичное описание сути происходящего в данном случае).

Сегодня в в своей RSS-ленте обнаружил ссылку на очередную статью о конфронтации .png и IE. Воспринял ее, пожалуй, как и бóльшая половина удививших заголовок выше — с предубеждением (мол, опять двадцать пять). Тем не менее, выяснилось много интересного. Например, теперь фоновые .png отлично подчиняются свойствам background-position и background-repeat.

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

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



Как оцениваете такой подход? Есть перспективы?

В статье речь пойдет об имитации классического ООП и строгой типизации в JavaScript (< 2.0).

Я расскажу про JsOOP – мини-фреймворк для написания JavaScript-кода в объектно-ориентированном стиле.

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

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