Достаточно часто нам приходится хранить данные в memcached или MemcacheDB. Это могут быть относительно простые данные, например, закэшированные выборки из базы данных, а иногда необходимо хранить и обрабатывать более сложные структуры данных, которые обновляются одновременно из нескольких процессов, обеспечивать быстрое чтение данных и т.п. Реализация таких структур данных уже не укладывается в комбинацию команд memcached get/set. В данной статье будут описаны способы хранения некоторых структур данных в memcached с примерами кода и описанием основных идей.

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

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

Некий Shaun Friedle написал любопытный javascript который автоматизирует распознавание captcha на megaupload.

Пара любопытных особенностей скрипта:

1. используется HTML 5 функция javascript getImageData для работы с пикселями;
2. используется искусственная нейронная сеть для распознавания и работает довольно точно.

Пример работы: herecomethelizards.co.uk/mu_captcha
Исходник: userscripts.org/scripts/review/38736

Многие видели моё введение в современные технологии высокопроизводительных вычислений и оценки производительности, теперь я продолжу тему более подробным рассказом о технологии CUDA.
Для тех кто не смотрел предыдущие серии: CUDA позволяет писать и запускать на видеокартах nVidia(8xxx и выше) программы написанные на С++ со специальными расширениями. На правильных задачах достигается значительное превосходство по производительности на $ по сравнению с обычными CPU.
Достижимая производительность — 1 трлн и выше операций в секунду на GTX295.

NB: Статья — краткое введение, покрыть все ньюансы программирования под CUDA в одной статье вряд ли возможно :-)

Новичкам в Django будет полезно узнать об очень полезном инструменте отладки — debug-toolbar. Он настолько крут, что его называют Firebug for Django. На больших проектах без него (или другого отладчика) не обойтись.

Иногда в проекте требуется проверить данные на предмет орфографических ошибок, не полагаясь на познания пользователя по части языков. Тут нам сможет помочь компания Google, с таким их сервисом, как проверка орфографии, используемым в Google Toolbar. Но, к сожалению, Google не предоставляет открытого API для работы с ним.

Итак, краткое описание:
Для того, чтобы проверить текст нам нужно отослать его в POST на https://google.com/tbproxy/spell?lang=ru, где для смены языка следует заменить значение параметра lang на соответствующий по ISO 3166-1 alpha-2. Текст оформляется в XML вида:

<?xml version="1.0" encoding="UTF-8" ?><br/>
<spellrequest textalreadyclipped="0" ignoredups="0" ignoredigits="1" ignoreallcaps="1"><br/>
 <text>Текст для проверки</text><br/>
</spellrequest>

ignoredups — подсветка повторов
ignoredigits — считать цифры ошибками
ignoreallcaps — не проверять слова написанные капсом (подсказал pointum)

Если всё успешно, мы получаем ответ вида

<?xml version="1.0" encoding="UTF-8"?><br><spellresult error="0" clipped="0" charschecked="272"><br> <c o="27" l="13" s="0"></c><br> <c o="73" l="11" s="1">орфографии и орфографии</c><br> <c o="190" l="11" s="1">пользоваться</c><br> <c o="226" l="13" s="0">пред оставляет пред-оставляет</c><br></spellresult>

Атрибуты тега spellresult:
error — произошла ли ошибка
charschecked — количество проверенных символов

В нем идет перечисление допущенных ошибок (теги c), их параметры:
o — начало исходного слова в тексте
l — длина этого слова
s — точность результата

В самом теге c содержатся предполагаемые варианты написания слов, разделенные символом \t.

P.S. Когда этот текст уже был написан, случайно наткнулся на статью в блоге Paul Welter, которая, в принципе, описывает тоже самое…


UPD: Пользователь wayly написал на PHP класс для проверки текста с помощью этого сервиса, скачать можно по ссылке proxysoft.ru/files/spellchecker.zip (зеркало).

UPD2: mezhevikin подсказал ajax-решение с использованием этого сервиса — orangoo.com/labs/?page_id=3

UPD3: Список поддерживаемых языков

_________
Текст подготовлен в ХабраРедакторе
Код подсвечен в Source Code Highlighter

Довольно оживленное обсуждение предыдущей стати (http://habrahabr.ru/blogs/programming/47416/) показало, что тема пролога оказалась интересна сообществу.
Чтобы заинтересовать еще более читателя и вместе с тем облегчить ему начало работы с этим языком, я решил написать немного начальных данных о прологе.

Кратко основные особенности.

Каждый раз, когда мне говорят «о! новый хромиум стал еще быстре, а новая опера — еще мелодичнее», в ответ я задаю простой вопрос: «А в вашем браузере есть telnet-сервер? А вот в firefox — есть», — после чего адепты других религий понимают, что пропаганда бесполезна.

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

Морфологический анализатор для русского языка — это что-то заумное? Программа, которая приводит слово к начальной форме, определяет падеж, находит словоформы — непонятно, как и подступиться? А на самом деле все не так и сложно. В статье — как я писал аналог mystem, lemmatizer и phpmorphy на Python, и что из этого получилось.

В продолжение темы Настройка Ubuntu 8.10 для кодинга под NVIDIA CUDA, я решил наладить себе рабочее место для использования одного из моих любимых языков программирования — Python. Для этого существует отличный набор библиотек PyCUDA, позволяющий реализовывать все прелести NVIDIA CUDA API с помощью удобного и красивого кода.

Вы наверное уже слышали о технологии масштабирования Liquid Resize, которая учитывает содержимое изображения. Если вам интересно как оно все работает и как можно реализовать все это самому, то читайте далее (осторожно, много рисунков).


(НЛО прилетело и растянуло этот рисунок здесь)

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

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

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

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

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

LLVM (Low Level Virtual Machine) — это универсальная система анализа, трансформации и оптимизации программ или, как её называют разработчики, «compiler infrastucture».

LLVM — не просто очередной академический проект. Его история началась в 2000 году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии как Apple и Adobe. В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple.

В основе LLVM лежит промежуточное представление кода (intermediate representation, IR), над которым можно производить трансформации во время компиляции, компоновки (linking) и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.

LLVM написана на C++ и портирована на большинство *nix-систем и Windows. Система имеет модульную структуру и может расширяться дополнительными алгоритмами трансформации (compiler passes) и кодогенераторами для новых аппаратных платформ. Пользовательский фронтенд, как правило, линкуется с LLVM и использует C++ API для генерации кода и его преобразований. Однако LLVM включает в себя и standalone утилиты.

Для тех, кто не без оснований считает C++ не лучшим языком для написания компиляторов, с недавних пор в LLVM включена обертка API для OCaml.

Чтобы понять, что можно сделать с помощью LLVM, и на каком уровне придётся работать, давайте разберёмся,

Привет, хабрачеловек. Сегодня я расскажу тебе про некоторые фундаментальные вещи в computer science: частичные вычисления, три проекции Футамуры и суперкомпиляцию.
 
 

1. Сразу к коду

-- функция, которая возводит x в степень y (неотрицательную)
power x y =
    case y of
        0 → 1
        1 → x
        _ → x * (power x (y - 1))


Введение

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

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

Sun недавно выпустила JavaFX, от которого я далеко не под впечатлением, ведь я видел, на что в действительности способна Java в плане визуализации. А видели ли вы?

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

Однако всё это бессмысленно без человека, способного пожинать плоды появляющихся возможностей. Сеть машинно-читаемых данных (семантический веб или сеть данных) далека от вычёркивания человека из процесса. Более того, она открывает огромные перспективы для взаимодействия человека и машины.

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

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

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

Но деньги на электронном кошельке, это не то же самое, что деньги в реальном кошельке. Этот пост посвящен способам вывода webmoney в Украине.

По долгу службы мне пришлось сталкиваться с курсорами. Хотелось бы рассказать, что это такое и о некоторых особенностях работы с ними. Официальная документация тут — dev.mysql.com/doc/refman/5.1/en/cursors.html Википедия даёт такое определение курсору курсор:

[ Часть I. Доставка видеоконтента ] [ Часть II. CDN своими руками ]

Что такое «контент» для видеохостинга? Во-первых, контент видеохостинга – это просто видео, которое представляет собой набор файлов в различных форматах, в частности, в формате FLV для просмотра пользователем через Flash Player. Эти файлы статичны, видеохостинг при загрузке пользователем видеоролика осуществляет конвертацию во все требуемые форматы с необходимым битрейтом. Хранение такого контента — это хранение обычных файлов, только довольно большого размера. Отдача контента — это, по сути, организация скачивания файлов.
Во-вторых, контент видеохостинга — это «живые» потоки или вещания. Вещания не записываются на диск, не происходит их конвертация, потоки раздаются клиентам с учетом пропускной способности каналов (происходит пропуск пакетов, если канал клиента недостаточен для получения потока вещания в полном качестве). Отдача контента в данной ситуации — это раздача потока на большое количество подключенных пользователей (тысячи смотрящих).

Сия заметка, плод трудов хабра-человека sevenov, ему и почёт, дабы в будущем ему хватило кармы оставить свой след на хабре самому ;)

~~~~

Сегодня возник вопрос о том, как сделать вот так:



После получасового гугления наткнулся на несколько тикетов на code.djangoproject.com (ссылок сейчас не подкину, в истории искать лень). В общем, суть их в том, что нужно переписать чуть ли не половину Django. Немного подумав, я реализовал по своему. Возможно это кто-то уже делал, но на решение я не наткнулся.