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

Задача: отправка и обработка файлов с помощью FormData и FileReader в форме со всеми возможными полями и пересылкой дополнительных параметров для каждого поля c объединением всех данных формы (кроме файлов и системных полей) в общий массив.

Поддержка: все современные браузеры, IE 10+.

Плагины: jquery-2.1.4

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

Что в таком случае обычно делают? Правильно, идут протоптанной дорожкой — Apache/nginx + PHP. А дальше начинается ад, потому что:

1. Все это нужно устанавливать и настраивать.
2. Все это жрет приличное количество ресурсов.
3. Из PHP как-то надо получать данные от разрабатываемой системы. Повезет если для этого достаточно просто залезть в СУБД.

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

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

Такие решения есть. И в этой статье я хотел бы поверхностно познакомить вас с одним из них – встраиваемый сервер Mongoose (не путать с MongoDB).

Здесь будет идти речь о том, как отдельно от всего реакт-приложения подгрузить удаленный реакт компонент и отрендерить его! Я покажу как решил эту проблему, т.к. год спустя я так и не могу найти аналогичные решения кроме как react-remote-component-demo.

Этот материал мы подготовили для JavaScript-программистов, которые только начинают разбираться с «Promise». Обещания (promises) в JavaScript – это новый инструмент для работы с отложенными или асинхронными вычислениями, добавленный в ECMAScript 2015 (6-я версия ECMA-262).

Идея очень проста, но дает значительные преимущества, по сравнению с кодом без применения данного шаблона, имеет потенциал активно применяться. Странно, но я не встречал ничего подобного в любом трендовом коде для повторного использования, поэтому назвал шаблон «CSN-Ajax» исходя из названия сайта и проекта «SKY Framewok», в котором шаблон впервые появился — CoreSky.Net, в моем проекте. Пример реализации я опишу здесь на основе применения PHP, jQuery и MVC паттерна. Итак, кратко, без комментариев:

Компьютер давно многим заменил телевизор, а что не хватает компьютеру для комфортного просмотра кино, сериалов и прочего? Мне, лично, не хватало пульта дистанционного управления.

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

• Возможность отправить ПК в режим сна
• Возможность выключить громкость

С помощью известного поисковика нашел консольную программу, NirCmd, программа позволяет осуществлять достаточно много действий кроме указанных выше. С основной частью мы определились. Как я говорил, немного изучаю php, веб-сервер у меня как правило запущен постоянно, поэтому ничего специфичного в плане сервера я придумывать не стал. Сервер написан на php и состоит из двух классов: Control, который представляет собой методы, которые исполняют консольные команды и Route, который делает валидацию приходящих запросов и исполняет методы класса Control.

Control выгладит вот так (код однотипный, поэтому я сократил):

Всем мир!

Содержание статьи:

1. Что такое CRAWL
2. Динамический CRAWL
3. Задачи, инструменты, решение
4. Почитать
5. Выводы

Здрасте!
Поговорим про самое спорное телодвижение компании Битрикс — технологию «Композитный сайт».
Спорное оно потому, что ребята запатентовали технологию, которая, по моему мнению, не тянет даже на курсовую 3 курса профильной специальности.

Ну да ладно, это ж маркетологи.

В статье рассмотрены:

• сама технология «Композитный сайт»
• альтернатива данной технологии «CompoJax» (через ДЖ)
• примеры кода, для той и другой технологии
• пример внедрения CompoJax в любую CMS на примере WordPress

Все вкусности внутри, го под кат.

Прошлую свою статью я посветил описанию «велосипеда» (загрузчика и шаблонизатора в рамках «легкого» framework’а). Волею судеб, для пары проектов я был вынужден выделить шаблонизатор и сделать его standalone версию, обогатив при этом рядом новых возможностей. Именно об front-end шаблонизаторе и пойдет речь.

Но чтобы сэкономить ваше время, прежде я обозначу тех, кому эта статья может быть интересной (ибо букв будет много):

• Вы front-end разработчик, и вам интересно использование шаблонов.
• Вы back-end разработчик, и вам интересно использование шаблонов на front-end’е.
• Вы давно ищете какой-нибудь инструмент для систематизации своей коллекции UI-control'ов, накопившуюся за несколько лет.
• Вы интересуетесь разработкой web-компонентов.
• Вам хочется высказать критические замечания и порекомендовать angularJS.
• У вас есть свободное время и вам интересно почитать об очередном велосипеде.
• У вас нет свободного времени, но вам интересно.
• Вы хороший и любознательный человек.

Наверное, каждый веб разработчик сталкивался с необходимостью в реализации поиска на сайте. Довольно распространенное решение — Apache Solr. В мире Drupal разработки это не исключение. Для интеграции Solr с Drupal и реализации фасетного поиска существуют модули search_api, search_api_solr и facetapi. Но в большинстве случаев нам бы хотелось, чтобы результаты поиска и фасетные фильтры обновлялись без перезагрузки страницы, то есть ajax'ом. И, как обычно в мире Drupal, на d.org найдется какой-нибудь проверенный временем и пользователями модуль (а может и не проверенный, как повезет), который делает то, что нам нужно. В данном случае это ajax_facets.

Я не сторонник велосипедов. Прежде чем начать разрабатывать свое решение тривиальной на мой взгляд задачи, всегда трачу уйму времени на поиски уже существующих библиотек или модулей. И далеко не потому, что мой код заведомо будет хуже стороннего. Просто, зачем придумывать то, что уже создано, проверено и отлажено. Гораздо лучше потратить время на создание чего-нибудь нового, непридуманного доселе. Однако в этот раз мне все-таки пришлось садиться за разработку самому. В статье речь пойдет об удобной js-библиотеке, позволяющей «связывать» данные.

У меня, как у художницы и web-разработчика, со временем появилась необходимость в собственной галерее. Обычно, у галерей две основные функции: показ витрины — всех (или некоторых) картин — и детальный показ одной. Реализация обеих функций есть практически в любой готовой галерее. Но «заношенный» внешний вид готовых галерей и, ставший стандартом, пользовательский интерфейс не годятся для художника :). А нестандартный — требует особой архитектуры и реализации кода, осуществляющего загрузку и показ картин. Сам показ и пользовательский интерфейс я в этой статье опущу. Основное внимание будет отдано загрузке картин с сервера. Об итоговой организации контролируемой загрузки с использованием очередей, асинхронного загрузчика, обработки блоб-объектов, каскадов выполнения обещаний и с возможностью приостановки и пойдет речь.



Примеры кода записаны на coffeeScript

WordPress, будучи одной из самых популярных CMS в мире, снабжен подробной документацией, а точнее, даже двумя. В связи с чем ни в коем случае не стоит воспринимать этот текст как описание неких “best practices” и уж точно никто не заставляет слепо следовать описанному. Статья — просто быстрый ответ на вопрос «как?!» (следующий абзац) и подробное описание всего, что нужно знать чтобы заставить WordPress отвечать на AJAX-запросы (вся остальная статья).

Кратко

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

Итак, работает это, «WordPress-way», вот так:

1. На бекенде с помощью функции admin_url получаем ссылку на обработчик AJAX-запросов и передаем ее во фронтенд одним из способов. Именно к этой ссылке мы будем делать наши запросы.
2. На бекенде регистрируется хук с функцией для обработки некоего экшена. Назовем этот экшен, например, get_posts.
3. Фронт-енд делает запросы к URL-у из пункта 1, передавая имя экшена. Например, ?action=get_posts.
   На бек-енде, если на экшен зарегистрирован хук, выполняется заданная нами функция.

Вот так вот просто. Теперь подробнее.

Вступление

Посещаю Хабр уже давно, но на статью решился только сейчас. Да и то, не статья это вовсе, а так — скорее, заметка о том, как легко и без напряга, без правки ядра и заморочек с самим аяксом взять и заменить стандартное убогое окошко прелоадера битрикса на свой произвольный HTML/CSS код. Приступим?

Недавно я опубликовал статью «Перенаправление данных из COM-порта в web», в которой описал прототип системы, транслирующей строки из последовательного порта компьютера в веб-браузер. В той статье я указал направления, в которых надо доработать прототип, чтобы приблизить его к продакшен-стадии:
— никакой дизайн веб-страницы
— в каждый момент времени данные получит только один веб-клиент
— очень ограниченный набор браузеров, с помощью которых можно получить доступ. Например, не работает ни в Internet Explorer 8, ни в браузере из Android 2.3.5
— требуется установка python

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

Многие знакомы с таким флагом XmlHttpRequest как withCredentials, знают для чего он нужен, какие заголовки нужно использовать с ним в паре, чтобы браузер нормально обрабатывал ответы сервера. И я вроде тоже знал, а что не знал — нагугливал, и всё работало как надо. Но однажды столкнулся с неожиданным поведением, о чём и хочу поведать.

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

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

Когда вокруг так много новых технологий, непросто понять, на изучение какой стоит потратить время.
(Karl Seguin)

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



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

AJAX-вызовы вывели работу web на новый уровень. Уже не нужно перезагружать страницу в ответ на каждый ввод информации пользователем. Теперь возможно отправлять вызовы на сервер и обновлять страницу на основании полученных ответов. Это ускоряет работу интерактивного интерфейса.

А вот что AJAX не обеспечивает – так это обновления с сервера, которые необходимы для работы приложения в реальном времени. Это могут быть приложения, в которых пользователи одновременно редактируют один документ, или уведомления, рассылаемые миллионам читателей новостей. Необходим ещё один шаблон для рассылки сообщений, в дополнение к запросам AJAX, который бы работал в разных масштабах. Для этого традиционно используется шаблон PubSub («publish and subscribe», «публикация и подписка»).

Какую задачу решил AJAX

До появления AJAX интерактивные взаимодействия со страницей были тяжеловесными. Каждое из них требовало перезагрузки страницы, которая создавалась на сервере. В этой модели основной единицей взаимодействия была страница. Неважно, какой объём информации отправлялся из браузера на сервер – результатом была полностью обновлённая страница. Это была трата как трафика, так и серверных ресурсов. И это было медленно и неудобно для пользователей.

AJAX решил проблему, разбивая всё на части: стало возможным отправить данные, получить конкретный результат и обновить лишь часть страницы, имеющую к этому отношение. От вызова «дай мне новую страницу» мы перешли к конкретным запросам данных. У нас появилась возможность делать вызовы удалённых процедур (RPC).