10 современных веб-технологий, о которых вы должны знать

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

Это новый стиль элементов для HTML5, который базируется на стандартах W3C. Компоненты позволяют создавать пользовательские элементы многократного использования для структур динамических страниц, таких как виджеты с вкладками, слайдеры изображений и выпадающие меню. Вместо того чтобы создавать всплывающее меню с маркированным списком, можно использовать тег <dropdown>.

На официальном сайте Web Components доступно множество практических примеров, но очень мало пояснений того, где они могут пригодиться.

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

Когда вы познакомитесь с Web Components, вам может понадобиться библиотека Polymer. Этот проект с открытым исходным кодом запустил Google. Он предназначен для создания стандартизированных веб-компонентов.

Эта библиотека упрощает разработку, если вы работаете с Web Components API. С ее помощью вы получите встроенные элементы для добавления таких функций, как видео, слайдеры и даже виджеты Google Maps.

Целью Polymer является создание модульной структуры. Вот почему она позволяет создавать собственные виджеты на основе Web Components API. Таким образом появляется возможность добавить несколько виджетов на одну страницу без повторной записи кода.

Библиотека Polymer неразрывно связана с Web Components, и две эти технологии значительно изменяют методы модульной разработки сайтов.

Google всегда пытается улучшить интернет. Проект Accelerated Mobile Pages (сокращенно AMP) позволяет адаптировать любую веб-страницу для мобильных устройств по стандартному шаблону.

Нужно просто добавить небольшой код на свою страницу и позволить Google сделать все остальное. Если ваш сайт AMP-оптимизирован, он будет загружаться быстрее. Таким образом, сайт будет больше похож на оригинальное приложение.

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

Gulp позволяет автоматизировать рутинные задачи. Он умеет компилировать Sass в CSS, добавлять в код шаблоны или заплатки для браузеров, автоматически обновлять страницы после внесения в код каких-либо изменений.

Google недавно утвердил TypeScript в качестве предпочтительного языка для своего front-end фреймворка AngularJS. Это делает TS еще более привлекательным, потому что он помогает сэкономить время, как при написании общих скриптов, так и при разработке специализированных Angular-проектов.

TypeScript является не новым языком, а скорее надмножеством JavaScript. Поэтому, если вы знаете JS, вам будет легко использовать эту популярную веб технологию.

Если вы следите за тенденциями WebGL и 2D / 3D веб-графики, то должны знать о Three.js. Это самый мощный движок рендеринга на основе JS, который можно использовать для веб-графики.

Немногим сайтам нужна 2D или 3D графика. Но количество таких сайтов увеличивается, и это одна из лучших JavaScript-библиотек, которые можно использовать для создания элементов холста и диаграмм данных.

Лучшее в Three.js это то, что данная библиотека является бесплатным инструментом с открытым исходным кодом, поэтому она постоянно совершенствуется вместе с WebGL API.

С помощью контейнерной платформы Docker можно поддерживать полную виртуальную среду и легко переносить сайты на разные серверы. Виртуальные контейнеры содержат интерфейсы для простой передачи файлов с одного сервера на другой.

Если вы являетесь приверженцем IT / DevOps, тогда Docker — это обязательная для вас технология. В последнее время данная веб технология начала набирать популярность.

Это бесплатная платформа с открытым исходным кодом для разработки мобильных приложений под iOS и Android. Каждое приложение пишется на оптимизированном коде. Поэтому можно создавать программное обеспечение на JavaScript, но конечный результат будет выглядеть как оригинальное мобильное приложение Swift / Java.

На данный момент уже выпущена версия 1.3, и Ionic получил большую поддержку со стороны веб-сообщества.

Фреймворк Foundation — невероятно мощный инструмент. В последнем релизе разработчики выделили веб-фреймворк из Foundation for Emails, который теперь поддерживает автоматизацию и шаблоны для email-разработки.

Но еще больше мне нравится их новый Motion UI, предназначенный для создания анимации «на лету». Можно создавать анимацию с помощью онлайн-инструмента Zurb и включать библиотеку Motion UI в любой проект на Foundation.

Google предлагает множество полезных технологий веб разработки, и одной из них является Web Starter Kit. Это библиотека полезных ресурсов для создания сайтов, модульного кода Sass / CSS, локальных HTTP-серверов и многого другого.

Предполагается, что Web Starter Kit предоставляет все основные компоненты, которые потребуются веб-разработчику. Это стартовый набор, который является отличным бесплатным решением для начинающих разработчиков.

Данная публикация представляет собой перевод статьи «10 Modern Emerging Web Technologies You Should Know About» , подготовленной дружной командой проекта Интернет-технологии.ру

Современные технологии веб-разработки: особенности тенденций 2018-го года

От автора: знаете ли вы об основном отличии специалиста web-разработки от любого другого представителя IT-профессий? Он больше остальных осознает, как быстро устаревают его инструменты. Самые прогрессивные разработчики погружаются в технологии веб разработки, отслеживая их развитие и изменения. Но даже несмотря на постоянный мониторинг, шанс упустить что-либо велик. Держим руку на пульсе прогресса — расскажем сегодня о тенденциях текущего года.

Приложение — новый стандарт сайта

Об этой технологии сегодня расскажем больше, чем об остальных. Причина — нам кажется, что тренд продержится дольше всех современных направлений разработки. Имя ей — Progressive Web-Application, сокращенно PWA. Ее суть в том, чтобы ресурс мог быть сохранен на домашний экран смартфона, подобно нативному приложению. Даже взаимодействие с ними похоже, но веб-приложения такого формата имеют ряд преимуществ перед «нативом» и обычным ресурсом в закладках. Основные отличия:

кроссбраузерность и кроссплатформенность. Когда вы создаете мобильное приложение, то вынуждены проводить web-разработку версий для основных операционных систем: Android, iOS, Windows. Это затратный процесс, особенно если сам проект рассчитан на небольшую аудиторию и не сулит баснословной прибыли. Но с PWA вы просто делаете что-то вроде ссылки, которую нужно красиво оформить;

экономия ресурсов. Нативы используют немало оперативной и физической памяти, в то время как PWA размещены на сервере и могут выполнять те же функции;

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Зарегистрироваться

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

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

Спрос на PWA объясняется и недавним исследованием, проведенным Recode. В последние несколько лет пользователи склонны к удалению обычных приложений. Они занимают место в памяти, на экране, а их установка/удаление отбирает время. Похоже, что спрос на них падает. Особенно это коснулось социальных сетей и Messenger, о котором говорилось выше.

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

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

PHP: второе дыхание на седьмой версии

Язык гипертекстового препроцессора очень напоминает селебрити: о нем постоянно говорят. Иногда хорошее, чаще плохое. Но суть в том, что он популярен среди разработчиков. Согласно данным компании Google, на нем работает более 80% процентов всех ресурсов в сети (ранее эта цифра была больше).

Те, кто только добавил в свой скилл-стек PHP 5, наверняка задаются вопросом, почему сразу седьмая, а не шестая версия? Но ответ очень прост: PHP 6 была настолько неудачной, что забвение — лучшее, что могло подарить ей общество. В той версии создатели сконцентрировались на поддержке Unicode, что весьма круто для web-разработки. Сначала все смотрели на идею с энтузиазмом, но вскоре он разбился о физические возможности: портирование всех библиотек занимало время, и это тормозило всю остальную разработку. Конечно, можно было бы назвать седьмую версию шестой, но это было уже невозможно.

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

Основным отличием версии 7 стала производительность: движок под названием Just in Time делает язык почти в два раза быстрее. Все изменения, которые происходили, были построены таким образом, чтобы оптимизировать его работу. Также был усовершенствован синтаксис, причем не совсем так, как того хотели «правильные» программисты. Несмотря на ожидания, «препроцессор» не стал сложнее в освоении. Вместо этого появилась возможность сократить количество написанных строк.

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

WordPress становится стандартом

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

WordPress — это система управления контентом, которая максимально адаптирована под web-разработку, освоить все это возможно без особых знаний в программировании и разметке. Потратив несколько часов на обучение, хорошие сайты на WP может создавать даже новичок с нулевым стеком освоенных технологий. Это привлекает не только самих разработчиков: владельцы ресурсов, «натянутых» на WordPress, могут без труда вносить в него изменения.

Радостно то, что большинство претензий к WordPress Tipton (2017), уже давно не актуальны. Современная версия лишена недостатков старых версий, среди которых:

низкая производительность сайта;

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Зарегистрироваться

перегруз хостинга при большом количестве посещений. Можно дать комментарий сразу по двум этим пунктам: это ошибка. На самом деле, Tipton не перегружает хостинг, а ресурсы, управляемые им, работают быстро и стабильно. Вы и сами можете в этом убедиться: столько топовых страниц работает на WordPress. Это и BBC America, и Rolling Stones (издание), и даже официальный портал с новостями о Star Wars. Их посещаемость варьируется от четырех до трехсот тысяч в день. Разве стали бы такие мощные компании доверять «плохой» системе? Конечно, нет;

на WP невозможно создать уникальный дизайн. Это правда, но разве для версии 2017-го года? Вовсе нет. Сегодня существует плагин Visual Composer. C ним можно создавать шедевры web-разработки, даже не вникая в базу HTML/CSS. Кстати, установка дополнения бесплатна, вопреки ожиданиям. А еще новичок может приобрести уникальные шаблоны, на основе которых разработает свой сайт. Стоит это совсем недорого;

поисковик не «видит» сайты на WordPress — популярный слух. Классический пример вывода из недоказанного. Основан на предположении, что на бесплатных и легких в освоении CMS пишут плохие ресурсы, а значит, поисковый движок должен игнорировать страницы на таких CMS в принципе. Проверяется с помощью любого современного поисковика — скажем, Google. Сделайте любой распространённый запрос, и большинство отображенных ресурсов, веб-приложений будут созданы на WordPress и Joomla — самых популярных бесплатных CMS.

Преимущества WP для web-разработки очевидны. Самое важное из них — масса удобных шаблонов. Их достаточно, а цены уютны даже для бюджетного стартапа — основной целевой аудитории. Кроме того, в WordPress легко создать адаптивы — версии для устройств с нестандартным разрешением экрана (мобильные девайсы).

Но новые версии радуют не только новичков, они также имеют существенные улучшения для профессионалов. Например, теперь система инспектирует код и уведомляет разработчика о допущенных ошибках. Также WР имеет плюсы в плане безопасности. Но и это не новость: большинство CMS хвастаются неуязвимостью, которая близка к абсолюту.

Блокчейн и виртуальная реальность: от концепта до применения в web

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

Блокчейн всему голова

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

Больше всего это затронуло сферу финансов: теперь только ленивый стартап не использует блокчейн в своих бизнес-процессах. Это может быть страхование, как в компании Black Insurance, или полноценный банк, как у Bankera. Весь спектр услуг, которые раньше предлагали большие компании с физическими представительствами, теперь полностью обслуживается веб-приложениями. Сегодня это уже серьезные разработки, а не просто идея, которая звучала на форумах.

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

Еще одна реальность

Существует ошибочное мнение о том, что дополненная и виртуальная реальность — это примерно одно и то же. Но существенные различия все же есть: VR (virtual reality) полностью погружает вас в придуманный разработчиком мир (используются шлемы, вроде Oculus Rift), а AR (augmented reality) накладывает объекты на реальный мир, как в игре Pokemon Go.

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

Также существуют проекты, которые сочетают в себе сразу web-разработку, блокчейн и дополненную реальность. Стартап Mossland смог объединить все это в одном продукте. По сути, разработанное приложение направлено на рекламу и развлечение одновременно. Пользователи делают виртуальные покупки реальных зданий в больших городах, обмениваются ими за внутреннюю валюту и продают игровое пространство под рекламу. Наводя устройство (очки дополненной реальности, камеру смартфона) на объект, пользователь видит его цену, владельца, а также рекламное объявление. Пока веб-приложение только ожидает своего запуска.

Таргет выбран верно: отслеживание активности

Одной из главных современных тенденций в создании веб-продуктов можно назвать контроль за действиями пользователей в сети. Некоторые считают, что это нарушает базовые права человека. Но посмотрим на жизнедеятельность в Интернете трезво: мы здесь давно под колпаком. Google Analytics собирает метаданные о своих юзерах уже несколько лет подряд. С этой точки зрения, ваша активность на одном только сайте — не такая уж и уникальная информация.

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

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

цена;

качество;

непривлекательный товарный вид.

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

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

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Зарегистрироваться

Верстка-Мастер. От теории до верстки популярных шаблонов

Изучите современную верстку сайтов с нуля

Подробнее

Выбор технологий для большого и не очень большого веб-проекта / SECL Group corporate blog / Habr

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

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

Как чаще всего выбирают технологию сейчас:

1. Она мне нравится
2. Знакомый посоветовал
3. Прочитал в Интернете
4. На этой технологии сделан аналогичный сайт

В чем тут проблема:

1. Нравится. Очень субъективно. А что, если по требованиям она не подходит? Или на ней работают очень дорогие и редкие специалисты? Или она вообще умирает?
2. Знакомый. Обычно это тот знакомый, который «чуть лучше» разбирается в ИТ, чем тот, кому он советует. И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомый не CTO Google, я бы так просто не доверял такой рекомендации.
3. Прочитал. Тут уже лучше: можно найти разные сравнения и аргументацию. Но опять же, чтобы разобраться во всех решениях человеку, пусть даже с крепкими знаниями в разработке, нужно время. А без знаний в разработке все прочитанные технические обзоры ничего не стоят.
4. Аналог. Большинство популярных сайтов написаны на тех или иных технологиях, потому что так «исторически сложилось». Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3-х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т.д. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах.

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

Важные критерии при выборе технологий:

1. Размер и тип проекта
2. Сложность проекта
3. Скорость разработки
4. Стоимость специалистов
5. Доступность специалистов
6. Доступные инструменты разработки
7. Наличие готовых решений
8. Гибкость решения
9. Наличие широкого сообщества
10. Отказоустойчивость решения
11. Тренд его развития
12. Наличие подробной документации
13. Стоимость поддержки
14. Требования к нагрузкам
15. Требования к безопасности
16. Кроссплатформенность
17. Возможности интеграции с другими решениями

Выбирая технологию по таким критериям, мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.

Какие бывают проекты

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

По сложности проекты делятся:

1. Простые (визитки, лендинги, простые интернет-магазины, простые приложения) — такие решения обычно делаются на тематических коробочных решениях, CMS или шаблонах.
2. Средние (сложные интернет-магазины и маркетплейсы, порталы национального масштаба, разнообразные сервисы, продвинутые приложения) — такие решения обычно делаются на фреимворках.
3. Сложные (огромные порталы, социальные сети, инновационные и нетиповые решения) — ядро таких проектов обычно разрабатывается на чистом (нативном) языке программирования.

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

Языки программирования

В технологиях я бы выделил 3 уровня абстракции:

1. Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают.
2. Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк, с одной стороны, помогает и ускоряет разработку, а с другой, накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.
3. CMS — это уже готовое решение, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц.

Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреимворки, а на фреимворках делают CMS. Для каждого популярного языка есть много разных фреимворков и CMS, но об этом позже.

Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно о Java, то сегодня это может быть почти любой язык, и утверждать, что сайты делаются на каком-то конкретном языке, — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается, и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.

На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь о небольшом проекте с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес., и он будет работать. Когда же мы говорим о сайте с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.

Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо решать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно только, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, чтобы разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.

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

1. PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Относительно дешевые программисты. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности.
2. Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично, и стоят они не дешево.
3. Ruby — современный язык, разработка на нем также быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало, и они дорогие.
4. Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями.
5. C# — аналог Java, также используют для больших проектов, часть в сфере FinTech.
6. JS — очень быстро развивается, тренд последних лет. Огромное количество наработок, и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получил недавно, потому примеров больших проектов пока мало, специалисты самые дорогие, и найти их сложнее всего.

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

Примеры больших сайтов:

• PHP: Facebook, Вконтакте, КиноПоиск
• Python: Instagram, Pinterest, Reddit
• Ruby: 500px, Groupon, Airbnb
• Java: Ebay, Amazon, Alibaba
• C#: Guru, Stack Overflow, Bank of America
• JS: LinkedIn, Walmart, PayPal

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

Фреймворки и платформы

Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированные, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.

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

Популярные фреймворки и платформы:

1. PHP: Symfony, Laravel
2. Python: Django
3. Ruby: Ruby On Rails
4. Java: Spring
5. C#: .NET
6. JS: Node.js, AngularJS

Больше всего фреймворков на PHP, и на этом языке есть, из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony.

.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.

Недавно мы проводили исследования по тем фреймворкам, на которых специализируемся. Смотрели в каких больших проектах они используются. В частности огромные сайты на Python / Django и огромные сайты на PHP / Symfony. Также мы писали, как мы разрабатывали социальную сеть на Symfony вместе с API (статья больше про API, самое широкое описание в рунете по этой теме). Такие же огромные сайты есть на каждом из перечисленных фреймворках.

CMS и CMF

Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитии языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому что уже есть сильные конкуренты на PHP, а для простого сайта язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.

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

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

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

Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно «тормозят», они абсолютно не гибкие, их очень легко взломать, особенно бесплатные CMS. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не может выдержать большие нагрузки. Это решение небезопасно, чтобы не говорили разработчики конкретной CMS.

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

1. WordPress — некогда блоговый движек, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Система бесплатная.
2. Joomla! — CMS общего назначения. Качеством особо не отличается, на ней делают очень маленькие сайты, и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Система бесплатная.
3. Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Система бесплатная.
4. Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе.
5. PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. Система бесплатная.
6. OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. Система бесплатная.
7. 1С-Битрикс — очень распиаренная CMS общего назначения, номер 1 в рунете. Возможности очень широкие. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Система платная.

Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую — Joomla, с остальными можно работать. Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать.

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

Шаблоны

В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор, и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.

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

Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.

Мобильные приложения

В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.

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

Стек технологий в больших проектах

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

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

Для примера рассмотрим технологии Instagram (данные Insight IT):

• Ubuntu Server 14.04 LTS — основная серверная операционная система
• Python — основной язык программирования серверной части
• Django — фреймворк
• nginx — второй уровень балансировки входящих HTTP-запросов
• gunicorn — WSGI-сервер
• HAProxy — балансировка нагрузки внутри системы
• PostgreSQL — основное хранилище данных
• postgis — поддержка гео-запросов
• pgfouine — отчеты на основе логов
• pgbouncer — создание пула соединений
• Redis — дополнительное хранилище данных
• Memcached — кэширование
• Gearman — очередь задач
• Solr — гео-поиск
• munin, statsd, pingdom — мониторинг
• Fabric — управление кластером
• xfs — файловая система

И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.

Стоимость специалистов

Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это — самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам: https://jobs.dou.ua/salaries/ — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.

Зарплаты:

1. C# – 3072$
2. Java – 3300$
3. JS – 3500$
4. PHP – 2780$
5. Python – 3000$
6. Ruby – 3000$
7. Scala – 3900$

В США немного другая картина:

Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на нем всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala, как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.

Таким образом: если мы хотим экономить, то лучше смотреть на PHP — специалисты дешевые, а комьюнити большое. А если хотим самое качественное, то смотрим на Scala, который называют будущем веб-разработки, но, правда, на нем найти специалистов почти невозможно, и наработок просто нет.

Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одними из самых быстрых в разработке будут Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.

Тренды

Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне и через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.

Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:

По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.

Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Также многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.

Для иллюстрации посмотрим, каких специалистов не хватает в США:

Именно это можно считать реальной картиной трендов, которые мы видим и у нас.

На чем делались большие проекты за последние 10 лет?

1. Airbnb – Ruby
2. Instagram – Python
3. Pinterest – Python
4. Foursquare – Python
5. Groupon – Ruby -> JS
6. Twitter – Ruby -> Scala
7. Uber – JS

Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.

Стоимость поддержки

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

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

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

Так что выбрать?

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

Ниже я сделал опрос по предпочтительному языку программирования для большого проекта. Подразумевается уровень проектов с посещаемостью в 100 млн. пользователей и больше. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения. Разбавим некоторую долю субъективизма статьи мнениями других членов сообщества 🙂

P.S.. В нашей школе есть несколько интересных курсов по программированию. Чтобы записаться пишите на [email protected]

P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK и Twitter.

Автор:
Никита Семенов, CEO, Компания «SECL Group»

Обзор современных WEB технологий

Язык HTML (Hyper Text Markup Language — язык разметки гипертекста) был разработан Тимом Бернерс-Ли во время его работы в CERN и распространен браузером Mosaic, разработанным в NCSA. В 1990-х годах он добился особенных успехов благодаря быстрому росту Web. В это время HTML был расширен и дополнен. В Web очень важно использование одних и тех же соглашений HTML авторами Web-страниц и производителями. Это явилось причиной совместной работы над спецификациями языка HTML. HTML 2.0 (ноябрь 1995) был разработан под эгидой Internet Engineering Task Force (IETF) для упорядочения общепринятых положений в конце 1994 года. HTML+ (1993) и HTML 3.0 (1995) — это более богатые версии языка HTML. Несмотря на то, что в обычных дискуссиях согласие никогда не было достигнуто, эти черновики привели к принятию ряда новых свойств. Усилия Рабочей группы World Wide Web Consortium по HTML в упорядочении общепринятых положений в 1996 привели к версии HTML 3.2.

Большинство людей признают, что документы HTML должны работать в различных браузерах и на разных платформах. Достижение совместимости снижает расходы авторов, поскольку они могут разрабатывать только одну версию документа. В противном случае возникает еще больший риск, что Web будет представлять собой смесь личных несовместимых форматов, что в конечном счете приведет к снижению коммерческого потенциала Web для всех участников. В каждой версии HTML предпринималась попытка отразить все большее число соглашений между работниками и пользователями этой индустрии, чтобы усилия авторов не были потрачены впустую, а их документы не стали бы нечитаемыми в короткий срок. Язык HTML разрабатывался с той точки зрения, что все типы устройств должны иметь возможность использовать информацию в Web: персональные компьютеры с графическими дисплеями с различным разрешением и числом цветов, сотовые телефоны, переносные устройства, устройства для вывода и ввода речи, компьютеры с высокой и низкой частотой.

В HTML 4.0 вводятся механизмы таблиц стилей, скриптов, кадров, внедрения объектов, улучшенная поддержка разных направлений письма и направления справа налево, таблицы с большим количеством возможностей и новые свойства форм, обеспечивая лучшие возможности доступа для людей с физическими недостатками. Эта версия HTML разработана с помощью экспертов в области интернационализации, так что документы можно писать на любом языке и легко передавать их по всему миру. Важным шагом стало принятие стандарта ISO/IEC:10646 в качестве набора символов для документов HTML. Это наиболее содержательный стандарт в мире, в котором решены вопросы представления национальных символов, направления письма, пунктуации и других языковых вопросов. HTML теперь предоставляет лучшую поддержку различных языков в одном документе. Это обеспечивает более эффективное индексирование документов для поисковых машин, типографию высшего качества, преобразование текста в речь, более удобные переносы.

С появлением Internet проблема межплатформной несовместимости файловых форматов стала ощущаться особенно остро: ведь тем, кто размещает информацию в Сети, хочется, чтобы она была доступна как можно более широкому кругу пользователей без особенных затрат. Очевидно, что самый простой путь решения — разработка общепринятого формата файлов, под который и будут «подстраиваться» вновь создаваемые приложения. В WWW таким стандартом стал HTML. Основа WWW — файлы в формате HTML, или гипертекстовые страницы.

Гипертекст — это легкая в использовании и чрезвычайно мощная система связанных слов и фраз, позволяющая легко перемещаться по особым образом организованным страницам. Она связывает фразу или слово одной страницы с любой другой страницей, абзацем, фразой или словом. Если развить идею гипертекста и включить в него графику, видео и звук, мы получим гипермедиа. Гипермедиа — среда, основанная, как и гипертекст, на взаимосвязях, в которой в качестве гиперссылок могут выступать визуальные и аудиокомпоненты. Гипертекст и гипермедиа являются фундаментальными для WWW технологиями, а HTML — средство для работы с этими технологиями. HTML расширение языка SGML (Standart General Markup Language — стандартный язык разметки), глобального стандарта описания языков разметки гипертекста. SGML одобрен ISO (International Organization for Standartization — Международная организация по стандартизации) в 1986 г . и является стандартом для многих государственных и коммерческих систем создания документов. Документы SGML не «привязаны» к какой-нибудь программе, операционной системе и т. п.

Таким образом, когда потребовалось выбрать стандарт для документов WWW, выбор естественно остановился на HTML. Файлы HTML состоят из команд форматирования, текста и ссылок на другие файлы или объекты (графика, звуки, программы). Программа для просмотра HTML-документов (броузер) интерпретирует код HTML, содержащийся в файле, и согласно командам форматирования собирает готовую Web-страничку. Текстовые документы, написанные на этом языке, обрабатываются специальными приложениями, которые осуществляют вывод форматированного текста. Такие приложения, называемые браузерами или интернет-обозревателями, обычно предоставляют пользователю интерфейс для запроса страниц, их просмотра и, возможно, дополнительные возможности [5].. В середине 90-х годов возникла следующее явление. Производители браузеров — Netscape и Microsoft — начали внедрять собственные наборы тегов в HTML разметку. Создалась мешанина из различных конструкций для работы в Web, доступных для просмотра то в одном, то в другом браузере. Особенно большие трудности были при создании кросс-браузерных программ на JavaScript. Веб-мастерам приходилось создавать несколько вариантов страниц или прибегать к другим ухищрениям. Проблема постепенно теряет актуальность по двум причинам:

Из-за вытеснения браузером Internet Explorer от Microsoft всех остальных примерно до 2003 года.

Соответственно проблема веб-дизайнеров становилась проблемой пользователей альтернативных браузеров.

Благодаря следованию других производителей браузеров стандартам W3C (как Mozilla), или же создавая максимальную совместимость с Internet explorer (как Opera).

Поддержка спецификаций W3C в Internet explorer так и не реализована в полной мере, доля продуктов на движке Mozilla растёт. Возможно скоро мы будем наблюдать новый виток браузерных войн.

Возможности html

Язык HTML позволяет размечать в тексте:

Цвет, кегль, жирность, стиль, название шрифта для визуального вывода.

Смысловую роль текстового блока (например: логическое ударение, заголовок, параграф, пункт списка), который обрабатывается браузером в соответствии со смыслом или настройками пользователя…

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

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

Открытие и вывод мультимедийных файлов, выводимых как непосредственно браузером (изображения), аудиофайлы, так и внешними приложениями, также обычно имеющими возможность «встраивания» в окно браузера (Flash-анимация, Java-апплеты).

Версии html

Официальной спецификации HTML 1.0 не существует. До 1995 года существовало множество неофициальных стандартов HTML. Чтобы стандартная версия отличалась от них, ей сразу присвоили второй номер. Версия 3 была предложена W3С в марте 1995, и обеспечивала много новых возможностей вроде поддержки таблиц, обтекание изображений текстом и отображения сложных математических формул. Даже при том что этот стандарт был совместим с второй версией, реализация его была сложна для браузеров того времени. Версия 3.1 официально никогда не предлагалась, и следующей версией стандарта HTML стала 3.2, в которой были опущены многие нововведения из версии 3.0, зато добавлены нестандартные теги поддерживаемые браузерами Netscape и Mosaic. Поддержка математических формул пошла дополнительным стандартом MathML.

Стандарт HTML 3.2 является спецификацией языка разметки гипертекста, предложенной организацией W3C и разработанной в начале 1996 года в кооперации с такими поставщиками, как IBM, Microsoft, Netscape Communication Corporation, Novell, SoftQuad, Spyglass, и Sun Microsystems. Версия 3.2 языка HTML дополнена такими широко распространенными элементами, как таблицы, апплеты и обтекание текстом изображений. При этом обеспечивается полная обратная совместимость с ныне существующим стандартом HTML 2.0. HTML 4.0 также содержит много определенных браузером тегов, но в то же самое время начал пробовать почистить стандарт от лишних тегов.

Новых версий HTML не будет. Однако существует дальнейшее развитие HTML в виде XHTML, основанном на XML.

Структура html документа

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

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

Далее обозначается начало и конец документа тегами и соответственно. Внутри этих тегов должны находиться теги заголовка() и тела() документа.

Значение html

Изначально разработанный для создания Web-страниц, HTML оказался полезным во многих других, иногда неожиданных, приложениях, и поэтому очень скоро развился в мощное средство программирования. Хотя Всемирная паутина считается самым большим «потребителем» HTML, этот язык широко используется при создании корпоративных сетей Intranet, для придания неповторимого облика электронной переписке и даже в разработке графических интерфейсов пользователя (Graphical User Interface, GUI) для индивидуального или сетевого применения. Соответственно, язык разметки приобретает все новые функции и особенности, поэтому сегодняшняя версия (НТМL 4.0) имеет мало общего со своими более простыми и менее амбициозными предшественниками. За несколько лет HTML превратился в мощное и широко используемое средство программирования.

История создания и развития php

PHP (рекурсивный акроним словосочетания «PHP: Hypertext Preprocessor») — это широко используемый язык программирования общего назначения с открытым исходным кодом. PHP сконструирован специально для ведения Web-разработок и может внедряться в HTML-код.

За последние годы PHP прошел долгий путь от набора Perl скриптов, позволяющих следить за посетителями страницы, и до, написанного уже на языке С, одного из самых известных и широко распространенных скриптовых языков для создания сложных, динамических, интерактивных web-сайтов.

PHP лучше всего охарактеризовать как работающий на стороне сервера встроенный язык web сценариев, позволяющий разработчикам быстро и эффективно создавать динамические web-приложения. С позиций грамматики и синтаксиса PHP напоминает язык программирования C, хотя разработчики включили в него некоторые весьма полезные средства из других языков программирования, в том числе из Perl, Java и C++. Среди ценных заимствованных возможностей – поддержка регулярных выражений, мощные средства работы с массивами, объектно-ориентированная методология и обширная поддержка работы с различными базами данных.

История PHP начинается осенью 1994 года. Когда Расмус Лердорф (Rasmus Lerdorf) начал работать над тем, что впоследствии стало PHP, единственной целью, которая была у него в мыслях, выяснить, кто читает его резюме. В то время, являясь независимым подрядчиком, Лердорф рассылал потенциальным работодателям свое мини-резюме с URL ссылкой на его полную версию. Чтобы следить за посетителями, он создал CGI скрипт на Perl-e, который вставлялся как специальный тег в HTML код его страницы, и собирал информацию о посетителях. Чтобы произвести впечатление на потенциальных работодателей, он позволил любому посетителю страницы просматривать собираемую статистику посещений.

Он назвал этот код для сбора статистики «PHP-Tools for Personal Home Page», поскольку сам использовал его на своей персональной домашней странице (personal home page). Несколько человек поинтересовались тем, как они могли бы получить этот инструмент, и Лердорф принял решение предоставить его другим лицам. «Это чудо программного обеспечения. Вы можете дать это и тем не менее оставить это себе», остроумно заметил Лердорф. В то время движения Open Source не существовало. «Тогда оно назвалось freeware». Ближе к концу 1995 года Лердорф открыл для людей первый список рассылки по PHP, чтобы можно было обмениваться идеями, исправлениями ошибок и кодом.

Php/Fi. В результате своих действий, Лердорф получил контракт в Университете Торонто на создание dial-up системы, предоставляющей студентам доступ в интернет. Требование включало разработку административного web интерфейса и возможности доступа студентов к Университетской библиотечной системе, хранившейся на мейнфрейме IBM. Было необходимо, чтобы администраторы библиотеки могли предоставлять студентам доступ на основе платежей, сделанных ими для своих интернет эккаунтов, и, чтобы эта информация обновлялась в базе данных в реальном времени.

В середине 1995 года синтаксический анализатор PHP был переписан на языке C. Кроме того, Лердорф создал некоторое количество тегов для вставки их в HTML код. Эти теги он назвал «Form Interpreters» (интерпретаторы форм) поскольку они должны были получать данные, которые вводились в форме, и преобразовывать эти данные в символьные переменные так, чтобы они могли быть экспортированы в другую систему.

В то время не было инструментов для «стыковки» web-страниц и баз данных. Поэтому Лердорф добавил в PHP поддержку базы данных mSQL, чтобы облегчить разработку web-сайтов, которым необходима реляционная база данных.

Объединив интерпретатор форм с пакетом PHP-Tools, Лердорф подошел в 1996 году ко второй версии PHP, названной PHP/FI. Он отнесся легкомысленно к идее создания из него коммерческого продукта. Но в то же самое время, Лердорф получал огромное число сообщений от других программистов, которые присылали ему улучшения кода и исправления ошибок.

Привести точную статистику непросто, но приблизительно в конце 1996 года PHP/FI использовался не менее чем на 15,000 web-сайтов во всем мире. А в середине 1997 года это число превысило 50,000.

Php 3. PHP 3.0 был первой версией, которая близко походила на тот PHP, который мы знаем сегодня. Он был создан Энди Гутмансом (Andi Gutmans) и Зивом Суразски (Zeev Suraski) в 1997 году как полная переделка предыдущей версии PHP, после того, как они нашли, что возможностей PHP/FI 2.0 сильно не хватает для развития их собственного приложения для eCommerce. Энди Гутманс, Расмус Лердорф и Зив Суразски решили начать работу над новой версией PHP с существующей базы PHP/FI и, объединившись, выпустили PHP 3.0 как официальный последователь PHP/FI 2.0, а развитие PHP/FI 2.0 был в основном прервано.

Одной из наиболее сильных сторон PHP 3.0 были его мощные возможности по расширению. В дополнение к предоставлению конечным пользователям единой инфраструктуры для множества различных баз данных, протоколов и API, были возможности по расширению PHP 3.0, которые привлекли десятки разработчиков к объединению и предоставлению на рассмотрение новых модулей расширения. Возможно, это и было ключом к огромному успеху PHP. Другой возможностью, представленной в PHP 3.0, была поддержка объектно-ориентированного синтаксиса и гораздо более мощный и последовательный синтаксис языка.

Полностью новый язык был выпущен под новым именем, из которого был удален намек на ограниченное персональное использование, который содержался в имени PHP/FI 2.0. Он был назван просто «PHP», со значением, являющимся рекурсивным акронимом – «PHP: Hypertext Preprocessor».

Php 4. К зиме 1998 года, вскоре после официального выхода PHP 3.0, Энди Гутманс и Зив Суразски начали работу по переписыванию ядра PHP. Целью их плана было увеличение производительности сложных приложений и совершенствование модульности основы кода PHP. Существование таких приложений стало возможным благодаря новым возможностям PHP 3.0 и поддержкой PHP широкого диапазона различных баз данных и API сторонних производителей. Но все же PHP 3.0 не был предназначен для эффективной обработки таких сложных приложений.

Новый движок (ядро PHP), прозванный «Zend Engine» (составлено от первых букв их имен – Зив и Энди), успешно удовлетворил этим целям и был впервые представлен в середине 1999 года. PHP 4.0, базирующийся на этом движке и дополненный различными новыми дополнительными возможностями, был официально выпущен в мае 2000 года, почти два года спустя после своего предшественника – PHP 3.0. В дополнение к сильно увеличенной производительности, PHP 4.0 включил другие ключевые возможности, такие как поддержку гораздо большего количества web-серверов, HTTP-сессии, буферизацию вывода, более безопасные пути обработки ввода пользователей и ряд новых языковых конструкций.

Сегодняшняя ведущая команда разработчиков РНР включает специалистов со всего мира. Зив Сураски и Энди Гутманс живут в Израиле, Шейн Каравео (Shane Caraveo) постоянно находится во Флориде, Стиг Беккен (Stig Bakken) – из Норвегии, Андрей Змиевски (Andrei Zmievski) живет в штате Небраска, Саша Шуман (Sasha Schumann) и Тес С. Арнцен (Thes С. Arntzen) – из Германии, Джим Уинстед (Jim Winstead) – из Лос-Анджелеса, а сам отец РНР – Расмус Лердорф, постоянно живет в Северной Каролине. Команда разработки PHP включает десятки разработчиков, и немало других людей работают над проектами, связанными с PHP, такими как PEAR, Smarty и Проект документации. Благодаря открытости ресурсов РНР многие разработчики и любители внесли собственный вклад в развитие и совершенствование РНР.

Php 5. Пятая версия PHP была выпущена разработчиками 13 июля 2004 года. Изменения включают обновление ядра Zend, что существенно увеличило эффективность интерпретатора. Введена поддержка языка разметки XML. Полностью переработаны функции ООП, которые стали во многом схожи с моделью, используемой в Java. В частности, введён деструктор, открытые, закрытые и защищённые члены и методы, окончательные члены и методы, интерфейсы и клонирование объектов. Нововведения, однако, были сделаны с расчётом сохранить наибольшую совместимость с кодом на предыдущих версиях языка. На данный момент самыми стабильными и часто используемыми являются именно версии 5.xx, даже несмотря на то, что уже имеется dev-версия PHP 6.

Php 6. Шестая версия PHP находится в стадии разработки. В ней уже сделано множество нововведений, как, например, исключение из ядра POSIX-регулярных выражений и «длинных» суперглобальных массивов.

Общие сведения о ASP и ASP.NET

ASP (англ. Active Server Pages — «активные серверные страницы») — технология от Microsoft, позволяющая легко разрабатывать приложения для World Wide Web. ASP работает на платформе операционных систем линии Windows NT и на веб-сервере IIS. ASP не является языком программирования — это лишь технология предварительной обработки, позволяющая подключать программные модули во время процесса формирования Web-страницы. Относительная популярность ASP основана на простоте используемых языков сценариев (VBScript или JScript) и возможности использования внешних COM-компонент.

ASP.NET — это технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 2.0.

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

Хотя ASP.NET берёт своё название от старой технологии Microsoft, ASP, она значительно от нее отличается. Microsoft полностью перестроила ASP.NET, основываясь на Common Language Runtime (CLR), который является основой всех приложений Microsoft.NET. Программисты могут писать код для ASP.NET, используя различные языки программирования, поддерживаемые в .NET Framework, обычно Visual Basic.NET, JScript .NET или C#, а также «открытые» языки, например, Perl и Python. ASP.NET имеет преимущество в скорости по сравнению с другими технологиями, основанными на скриптах, потому что код на стороне веб-сервера обычно компилируется в одну или несколько DLL.

Преимущества ASP.NET перед ASP

Компилируемый код выполняется быстрее, большинство ошибок отлавливается ещё на стадии разработки

Значительно улучшенная обработка ошибок времени выполнения

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

Использование метафор, уже применяющихся в Windows-приложениях, например, таких как элементы управления и события

Расширяемый набор элементов управления и библиотек классов позволяет быстрее разрабатывать приложения

ASP.NET опирается на многоязыковые возможности .NET, что позволяет писать код страниц на VB.NET, C++, J# и т.д.

Возможность кэширования всей страницы или её части для увеличения производительности

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

История создания java

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

Рождению языка Java предшествовала довольно интересная история. В 1990 году разработчик ПО компании Sun Microsystems Патрик Нотон (Patrick Naughton) понял, что ему надоело поддерживать сотни различных интерфейсов программ, используемых в компании, и сообщил исполнительному директору Sun Microsystems и своему другу Скотту МакНили (Scott McNealy) о своем намерении перейти работать в компанию NeXT. МакНили, в свою очередь, попросил Нотона составить список причин своего недовольства и выдвинуть такое решение проблем, как если бы он был Богом и мог исполнить все, что угодно.

Нотон, хотя и не рассчитывал на то, что кто-то обратит внимание на его письмо, все же изложил свои претензии, беспощадно раскритиковав недостатки Sun Microsystems, в частности, разрабатываемую в тот момент архитектуру ПО NeWS. К удивлению Нотона, его письмо возымело успех: оно было разослано всем ведущим инженерам Sun Microsystems, которые не замедлили откликнуться и высказать горячую поддержку своему коллеге и одобрение его взглядов на ситуацию в Sun Microsystems. Обращение вызвало одобрение и у высшего руководства компании, а именно, у Билла Джоя (Bill Joy), основателя Sun Microsystems, и Джеймса Гослинга (James Gosling), начальника Нотона.

В тот день, когда Нотон должен был уйти из компании, было принято решение о создании команды ведущих разработчиков с тем, чтобы они делали что угодно, но создали нечто необыкновенное. Команда из шести человек, с кодовым названием Green, ушла в самовольное изгнание, погрузившись в исследования бытовых устройств, таких как Nintendo Game Boys, устройств дистанционного управления. Команда Green пыталась найти средство, с помощью которого можно было бы установить взаимодействие между этими устройствами. Вскоре стало ясно, что такие электроприборы, как видеомагнитофоны, проигрыватели лазерных дисков, стереосистемы — все они были реализованы на разных процессорах. Это означало, что если производитель захочет добавить телевизору или видеомагнитофону дополнительные функции или характеристики, он будет зажат в рамках средств, зашитых в аппаратное обеспечение. Эта проблема, в сочетании с ограниченностью памяти микросхем этих устройств, выдвинула новый подход к программированию ПО, который должен был стать ведущим на рынке бытовой электроники.

Команда приступила к разработке нового объектно-ориентированного языка программирования, который был назван Oak (дуб), в честь дерева, росшего под окном Гослинга.

Вскоре компания Sun Microsystems преобразовала команду Green в компанию First Person. Новая компания обладала интереснейшей концепцией, но не могла найти ей подходящего применения. После ряда неудач неожиданно ситуация для компании резко изменилась: был анонсирован Mosaic — так родился World Wide Web, с которого началось бурное развитие Internet.

Нотон предложил использовать Oak в создании Internet- приложений. Так Oak стал самостоятельным продуктом, вскоре был написан Oak-компилятор и Oak-браузер «WebRunner». В 1995 году компания Sun Microsystems приняла решение объявить о новом продукте, переименовав его в Java (единственное разумное объяснение названию — любовь программистов к кофе). Когда Java оказалась в руках Internet, стало необходимым запускать Java-аплеты — небольшие программы, загружаемые через Internet. WebRunner был переименован в HotJava и компания Netscape встала на поддержку Java-продуктов.

О технологии java

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

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

За последние годы увеличилось множество несовместимых аппаратных архитектур, каждая из которых поддерживает множество несовместимых операционных систем, которые, в свою очередь, управляют несовместимыми графическими пользовательскими интерфейсами. Задача создания распределенных клиент-серверных сред сталкивается с проблемой интеграции подобных разрозненных продуктов. Развитие Internet, World Wide Web и электронного бизнеса привнесло новый уровень сложности в процесс разработки. Язык Java компании Sun Microsystems решает эти проблемы. Java является объектно-ориентированным и одновременно простым языком программирования. Цикл разработки программных средств с использованием Java значительно сокращается в силу того, что Java — интерпретируемый язык. Процесс компиляции-сборки-загрузки устарел — теперь программу надо только откомпилировать и сразу запускать.

Приложения переносимы на многие платформы. Однажды написанное приложение не придется модифицировать под другие платформы: оно будет работать без каких-либо изменений на различных операционных системах и аппаратных архитектурах. Приложения надежны так как Java контролирует обращения к памяти. Несмотря на то, что язык Java — интерпретируемый, код Java программы оптимизируется до фазы исполнения в следствии чего получаем высокую производительность. Поддержка системы многопоточности позволяет создавать параллельно исполняемые взаимодействующие легковесные процессы. Возможна динамическая загрузка программных модулей из любого места в сети. Пользователи могут быть уверены в безопасности приложений, даже если в них загружен программный код из любого места в Internet. Исполняющая система Java имеет встроенную защиту от вирусов и попыток взлома.

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

Основные характеристики языка java

Развитие Internet и World Wide Web заставляет совершенно по-новому рассматривать процессы разработки и распределения программного обеспечения. Для того, чтобы выжить в мире электронного бизнеса и распространения данных, язык Java должен быть

безопасным,

высокопроизводительным,

надежным.

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

нейтральным к архитектуре,

переносимым,

динамически подстраиваемым.

Разработчики Java с самого начала хорошо понимали, что язык, предназначенный для решения проблем гетерогенных сред, также должен быть

простым

ясным

объектно-ориентированным

многопоточным

интерпретируемым

Более подробно рассмотрим перечисленные характеристики Java.

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

Разработчиками Java было принято во внимание, что многие программисты хорошо знакомы с языком С++, поэтому Java, насколько это возможно, приближен к С++.

В Java не включены некоторые редко используемые, плохо понимаемые и усложняющие работу возможности С++, которые приносят больше проблем, чем преимуществ. Пришлось отказаться от

перегрузки операторов (но перегрузка методов в Java осталась),

множественного наследования,

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

Добавилась автоматическая сборка мусора, упрощающая процесс программирования, но несколько усложняющая систему в целом. В С и С++ управление памятью вызывало всегда массу проблем, теперь же об этом не придется много заботиться.

Объектно-ориентированность. Язык Java с самого начала проектировался как объектно-ориентированный. Задачам распределенных систем клиент-сервер отвечает объектно-ориентированная парадигма: использование концепций инкапсуляции, наследования и полиморфизма. Java предоставляет ясную и действенную объектно-ориентированную платформу разработки. Программисты на Java могут использовать стандартные библиотеки объектов, обеспечивающие работу с устройствами ввода/вывода, сетевые функции, методы создания графических пользовательских интерфейсов. Функциональность объектов этих библиотек может быть расширена.

Надежность. Платформа Java разработана для создания высоконадежного прикладного программного обеспечения. Большое внимание уделено проверке программ на этапе компиляции, за которой следует второй уровень — динамическая проверка (на этапе выполнения). Модель управления памятью предельно проста: объекты создаются с помощью оператора new. В Java, в отличие от С++, механизм указателей исключает возможность прямой записи в память и порчи данных: при работе с указателями операции строго типизированы, отсутствуют арифметические операции над указателями. Работа с массивами находится под контролем управляющей системы. Существует автоматическая сборка мусора. Данная модель управления памятью исключает целый класс ошибок, так часто возникающих у программистов на С и С++. Программы на Java можно писать, будучи уверенным в том, что машина не «повиснет» из-за ошибок при работе с динамически выделенной памятью.

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

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

Переносимость. Архитектурная независимость — лишь составная часть переносимости. В отличие от С или С++ в Java не существует понятия «зависимости от реализации», когда речь идет о размерности базовых типов. Форматы типов данных и операции над ними четко определены. Тем самым, программы остаются неизменными на любой платформе — не существует несовместимости типов данных на аппаратных и программных архитектурах. Архитектурная независимость и переносимость программного обеспечения Java обеспечивается виртуальной машиной Java (Java Virtual Mashine — JVM) — абстрактной машиной, для которой компилятор Java генерирует код. Специальные реализации JVM для конкретных аппаратных и программных платформ предоставляют уже конкретную виртуальную машину. JVM базируется на стандарте интерфейса переносимых операционных систем (POSIX).

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

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

Многопоточность. Большинству современных сетевых приложений обычно необходимо осуществлять несколько действий одновременно. В Java реализован механизм поддержки легковесных процессов-потоков (нитей). Многопоточность Java предоставляет средства создания приложений с множеством одновременно активных потоков. Для эффективной работы с потоками в Java реализован механизм семафоров и средств синхронизации потоков: библиотека языка предоставляет класс Thread, а система выполнения предоставляет средства диспетчеризации и средства, реализующие семафоры. Важно, что работа параллельных потоков с высокоуровневыми системными библиотеками Java не вызовет конфликтов: функции, предоставляемые библиотеками, доступны любым выполняющимся потокам.

Динамичность. По ряду соображений Java более динамичный язык, чем С++. Он был разработан специально для подстройки под изменяющееся окружение. В то время как компилятор Java на этапе компиляции и статических проверок не допускает никаких отклонений, процесс сборки и выполнения сугубо динамический. Классы связываются только тогда, когда в этом есть необходимость. Новые программные модули могут подключаться из любых источников, в том числе, поставляться по сети. В случае с браузером HotJava и другими подобными приложениями интерактивный выполняемый код может быть загружен откуда угодно, что позволяет производить прозрачные модификации приложений. В результате возможно создание интерактивных служб, безболезненно модифицируемых, обслуживающих большое количество клиентов и обеспечивающих развитие электронного бизнеса через Internet.

На парусах HTML5. Как новые технологии меняют современный веб / Microsoft corporate blog / Habr

Статья по следам моего доклада на концеренции User Experience`11.

Что такое HTML5?

Сегодня про HTML5 их числа тех, кто так или иначе связан с веб-разработкой, не слышал только ленивый. Вы не сильно прогадаете, предположив, что на каждой модной конференции, где есть что-то про веб, почти наверняка, звучит и что-то про HTML5. Практически каждая крупная компания, связанная с вебом, будь то Google, Apple, Microsoft, Amazon, Adobe, Oracle, Facebook, Яндекс, Mail.ru… говорит что-нибудь про HTML5, расписывается в любви на века и приверженности продвижению и развитию HTML5. Yeah! (Opera и Mozilla, безусловно, тоже в этом списке.)

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

Огромные перспективы, новая волна развития веба, новое поколение веб-приложений! Круто.

Я не буду рассказывать, что такое HTML5. В контексте статьи важно ясно понимать одну вещь: есть два понимания HTML5.

Первое — это стандарт HTML5, документ, лежащий на сайте W3C, в котором описаны все новые теги, атрибуты, новые API, и ряд сопутствующих документов, в которые вынесены некоторые дополнительные детали, вроде API для Canvas.

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

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

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

Революции для «HTML5» и в «HTML5»

Чтобы лучше понимать, куда движется современный веб, первое, на что нужно обратить внимание, — это характерные трансформации, произошедшие в ИТ-индустрии в целом и веб-индустрии в частности. Мир, который мы наблюдаем сегодня заметно отличается от того, каким он был каких-то 5-10 лет назад (напомню, что HTML 4.01 был утвержден более 11 лет назад).

Среди этих изменений нельзя не отметить следующие:

• Новое железо. Графические чипсеты, многоядерные процессоры и различные сенсоры, проникающие в совершенно разные устройства, вплоть до мобильных телефонов, а также большое стремление к энергоэффективности (как тут не вспомнить ARM и Intel Atom). Плюс огромное разнообразие форм-факторов: от мобильных устройств, планшетов, таблеток, нетбуков и ноутбуков до стационарных компьютеров и телевизоров. И везде хочется иметь доступ к интернету!
• Новые веяния в сервисах. Облако, социальность, мобильность и постоянная доступность независимо от устройства доступа.
• Изменения в браузерах. Рост конкуренции — сегодня на рынке целых пять браузеров, имеющих долю достаточную для того, чтобы их нельзя было игнорировать. Плюс, конечно, мобильный зоопарк 🙂 И важный момент: сегодня (или завтра) современный браузер знает и про графическое ускорение, и про многоядерную архитектуру, и про сенсоры и различные медийные устройства ввода, и про энергоэффективность, и про облако и про социальные сервисы, и про мобильность. Конкретные детали могут отличаться от браузера к браузеру, но общий тренд очевиден.

Все это находит очевидное воплощение в тех или иных веб-стандартах, поэтому сегодня мы имеем действительно новое и постоянно растущее поколение технологий (буквально недавно Adobe на своей конфереции Adobe MAX представила предложение нового стандарта и вариант его реализации — фильтры и шейдеры для CSS):

• HTML: Semantics, Graphics, Multimedia, WebForms, Security, DnD, History, Offline…
• CSS: Fonts, Colors, Borders & Backgrounds, Layouts, Media Queries, Transformations, Transitions & Animations…
• APIs: Geolocation, DB & LocalStorage, Sockets, Files, Media, Workers…
• JS: ECMAScript5

Важно также понимать, что между всеми этими инновациями в устройствах, ПО, сервисах, стандартах и различных практиках разработки существуют тесные переплетения — и то, что мы сейчас наблюдаем в области веб-разработки и веб-стандартов, безусловно, найдет свое отражение и в различном ПО, реализующем и поддерживающем эти стандарты (от инструментов разработки до браузеров и ОС), и на железном уровне (возможно, даже сбудется мечта Google и в ключевых устройствах появится аппаратная поддержка webm ;).

Теперь давайте поговорим о том, как, собственно, меняется современный веб и какие технологии и практики за этим стоят.

5A

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

Чем больше у вас A-A-A-A-A, тем лучше. Чем меньше, тем унылее. А-а-а-а-ах! — хорошо. А-а-ууууууу — плохо.

Будет хорошо, если обдумывая свой следующий проект или анализируя текущий, вы посмотрите на него и сквозь призму этих «A».

A1. Accessible

Первое A — это Accessible. Сайт должен быть доступным. Безусловно, это включает вопросы доступности для людей с ограниченным возможностями (Accessebility), но не только. Сайт должно быть доступен для всех участников интернета и это также включает поисковые механизмы и любые программы, задачей которых является извлечение смысла ваших документов.

Тут самое место и время вспомнить про семантическую разметку и правильный баланс между разметкой, стилями и логикой на JavaScript. Сегодня реальность такова, что не просто из разметки выносится по возможности все, что относится к части представления контента, но и часть вещей из JS выносится в декларативное описание на CSS.

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

Часть существующих тегов в HTML5 приобретает новое значение. Так, если раньше выбор между i и em (аналогично b и strong) был чаще в пользу более короткого написания, то сегодня это теги с различной смысловой нагрузкой, даже если по умолчанию они имеют одинаковое представление курсивом или жирным начертанием.

См. также статью HTML5. Семантика или разметка со смыслом.

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

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

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

Наконец, тема, которую также не могу не упомянуть в этом блоке — это HMTL Microdata. Microdata представляет собой развитие идей микроформатов и предлагает правила аннотации данных в соответствии с теми или иными схемами:

<div itemscope itemtype="http://schema.org/Person">
   <span itemprop="name">Konstantin Kichinsky</span>
   <img src="http://a1.twimg.com/profile_images/1464844323/avatarh5f_reasonably_small.png" itemprop="image" />  
   <span itemprop="jobTitle">ADE</span>
   <a href="http://constantin.kichinsky.ru" itemprop="url">constantin.kichinsky.ru</a>
</div>

См. примеры схем на сайте http://schema.org/ — тут собраны шаблоны, поддерживаемые Bing, Google и Yahoo!

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

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

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

Проявления обоих тенденций мы еще не раз увидим 😉

A2. Adaptive

Второе A — это Adaptive. Сайт должен быть адаптивным под окружающие его условия, подстраиваться под внешнюю обстановку. Тут надо сказать, что адаптивность не есть что-то сильно дополнительное по отношению к доступности сайта, это скорее расширение и развитие, потому что адаптивность должна вырастать из идей доступности.

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

В принципе, адаптация базируется не только на конкретных стандартах, но и на различных техниках и подходах, которые могут применяться в процессе дизайна и разработки веб-сайтов, а также всевозможных их сочетаниях. В этом контексте я хочу упомянуть два важных термина, в сторону которых вам обязательно стоит посмотреть: Responsive Design (см. статью Responsive Web Design by Ethan Marcotte) и Progressive Enhancement (см. статью Progressive Enhancement and the Future of Web Design by Steven Champeon).

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

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

Вы можете представить себе большую схему различных сценариев, где по горизонтали будут всевозможные разрешения экранов (и связанные с ними форм-факторы), а по вертикали будет движение от менее продвинутых браузеров к более современным. Responsive Design и Progressive Enhancement — это способы навигации (и мышления) для движения вверх и вниз, вправо и влево.

Давайте посмотрим на несколько конкретных технологий и веб-стандартов.

CSS3 Media Queries

Первая задача, с которой вы все сталкиваетесь, это адаптация сайта под различные разрешения экрана. Проблема здесь в том, что их много, они разные и постоянно появляются новые. Я думаю, все, кто занимается веб-разработкой (или дизайном) не первый год, помнят все эти разговоры про то, пора или не пора переключаться с минимального размера 800x600px на больший 1024x768px, изучение статистики и трендов в размере экрана у среднестатистического пользователя.

Вообще говоря, сегодня этот вопрос, да и сама постановка такого вопроса уже не актуальны. Знаете почему? Потому что вместо того, чтобы постепенно прийти ко все большим и большим размерам экрана, на самом деле мы пришли ко все большему и большему разнообразию размеров экрана, причем в обе стороны — к маленким мобильным вроде 480x800px и большим у современных мониторов — 1920x1080px и более.

Причем во всем этом диапазоне на конечном устройстве может работать современный браузер — будь это движок IE (от Windows Phone до десктопной Windows) или один из движков на базе webkit (от iPhone и iPad до MacOS X и десктопной Windows), а могут быть и совсем разные движки, включая огромный зоопарк java-браузеров в различных мобильных устройствах.

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

Если на несколько минут ограничиться современным движками, вы обнаружите, что все они поддерживают специальную технологию, которая называется Media Queries (это один из модулей CSS3).

CSS3 Media Queries расширяет традиционные Media Types, доступные еще в HTML 4.01 и CSS 2.1, и позволяет более прицельно определять правила CSS в зависимости от различных параметров контекста воспроизведения, будь то размеры экрана, ориентация устройства, глубина цвета, монохромная или цветная печать и т.п.

Идея Media Queries заключается в том, что вы можете определить, как размещать контент, какой контент показывать, а какой нет, в зависимости от значения всех этих параметров. Если экран маленький, значит нужно перегруппировать все элементы так, чтобы они разумно умещались в маленький экран, если большой, где-то можно более оптимально занять доступное место, а где-то и побольше показать. Вы можете самостоятельно посмотреть, как это все работает в примерах, собранных на сайте http://mediaqueri.es

Использование Media Queries, кстати, сильно завязывается на то, что вы действительно отделяете разметку контента от его представления. Поэтому доступность (и семантичность) лежит во главе угла. Плюсом является то, что вы делаете один сайт под разные устройства. Устройства, не знающие Media Queries, проигнорируют ваши правила.

Обычно в простых сценариях достаточно возможностей только CSS 2.1 и модуля Media Queries, но в случаях сложной верстки, чтобы сделать что-то стоящее и к тому же эффективное в исполнении, нужны дополнительные инструменты.

Вам, наверняка, придутся по душе многие другие модули CSS3, отлично сочетающиеся с идеями Media Queries.

Посмотрите в сторону CSS3 Exclusions and Shapes (ранее Positioned Floats), позволяющего настраивать позиционирование отдельных элементов относительно обтекающего их контента, причем поведение контента в свою очередь может определяться другими параметрами, включая размеры экрана и режимы размещения:

В примере выше CSS3 Exclusions используется в сочетании с многоколоночной версткой и версткой с использованием сетки.

О последнем нужно сказать отдельно. Размещение блоков по сетке — огромная головная боль всех верстальщиков. Когда-то это была табличная верстка, потом это стало немодным и почти все признали этот подход неверным. Стали использовать блочную верстку c многоэтажными css-правилами, если требовалось сделать что-нибудь более сложное, чем верстку в две-три колонки.

Среди новых модулей CSS3 есть и модуль, посвященный именно этой задаче, — CSS3 Grid Layout. Grid позволяет выстроить элементы по виртуальной сетке. Это довольно мощный инструмент — представьте себе, что вы просто можете использовать разные сетки для ваших блоков при различных разшерениях экрана! Скоро сможете 😉

Еще один интересный модуль — CSS3 Flexible Box, позволяющий вашим блокам заполнять отводимое под них пространство в соответствии с вашими пожеланиями, будь то заполнение свободного пространства или распределение пространства между блоками в заданной пропорции. Сегодня многие подобные задачи решаются с помощью различных ухищрений в верстке и стилевых правилах, завтра будет достаточно указать, что именно требуется (см. также статью CSS3 Flexible Box Layout Explained by Richard Shepherd).

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

Теперь давайте вернемся к Progressive Enhancement.

Progressive Enhancement

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

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

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

Как это работает? Очень просто.

Думаете над применением чего-то из арсенала CSS3 Borders & Backgrounds? Сделайте квадратные уголки для тех, кто не поддерживает круглые, и круглые для тех, кто их поддерживает. Нечего городить вокруг постройки оберток и ползать тут со своим скотчем. Сделайте сплошной фон для старых браузеров и градиентный для современных. Если можно обойтись одним фоновым изображением в IE6-8, оставьте использование множественных фонов для IE9+.

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

Думать о Progressive Enhancement можно в духе аналогии с телевидением. Мы прошли долгий путь от черно-белого эфира к цветному и далее видео высокой точности. И (пока речь идет об аналоговой технологии), старые телевизоры могут по-прежнему показывать современные передачи, но в черно-белом варианте. Зрители знают, что в современном телевизоре картинка будет лучше. Однако, передаваемый сигнал не зависит от телевизора.

A3. Agile

Третье A — это Agile. Мир сложен и иногда недостаточно быть просто доступным и адаптивным под какие-то разные, но общие параметры. Сайт должен быть гибким и должны быть гибкими принимаемые технологические решения.

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

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

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

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

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

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

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

К примеру, известная игра Angry Birds, выполненная на HTML5, для воспроизведения музыкального сопровождения и аудио-эффектов использует Adobe Flash. Это может показаться странным, однако, это нормальное, гибкое технологическое решение, позволяющее использовать те, технологии, которые доступны и достаточно эффективно работают в широком диапазоне браузеров. В данном случае разработчики столкнулись с рядом проблем в воспроизведении аудио через audio-элемент в HTML5 (кстати, это был не Internet Explorer, а другой популярный браузер 😉 и для решения задачи воспользовались флешем. Это пример гибкого сочетания технологий без вовлечения религиозных чувств.

Другой характерный пример — Kindle Cloud Reader от Amazon. Это браузерное приложение, позволяющее читать книги прямо через браузер, причем оно работает даже в offline-режиме. Этот чудесный момент мы рассмотрим чуть позже. Что нам интересно сейчас, так это технологическая гибкость.

Не знаю всех бизнес-деталей мотивации Amazon, но, в конечном счете, в Kindle Cloud Reader явно проявляется стремление компании напрямую взаимодействовать с конечными пользователями через браузер, минуя магазины приложений. Если вы посмотрите на первоочередную целевую аудиторию — это пользователи iPad и планшетов на Android.

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

Webkit поддерживает технологию WebSQL Database, позволяющую делать именно то, что нужно: хранить данные в локальном хранилище. В этот момент, если вы знакомы с новыми веб-стандартами, у вас должно что-то щелкнуть. На самом деле, на сайте W3C красными буквами в рамочке и дополнительно белыми на черном фоне с желтыми кружочками (см. выше) написано, что развитие технологии остановлено. В реальности сегодня W3C и разработчики браузеров смотрят в сторону альтернативной технологии — IndexedDB (и Local Storage для относительно простых сценариев).

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

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

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

Хотя эта технология и доступна только в IE, она позволяет небольшими усилиями расширить функционал сайта, сделать его более доступным и адаптироваться под дополнительные возможности. Это гибкое расширение UX пользователя во взаимодействии с сайтом.

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

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

Это так называемые fallback-сценарии, когда, к примеру, в старых браузерах конкретный неподдерживаемый (как правило, не потому что браузеры плохие, а потому что они старые) механизм реализуется через другие доступные технологии:

• HTML5 Video ⇒ Flash | SL ⇒ File
• Web Sockets ⇒ Flash | SL ⇒ Comet
• Canvas ⇒ Flash | SL
• SVG ⇒ VML | Flash | SL
• …

В каких-то случаях возникающая разница между современным уровнем и тем, что есть в старых браузерах заполняется с помощью так называемых Polyfills (см. статью What is a Polyfill? by Remy Sharp).

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

И, конечно, не забывайте про использование подхода Feature Detection и библиотеки Modernizr.

A4. Async

Четвертое A — это Async. Сайт должен понимать асинхронность нашего мира и его веб-части в частности. Может показаться, что асинхронность — это что-то совершенно отличное от всего того, что мы обсуждали до этого, но, на самом деле, это не так.

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

Проблема асинхронности возникает в нескольких ключевых точках, о которых важно всегда помнить:

• Взаимодействие с сетью
• Взаимодействие с сервером
• Процессы в браузере
• Взаимодействие с пользователем

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

Например, что будет с сайтом, если пропадет соединение с интернетом? Очевидный ответ из вчерашнего дня: сайт не будет работать. Сегодня у нас есть ответ получше: сайт может оставаться функциональным, но не будет получать обновления из сети и не сможет отсылать запросы на сервер. Посмотрите в сторону Application Cache из HTML5 и локальных хранилищ данных, они открывают огромное количество новых сценариев.

Что будет с сайтом, если долго нет ответа от сервера? Может быть, он просто упал, а может быть, вышел timeout? Или, может быть, просто временно пропало соединение? На все эти вопросы сайт (или приложение) должен уметь давать ответы конкретным поведением в сложившейся ситуации. Или другой вариант: нужно поддерживать постоянное соединение с веб-сервером для регулярного обмена сообщениями. Можно использовать старый добрый AJAX и технологии на его базе, а можно посмотреть в сторону Web Sockets там, где эта технология уже поддерживается сегодня.

Что, если вам необходимо на клиентской стороне произвести какой-то рассчет, обработку данных или, к примеру, локального файла, загруженного через File API? Все такие процессы потенциально могут привести к блокированию потока UI, что крайне нежелательно. Выходом могут стать технологии Web Workers и Web Messaging, позволяющие запускать выполнение задач на JavaScript в отдельных потоках и осуществлять взаимодействие между ними.

Да, все такие вопросы усложняют решение, но в итоге выигрывает пользователь. Это стоит того.

A5. Attractive

Наконец, пятое A — это Attractive. Сайт должен быть привлекательным для пользователя. И, это тоже еще один взгляд на вопросы доступности, адаптивности, гибкости и асинхронности. Пользователя привлекает решение, которое подстраивается под него и удобно ему.

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

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

Здесь вам в помощь и графические возможности HTML5 — Canvas и SVG, и мультимедийные HTML5 Audio и Video, и огромное количество новых возможностей CSS, включая типографику, анимации, трансформации и различные эффекты.

Посмотрите, например, на комикс для диснеевского Трона, сделанный с помощью HTML5 Canvas. Это уже не просто последовательность картинок, а целое интерактивное представление, с которым зритель может взаимодействовать. Совершенно другой уровень!

Посмотрите заодно и комикс Never Mind the Bullets. Это тоже интерактивный сценарий, но на этот раз используются возможности CSS3 с множественными фонами, позволяющие создать эффект паралакса. Это действительно вовлекает зрителя в процесс разворачивающихся событий.

Наконец, просто не могу пройти мимо новой фишки Bing, если раньше это были каждодневные классные и уникальные фотографии, то теперь Bing периодически радует классными видео-фонами на HTML5 Video (если у вас не работает, попробуйте сменить регион на USA).

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

5A. Заключение

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

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

Печеньки на стороне 5A. Спасибо вам, что делаете сайты!

p.s. Упомянутые технологии и IE

На всякий случай суммирую упомянутые в статье технологии:

• HTML5 Semantic Tags — IE9+ (+HTML5 Shim для <IE9)
• HTML5 Canvas, Audio + Video, SVG — IE9+
• HTML5 Offline|Application Cache, Web Forms — IE10+
• ARIA, role attributes — IE8+, IE9+
• CSS3 Media Queries, Transforms 2D, Fonts (Font-face + WOFF), Borders & Backgrounds (Border Radius, Multiple Backgrounds) — IE9+
• CSS3 Exclusions and Shapes, Grid Layout, Flexible Box, Transforms 3D, Transitions, Animations, Borders & Backgrounds (Gradients) — IE10+
• Web Storage — IE8+
• IndexedDB, Web Sockets, Web Workers, Web Messaging — IE10+
• IE Pinned Sites — IE9+

Это далеко не все новые возможности, доступные в IE и других браузерах.

выбери себе приключение / Авито corporate blog / Habr

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

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

upd — немного дополнил текст до ката.

Предположим, что я и мой друг Валерка решили сделать стартап. Uber for X, или там еще что-нибудь в таком духе. Собрались в баре, обсудили эту идею, клёвая тема. Надо сделать. Три месяца не спали, не ели, не выходили из дома. Разрабатывали. Запустили и поняли, что это никому не нужно.

Печаль. Попробуем еще раз. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. Прототип взлетел. Круто, идем дальше.

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

Язык

По порядку. На каком языке писать? Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.

Попытка номер два. Можно взять что-нибудь проверенное временем. Например, PHP. Это неплохой язык, его модно иногда критиковать, у него есть свои минусы, но на нем легко делать бизнес-логику, он достаточно быстрый, неплохо масштабируется, можно нанять людей когда угодно и где угодно. Но он не очень производительный. Поэтому нам нужно либо много железа, либо писать свой компилятор, как сделали Facebook или ВК.

Еще варианты? Можно взять Perl, но тогда будет некого нанимать ещё вчера. Ещё?
Java. Java — норм. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам.

Ладно, у нас есть еще Python. В принципе, у него всё ок. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Либо можно взять что-то современное: Go, Rust, еще что-то. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать. Пусть в итоге это будет JS, сойдет.

База данных

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

Ок, давайте возьмем реляционную базу. MySQL, PostgreSQL, или Oracle, если денег хватит. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. Это не обязательно произойдёт с нашим проектом. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Долго делаем фичи.

Ладно. Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Когда-нибудь (spoiler: никогда).

Архитектура

Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».

Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Сервисы уже работают в продакшене, а мы их не тестируем. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Поэтому мы долго делаем фичи.

Ок, тогда давайте бахнем монолит. Это самая правильная идея для стартапа. Очень долго можно жить с отличным монолитом и не иметь проблем. Но если мы решим сильно расширить команду, то надо быть осторожнее. Монолит нормально масштабируется, пока разработчиков 20, 30, 50. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей.

Где запускать проект?

Это всё надо где-то запускать. 2018 год, самый логичный вариант сделать это в облаке. Запустишь не в облаке — пацаны засмеют. Но, во-первых, есть федеральный закон 152, значительно ограничивающий выбор облачных провайдеров, у которых можно хоститься. Во-вторых, очень легко приватный ключ от своего аккаунта на Amazon случайно закоммитить в Github, и кто-то обязательно придёт и потратит все ваши деньги. А если этого не произойдёт, то в какой-то момент вас разорят облачные тарифы.

Можно арендовать дата-центр. Может, это не так ресурсоэффективно изначально, но в долгосрочной перспективе, вероятно, обойдётся дешевле, чем хоститься в облаке. Но тут нужны люди, которые это будут поддерживать. По моему опыту, те, кто это любят и умеют делать, не очень любят общаться со всеми остальными, поэтому они организуются в отдел. А отдел – это сепаратизм. Я имею в виду то, что внутри команды админов будет легче обмениваться опытом, но в будущем это может работать не очень хорошо. Будут вопросы с приоритезацией задач от других коллег, с синхронизацией. Другие специалисты не будут знать, что происходит внутри отдела, который поддерживает наш дата-центр.
В общем, сепаратизм нам не подходит. Логично переходим к вопросу набора команды.

Разработка

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

• токсичными пижонами, которые ничего не будут делать и создадут плохую атмосферу в коллективе,
• либо идеалистами, выстраивающими по крупицам безукоризненную архитектуру, ставящими ORM перед базами, которые никогда менять не придется…

В итоге… да-да, долго делаем фичи. Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Это не очень эффективно. Как это можно решить? Начальник может читать весь код. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли). Понятно, это не масштабируется и все медленно делают фичи.

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

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

Quality Assurance

Можно сказать, что QA-специалисты нам не нужны. Многие так делают, это иногда работает. Но не все разработчики любят писать тесты. Их можно понять. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты.

Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.

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

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

Как это разрулить? Общаться с коллегами в кружках по интересам. Где-то это называют гильдиями, где-то — коммьюнити. Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити…

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

А ещё — всё это интересно. Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. Интересно делиться знаниями.

Лекции Технопарка. 1 семестр. Web-технологии / Mail.ru Group corporate blog / Habr

Сегодня этим постом мы открываем цикл еженедельных публикаций учебных материалов Технопарка. Если кто-то ещё не знает, Технопарк — это совместный образовательный проект Mail.Ru Group и МГТУ им. Н. Э. Баумана. На данный момент здесь проходит обучение по 20 IT-дисциплинам 91 наиболее талантливый студент. Технопарк существует с 18 ноября 2011 года, а первые счастливчики приступили к занятиям в декабре 2011 года.

Обучение в Технопарке совершенно бесплатное, оно проходит после занятий в университете. Стать участниками проекта могут студенты 3-5 курсов. Хотя для 2 и 6 курсов можем сделать исключение. Обучение длится 2 года, оно разбито на 4 семестра, в каждом из которых проходят по 3-4 предмета. Первый блок первого семестра посвящён всему, что связано с web-технологиями, от истории возникновения до программирования и безопасности web-приложений.

Лекция 1. Введение

На вводном занятии вы познакомитесь с краткой историей развития интернета, основными трендами в развитии web-приложений, облачных сервисов и мобильных приложений. Также на лекции разобрано устройство и работа несложного web-приложения, обсуждены такие фундаментальные понятия, как система адресации в интернете, домены, HTML-страницы и протокол HTTP. Напоследок кратко рассказано о CGI-скриптах, их назначении и особенностях работы.

Лекция 2. Сетевые протоколы

Вторая лекция посвящена сетевым протоколам. Сначала даны теоретические основы о модели OSI и вложенности протоколов, рассмотрено назначение и устройство протоколов TCP и IP, подробно рассказано о доменах, доменных зонах и делегировании. Затем лектор рассказывает о том, что собой представляет протокол HTTP, о назначении HTTP-заголовков, кодах ответа сервера и прочих нюансах передачи данных в сети. В оставшуюся часть лекции затрагиваются все вопросы, касающиеся электронных писем: какова структура e-mail, как составляются заголовок и тело письма, устройство и работа протоколов SMTP, POP3 и IMAP. В конце обсуждаются сугубо практические темы: составление списков рассылок, методы борьбы со спамом, назначение и работа расширения SPF, использование обратной зоны DNS.

Лекция 3. Web-серверы

На этой лекции рассмотрена общая схема работы web-сервера: что такое сокеты, конструкция запросов, файловая структура и ведение логов. Рассказано о различиях между frontend- и backend-серверами, а также об использовании серверов для получения статического контента и проксирования запросов. Далее затрагиваются азы конфигурирования сервера, рассказывается о таких понятиях, как MIME и Content-Type. После рассмотрения роли web-сервера в качестве сервера приложений, лектор переходит к информационному блоку об интерфейсах взаимодействия с языком программирования. А в конце лекции рассказывается о модели обработки запросов и способах сравнения производительности разных web-серверов.

Лекция 4. Серверная разработка

Вначале проведён небольшой обзор языков, используемых для разработки серверов. Затем подробно изучен протокол CGI, устройство CGI-скриптов и библиотеки для работы с ними. Лектор рассказывает о том, как обрабатывать входные данные и работать с БД. Рассматривается работа с объектами и их списками, а также с формами. Затем вы узнаете, как использовать перенаправления, где и в каком виде хранятся данные на клиенте, как использовать cookie и сессии. Напоследок будет рассмотрена работа с шаблонами: использование шаблонизаторов, для чего нужны подшаблоны и особенности наследования шаблонов.

Лекция 5. Реляционные базы данных

Из этой лекции вы узнаете о том, что такое реляционные БД, для чего они используются и как развивались. Затем рассмотрены основные понятия, связанные с работой в реляционных БД, типы данных в SQL и работа с ними (нормализация, управление данными, выборки). Также лектор рассказывает о способах проверки целостности базы, использовании внешних ключей, а в конце лекции — о преимуществах и недостатках наиболее распространённых СУБД.

Лекция 6. MVC-фреймворки

MVC — это схема использования нескольких шаблонов проектирования. На лекции рассказывается о том, что это вообще такое и как эту схему применять на практике. Далее подняты вопросы маршрутизации URL и обработки HTTP-запросов. Затем рассказывается о визуализации данных с помощью представления и использовании шаблонов.

Лекция 7. Django (часть 2)

В конце предыдущей лекции была затронута тема реализации MVC во фреймворке Django. Здесь этот вопрос рассматривается уже подробно. В частности, вы узнаете о том, как написать скрипт управления django-приложением, что такое middleware и зачем оно нужно. Также вы познакомитесь с представлениями-классами (Class Based Views), расширениями фильтров и тэгов в шаблонизаторе и многим другим.

Лекция 8. HTML и CSS

После просмотра этой лекции вы многое узнаете о вёрстке web-страниц. Здесь рассказывается об истории развития и особенностях таких языков разметки, как HTML, XML и XHTML. В лекции преподаются основы вёрстки, рассматриваются основные тэги и атрибуты, без которых нельзя создать даже простейшую страницу. Вы узнаете, какие бывают типы элементов страницы, как создавать таблицы и списки. Затем рассказывается о каскадных таблицах стилей (CSS), их создании и использовании.

Лекция 9. Javascript

Здесь вы познакомитесь с основами языка программирования JavaScript: с его синтаксисом, способами подключения к web-странице и моделями обработки событий. Заодно вы узнаете, что такое AJAX и как подключать JS-библиотеки. Остаток лекции посвящён использованию библиотеки jQuery и её плагинов.

Лекция 10. Rich Internet Applications

На данной лекции рассказывается о том, что собой представляют Rich Internet Applications, web-приложения, доступные через интернет. Они появились благодаря недостаткам, присущим HTML, CSS и JavaScript. Вы узнаете о возможностях, преимуществах и недостатках RIA, их устройстве и наиболее популярных видах использования.

Лекция 11. Безопасность web-приложений

Последняя лекция этого блока в Технопарке. На ней рассказывается об основных аспектах безопасности, которые необходимо знать web-разработчику: как реализована авторизация в протоколе HTTP, как можно сделать систему авторизации с помощью web-приложения, базовые понятия криптографии, средства безопасности в браузерах и какие бывают виды атак на web-приложения.

Подписывайтесь на наш youtube-канал!