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

Для чего это еще может пригодиться? В наше время смс сервисы используются достаточно широко. Способов их реализации достаточно много. У меня недавно возникла необходимость реализовать сервис, при котором клиенты могли бы посылать смс сообщением номер заказа и в ответ приходил бы его статус. Задача решилась так: за 500 руб., на барахолке был куплен старенький Nokia 7610 в разваливающемся состоянии, у которого не работала половина кнопок, были проблемы со звуком и т. д. Туда была вставлена сим карта от местного оператора с безлимитным смс пакетом. Теперь этот аппарат будет играть роль сервера, который будет работать в режиме 24/7, с бесперебойным источником питания (аккамулятор), и не будет знать проблем с охлаждением :)

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

Данное руководство ориентировано на виртуальные серверы (VDS/VPS), доступ к которым осуществляется по VNC через интернет. Это задает основные приоритеты — экономное использования ресурсов сервера и работа по недостаточно быстрому каналу. В качестве базовой системы, на которую выполняется установка, используется минимальная инсталляция Ubuntu 9.10. С небольшими изменениями это руководство применимо к другим дистрибутивам Linux и операционным системам семейства Unix, а также для настройки VNC на обычных выделенных серверах и на серверах в локальной сети.

* Способы организации работы VNC-серверов
** Встроенный VNC-сервер в эмуляторах аппаратного обеспечение (Xen/HVM, VMWare, Qemu)
** VNC-сервер, привязанный к работающему X-серверу (GNOME vino)
** VNC-сервер с встроенным X-сервером
*** VNC-сервер, запускаемый вручную
*** VNC-сервер, запускаемый в режиме демона
*** VNC-сервер, запускаемый через inetd
* Выбор VNC-сервера
* Тюнинг сервера
** Тюнинг десктопа
** Опции VNC-сервера

Товарищ caffeine искал плагин к jQuery, который делает дерево с чекбоксами, которые имеют три состояния — установленный, снятый и «чуть-чуть установленный». Не нашел, попросил меня написать. Я написал и делюсь со всеми желающими.

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

Внимание, вопрос JS программерам, есть ли какие-то вещи, которые не нашли отражения в этом тесте?

Вслед за первой частью, призванной в первую очередь показать, что «не так страшен чёрт, как его малюют»

Статья об архитектуре части проекта, которая занимается он-лайн платежами. Намеренно не хотелось бы сейчас подробно описывать API конкретного биллинга или процедуру регистрации в нём. Тонкости конкретных биллингов нужно обсуждать отдельно, иначе тему просто не раскрыть. Цель статьи: обсудить вариант архитектуры, позволяющий нанизывать новые виды биллингов и типы платежей, с наименьшей головной болью.

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

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

В проекте есть на данный момент 2 зоны:

1. географическая зона, реализованная на базе Google Maps, которая отображает нанесенные пользователями на карту географические объекты (маркеры, маршруты и области);
2. информационная зона, которая представляет собой большой иерархически организованный каталог, содержащий информационные материалы.

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

Бодрый день, хаброчеловеки!

Что такое Redis?

Redis — это высокопроизводительное нереляционное распределённое хранилище данных. В отличие от Memcached, который может в любой момент удалить ваши данные, вытесняя старые записи новыми, Redis хранит информацию постоянно, таким образом он похож на MemcacheDB.

Чем Redis отличается от существующих решений?

API для работы с Memcached (MemcacheDB) позволяет хранить массивы, но эти массивы будут сериализованы и сохранены как строки, таким образом атомарные операции над такими массивами не возможны.
Redis позволяет хранить как строки, так и массивы, к которым можно применять атомарные операции pop / push, делать выборки из таких массивов, выполнять сортировку элементов, получать объединения и пересечения массивов.

Производительность

110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня (тесты).

Высокая скорость работы Redis обеспечивается тем, что данные хранятся в оперативной памяти и сохраняются на диск либо через равные промежутки времени, либо при превышении определённого количества не сохранённых запросов. Из этого вытекает, что используя Redis, вы можете потерять результаты нескольких последних запросов, что вполне приемлимо для большинства веб-приложений, учитывая, что обращение к Redis по скорости сравнимо с обращением к оперативной памяти. Тем не менее, потерь можно избежать через избыточность — Redis поддерживает неблокирующую master-slave репликацию.

Sharding

Redis, как и Memcached, может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

API

API доступно для следующих языков:

• Ruby
• Python
• PHP
• Erlang
• Tcl
• Perl
• Lua
• Java

API для PHP доступно как в виде модуля, написанного на C, так и в виде PHP5 класса, который общается с Redis-сервером через сокеты, таким образом не требуется устанавливать модуль.
Кроме того существует PHP5 класс от отечественного разрабочика (с именем, заслуживающим доверия. Я серьёзно.) — IMemcacheClient. (Спасибо DYPA за наводку)

Перспективы развития

Разработка ведётся очень активно, комиты происходят почти каждый день, сейчас доступна версия Redis 0.900 (1.0 release candidate 1), которая очень скоро станет версией 1.0
В ближайшем будущем авторы обещают внедрить разные интересные фичи, в том числе и сжатие данных.

Лицензия и поддерживаемые платформы

Redis — написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией =)

Up: Rediska — удобный PHP-клиент для key-value базы Redis. Оф.сайт.

Иногда скорость роста проекта несколько выше чем скорость оптимизации веб-приложения или приобретение более мощного оборудования под backend.

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Появилось желание сделать сервис подобный letitbit.net в отдельно взятой стране на окраине Европы.
Требовалось:

• позволять загружать/отдавать большие файлы;
• не позволять перепубликовывать прямые ссылки на файлы;
• ограничивать количество одновременно скачиваемых файлов.

Для реализации выбрали NGINX в связке с PHP через fastcgi.
В NGINX добавили:

1. великолепный Nginx upload module, который позволяет избежать многократное копирование загруженного файла на пути NGINX-PHP. К тому же, при небольшой доработке, возможна загрузка сразу в нужную папку, что позволяет использовать простое переименование вместо копирования в PHP
2. нужную заплатку к модулю secure_link, позволяющую делать безопасные ссылки действительными ограниченное время

PHP взяли самый обычный и запустили через spawn-fcgi.
Поставили сервачок, напихали туда штук 12 терабайтных дисков.
Программист написал PHP код, а Марис Рускулис придумал следующий трюк с rewrite для NGINX, позволяющий избежать обращение к PHP при скачивании файла.
В результате, конфигурация NGINX выглядела примерно так:
http {
limit_zone regular $zonekey 10m;
limit_zone premium $zonekey 10m;
server {
root /www/oursiteishere;
location / { try_files $uri @files; }
location ~ \.php$ { try_files $uri @files; fastcgi_stuff_here; }
location @files { rewrite ^(.*)$ /index.php?$1 last; }
location /storage/ { root /storages/; internal; }
# Location for regular users
location ~ /download/.+/(.+)/0/.+/.*/(.+)$ {
set $fname $2;
set $username $1;
set $zonekey "$binary_remote_addr $username";
limit_conn regular 1;
limit_rate '100k';
secure_link_secret megasecret;
secure_link_ttl on;
if ($secure_link = "") { return 403; }
add_header Content-Disposition "attachment; filename*=UTF-8''$fname";
rewrite ^/download/([a-f0-9]+)/([\.~0-9a-zA-Z_]+)/([01])/([0-9]+)/(.+)/.+$ /storage/$4/$5 break;
}
# Location for premium users
# Location for upload using upload module
}
}

Замечательной вещью в данном конфиге является тот факт, что при скачивании файла по сгенерированной защищённой от подмены временной ссылке (проверку осуществляет secure_link) не вызывается PHP с последующим X-Accel-Redirect.
Возможно, данное решение накладывает ограничение на присутствие логики перед непосредственной отдачей файла, но тем не менее, на мой взгляд, является довольно оригинальным трюком, позволяющим немного сэкономить на fastcgi.

Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер (Wikipedia ).

Если проще, то тонкий клиент – это недокомьютер, который загружает легкую операционную систему (обычно используется Linux, в обзоре возьмем это за априори) и соединяется с терминальным сервером.

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



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

Некоторое время назад мы с вами обсуждали получение чистого текста из различных форматов данных: будь то PDF или DOC. В одном из обсуждений был высказано предположение, что при парсинге презентаций PowerPoint я заработаю геморрой или другую страшную болезнь мягкой точки. Что ж, волей судеб мне пришлось доставать текст и из этого «сладенького» формата. Скажу честно, геморрой заработать не удалось, а вот класс для парсинга презентаций вышел.

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

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

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

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



Интересно?

Пока nerezus сочиняет статью о встраивании PHP, я постараюсь продолжить его рассказ о написании расширений. Рассказано будет далеко не всё, поскольку я считаю, что сложность наращивать надо постепенно, иначе материал будет трудноусвояемым и совсем не питательным. В связи с этим я всё-таки не расскажу в этот раз, как подменить операторы в классе, кто захочет, может почитать исходники модуля Operator от Сары Големон — основного автора какой бы то ни было информации о разработке расширений PHP.
Поскольку разработку я веду исключительно в линуксе, то писать мы будем без всяких хитрых аддонов к Visual Studio, ручками, с нуля :) А что, лучше сразу разобраться, а потом уже упрощать свой труд.

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

Чуть ниже под катом я подпишу смертный приговор всем велосипедам в универсальных API. Чтобы не быть голословным, я все проиллюстрирую примерами.
Но должен предупредить сразу — после прочтения статьи вы не сможете без рвотного рефлекса смотреть на очередной велосипед Васи Пупкина под гордым названием «универсальное API сайта».

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.

Недавно мы опубликовали визард для VisualStudio, с помощью которого можно создать экстеншн в пару кликов мыши. Теперь с помощью него мы напишем наши два первых расширения: «Привет, мир» и «вытащим иконку из exe».
Сразу прошу прощение, что очень сильно задержал статью, но жизненные обстоятельства вынудили это сделать, но они исключительно уважительные.

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

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

Такое ограничение сразу приводит к вычеркиванию из списка методов оплаты заполнение квитанции в Сбербанке. Да, это тоже метод, но метод небыстрый. Особенно, если на дворе поздний вечер, пользователь расслабился за бутылкой пива чашкой чая. Какой Сбербанк, тёпленьким его брать, тёпленьким!

Традиционно все десктопные приложения пишутся на императивных языках программирования, этот подход прост и понятен, куда проще описать последовательность действий для решения той или иной задачи, нежели поставить задачу в понятной для машины форме, но когда речь заходит о проектировании внешнего вида и поведения, возникают сложности.
Веб дизайнеры же привыкли описывать, как должно выглядеть веб приложение, то есть ставить задачу, а не по пунктам описывать её решение, такой подход называется декларативным, он удобен, но к сожалению в традиционных приложениях до сих пор господствует именно императивный подход. Есть конечно дизайнеры форм, но они лишь позволяют в общих чертах обрисовать внешний вид приложения, но совершенно не способны описать его поведение. Для решения это проблемы в Qt Software был предложен новый проект Declarative User Interface и в рамках него новый язык разметки:

Встречаем QML

Это новый язык разметки, позволяющий описывать не только внешний вид, но и поведение ваших приложений. Он очень прост и обладает json образным синтаксисом, немного сближающим его html5, что думаю очень придется по душе веб-дизайнерам, да и программистам тоже. А в перспективе это наконец позволит полностью разделить внутреннюю логику работы приложения и его внешнее поведение, в результате чего будет наконец решена извечная проблема, когда программист занимается ещё и внешним видом приложения, потому, как дизайнерам слишком сложно было вникнуть в программирование.