После долгих месяцев разработки, я могу представить публике новую версию программы для сбора информации о компьютере для ОС Windows – Aspia 0.2.5. Дата релиза неоднократно сдвигалась с целью доделать все запланированные возможности, однако дальше тянуть с выходом я не мог. В связи с отсутствием железа для тестирования, я не смог сделать поддержки чтения данных SPD для DDR3 и получения температур с процессоров производства AMD. Однако, несмотря на все эти сложности, релиз получился достойным.

Что же нового удалось реализовать?

Неделю назад в одном из моих проектов возникла задача заменить существующее слайд-шоу, реализованное на JavaScript более красивым, сделанным на Flash. При минимальном изменении кода требовалось вставить флеш-ролик и наладить передачу данных и обработку событий на страничке так, чтобы она и дальше продолжала работать корректно.

Русскоязычные статьи на тему передачи данных в связке JavaScript—Flash дают общее представление о процессе, но не учитывают одну важную деталь: в разных браузерах следует использовать различные объекты для выбора флеш-ролика. Наиболее часто предлагаемое решение работает в Chrome, но отказывается работать в Firefox, и уж тем более в IE.

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

Преамбула

Пару лет назад я и мои сотрудники столкнулись с проблемой сопровождения большого количества аналогичных БД на удаленных филиалах. Удалены они иногда на тысячи километров, а объемы исчислялись гигабайтами – что не позволяло использовать какое-либо зеркалирование серверов. Осложнялась ситуация мелкими отличиями, т.е. 95% бизнес-логики филиалов совпадало, но было ещё 5%, которые сильно мешали и ни о какой автоматической обработке группы филиалов не было и речи.

Так случилось, что понадобилось нам внедрить в своё приложение возможность распознавания текста, поэтому начались поиски подходящей библиотеки. В конечном счёте остановились на двух опенсорсных проектах CuneiForm Linux и Tesseract-ocr. Внимательное изучение проекта CuneiForm показало, что это просто порт продукта компании Cognitive Technologies, исходники которого они открыли в 2008 году и благополучно забили получив свою порцию внимания (во всяком случае такое сложилось впечатление). По сути весь проект состоял в портировании, а о новых фичах даже речи не шло. Всё это, вкупе с печальной новостью на страничке проекта, заставило нас отказаться от CuneiForm в пользу Tesseract, который в данный момент принадлежит Google, что даёт некоторую уверенность в будущем проекта. Под катом опыт сборки Tesseract-ocr под Windows с использованием MinGW и последующего создания простейшего приложения на С++.

Soundex — один из алгоритмов сравнения двух строк по их звучанию. Был разработан чуть менее 100 лет назад Робертом Расселом и Маргарет Оделл. Активно используется в США при диктовке фамилий.

Я давно интересовался применением этого алгоритма и нашёл ему место для фильтрации данных на клиенте, а точнее, для поиска отеля по названию в проекте Островок.ru.

Задача

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

До сих пор разработчики мобильных приложений следовали довольно предсказуемому modus operandi: сначала разработать приложение для iOS, потом — для Android, а потом для других платформ.

В прошлом же году компания Nitobi начала разработку открытого проекта PhoneGap, позволяющего, используя HTML, CSS и JavaScript, легко создавать приложения сразу для Android, Bada, BlackBerry, iOS, Symbian, webOS и Windows Phone 7.

Кроме Nitobi, в разработке участвуют сотни отдельных разработчиков и команда старших инженеров-программистов IBM. Проект быстро набирает обороты, у него уже около 40 000 загрузок в месяц — в общей сложности 600 тысяч — и постоянный поток пожертвований.

Сейчас же вышла версия PhoneGap 1.0, в которой сделан акцент на доступ к нативным API устройств. Другие улучшения включают в себя общую стабильность API и «подключаемую» архитектуру, совместимость API с W3C DAP, API контактов и средства удалённой отладки. Более того, новый интерфейс делает добавление платформ и расширений платформ проще, наряду с упрощением процесса разработки плагинов.

via Engadget, The Next Web

Оплата покупки на сайте — необходимый атрибут любого хорошего интернет-магазина. Это не просто правило хорошего тона, это значительное повышение оборотов. Способов оплаты в рунете много — электронные валюты Яндекс.Деньги, Киви, WebMoney, RBK Money, а также банковские карты, счета мобильных телефонов, смс микроплатежи и т.д. Как дать покупателям возможность оплачивать покупки любимым способом?
Для своего сервиса мы решили не заморачиваться и воспользовались услугами одного платежного агрегатора. Но по мере роста накопилось большое количество замечаний. Стало понятно, что агрегатор — временное решение, и рано или поздно от него придётся отказаться.

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

Я имею дело с PDF не только как пользователь, а, прежде всего, как разработчик софта, умеющего его читать и писать (возможно, вы сталкивались с продуктами компании ABBYY, работающими с PDF – ABBYY FineReader, ABBYY PDF Transformer). Я предполагаю, что вы прочитали статью habrahabr.ru/company/abbyy/blog/105006 и далее пишу только про некоторые особенности и ограничения PDF, которые больше интересны продвинутым пользователям. Никаких сложных технических деталей при этом не буду касаться, так что программистам, желающим научиться читать или писать PDF, лучше сразу перейти к чтению спецификацию версии 1.7 со страницы www.adobe.com/devnet/pdf/pdf_reference_archive.html :)

Формат PDF уже давно прижился как средство сохранения документов, которые затем не предполагается редактировать. Все PDF файлы можно условно разделить на два класса. Первый – это документы, которые были свёрстаны в цифровом виде, и затем были сконвертированы в PDF. Инструкция к какому-нибудь устройству будет, скорее всего, именно таким файлом. Внутри он выглядит как текст и графика плюс команды форматирования, описывающие, как надо располагать элементы на странице.

Второй класс – это документы, полученные в результате сканирования бумажных изображений. Их можно пропустить через ABBYY FineReader, и они превратятся в первый тип, а можно просто сохранить в PDF как картинки. И этим часто имеет смысл пользоваться, когда хочется сохранить исходный вид документа. Несмотря на то, что ABBYY FineReader довольно хорошо распознаёт документы, возникают ошибки распознавания, какие-то важные элементы на странице не находятся, в общем, то, что получается, по виду несколько отличается от исходного документа.

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

Сразу следует сказать, что лучшей информации по формату, чем много мегабайтный PDFReference с сайта Adobe не существует. Для тех, кто пишет на С++ есть готовое решение — XPDF. В линуксе это самая полнофункциональная замена продуктам Adobe. Русскоязычные материалы на эту тему поверхностны и служат лишь для ознакомления, а не для практической работы. Но я рассчитываю, что с ними, а лучше с PDFReference вы уже знакомы. Я решил описать конкретный упрощенный пример извлечения из файла PDF truetype шрифтов, потому что этот вопрос очень часто звучит в сети и остается без ответа. Мне известна только одна такая программа, которая работает с ошибками и без исходников. Напоминаю, что пользоваться извлеченными шрифтами не всегда законно, можно только выводить встроенным шрифтом текст из документа.

Добрый день! Сейчас я расскажу вам, как запускать код под учётной записью другого пользователя в Windows из Java с помощью JNA.

Андреас Гал (Andreas Gal) с коллегами из Mozilla разработали первый нормальный движок pdf.js для отображения PDF средствами HTML5/JavaScript (демо).

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

Внедрение в браузер нативных или open-source плагинов тоже нельзя назвать идеальным решением, потому что это потенциальная брешь в безопасности.

Вступление

Kango позволяет создавать расширения для популярных браузеров используя только JavaScript, причем код един для всех браузеров. На данный момент поддерживается Chrome, Firefox, Internet Explorer (в публичном доступе только версия с поддержкой Chrome и Firefox) и ведется работа над поддержкой Opera и Safari. Ниже будет рассмотрено как можно быстро создать простой кроссбраузерный Gmail Checker

Что должно получиться в итоге:

Джед Шмидт, Томас Фухс и Дастин Диаз — достаточно известные в JavaScript-коммьюнити ребята в последнее время нашли себе новую развлекуху — писать полезные штуки размером не больше одного твита, то есть 140 байт. Даже домен зарегали — 140byt.es, куда приглашаются все желающие попробовать свои силы в написании супер-компактных функций.

Естественно, в ход идут все самые изощренные способы и техники уменьшения размера исходника. У них есть вики-страничка с советами, которую я и решил перевести.

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

Если вы пишете программы для кофемолок (холодильников, ZX Spectrum, телевизоров, встроенных систем, старых компьютеров — нужное подчеркнуть), и хотите использовать при этом красивые шрифты, не спешите сохранять буквы в растровый формат. Потому что сейчас я расскажу, как сделать растеризатор векторных шрифтов размером в пару килобайт, не уступающий по качеству FreeType 2 с выключенным хинтингом.

Статья будет интересна и тем, кто просто хочет узнать, как работают библиотеки-растеризаторы.

Одной из клёвых особенностей AS3 (а ещё AS2 и JS) является возможность динамического доступа к полям любых объектов. Это приводит к созданию более «динамичного» кода, так как вам не нужно знать о существовании полей во время компиляции. Эта возможность, как и другие возможности динамических языков, может значительно повлиять на производительность приложения. Сегодня мы рассмотрим примеры, в которых будет показано, на сколько «медленным» является динамический доступ к полям.

В своём фреймворке AtomJS я активно использую аксессоры — геттеры и сеттеры:

Foo = atom.Class({
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
});

Я уже описывал теорию, но в топике я расскажу о том, как заставить их работать во всех современных браузерах, а именно — как разрулить ситацию с тем, что Internet Explorer 9 ничего не знает о __defineSetter__ и подобных методах.

Постановка проблемы

Некоторое время назад по долгу службы работы, встал на обсуждение вопрос «А нужно ли делать на новом проекте авторизацию через сторонние сервисы?». Мозг, взбудораженный красивыми всплывающими окошками, виджетами и прочими украшательствами, призывно требующими «Войди через меня!», конечно же обеими руками был за, да и современные вебдванольные (а то и, тьфу тьфу, вебтринольные, быть может?) тенденции развития крупных порталов, как бы, намекают. Однако, я не зря сказал, что началось всё с обсуждения, ибо, где есть споры, там есть и камни преткновения. Такой камень мы нашли и здесь.

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

Казалось бы, какая разница, регистрировать аккаунт на сайте, или входить через внешние ресурсы?

Google выпустил библиотеку Snappy под лицензией Apache 2.0. Эта библиотека для компрессии/декомпрессии нацелена не на максимальную степень сжатия или совместимость с другими библиотеками, а на максимальную скорость работы. Например, по сравнению с самым быстрым режимом zlib, Snappy примерно на порядок быстрее для большинства входящих данных, но архивы получаются на 20–100% больше по размеру. На одном ядре Core i7 в 64-битном режиме Snappy скорость компрессии больше как минимум на 250 МБ/с, а декомпрессии — минимум на 500 МБ/с.

Snappy широко используется в Google, в разных системах от BigTable и MapReduce до внутренних RPC-систем (в некоторых презентациях она упоминалась под названием Zippy).

Дополнительную информацию см. в файле readme. Бенчмарки по сравнению с другими библиотеками (zlib, LZO, LZF, FastLZ и QuickLZ) поставляются в комплекте с исходниками.

В прошлой моей статье про скорость работы с данными GAE был встроен графический счетчик показов. Каждый мог видеть значение счетчика и израсходованные ресурсы CPU. Как я уже говорил, счетчик был довольно «тяжелым»: создаваемая им нагрузка эквивалентна отображению на странице 1000 записей из базы данных без использования кеширования.

Эксперимент со счетчиком оказался весьма полезным, а его результаты несколько неожиданными для меня (отличными от запросов с одного IP-адреса). Хочу поделиться результатами эксперимента и поставить новый эксперимент, уже с учетом пройденных ошибок. Кстати, исходный код нового графического счетчика доступен для всех и приведен в статье.