Доброго времени суток, %username%.
Представляю твоему вниманию анонс Ample SDK, новой кросс-браузерной библиотеки интерфейса пользователя.

Познакомиться с проектом Ample SDK тебе будет интересно по следующим причинам:

• упрощает создание клиентских веб-приложений
• реализует стандартные веб технологии и API кросс-браузерно
• повторяет архитектуру веб-браузера (ничего нового учить не надо!)
• позволяет использовать SVG в HTML (также в Internet Explorer, хм!?)
• позволяет использовать XUL в любом современном браузере
• позволяет легко определять новые доменно-зависимые UI технологии
• проект с открытым (MIT/GPL) исходным кодом (на GitHub)

Для затравки, один и тот-же SVG Tiger документ отображенный в Internet Explorer 6 и Google Chrome 3:



Интересно?

Не так давно при разработке своего проекта возникла идея реализовать полноценные коллекции для хранения объектов одинакового типа, по удобству напоминающие List<Type> в C#.
Идея состоит в том, чтобы коллекции, содержащие объекты различных типов сами по себе различались, а не имели, скажем, один унифицированный тип Collection. Другими словами, коллекция объектов типа User это не то же что коллекция объектов Book. Естественно, первой мыслью было создание различных классов для коллекций (UserCollection, BookCollection, …). Но данных подход не обеспечивает нужной гибкости, плюс ко всему, нужно тратить время на объявление каждого подобного класса.
Немного поразмыслив, реализовал динамическое создание классов коллекций. Выглядит это так: пользователь создаёт коллекцию объектов типа Book, а нужный тип BookCollection создаётся (т.е. объявляется) автоматически.

Сейчас в тематических интернетах модно слово «Node.js». В этой небольшой статье мы попробуем понять («на пальцах»), откуда всё это взялось, и чем такая архитектура отличается от привычной нам архитектуры с «синхронным» и «блокирующим» вводом/выводом в коде приложения (обычный сайт на PHP + MySQL), запущенного на сервере приложений, работающем по схеме «по потоку (или процессу) на запрос» (классический Apache Web Server).

Не так давно в рамках конференции Build был доклад «Future directions for C# and Visual Basic» от Anders Hejlsberg, в котором анонсировался Roslyn Project. Сейчас об этой разработке известно не так много, но я постараюсь осветить наиболее интересные моменты, имеющиеся на данный момент.

В настоящее время компиляторы C# и Visual Basic представляют из себя чёрный ящик — они берут исходный высокоуровневый код и выдают нам готовый IL-код. Roslyn Project представляет из себя compiler as a service, т.е. компилятор, предоставляющий разработчику API, позволяющее добираться до его внутренних данных. Теперь можно анализировать код и принимать участие в компиляции — проводить модификацию исходного кода, создавать дополнительную функциональность для C# и VB.

Все мы тут собрались умные, образованные, красивые и опытные. И на сегодняшний день, мне кажется, почти все используют тот, или иной вид RPC между JavaScript и PHP, который работает на API из того, или иного фреймворка. Кое кто даже разрабатывает какие-то свои костыли и подпорки. Я не исключение, конечно же. Правда пошел я по пути наименьшего сопротивления и, собственно, речь в этой статье пойдет как раз об этом — об очередной реализации XML\JSON RPC для JavaScript и PHP.

Предыстория такова, что мне необходимо было разработать некую систему управления данными. Естественно, что данные хранятся в СУБД, а управлять ими надо через веб. Привязываться к фреймворкам готовым очень не хотелось, потому выбор был не велик — PHP-быдлокодинг, или MVC с рендерингом на основе готовых разработок вроде smarty. Однако, примерно в то же время, я обратил внимание на такие проекты как extJS (он же Sencha теперь) и qooxdoo, которые позволяют создавать полноценные веб-приложения минуя утомительную HTML-верстку, генерацию HTML/XML, XSLT преобразования и многие другие «страшные» вещи, характерные для MVC и PHP-быдлокода. Потому созрел следующий план действий.:

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



К таким библиотекам я отношу визуализацию графиков, чартов, графов, таблиц, отчетов, инфографик и т.д.

В свое время я написал несколько статей на тему визуализации данных в вебе (их можно поискать на хабре по ключевой фразе «Визуализация данных в вебе»).

Но с тех пор появилось много новых инструментов, мы получили HTML5 и т.д., поэтому вопрос опять стоит достаточно остро. Я решил собрать информацию о всех JavaScript инструментах, с помощью которых можно визуализировать данные в вебе (в первую очередь для себя, но потом решил, что, возможно, будет интересно это и другим). Я уже начал собирать информацию в виде списка инструментов с примерами в одном месте для того, чтобы не бегать по разным сайтам в поисках демок и описания функционала. Есть уже около 10 библиотек.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

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

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

Что представляет из себя этот паттерн?

Исходя из названия легко догадаться, что это некая, определенная, фабрика (или завод), который создает объекты. Еще раз выражу слово определенная. Как и в реальной жизни фабрика имеет некую специализацию, создавая товары или устройства какого-либо определенного типа. И фабрика, которая выпускает, например, мебель, не может производить, например, еще и компоненты для смартфонов. По аналогии с программированием фабрика объектов может создавать только объекты определенного типа, которые используют единый интерфейс. Самыми главными преимуществами данного паттерна в С++, является упрощение создания объектов различных классов, использующих единый интерфейс. Зачастую библиотекам, которые разрабатывают программисты нужно не только уметь работать с определенными объектами, но и создавать их. Самый очевидный пример загрузка файлов различных форматов. Мы не знаем, какой файл мы будем загружать заранее, но у нас есть список возможных форматов. Пользователь указывает файл, библиотека пытается определить тип файла и вызвать соответствующий загрузчик для него. В большинстве случаев программисты использует конструкции типа switch или if, чтобы определить экземпляр какого класса им необходимо создать. И чем больше возможных вариантов появляется, тем больше разрастается эта конструкция, в последствии превращающиеся в уродливого монстра.

Что нам может предложить фабрика объектов?
Во-первых, простой метод создания объектов, который сократит switch/if до 1ой строчки.
Во-вторых, удобные методы для работы с объектами фабрики. Мы всегда точно можем узнать, зарегистрирован ли у нее определенный класс, количество зарегистрированных классов, а так же удобные методы для добавления и удаления экземпляров классов в фабрику. С помощью фабрики можно ограничивать набор возможных классов, которая она будет создавать, используя некую конфигурацию.

Прочитал пост про Kerning.js — небольшую js-библиотеку, можно даже сказать утилиту, для реализации чудес типографики на веб-страницах. И вспомнил, что пользовал не так давно нечто подобное — библиотеку Lettering.js.

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

Итак, Lettering.js — помощник «радикального» веб-типографа, Cryptico.js — помощник Штирлица и Rasta.js — такой простой ajax get/set помощник. Далее ссылки на сайты разработчиков этих библиотек и инструкций по их использованию.

Что имеем

Начну с того, что расскажу немного о проекте, в котором работаю и как там все пишется. Может не у одних нас так…

Проект представляет из себя CRM систему, разрабатываемую специально для клиентов одного сегмента бизнеса. Проекту лет 6 и команда разработчиков состоит из 10 человек. Язык: C++ и PL/SQL.

Наша система исползует Plain Old XML, так уж повелось. И на используемые XML нет схем, по большей части. Что тут говорить, если юнит тесты прививаются здесь только второй год и менеджер до сих пор упрекает за время, потраченное на их написание. Да ладно…

По ходу дела все улучшения появляются тогда, когда текущее положение дел порядком надоедает и становится невмоготу. Так же произошло и сейчас.

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

Сейчас довольно популярно использование Comet-технологии, «когда при которой постоянное HTTP-соединение позволяет веб-серверу отправлять (push) данные браузеру, без дополнительного запроса со стороны браузера», согласно википедии.
Реализаций этой технологии есть много разных, но я сейчас хочу остановиться на одной из них, которая называется Long Polling. В статье я разберу, что это такое и с чем его едят.
Ну а тем, кто знает, что это, возможно, будетинтересно посмотреть на реализацию, которая не использует сторонний софт для своей работы — только PHP. Зачем это нужно, если есть специальные comet-сервера, которые выдержат гораздо более высокие нагрузки, чем скрипт на PHP? Это может пригодиться, если нужно сделать небольшой проект без высоких нагрузок, а на хостинге не дают ставить сторонний софт. Ну и если мне в рамках одного задания, где как раз нельзя было использовать сторонние приложения, пришлось реализовать данный функционал, то почему бы не поделиться.

Yaf — это PHP микро-фреймворк, взявший за основу структуру приложения Zend Framework, но написанный на С и является PHP extension доступным через PECL.

Основной (и единственной) задачей для написания его послужила необходимость максимально быстрой (сравнимой с php) обработки запросов в парадигме MVC но с удобством предоставляемым Zend Framework.

Yaf и Zend Framework, имеют аналогичные API и подобную концепцию, сохраняя при этом совместимость.
Я сгенерировал тестовое приложение (zf create project test) и провел небольшой синтетический тест производительности.

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

Молодые специалисты, прейдя на первый проект в своей жизни, воспринимают все традиции по ведению тестовой документации и тестированию как эталон, так как у них нет опыта и им не с чем этот процесс сравнить. Взяв за основу какой-либо стиль дизайна отчета об ошибке, при смене места работы на собеседовании могут возникнуть споры при ответе на вопрос: «Расскажите нам про дизайн баг-репорта», т.к. у команды, в которой вы хотите работать стиль описания может отличаться. Здесь важным моментом является не угадать этот самый стиль, а озвучив свой и услышав в его адрес критику, уметь обосновать свою точку зрения.

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

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

PhantomJS это все плюшки WebKit из консоли с управлением на JS и поддержкой различных стандартов и технологий: DOM, CSS, JSON, Canvas и SVG.

Внутри несколько примеров использования

Каркас для кроссбраузерной разработки ExtJS сейчас очень популярен. Это поистине грандиозный (и монструозный) набор компонентов, классов, функций, хелперов и т. п., которые могут как облегчить жизнь разработчика, так и усложнить ее. Говоря вообще, ExtJS (до 4-й версии) не устанавливает никаких «правил игры» для конечного разработчика: формально нет никаких требований и рекомендаций по проектированию и написанию надежных приложений.
Удивительно, что до сих пор качество пособий и туториалов для новичков ExtJS, мягко говоря, оставляет желать лучшего. Как и стандартная справка по ExtJS API, впрочем [1].
Цель данной статьи — показать, как писать приложения на базе ExtJS так, чтобы человеку, который будет поддерживать ваш код, не хотелось рвать волосы, а вам просто не было стыдно. А если серьезно, то в данной статье я предложу простой и короткий набор правил проектирования и написания приложений применительно к данному фреймворку.

Совсем недавно стала задача организовать кэширование данных. И получилась весьма удобная вещь. Реализацию смотри под хабракатом…

Введение

На мой взгляд, jqGrid — самый успешный и удобный на данный момент плагин для jQuery, работающий с таблицами БД через AJAX запросы и PHP (Так же существует версия для ASP.NET).

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

Приветствую! Речь пойдет о создании программы, которая сможет кодировать информацию в штрих код. Рассмотрим мы два варианта: EAN13 и Code 128.

Для начала разберемся что же предоставляет собой штрих код, и начнем с формата EAN 13. Внешне штрих код состоит из черных и белых полос. Каждая из полос согласно стандарту имеет ширину 0,33мм. А теперь посмотрим немного глубже. Согласно стандарту, информация в штрих коде алгоритмом конвертируется в последовательность нулей и единиц. Черная полоса соответствует «1» а белая соответственно «0». Таким образом мы получаем штрих код. То, что описано выше, справедливо для обоих форматов, а теперь перейдем к специфике форматов. EAN 13 код фактически может иметь 12 символов информации (обычно она разделяется на код страны, код завода, и.т.д., но никто вам не мешает создать штрих код с любыми цифрами). 13 цифра в штрих коде ( а он EAN 13 имеет их именно 13) является контрольной суммой. Она используется для проверки правильности декодирования, а также в зависимости то нее выбирается соответствующая таблица кодирования. Вот и все по формату EAN 13. Детальная информация об алгоритме кодирования и о расчете контрольной цифры есть тут:

Итак, что нам нужно сделать для программной генерации штрих кода (причем обоих форматов):

1. Настроить графический интерфейс так, чтоб 1 юниту соответствовало 0.33 мм
2. Конвертировать код в двоичную последовательность (из «0» и «1»)
3. Отобразить последовательность таким образом что каждая единица- прямоугольник с шириной 0,33 мм. Замечу, что можно изменять величину штриха, но по стандарту сказано 0,33мм.

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

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