Ajax *

Любая миграция должна начинаться с оценки того, что нужно мигрировать. Каким образом это делать — мнения разнятся. Кто-то делает это в Excel, кто-то рисует схемы, а некоторые используют утилиты. Одна из таких утилит — Microsoft Assessment and Planning Toolkit - конечно, не серебряная пуля, которая решит все за вас, но процесс инвентаризации упростит значительно. Просто запустить ее в AD либо дать ей список IP-адресов (да, и не только для Windows) — и она соберет не только данные о ресурсах виртуальной или физической машины, но и проведет анализ загруженности в течении определенного вами времени, чтобы вы могли увидеть, что большой сервер, купленный за большие деньги, на самом деле загружен на 25%. По результатам будет сгенерирован Excel-отчет, который можно показать как аргумент. Полезно, учитывая периодические EOS. :)
Под катом мы инвентаризуем тестовую виртуальную инфраструктуру. Все посты из серии «Гибридная история» помечены соответствующим тегом hybrid story.

 

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

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

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Во многих компаниях, как и моей, есть много проектов и продуктов. И у продуктов бывают веб-интерфейсы, чтобы этими продуктами как-то манипулировать. В нашем случае это простенькие RESTful веб-сервисы, а поверх них ещё более простенькие веб-странички с формочками и кнопочками. Все эти веб-странички до того похожи друг на друга, что возникла мысль написать унифицированный продукт, который бы спрашивал сервер о поддерживаемых сервисах, и получал бы полное описание параметров к этим сервисам, так чтобы можно было нарисовать те самые простенькие формочки. То есть, веб-сервисы должны описывать себя, достаточно исчерпывающе, чтобы наш клиент мог построить GUI для них, и ничего не надо было бы делать руками. Как раз такая картинка гуглится по запросу «REST»:

Добрый день!
Хотелось бы продемонстрировать один из возможных подходов к решению проблемы работы с WCF сервисами с различных доменов. Найденная мной информация по данной теме была или неполной, или содержала избыточное количество информации, затрудняющей понимание. Хочу рассказать о нескольких способах взаимодействия WCF и AJAX POST запросов, включающих в себя информацию о Cookies и авторизации.

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

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

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

1. Вычисления не должны блокировать взаимодействие с интерфейсом и его рендеринг — пользователь всегда должен иметь возможность указать на фокус своих интересов.
2. Страница объекта, к которому обратился пользователь, должна отображаться мгновенно, не дожидаясь загрузки данных, в которых нуждается объект.
3. Запросы в сеть не должны уходить одной большой группой, не должны отправляться сразу; должны откладываться на небольшое время, складываться и приоритезироваться в случае необходимости.

Изложенная в этой заметке информация — это мой практический опыт проектирования и разработки интерфейса моего приложения для поиска и прослушивания музыки seesu.me. Приложения, в котором гармонично комбинируются огромные пласты данных из разрозненных сервисов, таких как last.fm, вконтакте, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com

Всем привет! Сегодня задача у нас следующая: необходимо создать интерфейс для загрузки картинок, который бы генерировал перед загрузкой превьюшки небольшого формата. На данный момент HTML5 вовсю шествует по планете, и, казалось бы, как это реализовать должно быть предельно ясно. Есть несколько русскоязычных статей на эту тему (вот, например). Но тут есть одно но. В рассматриваемом там подходе не уделено никакого внимания расходу памяти браузером. А расход может доходить до гигантских размеров. Разумеется, если загружать одновременно не более 5-10 картинок небольшого формата, то все остается в пределах нормы; но наш интерфейс должен позволять загружать сразу много изображений формата не меньше, чем у современных фотоаппаратов-мыльниц. И вот тогда-то свободная память начинает таять на глазах.

Все мы знаем множество преимуществ использования AJAX: пользователям не нужно ждать загрузку новой страницы, действия выполняются в фоновом режиме, в результате чего можно обеспечить гораздо более динамичный user experience. Идеи вроде бы просты, но создать сложное AJAX веб приложение достаточно тяжело. Я создал свой блог на основе AJAX, у меня есть несколько советов и я хочу поделиться с вами своим опытом. Надеюсь я помогу вам избавиться от некоторых проблем в будущем!

Большинство web-приложений и web-фреймворков используют архитектуру, не позволяющую разделить ui и backend разработку. Тем самым нет возможности разделить команду на узкоспециализированных frontend и backend разработчиков. Вне зависимости от предпочтений разработчика ему приходится иметь понимание как о слое представления, так и о слое логики. Если ui-разработчик знает только о том, как запустить сервер, и о модели данных — это огромная удача. В плохих случаях ui-разработчику необходимо провести полную сборку проекта чтобы увидеть изменения строчки в javascript файле, или знать о языке jsp файлов чтобы поменять стиль элемента. Формирование и передача на сервер обработанных html файлов так-же пагубно влияет на производительность сервера и сети.

Обрабатываете много данных в браузере?
Хотите отправлять их обратно на сервер?
Да так, чтобы отправлялось побыстрее и помещалось в один http запрос?

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

Это позволяет избежать CSRF/XSRF-атак (подделки межсайтовых запросов).

Рассмотрим следующий пример: допустим у Google есть URL вида gmail.com/json?action=inbox, который возвращает 50 первых сообщений вашего почтового ящика в формате JSON. Злоумышленник, чей сайт находятся на другом домене, не может выполнить AJAX запрос, обратившись по данному URL, чтобы получить данные, ввиду same origin policy (правило ограничения домена). Но ничто не мешает злоумышленнику включить вышеуказанный URL на свою страницу с помощью тега .


     Вдохновившись вот этой статьёй о Socket-соединениях в Веб-приложениях, решил сделать более-менее универсальный модуль с удобным интерфейсом, реализующий эту технологию.
     В этой статье под словом «сокет» имеется ввиду програмный интерфейс, который обеспечивает обмен данными между серверным и клиентским скриптами, с возможностью клиентского постоянно «слушать порт». Другими словами, как только что-то произошло на сервере, он может тут же сообщить об этом клиенту, и наоборот. Конечно же, в javascript нет возможности «слушать порты» и создавать полноценные сокеты, но зато у нас есть спички, изолента и пластилин, из которых можно смастерить какое-то подобие.
     Сначала я опишу примерный принцип действия этой системы, а затем, по традиции, приведу код примитивного чата построенного на её основе, с, конечно же, ссылкой. Хотелось бы увидеть своими глазами хабраэффект в действии. Ещё в конце будет ссылка на репозиторий с исходниками.

Дабы не было двусмысленностей, обозначу суть. При приёме на новую работу мне дали тестовое задание, которое кратко можно описать так: «Написать аналог Glow для геовизуализации событий входа пользователей в кастомерку интернет-магазина». Проще говоря, необходимо мониторить лог системы на предмет возникновения определенных событий и в случае оных выполнять (в данном случае) отображение точки на карте, которая будет определяться IP-адресом пользователя. Цель реализации: создать приятную на вид «игрушку» для презентационных целей, способную погрузить смотрящего в нирвану гармонии и эстетического наслаждения. Основным условием было использование в процессе разработки стека Java-технологий, чем обусловлено принятие многих решений. Кроме этого, было решено реализовать это в виде одностраничного сайта. А поскольку с Java и web я был знаком крайне поверхностно (писал в основном на C/C++), пришлось многому научиться. Что ж, будем разбираться вместе.

Статья рассчитана на интересующихся и начинающих, однако не «разжевывает» простые вещи, с которыми можно ознакомиться с помощью документации или специализированных статей. Наиболее полезные ресурсы, ссылка на исходники (распространяются по лицензии BSD) и ссылка на рабочую версию приведены в конце статьи.

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

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

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

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

Здравствуйте, в этой маленькой заметке расскажу немного про ООП в JS, объект XMLHttpRequest, паттерн прокси, и дружелюбие джаваскрипта в этом плане.

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

I. Суть проблемы.

В список основных предназначений XMLHttpRequest, конечно, не входит запрос HTML, чаще этот инструмент взаимодействует с XML, JSON или простым текстом.

Однако связка XMLHttpRequest + HTML хорошо работает при создании расширений к браузеру, которые в фоновом режиме опрашивают на предмет новостей сайты, не предоставляющие для этого почтовую подписку, RSS или другие экономные API или предоставляющие эти сервисы с какими-то ограничениями.

При создании нескольких расширений для Firefox я сталкивался с такой необходимостью. Работать с полученным от XMLHttpRequest кодом HTML при помощи регулярных выражений — способ очень ненадёжный и громоздкий. Получить DOM от XMLHttpRequest можно было лишь для правильного XML. Поэтому приходилось следовать хитрым советам на сайте разработчиков. Однако начиная с Firefox 11 появилась возможность непосредственного получения DOM от XMLHttpRequest, а в Firefox 12 была добавлена обработка таймаутов.

Я испытал новую возможность на создании мини-индикаторов новых топиков для двух небольших форумов, и это оказалось очень удобным (50 строчек кода плюс расширение CustomButtons — вот и готовый индикатор за пять минут, с опросами по таймеру и четырьмя состояниями: нет новостей, есть новости, ошибка и таймаут; подробнее можно почитать здесь). Всё работало как часы.

Поэтому я попытался убрать из кода своих расширений все прежние костыли и ввести туда новый удобный парсинг. Однако при работе с сайтом rutracker.org возникла странная проблема (тестирование проходит на последней ночной сборке под Windows XP; очень прошу прощения за все косяки в коде и формулировках: у меня нет программистского образования и опыт мой в этой сфере, к сожалению, очень невелик.).

Реинкарнация кнопки «Читать все хабы» с возможностью вернуться к чтению избранных хабов (блогов); работает при авторизации; настройки выбора переносимы через JSON.

Эту кнопку «сломали» и пообещали, что «насовсем», разработчики сайта 14 марта 2012 года. Но свято место пусто не бывает, и появился её ослабленный клиентский «дух».

Скрипт сохраняет все ваши настройки блогов в одной большой JSON-строке, которая запоминается в хранилище браузера (не потеряется при сбое питания) и которая может быть вытащена для экспорта (кнопка «Импорт-экспорт») в другие браузеры и компьютеры (ею же можно воспользоваться, чтобы «посмотреть глазами других»). По кнопке-переключателю «Все/Свои» делается лёгкий выбор между всеми блогами или своими избранными. Фактически, это замена прежнему режиму «Читать все», убранному с сайта. Другие имеющиеся решения требуют чем-то пожертвовать: выбрать «всё» вручную (это означает — потерять свои избранные блоги), читать habrahabr.ru/posts/collective и habrahabr.ru/posts/collective/new (будут пропускаться блоги компаний) — обсуждение в QA.

Перейти на страницу скрипта. Сразу скачать скрипт habrAllHub.

(Опыт успешной борьбы с ветряными мельницами.)

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

Во время анализа стилей сайта в своё время было обнаружено, что в стилях и скриптах предусмотрено то, что должно быть по правилам юзабилити — показ режима ожидания ответа от сервера — но оно никак не проявляется визуально. Работает это только на страницах с новой вёрсткой — почти на всех, исключая некоторые специально оформленные (в старой вёрстке, принятой до октября 2011) страницы блогов компаний. Так давайте же использовать то, что сделано!

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

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

8.4% всех зависаний страниц в IE9 за прошедший месяц являются следствием того, что XMLHttpRequest объекты блокируют поток UI синхронным запросом. Это огромное число! С помощью нескольких доступных изменений в коде эти зависания можно легко избежать — и разработчики могут обеспечить своим пользователям намного лучшие впечатления от работы с их сайтами. Мы рассмотрим, что происходит при зависании, что вы можете с этим сделать, и мы также попробуем сделать небольшую демонстрацию, чтобы воочую посмотреть, что происходит, когда синхронный запрос подвешивает браузер.