HTML5 для веб-дизайнеров

1. Краткая история языка разметки
2. Модель HTML5
3. Мультимедиа
4. Формы 2.0
5. Семантика
6. HTML5 и современные условия

В истории всемирной сети каждый очередной виток перехода на новый уровень развития начинался с какого-нибудь технологического нововведения. Когда в HTML добавился элемент img, это в корне изменило облик сети. Затем введение JavaScript сделало ее более динамичной и интерактивной. Чуть позже появился Ajax, что открыло возможности для создания в сети полноценных приложений.

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

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

Эти технологии — «плагины», эдакие «затычки», заполняющие «дыры» в сети. Они делают относительно простой публикацию игр, фильмов и музыки онлайн, но они не открыты и принадлежат и контролируются частными компаниями. Да, тот же Flash — мощный инструмент, но его применения в какой-то мере схоже со сделкой со злыми силами: мы получаем новые, недоступные другим путем, возможности, но взамен теряем часть свой независимости.

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

HTML5 для веб-дизайнеров

1. Краткая история языка разметки
2. Модель HTML5
3. Мультимедиа
4. Формы 2.0
5. Семантика
6. HTML5 и современные условия

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

Эта история постоянно повторяется. Как только определенный шаблон или задача становятся достаточно популярными, они почти непременно в конце концов упрощаются в техническом плане и делаются более доступными. Именно так в CSS3 появилось много функций для создания простых анимаций, для которых прежде требовался JavaScript.

Говоря о формах, тут возможности CSS довольно ограничены. И теперь на сцену снова выходит HTML5. Следуя тому же принципу, он вводит новые функции, которые на самом деле вовсе не новые, но сделаны проще и удобнее.

Нетрудно догадаться, что прежде они были частью отдельной спецификации WHATWG под названием Web Forms 2.0.

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Продолжение темы порталов, поднятой в моей предыдущей статье.

Наиболее сложная проблема, с которой я столкнулся при написании данной статьи, заключалась в достоверности определений даваемых различными источниками. Не помогла мне и пресловутая Wikipedia, т.к. некоторые определения вызывали явные сомнения (конечно, я бы мог бы их поправить, с другой стороны, ну кто я такой?). Кроме того, версии Wikipedia на русском и английском языках содержали несколько отличающиеся определения. Было бы неправильно писать эту статью основываясь только на собственном опыте, поэтому в качестве источника, к которому я буду апеллировать, я выбрал ежегодные отчеты аналитического агентства Gartner о горизонтальных порталах.

Давайте обратимся к определению портала, которое дает авторитетное аналитическое агентство Gartner: портал – это программная инфраструктура для Web, предоставляющая доступ (с возможностью взаимодействия) к релевантным информационным активам (например, к информации/контенту, приложениям и бизнес-процессам), интеллектуальным и человеческим активам путем выборки по целевой аудитории, предоставляемыми с высокой степенью персонализации.

Aгентство Gartner предлагает следующее деление порталов по целевой аудитории:

• B2E (business-to-employee) – порталы для взаимодействия с сотрудниками,
• B2C (business-to-customer) – порталы для взаимодействия с заказчиками,
• B2B (business partners) – порталы для взаимодействия с бизнес-партнерами.

Aгентство Gartner предлагает также подразделять программные продукты, позволяющие создавать и поддерживать порталы, по их устройству на следующие типы:

• Вертикальные порталы – фокусируются на специфических приложениях и бизнес функциях;
• Горизонтальные порталы – собирают интегрированную информацию из множества межотраслевых приложений, а также специфических бизнес сервисов и приложений для определенной отрасли производства.

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

На рассмотрение в IETF поданы спецификации новых кодов состояния HTTP, которые более точно описывают некоторые типичные ситуации.

428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large 
511 Network Authentication Required

Протокол WebSocket получил свой номер RFC и опубликован в официальной библиотеке IETF как RFC 6455. Это означает, что черновик спецификаций признан вполне удачным, в целом стабильным и подходящим для стандартизации. Его дальнейшую судьбу будет отслеживать организация IETF, и впереди у потенциального стандарта — два этапа. После «предложенного стандарта» будут рассмотрены улучшения, которые представит сообщество, затем документ RFC может получить статус «драфта» (чернового стандарта) и, в конце концов, может быть признан как полноценный Стандарт Интернета (STD) — из нескольких тысяч кандидатов до такого статуса дожили всего 72.

WebSocket — протокол двунаправленной связи между браузером и веб-сервером. Протокол включает в себя описание запроса клиента и ответа сервера на установление соединения, а также базовое оформление сообщений, передаваемых поверх TCP-соединения.

С помощью WebSocket можно создавать интерактивные браузерные веб-приложения, которые постоянно обмениваются данными с сервером, но при этом не нуждаются в открытии нескольких HTTP-соединений, как XMLHttpRequest или <iframe>’ы.

В качестве авторов RFC 6455 указаны Ян Фетте из Google Security Team и Алексей Мельников (isode.com).

Данная статья является переводом первой статьи из цикла статей о протоколе HTTP с сайта opera.com.
Пересоздал её, чтобы тип статьи стал переводом.

Введение

В Бутане, когда люди знакомятся, они обычно приветствуют друг друга словами «Твоё тело чувствует себя хорошо?». В Японии они могут кланяться, в зависимости от обстановки. В Омане мужчины обычно целуют друг друга в нос, после рукопожатия. В Камбодже и Таиланде они обычно соединяют ладони, как при молитве. Это все протоколы общения, простая последовательность кодов, которая имеется значение и готовит обе стороны к обмену информацией.

В Интернете есть очень эффективный протокол прикладного уровня, который готовит компьютеры к обмену информацией: Hypertext Transfer Protocol, или HTTP. HTTP — протокол прикладного уровня поверх коммуникационного протокола TCP/IP. HTTP часто упускается из вида при изучении веб-дизайна и веб-разработки, что является ошибкой: понимание его помогает определить лучший способ взаимодействия с пользователями, достичь лучшей производительности сайта и создает эффективный инструмент для управления информацией в сети Интернет.

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

Сейчас редко найдешь среднюю или большую ИТ компанию, не имеющую ISO 9001 сертификата.
Тем не менее, я считаю, что в ближайшей перспективе ISO 9001 умрет для ИТ мира. Почему?
Попытаюсь обосновать.

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

Добрый день!

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

Вероятно, многие из вас уже сталкивались с этими требованиями в виде либо каждодневной рутины, либо авралов в конце календарного года (больше склоняюсь ко-второму), но лично я, кроме упоминаний таких понятий как SOX, HIPAA, SAS 70 (заменен на SSAE 16) и ITGC, не встречал сколько-нибудь исчерпывающего описания этого вопроса.



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

Если вас интересует данный вопрос, добро пожаловать.

Распространенная ситуация: у вас на руках документ/изображение/клип и т.п. в непонятном для вас формате XYZ. Что обычно делается, вернее делалось:

1. Гуглим примерно следующее: «чем прочитать XYZ», «как конвертировать XYZ в ABC» или что-то в этом роде.

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

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

Вступление

Рост числа интернет-магазинов уже никого не удивляет. 2013 год не будет исключением. Появится еще не одна тысяча торговых интернет-проектов. На данный момент мало кто говорит об огромной проблеме — малом количестве поставщиков, готовых работать “под заказ”. Небольшие интернет-магазины не могут позволить себе приобретать товар на склад, поэтому им нужна возможность сразу после поступления заказа от клиента резервировать товар у поставщика, на следующий день забирать его и везти клиенту. Но для любого оптового поставщика это означает получение огромной операционной нагрузки. Чтобы эффективно продавать товар интернет-магазинам, оптовики внедряют B2B-системы.

28 февраля 2013 года, после нескольких лет ожидания, наконец-то была опубликована финальная версия руководства по доступности Интернет-ресурсов WCAG версии 2.0 в уполномоченном русском переводе.

Организатором перевода выступил Информационный центр ООН Россия, а координатором — Даниэль Новичков.

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

Для начала, в двух словах о «Фингуру».

Фингуру является дочкой таких китов как ЗАО «РЦ Практик» и «СКБ Контур». Наш бухгалтерский сервис — это полная замена профессионального бухгалтера в штате. Это компания, которая оперативно поможет с бухгалтерией, подготовит за вас все необходимые документы и отчитается во все контролирующие органы. Никакой бизнесмен не любит бумажную волокиту — он любит заниматься своим делом, поэтому мы в свое работе преследовали 2 цели. Первая цель — социальная: сделать так, чтобы бизнесу в России стало проще работать, освободив его время от «копания» в платежках, счетах-фактурах, приходно-расходных ордеров и прочего. И вторая — собственно коммерческая: создать массовый сервис, способный работать с десятками тысяч клиентов самого разного уровня бизнеса. В итоге, получился такой бухгалтерский «Макдональдс», где за относительно небольшие деньги можно получить услугу быстро и стандартно хорошего качества. А теперь, собственно, о правилах, которым мы следовали.

Правила маркетинга

Любой «продукт» состоит из собственно производственной части (как делаем) и маркетинговой (кому продаем, как и зачем). Мы начнем описание с этого последнего блока, поскольку понимание нужд своей аудитории — основной аспект бизнеса.
Рассказывает: Алексей Ермолов, генеральный директор «Фингуру»:

Правило #1. Мышление от клиента или «Не называйте меня дураком»

«С понимания того, что хочет клиент, начинается наша услуга. У нас с этим все достаточно просто: клиент хочет уделять больше внимания своему бизнесу и не иметь проблем с налоговой, пенсионным и страховым фондами. Но когда он обращается в бухгалтерскую фирму, часто ему приходится работать напрямую с бухгалтером, который общается с ним на своем «птичьем языке». Нередки случаи, когда клиент обижается, потому что «чувствует себя дураком», не понимая, что ему говорят, хотя на самом деле консультация может быть оказана супераудитором и суперпрофессионально».
Чтобы с нами не происходило таких ситуаций, в «Фингуру» работают клиентские менеджеры, которые выступают своеобразными переводчиками, понимающими и тех и других. Это очень важно и это экономит время.

Как говорят, с годами планета уменьшается. Лет 500 назад на неизвестных территориях карты писали «здесь живут драконы». Лет 200 назад на планете ещё существовали белые пятна.

Теперь же у нас есть GPS, интернет и Google Maps, и планета уже не кажется такой большой.

Хорошо бы и адрес также можно было уменьшить. Вместо «страна, регион, город, улица, дом» и вместо длинных цепочек цифр-координат — что-нибудь типа короткого url.

Есть такая возможность — это замена координатам и адресам под названием Mapcode. К примеру, адрес телецентра на Королёва, 12 — JC.B4J. Адрес ГУМ — JF.XG.

И так далее.

В ответ на оптимистичную и захватывающую статью «Mapcode — простой и короткий адрес», хотелось бы отозваться критикой этой системы, чтобы лишний раз не распалять несведущие умы глобальными идеями а-ля «отмены часовых поясов». Итак, что было недосказано и что «не так» в этой «идиллии адресов»:

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

Здесь мы поделимся тем, что у нас уже есть — своими наработками и мыслями «кому и почему это выгодно», а в конце статьи нам бы хотелось получить обратную связь: как Вам наше предложение, готовы ли Вы подключиться к нам и предложить свои идеи.

Когда мы запускали инновационный бухгалтерский сервис «Фингуру», наш старт не был идеальным. Но мы сумели вынести уроки из своих ошибок и хотим поделиться с вами информацией о том, «как не надо запускать бизнес». Это честный пост не только для других бухгалтерских сервисов (которые захотят развиваться сами или выразят желание с нами сотрудничать), но и для всех молодых IT-компаний.

Ошибка 1. «Бумажный монстр», который ест ваше время

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

Clinical Document Architecture ﴾CDA﴿ — один из стандартов HL7, разработанный для стандартизации структуры и обеспечения семантической совместимости мед систем при обмене медицинской информацией и/или мед документами. Первая версия стандарта была одобрена ANSI ещё в 2001 году. Вторая версия, котороя используется и по сей день, была утверждена ANSI в 2005. Третья версия, CDA R3, находится в стадии разработки и согласования.

CDA R2 (Release 2) гарантирует наличие следующих семи характеристик в CDA документе:
• Сохранность представленной информации;
• Управление представленной информацией;
• Поддержка требований к аутентификации всей представленной информации;
• Поддержка контекста представленной информации;
• Поддержка цельности информации;
• Возможность чтения представленной информации человеком;
• Поддержка бинарной информации, таких как мультимедийные компоненты, PDF, изображения и прочее.

Подобные характеристики делают CDA крайне гибким к использованию в различных областях. И даже несмотря на то, что в среде разработчиков мед систем CDA считается крайне сложным стандартом, он стал одним из наиболее успешных разработанных HL7 для интеграции мед данных и согласуется с требованиями Meaningful Use 1 и 2 принятыми в США. Большинство мед систем в настоящее время кодируют информацию в одном из девяти возможных шаблонов документов CDA, например, Continuity of Care Document (CCD) один из таких шаблонов.

В данной статье представлен обзор или упрощённое описание основных компонентов CDA. И так, как и любой документ, CDA содержит заголовок документа (CDA Header) и тело документа (CDA Body).

EDI стандарт (Electronic Data Interchange) — часть старых, устоявшихся систем. Но мы постоянно видим, как EDI представляют, как современный стандарт. Так ли это? Надо ли нам рассматривать EDI в качестве базовой технологии для новых проектов?
Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.