JavaScript *

Наверно каждый веб-программист задумывался о том, как избавиться от назойливых картинок антиспама, которые по смыслу должны пресекать ботов-спамеров, а на деле отпугивают реальных посетителей. Работая над очередной поделкой на HTML5+JS+canvas, пришла идея нового прототипа защиты от ботов. Данная идея не что иное как очередная вариация самой капчи, но на этот раз без дурацких «угадываний» символов.

С traceGL можно увидеть весь JavaScript поток в шустром webGL визуализаторе. Это как осциллограф, только для кода.

На сайте traceGL предлагают купить за $14.99 или € 11.50

jRIApp — ещё один HTML5 фреймворк, созданный для разработки Web приложений, которые по своей функциональности мало чем уступают desktop приложениям.

Основное отличие от уже существующих фреймворков типа angularJS или emberJS, это наличие интегрированного с фреймворком сервиса данных, а также использование MVVM дизайн-архитектуры вместо наиболее распространенного в фреймворках такого типа MVC дизайна.
В общих чертах его можно охарактеризовать как HTML5 Фреймворк реализующий привязку к данным, имеющий инфраструктуру для декларативного прикрепления логики к HTML элементам, имеющий классы для работы с данными (DbContext, DbSet) и имеющий реализованную серверную часть дата сервисов.

Клиентская часть фреймворка написана на javascript (сейчас в разработке typescript версия), а серверная часть на C#.

Этот фреймворк опубликован на GitHub под MIT лицензией. Он включает демо-приложение написанное с использованием ASP.NET MVC4 и содержит документацию по его использованию.

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

В целом, это хочется делать просто и понятно. При этом хочется разумного компромиса. Я встречал некоторые библиотеки, которые дают мощный функционал, но при этом по объему — десятки килобайт JavaScript кода. Несколько десятков килобайт, чтобы, например, подменить параметр в QueryString? Эх…

Недавно я задался вопросом поиска инструментария для разработки мобильных приложений на html/css. Из требований были: доступность, легковесность, простота настройки. Выбор пал на встроенный Node менеджер NPM. NPM содержит
инструментарий для базовых тасков типа install и запуска пользовательских скриптов. Также NPM не такой громоздкий, как Grunt и не требует адаптации модулей под себя, т.к. запускает модули с командной строки.

В скрипте HabrAjax (113.2013.04.20) добавлено удобное редактирование исправлений в собственных статьях. Достаточно просто выделить уникальный участок текста и среди контекстных кнопок выбрать кнопку <E>. В фрейме половинной высоты откроется поле ввода с выделением именно на том месте, которое было выделено.

Также, обеспечена поддержка браузеров Iceweasel (на основе Fx3.6) в Дебиане и возвращена поддержка Firefox 3.6 в остальных ОС (но там будет иметься проблема установки старой версии Greasemonkey, актуальной для 3.6). Потенциальная аудитория — 1% от остальных пользователей Firefox.

Аудитория пользователей HabrAjax и направленность статьи

Среднее число пользователей скрипта — 40-60 человек. Поэтому, если статью прочитает 3000 человек, то практический интерес она может иметь только для 1.5% читателей. Пусть, ещё 10% будут иметь желание попробовать скрипт. Но не более. Потому что скриптами вообще пользуются немного людей. Остальным — достаточно узнать, что функции, сделанные для удобства пользования, имеются в том или ином скрипте.

Что такое GruntJS

Большинство JS разработчиков уже используют какие-то инструменты компоновки для своих разработок, даже если не знают или не используют этот термин. Они объединяют файлы при разработке, уменьшают код JavaScript-а, чтобы ускорить загрузку страниц и конвертировать Sass, или уменьшают количество файлов в CSS для браузера, и много чего другого. Чаще всего это разные инструменты, что есть не очень удобно.

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

Речь в статье пойдёт об оконном калькуляторе. Да, я знаю что их море, но тот, о котором хочу рассказать — особенный. Он позволяет считать стоимость оконных изделий на сайте со средним отклонением от расчётной программы на производстве в 0.002%. На момент запуска проекта (май 2011 года) это калькулятор был единственным решением такого рода. Как обстоят дела с этим сейчас я не знаю, но судя по периодическим звонкам, допускаю что изменилось мало чего.

Особенности проекта:

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

Выбор HTML5 Canvas в качестве основы для графической реализации. Многие разработчики до сих пор считают что данная технология “экспериментальная” и не подходит для сервисов ориентированных на широкую публику. Что тут говорить о марте 2011 года?.. Данный выбор стоил мне килограмма нейронов, но он полностью себя оправдал. Этому, а также другой специфике с которой пришлось бороться при реализации задачи будет посвящена вторая часть.

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

Релизнулась версия 2.0 самой популярной JavaScript-библиотеки.

В релизе выкинули поддержку Internet Explorer 6, 7 и 8. За счёт этого выиграли в размере на 12% и прибавили в скорости. Можно выиграть в размере ещё больше, если сделать свой билд, убив ненужные из 12-и встроенных по умолчанию модулей.

Тем, кому нужны старые IE остаются на ветке 1.x, которая их поддерживает и которую не забросили (скоро выйдет 1.10) и планируют поддерживать ещё несколько лет. API 2.0 хоть и совместим с не-deprecated 1.9, но изменений всё-таки много.

Подробный список изменений есть в официальном анонсе.

При разработке веб приложений, мы используем Asp.net MVC и backbone.js. При написании логики проверки достоверности у нас возникла проблема дублирования кода. Логику приходится описывать в модели на сервере и в модели backbone на клиенте. Хотелось бы автоматически перенести правила валиции с сервера на клиент. Для решения этой проблемы мы реализовали аналог стандартной ненавязчивой проверки достоверности данных MVC для backbone.js Подробности ниже.

2 месяца назад я выложил на GitHub первую бета-сборку WebQuake — порта первого Quake, работающего в браузере через WebGL.

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

Итак ajax запросы, всё просто, все привыкли их уже писать, но всё же как можно сократить количество написанного кода.
jquery.async.js

Сразу пример:

<form action="/" jasync>
	<input type="submit" />
</form>

форма отправляется ассинхронно

<input type="file" href="/" multiple jasync />
<div type="file" href="/" multiple jasync>Выберите файл</div>
<div href="/" jasync dropfile>Перетащите файлы и они отправятся на сервер</div>

файлы загружаюся асинхронно

<a href="/" jasync data="year=2013&month=5" class="send">отправить данные</a>

данные отправляется ассинхронно

И тут у многих наверное возник вопрос, как обрабатывать полученные данные, если форма не валидна зачем её отправлять, а если я хочу ещё отправить дополнительные параметры?

(Дата публикации оригинала — 12.04.2013)
Выбор JavaScript MVC фреймворка — тяжёлая работа. Нужно учесть много факторов, и число вариантов выбора может быть огромно. Достаточно взглянуть на проект ToDoMVC (о нем по-русски).

Я работал с 4 фреймворками: Angular, Backbone, CanJS и Ember. Поэтому решил сделать сравнение, чтобы помочь вам решить, какой из них использовать. Я выделю несколько факторов, которые вы можете использовать при выборе. Каждый фактор будет иметь оценку от 1 до 5 (больше — лучше). Я старался быть беспристрастным, но, конечно, оценки основаны на личном опыте.

Собственно, сам сниппет

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

На эту тему был нагуглен один изящный механизм, использующий одну известную особенность многих языков программирования. Если установить несуществующую дату для какого-либо месяца (например 31 апреля), то в результате нашем объекте будет сохранено соответствующее число следующего месяца (в данном случае — 1 мая).

Таким образом, для того, чтобы получить количество дней в указанном месяце, необходимо отнять результат вышеописанной операции из числа 32. То есть, если задать в качестве даты 32 апреля, в результате мы получим 2 мая. Проверим: 32-2=30 — такое количество дней будет в апреле.

	var days_in_april = 32 - new Date(2013, 3, 32).getDate();

Доброго времени суток!

Хочу поделиться своей наработкой для перевода страниц сайта с помощью простейшего jQuery плагина и такой приятной новой плюшки html5, как data-* атрибуты.

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

Теперь немного кода. Предположим у нас имеется вот такая вот нехитрая html разметка:

<h1 data-translate-key="HEADING-ONE">Heading 1</h1>
        
<p data-translate-key="SOME-TEXT">Some text in tag P</p>
        
<p data-translate-key="ANOTHER-TEXT">another text</p>

Вот два изображенья — вот и вот: ^*



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

Здесь уместно припомнить, что веборазработчики постепенно выучились употреблять градиенты в качестве фоновых рисунков: для этой цели им верно служит свойство «background: linear-gradient(…);», описываемое в стандарте «CSS Image Values and Replaced Content Module Level 3». И если сейчас перейти к стандарту по гиперссылке, то станет видно, что он достиг уж статуса «Candidate Recommendation», и что датируется он семнадцатым апреля 2012 года. В честь первой годовщины этого дня позвольте поговорить о том, что градиентная отрисовка текста всё ещё распространена в Сети куда менее, чем градиентная отрисовка фона.

Почему это так? Да потому, что единственным широко известным средством для градиентной раскраски текста служит нам нестандартный CSS-код «-webkit-background-clip: text», который обрезает любой фон (в том числе градиентный) по границе текста — и который употребляется обыкновенно в сочетании с CSS-кодом «-webkit-text-fill-color: transparent», обеспечивающим прозрачность букв самогó текста, так что фон через него проглядывает. Этот код работает с весны 2008 года, но, к сожалению, только во браузерах на основе WebKit, число которых хотя и возросло недавно (благодаря Опере, отступившейся от собственного движка), но ими одними плоды мирового браузеростроения не исчерпываются. Ни в Firefox, ни в Internet Explorer этот код не заработает.

Можно ли преодолеть этот тупик и достичь кросс-платформенности текста, отрисовываемого цветовым градиентом? Да, это возможно; но для этого придётся вместо CSS прибегнуть ко джаваскрипту.

Привет, Хабрачитатель!

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

Суть мысли, или даже вопроса — почему никто (встречавшийся мне) не использует отдельные блоки кода (помимо тех, которые используются с выражениями if else и т.д.) в своих JavaScript приложениях?

Текстовый редактор bootstrap-wysiwyg — это всего 1.5 Кб в минифицированном и сжатом виде и чуть больше 6 Кб исходного кода, базовые функции редактирования на основе execCommand, drag-and-drop для вставки изображений, поддержка стандартных горячих клавиш и ничего лишнего. Редактор работает в современных браузерах (Chrome 26, Firefox 19, Safari 6) и на мобильных платформах (IOS 6 iPad/iPhone, Android 4.1.1 Chrome). Зависимости — jQuery, jQuery HotKeys и Bootstrap.

После запуска в какой-то мере скандального сервиса MEGA разговоры о его защищенности немного побурлили и затихли. На сегодняшний день сервис живет своей жизнью и его никто даже не поломал. Из всех разговоров почему-то был упущен термин «User Controlled Encryption» (UCE, или Контролируемая пользователем криптография), которой кичится MEGA. Под словом «упущен» я подразумеваю тот факт, что мы не рассмотрели все возможности, которые дает нам криптографический движок, выполняющийся в JavaScript на стороне клиента.

Конечно, сам сервис MEGA под этим подразумевает всего лишь то, что ключи шифрования не хранятся на сервере, а вся их криптография выполняется в контексте браузера. При этом после запуска сервиса было много разговоров о том, что в нем используются нестойкие криптографические алгоритмы и что вообще все плохо и мы все умрем, а наши файлы прочитает ФСБ. Это подтолкнуло меня на мысль расширить понятие «UCE» и действительно взять криптографию под свой контроль, а именно — заменить или дополнить некоторые механизмы обеспечения безопасности сервиса.

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

Эта история началась, когда мой друг и соратник, Яп Чэ-шень, сказал мне следующее:

— Я больше не хочу никогда в своей жизни писать на Дельфи! Я поклялся: больше ни единой строчки! С сегодняшнего дня все свои проекты и библиотеки перевожу на JavaScript!

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