Рубрика «web» - 21

Web Components — будущее Web

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

— Sam Stephenson, создатель Prototype.js, You Are Not Your Code

Создатели браузеров поступают гармонично. Решение о новых API принимают с учётом текущих трендов в opensource сообществах. Так prototype.js способствовал появлению Array.prototype.forEach(), map() и т.д., jquery вдохновил разработчиков на HTMLElement.prototype.querySelector() и querySelectorAll().

Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаус под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.
Читать полностью »

Регистрация на сайте: c начала и до обедаПривет!
Я работаю в области web-разработки и на днях у меня появилась интересная задача – необходимо было создать сложную форму регистрации, на которой будет расположено двадцать два (22!) текстовых поля и один большой список с чекбоксами.
Я всегда руководствовался принципом, что большое количество полей на форме регистрации очень неприятно для пользователей, даже если они будут получать материальные бонусы по завершению. Поэтому я всегда старался сделать форму максимально простой, максимум в 4 поля, если это было возможно со стороны бизнеса (заказчика). И даже пренебрегал полем с капчей, использовав вместо нее скрытую js-капчу, или вовсе отказывался от нее. Но все попытки донести это заказчику были безуспешны.

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

Читать полностью »

Добрый вечер, читатели!
Так уж сложилось, что публично я пишу API integration, да и не публично тоже, хотя в рабочей жизни это наиболее редкое мое занятие. И захотелось мне высказаться на примере четырех сервисов обертки над АПИ которых есть у меня в профиле github.
Читать полностью »

в 12:15, , рубрики: php, web, метки: ,

Где-то читал высказывание разработчиков самого языка что он изначально разрабатывался не для Веб программирования а немного для других областей применения, однако, сейчас в нём вроде бы есть всё для использования в Веб программировании, и многие присматриваются к нему сопоставляя php vs Go, node.js vs Go.
Читать полностью »

15 октября славный город Санкт-Петербург посетил суперзлодей Вселенной Joker.
Нет, он никого не убил, и ни один Бэтмен не пострадал. Но его посещение, тем не менее, запомнится многим. Во-первых, это была премьера новой конференции по Java технологиям. Во-вторых, эта конференция удалась на славу, а значит, её ждёт большое будущее, а первая конференция – всегда история.

image
Читать полностью »

Всем привет!
Удобно смотреть отчёты через браузер, не надо пользователю никакие программы устанавливать.
Для более удобной работы с данными журнала использования Интернета (WEB) и журналом брандмауэра (FWS) сервера MS TMG их можно загрузить в базу MySQL. Можно написать сколько угодно отчётов по этим данным. Для доступа к отчётам используется веб-интерфейс.
Пример реализации под катом.
Читать полностью »

Эта статья является частичным переводом.

Взглянем на текущую ситуацию с веб технологиями от Microsoft. Основным средством разработки с 98 года является конечно ASP .Net. Это классика: богатый функционал, разделение логики от разметки, .net, новая модель разработки веб приложений. Много плюсов и минусов тоже: Все логически-разнородные компоненты тесно связанны в одну единственную сборку System.Web (объекты ядра HTTP, webforms и т.д.). Ко всему этому ASP .net включен в состав большого NET Framework, а значит время между отдельными релизами может составлять несколько лет. И это не позволяет ASP .NET идти в ногу со временем и поспевать за веб технологиями. Монолитная архитектура делает все это богатство неповоротливым и инертным, а какие-либо изменения затрагивают множество компонентов.

Со временем ситуация на рынке меняется: ASP .NET получает MVC framework и Ajax уже в виде отдельных модулей, не входящих в основную сборку и это позволяет разработчикам этих компонентов ускорить выпуск новых версий и своевременно реагировать на ситуацию в сфере веб разработки. ASP .NET становится семейством подключаемых компонентов, а не единой структурой.
Читать полностью »

В качестве предисловия

Веб-дизайнерский народ в последнее время распробовал single page web applications. Что оправдано во многих случаях.
Но яыно ошибочно считать что single page web application не сделать без чего-то типа AngularJS, Ember и прочих Knockouts.
Во всяком случае если вам нужно сделать нечто простое типа To-do списка совершенно не обязательно тащить на клиент килобайты мега-фреймворка. На самом деле килобайты трафика это пол беды. Основная цена, скажем AngularJS, в том что он, как любой универсальный data binding механизм, создает значительную run-time нагрузку.

Эта статья про то как в 60 строках кода + jQuery/Zepto сделать простой app framework котрый можно расширять под свои нужды и без лишних сущностей в нагрузку.

Постановка задачи

Наш framework должен ...:

  1. … поддерживать routing, т.е. должна быть возможность сказать в деклартивной модели: «этот вот url hash должен быть показан в этом view».
  2. Должна быть возможность динамической загрузки разных view. Какие-то части нашего прилжения могут быть либо тяжелы для начальной загрузки либо не нужны например для незалогиненного пользователя.
  3. Должна быть возможность динамической загрузки скриптов. По причинам изложенным в п. 2
  4. Наше приложение будет поддерживать browsing history — кнопка «назад» в браузере должна показывать предыдущую страницу и т.д.
  5. Ну и все это должно быть компактным и расширяемым как того будет требовать логика нашего приложения.

Пример того что мы хотим получить

Приложение Bootstrap'нутый список контактов — содержит сам список, карточку — детали контакта и некую панель управления (dashboard). Что будет на той панели нам не важно — знаем что что-то будет и ладно.

Personas demo

Читать полностью »

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

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

О чем проект
FAVORaim – это персональные события и предложения.
1. FAVORaim помогает быть в курсе событий на строго интересующие темы.
Например, для любителей сериала «Сверхъестественное» FAVORaim подбирает тематические вечеринки и встречи поклонников (то же самое и для любителей других сериалов и культовых фильмов). А для стартапера система найдет не только профессиональные конференции и встречи с венчурными финансистами, но и неформальные startup-вечеринки. Также, у пользователя есть возможность отслеживать более детальные и профессиональные темы: Android, SMM, веерный маркетинг и т.п. Мощным направлением у нас выросла тема аниме.
image
2. Анализ внешней информации на соответствие интересам пользователя.
Даже не заходя в магазин, с помощью мобильного приложения FAVORaim пользователь может посмотреть, что здесь подойдет ему по стилю, размеру и предпочтениям. А в торговом центре посмотреть, что есть интересного и подходящее для пользователя (пока без indoor-навигации).
Читать полностью »

В последнее время стало модным использовать термины «Web-приложение», «front-end-архитектура», «Web 2.0», «HTML5-приложения». Но, к сожалению, в большинстве случаев контекст использования этих терминов не всегда верен, поскольку не учитывает всю специфику реализации и использования архитектуры Web-приложения. Сегодня речь будет идти именно об архитектуре.

Толчком к написанию данной статьи послужила публикация в блоге http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html. Стоит заметить, что она достаточно сжата и не учитывает возможности конверсии HTML5/Mobile. Здесь же мы попытались рассмотреть архитектуру более подробно, с учетом последних трендов в Web и некоторых ключевых моментов для заказчика приложения (таких, как безопасность).

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

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

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

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

Пользователь:
Отзывчивость/юзабилити: обновление данных на странице и переключение между страницами (время отзыва). Богатство и удобство интерфейса, его интуитивность.
Linkability: возможность сохранять закладки и ссылки на различные разделы сайта.
Оффлайн: возможность работы приложения без сети.

Разработчик:
Скорость разработки: скорость добавления нового функционала, рефакторинг, распараллеливание процесса разработки между разработчиками и верстальщиками, и т. д.
Производительность: максимально быстрый отклик от сервера с минимальными затратами вычислительных мощностей.
Масштабируемость: возможность увеличения вычислительных мощностей либо дискового пространства в связи с ростом количества информации либо количества пользователей. В случае использования распределенной масштабируемой системы должна обеспечиваться согласованность данных, доступность и устойчивость к разделению (CAP-теорема). Надо заметить, что количество фич/скринов приложения с ростом пожеланий заказчика (на клиентской стороне) не относится к данному определению — это уже скорее зависит не от типа Web-архитектуры, а от используемого фреймворка и исполнения.
Тестируемость: возможность и легкость тестирования (модульное авто-тестирование).

Заказчик:
Функциональная расширяемость: возможность наращивания функционала с минимальными временными и денежными затратами.
SEO: пользователи должны иметь возможность найти приложение, используя любую поисковую систему.
Поддержка: расходы на поддержание инфраструктуры приложения — затраты на железо, сетевую инфраструктуру, персонал, необходимый для обслуживания приложения.
Безопасность: Заказчик приложения должен быть уверен в сохранности бизнес-данных и недоступности данных о других пользователях. В качестве главного критерия безопасности мы будем рассматривать только возможность изменения функциональности поведения приложения на клиенте, а также связанные с этим риски. Стандартные угрозы (к примеру, анализируемые в https://www.owasp.org/index.php/Main_Page) одинаковы для всех сравниваемых архитектур. Безопасность же на участке передачи данных «сервер-клиент» мы не берем во внимание в связи с тем, что все рассматриваемые архитектуры одинаково подвержены взлому — канал передачи данных может быть одним и тем же.
Конверсия: сайт — мобильное или десктопное приложение: возможность опубликовать приложение в мобильных маркетах, или обернуть его в десктопное приложение с минимальными дополнительными затратами.

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

Попробуем выделить основные типы Web-приложений в зависимости от ролей, выполняемых сервером и браузером (клиентом).

Тип 1: Server-side HTML

image

Самая распространенная на данный момент архитектура. Заключается в том, что сервер генерирует HTML-контент и отправляет его клиенту как полноценную HTML-страницу.
Иногда эту архитектуру называют «Web 1.0», по причине того, что она появилась первой, и в данный момент является доминирующей в Web.

Отзывчивость/юзабилити: 1/5. Наименее оптимальная из рассматриваемых архитектур. Связано это с тем, что между сервером и клиентом необходима пересылка огромного объема данных, ответственных не только за сами бизнес-данные, но и за их оформление. Пользователь вынужден ждать перезагрузки страницы в ответ на тривиальные действия, например обновление только небольшой части страницы. UI-шаблоны на клиенте зависят непосредственно от фреймворков, применяемых на сервере. В связи с ограниченностью мобильного интернета и большими объемами пересылаемых данных, данная архитектура практически не работоспособна в мобильном сегменте. Нет способа доставки мгновенных обновлений данных или изменений в реальном времени. Если рассматривать возможность изменений в реальном времени путем генерации на стороне сервера и обновления клиента (через AJAX, WebSockets) в виде готовых кусков контентa, плюс оформление с заменой части страницы, то мы уже выйдем за границы рассматриваемой архитектуры.
Linkability: 5/5. Из рассматриваемых архитектур linkability легче всего реализуема в этой. Связано это с тем, что на сервере по умолчанию в соответствие одному URL ставится конкретный HTML-контент.
SEO: 5/5. Реализуется достаточно просто, аналогично предыдущему пункту — контент страницы известен заранее.
Скорость разработки: 5/5. Самая старая архитектура, поэтому возможно выбрать любой серверный язык и фреймворк под конкретные нужды.
Масштабируемость: 4/5. Если рассматривать генерацию HTML, то при возрастающей нагрузке в конце концов возникает момент, когда необходима реализация балансировки для распределения нагрузки. Гораздо сложнее ситуация с масштабированием БД, но эта задача одинакова и характерна для всех трёх рассматриваемых архитектур.
Производительность: 3/5. Тесно связана с отзывчивостью и масштабированием в плане траффика, скорости и т.п. Производительность низкая, так как требуется пересылка самого большого объема данных, которые содержат в себе HTML, оформление, а также сами бизнес-данные. Таким образом, необходимо генерировать данные для всей страницы (а не только для измененных бизнес-данных), а также всю сопутствующую информацию (например, оформление).
Тестируемость: 4/5. Положительный аспект данной архитектуры состоит в том, что для тестирования фронт-энда в общем случае не нужны специальные инструменты, поддерживающие интерпретацию JavaScript (поскольку контент страниц является статическим).
Безопасность: 4/5. «Нельзя сломать то, чего нет» — вся логика поведения приложения находится на сервере. При этом данные пересылаются в открытом виде, поэтому по необходимости рекомендуется защищенный канал (что по сути касается любой архитектуры, связанной с сервером). Вся функциональность защиты ложится на серверную сторону.
Конверсия: сайт — мобильное или десктопное приложение: 0/5. В большинстве случаев это просто невозможно. Исключение (или, скорее, экзотику) составляют редкие случаи: к примеру, если у Вас сервер реализован на node.js, и при этом нет больших баз данных; или если Вы пользуетесь сторонними веб-сервисами для получения данных (но это уже более продвинутый вариант архитектуры). Таким образом Вы обернете ваше приложение с помощью node-webkit или аналогов.
Оффлайн: 2/5. Реализуется с помощью манифеста на сервере, введенного в спецификации HTML5. Если браузер поддерживает данную спецификацию, все страницы приложения будут кэшироваться, и в случае отключения от сети пользователю будет показана кэшированная страница.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js