За мою карьеру программиста я сделал огромное количество ошибок в нескольких различных языках. На самом деле, если я пишу 10 или больше строчек кода, которые работают с первого раза, я становлюсь подозрительным и принимаюсь тестировать его более тщательно, чем обычно, предполагая найти ошибку в синтаксисе, или неверную ссылку на массив, или неправильно записанную переменную, или что-то ещё.

Мне нравится подразделять эти ошибки на три большие группы: провалы, погрешности и недочеты. Провал – это когда ты сидишь тупо смотришь на экран и тихо говоришь «ой»; вещи вроде удаления базы данных или целого сайта, записи чего-либо поверх результата трехдневной работы, или случайной отсылки письма 20 тысячам человек.

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

Когда ошибка настолько неочевидна и неуловима, что это почти прекрасно, я зову это недочетом. Такое случается, когда кусок кода сталкивается с совершенно непредсказуемыми и весьма маловероятными обстоятельствами. Вы откидываетесь на спинку стула и думаете «Ого!», словно увидев яркую радугу или падающую звезду.

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

Судя по комментариям в этой статье, создание веб-приложений с возможностью аякс-навигации является интересной для сообщества темой и пока еще немногие сталкивались с подобной задачей. Я расскажу о ее решении с помощью небольшой библиотеки под названием jQuery-Pjax (либо моего форка ее).

Моя мотивация: в проекте нужно было реализовать mp3-плеер, играющий независимо от навигации на сайте. Далее потребовалось добавить поддержку браузеров без pushState — и я сделал форк библиотеки.

Основные особенности

• навигация по сайту и обработка форм без полной перезагрузки страниц
• чистые url, доступные для прямого доступа
• поддержка #!/hash для устаревших браузеров (добавлено в моей версии)
• работа с кнопками «назад» и вперед» для современных браузеров
• а теперь и для старых — благодаря benalman.com/projects/jquery-hashchange-plugin
• похоже, есть проблемы с ИЕ7 (спасибо Nc_Soft) (тем более, большое спасибо за участие Nc_Soft) и, возможно, opera 11.5 (пока не могу подтвердить, но нахожу крайне удивительным из-за dev.opera.com/articles/view/introducing-the-html5-history-api) — сообщение artishok — проверено и работает на сборке 1074 (not_ice)
• imsamurai (https://github.com/imsamurai) предложил улучшения библиотеки (и я радостью слил изменения): встроенная функция для отправки форм, улучшения работы с хешами и более развитая система триггеров. (у imsamurai, к сожалению, нет аккаунта на хабре — будем рады помощи)

Ссылки

• jQuery Pjax github.com/defunkt/jquery-pjax
• мой форк с поддержкой хеш-навигации github.com/ckald/jquery-pjax
• работа библиотеки на примере моего проекта amsterdamusic.com.ua
• пример от создателя pjax.heroku.com

Принцип работы Pjax

Статья посвящена плагину, который упрощающает жизнь client-side программиста.

При заполнении формы случается так, что учитывая введенные данные, форму нужно менять (прятать и показывать поля). Простейший пример: при заказе доставки товара пользователь выбрал «самовывоз», значит поля про адрес доставки можно спрятать, зато было бы здорово показать карту проезда для самовывоза.

И что дальше

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

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

Второй подход это писать «портянки» javascript'а который всю эту логику реализует на стороне клиента. Особенно грустно писать «каскадную» логику типа «если ввели a в поле A, показать B, если ввели c в поле B, то показать D. Если в A ввели что-то другое, спрятать B, а потом D».

Оба варианта нельзя назвать удобными. Прежде всего потому что логика реализуется императивным стилем вместо уместного для таких случаев декларативного. Но выход есть!

Часть 1: Архитектура
Часть 3: Клиент-серверное взаимодействие
Часть 4: Переходим в 3D

Итак, продолжим создание многопользовательской игры.
Сегодня мы рассмотрим создание протокола передачи данных.
А также создадим заготовки TCP сервера и соответственно клиента.

Часть 2: Протокол
Часть 3: Клиент-серверное взаимодействие
Часть 4: Переходим в 3D

В общем, как и обещал, публикую серию статей по разработке многопользовательской сетевой игры. Изначально я хотел просто накатать статейку по разработке серверной части на интересном языке Scala. Но понял, что одной статейкой для развертывания темы не получится обойтись. А писать очередной топик обо всем и ни очем, не хотелось изначально. Поэтому встречайте пьесу в трех действиях. В течении которой мы разработаем архитектуру проекта, реализуем серверную и клиентскую части…
Все помнят прикольные танчики на денди?
Ну вот на примере этих танчиков и будем разрабатывать сервер и клиент.

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

Пришло время ответить на данный вопрос. Я немного затянул т.к. хотел рассказать доклад на одноименную тему на Я.Субботнике. Доклад был очень коротким многие важные моменты пришлось выкинуть. Статья — более-менее полная версия.

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

Краткое введение

В статье пойдет речь о вещах, которые сотни раз описаны в талмудах по CS: об общепринятых стилях кодирования, о документировании кода, об юнит-тестах и т.п. Это крошечный сборник советов для студентов начальных курсов IT-специальностей. Сумбурный текст и повторения необходимы для лучшего пережевывания материала.

Статья предназначена для начинающих студентов-программистов.

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

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

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

Забегая вперед скажу, что выбор полностью себя оправдал — мы избавились от огромного количества проблем при разработке и проектировании БД, код проекта сильно упростился и стал гораздо лучше структурирован, но самое главное — тот самый поворот в сознании, который нам дал CouchDB. За это время я лично набил множество шишек при разработке и хотел бы поделиться опытом с Хабрасообществом. Эти советы не для начинающих — это советы по использованию CouchDB на живом production.

Если ваш веб проект так или иначе будет связан с поиском и предоставлением пользователям некоторых данных, то перед вами наверняка встанет задача реализации строки поиска. При этом, если в проекте по какой-либо причине не удастся использовать технологии умных сервисов как Google или Яндекс, то поиск частично или полностью придется реализовать самостоятельно. Одной из подзадач наверняка будет реализация нечеткого поиска, ведь пользователи часто ошибаются и иногда не знают точных терминов, названий или имен.

В данной статье описывается возможная реализация нечеткого поиска, которая была применена для поиска на сайте edatuda.ru.

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

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

Введение

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

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

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

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

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

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

Была у пользователей Эльбы мечта — вставлять изображения печатей и подписей в счета, акты, накладные и прочие серьезные документы. Отчего бы не порадовать мечтателей, подумали мы. Оглядевшись по сторонам, мы поняли, что обычно в таких случаях всю грязную работу сваливают на пользователя (ну, вы знаете: «картинка должна быть 300 на 400 пикселей, с высоким контрастом, хорошим разрешением и идеально белым фоном»). Но судя по опыту нашей команды, которая бывает в колл-центре, даже простая загрузка изображения с фотоаппарата повергает пользователей в глубокую депрессию, и вызволять их приходится богопротивными способами, а-ля «вставьте картинку в Ворд». Конечно, не может быть и речи о том, чтобы заставлять пользователей чистить печати в фотошопах — пусть фотографируют как умеют, а Эльба выполнит за них все остальное!



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

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

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

В этом топике я хотел бы рассказать, как добавить изображениям на веб странице эффект размытия по Гауссу без использования флеша. Статью я планировал написать еще год назад, и, к моему большому удивлению, меня никто не опередил, хотя тема достаточно проста и интересна как с точки зрения веб дизайна, так и с точки зрения клиентской разработки. Для создания эффекта будем использовать уже ставшую популярной технологию SVG, которая работает во всех последних версиях браузеров. Для IE8- воспользуемся CSS фильтрами (Blur в частности), которые работают только в продуктах Microsoft. Для начала, предлагаю ознакомиться с итоговым вариантом здесь (наведите на любое изображение). Скрипт представлен в виде jQuery плагина, но выдернуть его для использования вне jQuery не составит труда.

Очевидно, целью работы являетя не только размытие картинки, а и анимация этого размытия.

Из простейшего примерамы видим, что интенсивность размытия зависит от атрибута stdDeviation в теге feGaussianBlur.

Представляю вашему вниманию перевод статьи под названием "Designing Web Registration Processes for Kids" от Deb Gelman. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания A List Apart.

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



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

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