Re-использование кода

Елена Сагалаева интересную заметку написала. Похоже, что у всех такие проблемы возникают и идеально не решаются. У нас гораздо меньше, чем 50 человек, но какая-то дисциплина тоже требуется. И решил я, что:

1. Нужен корпоративный портал, который предоставит всю функциональность в удобном виде (что-то типа code.google.com, sourceforge и т.п.)
2. Все модули, которые предполагается повторно использовать, должны версионироваться - если в каком-то проекте уже используется какая-то версия модуля, то его нельзя менять!
3. Модуль должен быть снабжен документацией в вики-формате, состоящей из двух частей - человеческой и автосгенерированной по коду.
4. Документация должна версионироваться вместе с модулем.
5. При создании новой версии модуля необходимо обязательно указывать отличия. Провели рефакторинг, ускорили алгоритм на 20% - будьте добры написать. Возможно, кто-то только этого и ждал.
6. Разработчики проекта, в котом используется такой общий модуль, автоматически подписываются (пожизненно :) на выход новых версий модуля.
7. Модули должны быть доступны как в собранном виде, так и в виде исходников, чтобы все-таки позволить сделать копи-паст.
8. И было бы неплохо иметь утилиту, которая попробует собрать все (!) проекты, использующие данный модуль, с новой версией модуля. И запустит тесты. Ибо удобство превыше всего.

Ну и должна быть страница, которая угадывает мысли. Нужен вам какой-то функционал - пожалуйста, смотрите вот этот модуль. Без этой страницы никакое повторное использование невозможно. Именно у нее будут спрашивать: "а не написал ли уже кто-нибудь то, что мне нужно?"

Как определить город посетителя (определение адреса по ip)

Все хорошие сайты умеют определять адрес, вернее, город, в котором живет посетитель. И делается это, понятно, по ip-адресу. Только вот кто откуда берет географические привязки ip? Лично я решил использовать сервис IpGeoBase. Он позволяет скачать базу целиком или же использовать xml-сервис. Я предпочел пока второй вариант, чтобы не заморачиваться с ежедневным выкачиванием базы. Понятно, что когда поток посетителей у меня возрастет до небывалых высот, я буду выкачивать базу. А пока у меня это работает очень быстро и выглядит так (код на Питоне 2.6):

#coding=utf-8

def getGeoData(ip):
  """Получить город по ip-адресу (адрес предается как строка).
  Возвращает словарь с элементами-строками city, region, district
  """
 
  import httplib
  import re
  from xml.dom.minidom import parseString
 
  conn = httplib.HTTPConnection("194.85.91.253:8090")
  conn.request("POST", "/geo/geo.html", \
    "<ipquery><fields><all/></fields><ip-list><ip>" + ip + \
    "</ip></ip-list></ipquery>")
  resp = conn.getresponse()
 
  data = resp.read()
  conn.close()
 
  # если ничего не найдено
  if re.search("<message>Not found</message>", data):
    return None
 
  dom = parseString(data)
  city = dom.documentElement.getElementsByTagName('city')[0]\
    .firstChild.nodeValue
  region = dom.documentElement.getElementsByTagName('region')[0]\
    .firstChild.nodeValue
  district = dom.documentElement.getElementsByTagName('district')[0]\
    .firstChild.nodeValue
 
  return {'city' : city, 'region' : region, 'district' : district}

Теперь вопрос остальным: кто как справляется с этой задачей?

UPD: иногда сервис неверно определяет адрес по ip, потому что некоторые провайдеры используют общий DHCP для всех регионов, или же информация об адресах еще не собрана. Войдя на IpGeoBase, можно указать свой правильный адрес, если по ip он определился неверно.

Memcached для Windows и .NET

Вообще, довольно странно размещать memcached на машине с виндой, так как за операционку надо платить. Гораздо дешевле под эти нужды поднимать линуховые тачки. Но, допустим, у вас веб-приложение на ASP.NET или веб-сервис, который хостится под IIS. Кэш вы храните как синглтон в рабочем процессе, у вас отлично реазилованы многопоточные блокировки и т.д. Или даже вы используете какую-нибудь библиотеку для кэширования. Однако, по расписанию регулярно происходит рестарт рабочего процесса, и весь кэш теряется - приходится грузить данные заново.

Еще хуже, если вы включаете для пула приложений режим "веб-сад", т.е. позволяете IIS запускать несколько рабочих процессов для вашего сервиса. Теперь каждый экземпляр вашего сервиса будет делать запросы в базу и складывать все в свой собственный кэш. Вот для таких случаев лучше всего подходит memcached для windows. Этот кэш будет существовать в единственном экземпляре, обслуживать сколько угодно процессов и сбрасываться только при рестарте системы.

Собственно, сам memcached тянуть отсюда (ищите бинарник под свою винду). В архиве будет один exe-шник. Его можно скопировать, например, в C:\Program files\Memcached\ (папку предварительно надо создать). Потом из командной строки запускаем memcached -d install, в результате он регистрирует себя как windows-сервис (службу) и выполняется с правами "локальная система". По умолчанию он слушает на 11211 порту. Осталось только стартануть сервис memcached из консоли управления службами. После перезагрузки он будет запускаться автоматически.

Теперь про клиентскую часть. Под .NET клиентов несколько, я себе поставил этот. Из архива нам нужны только 2 модуля: log4net.dll и собственно Enyim.Caching.dll. В проекте не забудьте указать ссылки на оба.

sample.config содержит фрагменты, которые вы должны вставить в app.config или web.config. Там может быть указано несколько серверов - вам надо оставить только один с адресом 127.0.0.1 и прописать порт 11211. Особое внимание на тэг <memcached enabled="true"> - так работать не будет. Его надо заменить просто на <memcached>.

Все, можно пользоваться. Мануалов к этому клиенту я не нашел, но он должен придерживаться общепринятого стандарта, так что пойдет любая документация по memcached-клиенту. Еще хочется отметить, что все собственные типы данных, которые вы собираетесь класть к кэш, должны быть помечены атрибутом [Serializable] или [DataContract] (это из WCF). В общем, они должны быть сериализуемыми.

Небольшой пример на C#:

// создание клиента очень быстрое,
// так что не обязательно делать его синглтоном
MemcachedClient client = new MemcachedClient();
// сохранить в кэше
client.Store(StoreMode.Set, "MyIntValue", 12345,
    DateTime.Now.AddMinutes(20)); 
// получить из кэша 
int value = client.Get<int>("MyIntValue");
// удалить из кэша
client.Remove("MyIntValue");

Проблемы с easy_install MySQL-python

Пробовал поставить таким образом MySQL-python, чтобы Django заработал с MySQL, но никаким образом мне это не удавалось. У меня Windows XP и Python 2.6. Уже решил, что буду ставить Python25. Но, помог готовый инсталлятор под винду, собранный добрым человеком - вот ссылка. Качать надо "MySQL-python-1.2.3c1.win32-py2.6.exe" - это последняя версия.

Кстати, 1 октября вышел новый релиз Питона - 2.6.3. Исправлено около ста багов, новых фич не добавлено.

Semantic Web: вы в него верите?

Web 3.0

Я здесь буду говорить о том, как плох Semantic Web.

Я не так давно стал углубляться в эту тему, поэтому моя статья не является обоснованным заключением относительно этой вроде бы перспективной технологии, а всего лишь призвана обратить внимание читателей на некоторые важные вопросы, ответы на которые я пока найти не сумел. Конечно, много уже научных статей и диссертаций про Semantic Web понаписано, и многие читатели, наверно, раскритикуют меня, но мне важно, чтобы это была обоснованная критика по существу. Статьи, виденные мной, в большинстве своем опираются на то, что Semantic Web - это круто, что Semantic Web в силу своей архитектуры и красивого названия способен выполнять возложенные на него функции. А где их авторы это прочитали?

Что имеем сейчас

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

Итак, технология обширна и сложна. W3C уже принял вторую версию языка онтологий – OWL 2.0, который совместим с другим творением - языком RDF (Resource Description Framework, модель для описания ресурсов). Документация по SPARQL – языку запросов к RDF, вообще приводит в ужас неподготовленного читателя своим объемом. На RDF мы пишем утверждения вида «субъект — предикат — объект», где субъекты и объекты являются представителями каких-то классов, на OWL мы описываем связь классов и отношения между ними, а на SPARQL пишем запросы. В целом, стандарты объемные, и редактировать все это вручную уже не так-то просто, поэтому появляется множество редакторов онтологий.

Механизмов семантического вывода оказалось тоже немало – взгляните хотя бы на Вики или сюда. Большинство проектов – open source. Раз столько разных подходов – значит, есть спорные моменты.

Кстати, о великих. О кое-какой (примитивной) поддержке Semantic Web заявляли в разное время Yahoo, Google и Яндекс (поддержка тега Friend-Of-A-Friend в блогах).

Красота

Я думаю, все, кому интересен Semantic Web, читали статью Тима Бернерса-Ли, родителя всей этой штуки. Там рассказывалось о том, как, используя семантическую метаинформацию, специальные программы-агенты могут, например, забронировать место у врача в нужное время в поликлинике неподалеку.

Из всей красиво звучащей концепции явно выпирает такой момент: онтологии, создаваемые различными пользователями, могут объединяться программами-агентами. Причем, они (онтологии) могут существенно различаться, создавая тем самым многозначность при анализе информации. Автор предполагает, что для некоторых «важных» областей, таких как медицина, будут существовать официально утвержденные онтологии. Идея неплохая, стандарты должны быть. Желательно международные. Хорошо, допустим, официальные онтологии утверждены, очень грамотно составлены и пригодны для повсеместного использования. Заодно отчасти решается другая проблема: «черные оптимизаторы» в целях поднять свой сайт повыше и опустить другие пониже могут создавать свои собственные онтологии, но умные поисковики и агенты будут доверять только официальным источникам.

Ну а как быть с теми онтологиями, которые не будут никем утверждены? Пусть там царит хаос? Ну нет, на помощь приходят механизмы вывода, работающие с нечеткими онтологиями, статистическими онтологиями и поддерживающими собственные расширения OWL (в примере – P-OWL).

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

Но забудем о простых смертных – давайте представим бизнес, основанный на Semantic Web и так красиво описанный в приведенной выше статье, учитывая все перечисленные аспекты…
Придут ли все к единому стандарту? Как вариант, я рассматриваю параллельное существование слабо совместимых языков описания онтологий и механизмов их анализа. Помимо этого, поисковые системы наверняка будут строить свои всеобъемлющие онтологии (на своем языке описания :).

Еще вопросы

Построен ли принятый сейчас OWL 2.0 так, чтобы иметь возможность исключить всякую многозначность в онтологиях в процессе семантического вывода? Или же для этого его надо урезать?

Позволяет ли он описывать сложные ограничения, например, что «у мужчины может быть только одна жена, если он не мусульманин; иначе до 4»?

Позволяет ли он описать процесс преобразования одного объекта в другой, чтобы система вывода смогла составить цепочку преобразований для выполнения некоторого действия? Например, у вашего друга День Рождения, и он больше всего на свете любит вареную сгущенку вперемешку с обычной. Но ни один магазин не удосужился внести метаинформацию про не продает вареную сгущенку, зато везде можно найти невареную. Что надо сделать? Правильно, купить и сварить :) Но сварить только часть, чтобы и невареная осталась.

Я пока не нашел ответов. Уважаемые читатели, если кто обладает расширенными знаниями в этой области – поделитесь, пожалуйста.

Мое ИМХО

Чтобы Интернет стал действительно семантическим, надо не вставлять метаинформацию в страницы, а анализировать уже имеющийся человеческий текст. Уже сейчас на конференциях Senseval показываются неплохие результаты в этом направлении (65.2% успехов в 2004 году, вот работа, в которой с темой можно познакомиться поближе). Таким образом, поисковые (и прочие) системы смогут строить семантические индексы, а не текстовые. За счет стройного языка представления модели мира (которую в единственном экземпляре надо всем миром построить), в отличие от той, что получится при описании с помощью OWL, информация не будет содержать многозначности и противоречий. Уже есть работы, в которых предлагается максимально простой способ представления модели мира с помощью минимального набора ограничений. Но это уже тема отдельной статьи.

Вместо того, чтобы рядом с Интернетом возводить «Инструкцию по его использованию для роботов», надо создавать механизмы по его Пониманию. Компьютер не станет ближе к человеку, пока не научится извлекать смысл из его слов. Независимо от количества интернетов. Вот и все.