Манускрипт Войнича (МВ или VMS) называют чашей Грааля криптографии. За несколько сотен лет тысячи человеко-дней были потрачены и продолжают тратиться в попытках разгадать его смысл и перевод. Причем пытались люди очень разные, в том числе выдающиеся мировые криптографы. Пока что получается не очень. Две с небольшим сотни пергаментных страниц, неизвестный алфавит, неизвестный язык, каллиграфический уверенный почерк, десятки рисунков неизвестных растений и обнаженных женщин, купающихся в странных каналах, зодиакальные астрологические диаграммы — множество зацепок, но пока ничего, что позволило бы дешифровать рукопись. Для любого, кто хоть чуть-чуть попробовал поразгадывать крючки, МВ представляется идеальной головоломкой — не имеющей пока известной разгадки.

Страница 16v

Видел несколько месяцев назад пост на Хабре про ацтекский язык и ботаников, опознавших несколько центрально-американских растений, но всё-таки достану из черновиков свои записи. Их цель — познакомить читателей с миром разгадывателей VMS и моим не очень глубоким анализом одной из относительно недавних гипотез — о маньчжурском языке манускрипта.

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

С развитием мобильных технологий и роста устройств, способ взаимодействия с браузерами изменился. Сегодня браузер должен органично вписываться в экосистему устройства, быть удобным для touch-интерфейсов, многофункциональным и современным. Вадим pepelsbey Макеев, веб-евангелист Opera Software, на международной мобильной конференции #MBLT14 рассказал слушателям о новом поколении современных браузеров на примере нового Coast — экспериментального проекта компании.


Презентация.

Под катом — интервью с Вадимом.

Недавно по работе собирал своего рода лекцию по веб-безопасности, ознакомился с известным рейтингом уявзимостей OWASP 2013 года, но с удивлением обнаружил, что корректной инфы на русском языке крайне мало, или её практически нет.

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

Некоторые из предоставленных в списке уязвимостей уже расписаны и не раз — известный факт, но без них список был бы неполным. Поэтому сразу дам небольшое содержание поста:

• SQL Injection
• Некорректная аутентификация и управление сессией
• Межсайтовый скриптинг (XSS)
• Небезопасные прямые ссылки на объекты
• Небезопасная конфигурация
• Утечка чувствительных данных
• Отсутствие контроля доступа к функциональному уровню
• Подделка межсайтовых запросов (CSRF)
• Использование компонентов с известными уязвимостями
• Невалидированные редиректы
• Кликджекинг
• Фишинг
• Include

Привет, Хабра!
При разработке игр на JavaScript часто возникает необходимость создавать множество объектов. О том, как правильно это сделать и не утонуть в коде, я рассказывал, примерно — месяц назад на Frontend Dev Conf в Минске. Возможно, доклад будет интересен тем, кто не был на конференции и сталкивался с проблемой создания множества объектов, либо является разработчиком HTML5 игр.



Под катом текст с картинками.

При создании приложений на AngularJS у начинающего разработчика возникает много вопросов, особенно в том случае, если до определенного времени он использовал библиотеки сходные с jQuery или Prototype. В данном посте хотелось бы поделиться некоторыми приемами, которые будут полезны начинающим AngularJS разработчикам.

Загрузка приложения и менеджер состояний

До момента загрузки самого фрэймворка, его зависимостей и отработки всех запросов в бэкграунде приложение может выглядеть весьма удручающе. И даже ng-cloak не сможет помочь в большинстве случаев. Обычно для таких целей используют div имеющий больший z-index чем основной контент сайта и перекрывающий его до загрузки всех компонентов и состояний. Он может выглядеть так:

<div class="loader" ng-show="loader"><div class="loader-content">Loading...</div></div>

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

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

Оригинальная версия старинной французской поговорки гласит: Le bon Dieu est dans le détail («Бог в деталях»). Собственно, неприметные на первый взгляд детали и отличают Sketch от многочисленных конкурентов. Давайте поближе взглянем на этот кладезь удивительных мелочей.

В нашем издательстве вышла довольство интересная книга по дизайну от Сhip Kidd’s:

В проекте используется angularjs, проект уже достаточно большой, используем очень много кастомных директив, но сегодня столкнулся с проблемой поведения ng-if .

Для меня было ожидаемо, что условие работает так же как и в js, то есть:

if (condition) {
 ...
} else {
 ....
}

В зависимости, что передано — элемент будет скрыт или показан.

Вчера Google анонсировал 64-битную версию своего браузера Chrome. Для того, чтобы получить эту версию, необходимо выбрать либо Dev Channel либо Canary channel, для пользователей Windows 7 и 8.

Введение

Всех приветствую!

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

Мобильные приложения, это не будущее разработки, это уже настоящее. В настоящее время пользователей мобильных приложений уже 1.2 млрд. человек, и это количество постоянно растет (Wikipedia). Вскоре количество мобильных устройств превзойдет количество людей на планете. Если скорость роста количества мобильных устройств останется неизменной, то к 2017 году ими будут пользоваться 5.1 млрд. человек.
Для нас, как для разработчиков приложений, важно разрабатывать свои приложение с учетом мобильных пользователей, если мы хотим чтобы они были востребованы. В AngularJS реализована поддержка мобильных устройств, написанная как командой AngularJS, так и сообществом.
В этой статье мы будем работать с двумя различными способами, чтобы дать читателям опыт в разработке мобильных приложений.

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

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Предыстория

За всё то время, что я занимаюсь веб-разработкой, как-то не возникало необходимости написать, наверное, чуть ли не самый распространённый вариант заказов на биржах фриланса — интернет-магазин. К такой потребности пришёл только, собственно, с уходом во фриланс. Передо мной встал извечный вопрос — какой же движок выбрать. Довольно долго шерстил сеть, встречал различные комментарии, обзоры, сравнения на этот счёт, наконец плюнул и взял одно из довольно популярных, хотя часто не замечаемых в угоду более известных и навороченных конкурентов, решение — OpenCart. Взял и не пожалел. Обычно я жутко не люблю и не перевариваю различные ширпотребные CMS, но OpenCart оказался исключением. Не думаю, что моё описание будет сильно полезно профессионалам — мини-анализ рассчитан скорее на тех, кто точно так же пытается определиться, на чём писать, или кто просто ещё не пробовал.

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

При составлении АПИ руководствовался принципом — как можно проще. Поэтому сначала несколько мыслей о загрузке файлов:

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

Загрузка каждого файла отдельным запросом. На любом хостинге существует ограничение на максимальный размер POST-запроса (напр., 10 МБ). Если мы грузим одновременно 10 файлов, значит их вес в сумме не должен превышать 10МБ. В 99% случаев проще пожертвовать производительностью и не иметь проблем с такими ограничениями.

Никаких отложенных загрузок. Файл должен загружаться сразу после добавления (не в 2000 году, чай, живем), поэтому никаких методов работы с очередью — выбрал файл, выбрал еще 5 штук, удалил один, нажал «отправить» — не будет. Зато будет отмена загрузки.

Не стоит разделять загрузку файлов по кнопке и перетаскиванием. В моем случае любая область, помеченная директивой позволяет перетаскивать на нее файлы, а если это инпут с типом file, то еще и в проводнике можно выбрать. Очень удобно знать, что на кнопку можно перетаскивать, когда потянул в браузер 10 файлов, а дизайнер забыл подсветить поле перетаскивания, и гадаешь перетащатся ли они или откроются в новом окне.

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

Dat

Dat — data package management. Это инструмент, который позволяет обмениваться большими наборами данных с целью построения совместного рабочего процесса, подобно git с исходными файлами. Важно упомянуть, что текущий статус проекта pre-alpha.

npm install dat -g

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

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

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

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

В Wordpress есть два типа контента: Посты и Страницы.
Эти типы содержат такие поля как название, описание, категории/тэги.
Дополнительное описание можно создать с помощью Пользовательских Полей (Custom Fields).

В Wordpress 3.0 появилась возможность создавать свой тип контента.

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