Пытаюсь скрыть

Это мой первый пост здесь и сразу хочу предупредить — это пеар :) Сейчас я буду нагло расхваливать свой собственный ресурс — File Qube. Как понятно из заголовка, речь пойдёт о хостинге файлов.

Это мой первый пост здесь и сразу хочу предупредить — это пеар :) Сейчас я буду нагло расхваливать свой собственный ресурс — File Qube. Как понятно из заголовка, речь пойдёт о хостинге файлов.

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

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

У такого подхода есть недостатки:

• Сложная логика JavaScript.
• Не работает навигация браузера back/forward.
• У отдельных фотографий нет своего адреса URL для прямого перехода.

Последние два недостатка сводятся к первому путем ещё большего усложнения JavaScript-кода. В статье я покажу, как разработать приложение простой фотогалереи с применением паттерна Page-View. Основное преимущество подхода — хорошо масштабируемый объектно-ориентированный JavaScript-код.

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

Наибольшие трудности при построении сайтов c применением AJAX возникают при реализации механизма AHAH (Asynchronous HTML and HTTP). Особенно выполнение на лету подгружаемых Javascript-ов. Также есть куча дополнительного «гемороя» при разработке AJAX сайтов и веб-приложений. Вы можете ознакомится с детальным описанием некоторых существующих проблем. Из-за указанных сложностей, многие разработчики отказываются от более насыщенного внедрения AJAX.

Однако, мало кто знает, что перечисленные проблемы можно решить.

Обсуждение предыдущей статьи было бурным. Самые ярые любители jQuery, Mootools кричали зачем мол нужен другой велосипед.
В данной статье мы рассмотрим использование техники Fly AJAX. Это одна из нескольких функциональных возможностей, которые не реализованы в ранее указанных больших (и мною уважаемых) фреймворках. Также, в данной статье, мы рассмотрим принципы правильного проектирования и построения сайтов для хорошей индексации с применением AJAX технологии.

Продолжаем цикл статей на тему построения сайтов (веб-приложений) ориентируясь на максимальное применение AJAX технологии. Зачастую, при работе сайтов и приложений использующих AHAH требуется вместе с подгружаемым HTML контентом догружать файлы скриптов, которые не использовались ранее на страницах сайта. Одним из моментов обработки догружаемого AJAX-ом контента является выделение из получаемого контента файлов скриптов, с последующим их применением к текущему документу (DOM). Благо, на данный момент практически все основные библиотеки умеют это делать. Однако, если копнуть глубже в реализацию процесса обработки догружаемых скриптов, то текущая ситуация совсем «не радужная». Не все хорошо известные библиотеки умеют это делать хорошо, а тем более оптимально. Давайте рассмотрим указанный процесс изнутри, разберем существующие проблемы и узнаем пути их решения.

Артель BrowserPlus (из Yahoo) выпустила API для сжатия файлов на стороне клиента. Как объясняется в нижеследующем скринкасте, джаваскриптовый API позволяет вам упаковывать и сжимать файлы в клиенте посредством LZMA или tar.


    «Client Side Compression» выложил Lloyd Hilaiel на Vimeo

Вы можете читать далее о реализации или испытать демонстрацию живьём (потребуется BrowserPlus).


    Прилад Browser Plus для упаковки на стороне клиента

Использовать этот API нетрудно: вызываем надобный метод и посылаем ему файлы:

BrowserPlus.Tar.tar({'files':files});
BrowserPlus.LZMA.compress({'files':files});

На GitHub доступны оба эти расширения — LZMA и tar.

Нюансы перевода:  слово «прилад», давно живущее в великорусском языке (как минимум, со времён Даля), здесь служит переводом технического термина «add-on» (а не «device», как в украинском), слово же «артель» означает команду разработчиков (в оригинале — «team»).

Вы помните, как все начиналось? Одна из самых интересных наших конференций — ClientSide. Летние встречи докладчиков...

Потихоньку и без горячки пробуем возродить идею. В Программном комитете ClientSide все те же люди, что были причастны и к первому ClientSide: Вадим Макеев, Дмитрий Сатин, Александр Шуркаев, Николай Мациевский, Сергей Чикуенок, Иван Дембицкий. Вы не знаете кто это? Наверное, Вы хардкорный PHP-программист, но не верстальщик ;-))

Под катом — программа секции «Клиентские технологии» на РИТ++

Данная статья является вольным переводом. Оригинал тут.

Введение

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

Предлагаю ознакомиться с решением на базе backbone.js, underscore.js и jQuery, которое поможет решить эту проблему.

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

Каким бы мы хотели видеть наше приложение? Вот основные моменты, которые мне кажутся важными:

1. Должен быть удобный способ описать модели нашей предметной области.
2. Любые изменения в модели должны немедленно отражаться в пользовательском интерфейсе, если модель в нем представлена каким-либо образом.
3. Понятная и легко-поддерживаемая структуризация кода в стиле MVC.

Попробуем решить эти задачи на примере простого приложения «Каталог фильмов».

С ходом времени автор понял, что ниженаписанное — полная глупость

Для тех, кому не хочется читать

Страничка, на которой всё нижепроделанное в примере (включайте alert).
Онлайн плеер, который и заставил меня дойти до этого топика.

Введение

Доброго времени суток! Не так давно затронул тему «Онлайн-плееров» и им подобных. Их много, очень я бы сказал. Я захотел сделать аналог, в первую очередь для себя. Захотел по стандарту — база vk.com, скробблинг last.fm (позже ласт), альбомы с него же, плейлисты, сердечки и так далее. Сразу вытекла проблема — мой хостинг очень плох для постоянных запросов на него. Ничего не оставалось, как перейти почти полностью на javascript (позже js). Итак, коль русского описания «Как работать с last.fm api javascript» я так и не нашёл, а потратил много нервов и времени на решение этой проблемы, то начнём, пожалуй.

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

Дзен Angular

• Хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.
• Хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.
• Хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.
• Хорошо, когда фреймворк ведет разработчика по всему циклу разработки приложения: от проектирования UI через написание бизнес-логики к тестированию.
• Хорошо, когда распространенные задачи становятся тривиальными, а сложные — упрощаются.

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

• Все, что вам нужно для создания CRUD-приложений: data-binding, базовые директивы для шаблонов, валидация форм, роутинг, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.
• Все, что вам нужно для тестирования: средства для модульного тестирование, end-to-end тестирования, mock-и.
• Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

AngularJS разрабатывается сотрудниками Google и используется, как минимум, в одном сервисе Google — DoubleClick.

Что первое приходит вам в голову, когда вы слышите аббревиатуру CDN? Наверняка, «тяжелый контент», «много видео», «терабайты данных», «миллионы хитов в день».

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

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

Ответы на эти вопросы — под катом…

Директивы — это ключевая особенность AngularJS. С помощью директив можно добавлять новое поведение существующим HTML элементам, можно создавать новые компоненты. Примерами директив, добавляющих новое поведения для существующих HTML элементов, могут служить input, select, textarea в связке с ngModel, required и т.п. Перечисленные директивы в основном связаны с валидацией форм в AngularJS. Но тема валидации заслуживает отдельной статьи.

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

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

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

Валидация — одна из автомагических возможностей AngularJS. Хотя магического здесь, конечно же, ничего нет. Просто такие стандартные теги html как form, input, select, textarea — это тоже директивы. И когда они объединяются с ngModel, required, ngPattern и т.п., начинает работать валидация.

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

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

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

Рано или поздно шаблонизация перемещается на клиент. На данный момент существует несколько общепринятых клиентских шаблонизаторов ими являются mustache и underscore.template или что-нибудь подобное (в доклад(ах) Сергея Бережного можно найти ещё). Несмотря на огромное количество клиентских шабнизаторов большинство, за редким исключением, являются строчными.

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

disclaimer: сравнение не подразумевает поднятие “холивара”, а делает обзор задач, решаемых одним инструментом в сравнении с другим. Я не являюсь знатоком всех тонкостей angularJs, но прочитав 10 статьей обзора этого инструмента, привожу альтернативный пример решения тех же самых задач на IML.