В этом посте я расскажу о текущем положении дел в проекте BeAware, опишу актуальные проблемы и очерчу ближайшие перспективы. Пост имеет дискуссионный характер, поэтому любые комментарии приветствуются (наши гуглогруппы: английская - beawareat, русская - beawareat_ru).
Начнем с сердца проекта - онтологии.
На мой взгляд, онтология BeAware должна удовлетворять следующим критерям:
1. Быть дружелюбной к пользователю. Этот пункт не случайно на первом месте. Мы создаем не академическое приложение, а поэтому нельзя допустить, чтобы пользоваться сайтом могли лишь обладатели степени PHD Оксфордского Университета.
2. Одним из конкурентных преимуществ семантических технологий является возможность логического вывода, поэтому считаю, что онтология должна максимально эффективно (эффективно для пользователя, опять же) его использовать. Сейчас работа движка логического вывода проявляется, например, при поиске всех развлекательных событий (сколько бы нижележащих уровней иерархии ни было) или научных конференций по всем гуманитарным наукам. Лучше, чем ничего... но эта сторона онтологии еще явно требует доработки.
3. Онтология должна быть обобщением основных типов событий, происходящих в мире.
Я уже говорил об этом в предыдущем посте, но не могу не повториться (уж очень это, на мой взгляд, важно). Проработка онтологии - сложная и ответственная задача. Сложная, потому что нужно рассмотреть огромное число происходящих в мире событий и обобщить их в удобной для конечного пользователя форме. Ответственная, потому что как только онтология будет стабилизирована, вступит в действие ограничение обратной совместимости, а значит мы уже не сможем свободно ее менять (так как для каждого типа уже будут созданы события, которые нужно будет поддерживать).
Список открытых вопросов по структуре онтологии:
1. Сейчас событие "музыкальный концерт" является наследником "развлекательного события". Однако, на мой взгляд, концерты классической музыки претендуют на звание культурного события. В рамках текущего подхода, когда корневыми событиями (корневыми в визуальном плане: все события являются наследниками базового класса Event) являются события, относящиеся к какой-либо сфере жизни, было бы логично выделить класс "концерт классической музыки" и сделать его подклассом "культурного события". Однако мне кажется, что такой подход будет путать пользователей (и концерты классической музыки будут по ошибке создаваться как экземпляры "музыкального концерта"), поэтому решение этой проблемы пока под вопросом.
2. У события "Театр" есть свойство "вид театрального искусства" (не придумал более лаконичного лейбла). Стоит ли оставить это так, или лучше выделить оперу, баллет и т. д. в подклассы класса "Театр"? С одной стороны, это загромоздит онтологию, с другой, - текущая реализация не позволит нам в будущем добавить дополнительные свойства, например, для балета (технически-то сможем, но юзабилити такого решения представляется мне сомнительным).
3. Есть ли какая-то стандартизированная классификация наук? Текущая иерархия для свойства "вид науки" взята из английской википедии, но, во-первых, она довольно куцая, а во-вторых, слабо коррелирует с классификацией, принятой на постсоветском пространстве.
4. Не приложу ума, куда разместить событие "выставка" (exhibition). Выставки бывают разные: картин, собак, IT (софт, железо, игры) и т. д.
5. У меня есть большой соблазн создать корневую категорию IT. Пока я с ним успешно борюсь... но встает более серьезный вопрос: по каким критериям выделять корневые события?
Перейдем ко второму пункту сегодняшнего поста - к обзору геоданных и их применения в BeAware.
Итак, каждое событие привязывается к определенному месту, где:
Место = Город (GeoNames) + [Объект (LinkedGeoData)], где объект - опциональный параметр.
Сначала предлагаю обсудить, как можно использовать привязку каждого события к GeoNames. Итак, имеем следующие исходные данные:
1. У каждого события есть URI из RDF-массива GeoNames
2. GeoNames построен на транзитивной иерархии (например, вот (http://ws.geonames.org/hierarchy?geonameId=1489425) иерархия для Томска: Томск->Томская область->Российская федерация->Европа->Земля). Причем количество и названия элементов иерархии меняются от страны к стране.
3. Движок логического вывода Virtuoso может играючи обрабатывать транзитивность, определяя принадлежность события, к тому или иному уровню иерархии.
Раз все так хорошо, почему у нас реализована лишь фильтрация по городам и странам? Дело в том, что мы пока не нашли красивого user-friendly решения. Я вижу два варианта реализации гибкой фильтрации (под гибкой я имею в виду фильтрацию, которая использует иерархию GeoNames в полной мере):
1. На базе существующего решения. Просто убираем ограничение поиска лишь по странам и городам - пользователь сможет найти и районы, и области, и республики и т. д. Но это будет полный бардак. Сейчас при поиске сущности вручную прописывается, является ли она городом или страной. Однако при гибком подходе мы можем прописать лишь GeoNames feature code (http://www.geonames.org/statistics/total.html), но это очень недружелюбно к пользователю.
2. Пользователь может вводить только города, но рядом с соответствующим фильтру городом отображается вышележащая иерархия (элементы которой можно выбрать наравне с городом). В этом случае засчет визуальности иерархии отчасти решается проблема первого подхода, но при этом рождается новая: пользователю нужно знать город в том регионе, который он хочет выбрать.
Ни один из вариантов мне не нравится но, вероятно, один из них придется реализовать. Что думаете на сей счет?
Иерархия GeoNames на текущий момент не включает в себя объединения стран. При этом идея фильтрации тех же научных конференции по всему Европейскому Союзу выглядит довольно интересной. Реализовать это можно: во-первых, в этом направлении идет работа внутри GeoNames, а во-вторых, есть замечательная геополитическая онтология, которую можно интегрировать с GeoNames. Вот, кстати, недавняя дискуссия на сей счет в гуглгруппе GeoNames. Но будет ли это востребовано? Есть ли еще объединения стран (кстати, необязательно именно стран) со столь же высокой степенью интеграции, как в Евросоюзе? Не хочется лишний раз нагружать и без того не самый простой интерфейс BeAware.
Продолжая вопрос геофильтрации, обратимся ко второму "измерению" месторасположения события, к конкретному объекту из LinkedGeoData. Почему бы не дать пользователям возможность фильтровать события по кокретному месту в городе? Навскидку, довольно полезный юзкейс: можно отслеживать все представления в любимом театре или все вечеринки в любимом ночном клубе. Серьезных сложностей с реализацией этой возможности возникнуть не должно, однако в релиз она попадет вместе со всеми изменениями, касающимися геоданных: придется крепко поломать голову над тем, как объединить все виды геофильтрации, и при этом не отпугнуть пользователей излишней сложностью.
Продолжим обсуждать геоданные, однако сменим тему на интерфейс выбора объекта в городе при создании/редактировании события. Сейчас пользователю предлагается сначала подгрузить типы объектов в видимой области карты, затем, выбрав некоторый тип объекта, получить список объектов данного типа и выбрать один из них. Такой интерфейс предполагает, что пользователь хотя бы примерно знает месторасположение объекта. Насколько, с вашей точки зрения, текущий интерфейс плох? Стоит ли реализовать другой/другие интерфейсы поиска объектов?
Довольно логичным решением было бы использовать интерфейс, базирующийся на поиске по имени/адресу объекта. Однако в этом случае пользователь может по ошибке выбрать объект, не находящийся в выбранном им городе. Кстати, этой проблемы не лишен и текущий интерфейс. Пользователь может выбрать город, затем увести карту куда угодно и выбрать объект в другой части света. Проверить принадлежность координат к городу довольно сложно, учитывая, что города постоянно растут. По крайней мере мне не известен ни один сервис, предоставляющий такую информацию. Может, у военных попросить... :) В качестве обходного пути я вижу следующее решение. Для каждого города у нас есть координаты его условного центра (просто некоторая точка внутри города). Также у нас есть некоторый объект (у которого тоже есть координаты). Мы можем рассчитать расстояние между этими точками и разделить его на население города (здесь предполагается, что размер города находится в прямой зависимости от его населения). Если это нормированное значение превышает некоторый порог, мы либо выдаем предупреждающее сообщение пользователю, либо отдаем событие на премодерацию. Что скажете?
На этом данный пост завершается и плавно переходит в следующий, который появится совсем скоро.
вторник, 25 мая 2010 г.
воскресенье, 23 мая 2010 г.
Запущена альфа-версия проекта BeAware
Все началось несколько месяцев назад, когда в поисках информации о конференции я посетил не один каталог событий, однако ни один из них меня не порадовал: отсутствие удобного поиска (что при большом наполнениии превращает сайт в мусорку), недостаток интеграции с геоданными и другие огрехи подтолкнули меня к идеи реализации собственной площадки событий. При этом, пожалуй, самым серьезным мотиватором стал потенциал применения в этом проекте технологий из стека Semantic Web (а такой проект я подыскивал уже давно). Объединившись с Ефимовым Александром, мы приступили к работе над проектом BeAware.
В сегодняшнем посте я устрою небольшой тур по основным достопримечательностям BeAware без погружения в технические детали.
Главную страницу мы оставим на десерт, а начнем со страницы создания события:
Слева отображается дерево событий, которое базируется на онтологии (онтология пока довольно плохо проработана, но основную идею отражает). Для каждого типа события есть набор свойств (который расширяется по мере того, как мы спускаемся по иерархии).
После того, как выбран тип события, необходимо задать место его проведения. Можно либо выбрать уже ранее отмеченное место (здесь ничего интересного), либо добавить новое:
Место - это, прежде всего, город (используется GeoNames)। Однако, выбрав город, можно задать и конкретный объект в нем (используется массив LinkedGeoData, который, в свою очередь, базируется на OpenStreetMap). Между выбором города есть промежуточный этап выбора типа объекта, который помогает отфильтровать объекты (кстати, здесь ненавязчиво используется логический вывод, например, при выборе всех типов зданий).
После того как место выбрано, перед нам открываются остальные свойства события (их список варьируется в зависимости от типа события):
Заполняем их - и событие создано.
Ознакомившись с тем, что из себя представляют события, вернемся на главную страницу и рассмотрим поиск, точнее его расширенную версию:
Для начала выберем тип события (текущая реализация выпадающего дерева событий не самая удобная... но мы работаем над этим), в результате чего подгрузятся дополнительные опциональные критерии фильтрации. Например, для научной конференции это будут два критерия: "платность/бесплатность" и вид науки. И иерархия событий, и иерархия значений свойств событий обрабатываются движком логического вывода, поэтому если пользователь запросит развлектельные события, в выдачу попадут как непосрдественно экземпляры класса "развлектельное событие", так и экземпляры всех его потомков (фестивали, карнавалы и т. д.). Аналогично, если пользователя интересуют научные конференции по всем гуманитарным наукам - нет проблем.
Теперь рассмотрим фильтрацию по месторасположению. На данный момент можно отфильтровать события либо по городу, либо по стране. И это лишь малая часть того, что мы можем сделать, имея в руках те мощные средства, на которых базируется наш сервис (GeoNames, LinkedGeoData, движок логического вывода из Virtuoso). Сейчас я не буду вдаваться в детали, но о том, почему мы остановились на такой реализации и какие перемены ждут геофильтрацию, подробно расскажу в следующем посте.
Итак, критерии заданы - осталось лишь нажать волшебную кнопочку "Найти события"... хотя текущее наполнение базы данных (точнее, его отсутствие) дискредитирует творящуюся при обработке поискового запроса магию.
Мы рассмотрели ядро сервиса BeAware, а сейчас немного поговорим о том, в каком направлении проект будет развиваться.
Во-первых, будет детальнее проработана онтология. Это очень сложная и ответственная задача. Сложная, потому что нужно рассмотреть огромное число происходящих в мире событий и обобщить их в удобной для конечного пользователя форме. Ответственная, потому что как только онтология будет стабилизирована, вступит в действие ограничение обратной совместимости, а значит мы уже не сможем свободно менять ее в будущем (так как для каждого типа уже будут созданы события, которые нужно будет поддерживать).
Во-вторых, будет улучшена геофильтрация. Это просто нелепо иметь в руках GeoNames+LinkedGeoData+Движок_логического_вывода и выжать из всего этого лишь фильтрацию по городам и странам. Постараемся существенно улучшить этот компонент.
В-третьих, будут реализованы подписки, интерфейс которых будет очень похож на интерфейс расширенного поиска. Подписки лишат пользователей, желающих отслеживать те или иные события, "удовольствия" ежедневного ручного поиска, дав им возможность получать уведомления посредством email или RSS.
В-четвертых, добавим RDFa-разметку.
В-пятых, интегрируем MusicBrainz для музыкальных концертов.
В-шестых, предлагайте свои идеи - мы не оставим их без внимания :)
До запуска беты наши основные приоритеты - функционал и юзабилити, после - популяризация.
P. S. Спасибо ребятам из компании "Соционика" за помощь с дизайном и версткой.
PP. S. Отдельное "спасибо" хабрачеловеку LeeMiller. Взявшись за разработку дизайна и верстки BeAware, он начал за здравие, но после получения предоплаты его как будто подменили. В течение полутора месяцев он кормил нас "завтрками" и враньем на любой вкус, а в результате сорвал нам все сроки (особенно если учесть, что его мы искали после того, как нас кинул предыдущий дизайнер: видимо, была черная полоса). Я, быть может, и забил бы на эту ситуацию, но LeeMiller проигнорировал мои сообщения о том, что было бы неплохо вернуть предоплату - а значит это уже не халатное отношение к работе, а мошенничество. Уважаемый LeeMiller, в ваших интересах прислушаться к моим сообщениям раньше, чем мы не доберемся с постами о BeAware на Хабр.
В сегодняшнем посте я устрою небольшой тур по основным достопримечательностям BeAware без погружения в технические детали.
Главную страницу мы оставим на десерт, а начнем со страницы создания события:
Слева отображается дерево событий, которое базируется на онтологии (онтология пока довольно плохо проработана, но основную идею отражает). Для каждого типа события есть набор свойств (который расширяется по мере того, как мы спускаемся по иерархии).После того, как выбран тип события, необходимо задать место его проведения. Можно либо выбрать уже ранее отмеченное место (здесь ничего интересного), либо добавить новое:
Место - это, прежде всего, город (используется GeoNames)। Однако, выбрав город, можно задать и конкретный объект в нем (используется массив LinkedGeoData, который, в свою очередь, базируется на OpenStreetMap). Между выбором города есть промежуточный этап выбора типа объекта, который помогает отфильтровать объекты (кстати, здесь ненавязчиво используется логический вывод, например, при выборе всех типов зданий).
После того как место выбрано, перед нам открываются остальные свойства события (их список варьируется в зависимости от типа события):
Заполняем их - и событие создано.Ознакомившись с тем, что из себя представляют события, вернемся на главную страницу и рассмотрим поиск, точнее его расширенную версию:
Для начала выберем тип события (текущая реализация выпадающего дерева событий не самая удобная... но мы работаем над этим), в результате чего подгрузятся дополнительные опциональные критерии фильтрации. Например, для научной конференции это будут два критерия: "платность/бесплатность" и вид науки. И иерархия событий, и иерархия значений свойств событий обрабатываются движком логического вывода, поэтому если пользователь запросит развлектельные события, в выдачу попадут как непосрдественно экземпляры класса "развлектельное событие", так и экземпляры всех его потомков (фестивали, карнавалы и т. д.). Аналогично, если пользователя интересуют научные конференции по всем гуманитарным наукам - нет проблем.Теперь рассмотрим фильтрацию по месторасположению. На данный момент можно отфильтровать события либо по городу, либо по стране. И это лишь малая часть того, что мы можем сделать, имея в руках те мощные средства, на которых базируется наш сервис (GeoNames, LinkedGeoData, движок логического вывода из Virtuoso). Сейчас я не буду вдаваться в детали, но о том, почему мы остановились на такой реализации и какие перемены ждут геофильтрацию, подробно расскажу в следующем посте.
Итак, критерии заданы - осталось лишь нажать волшебную кнопочку "Найти события"... хотя текущее наполнение базы данных (точнее, его отсутствие) дискредитирует творящуюся при обработке поискового запроса магию.
Мы рассмотрели ядро сервиса BeAware, а сейчас немного поговорим о том, в каком направлении проект будет развиваться.
Во-первых, будет детальнее проработана онтология. Это очень сложная и ответственная задача. Сложная, потому что нужно рассмотреть огромное число происходящих в мире событий и обобщить их в удобной для конечного пользователя форме. Ответственная, потому что как только онтология будет стабилизирована, вступит в действие ограничение обратной совместимости, а значит мы уже не сможем свободно менять ее в будущем (так как для каждого типа уже будут созданы события, которые нужно будет поддерживать).
Во-вторых, будет улучшена геофильтрация. Это просто нелепо иметь в руках GeoNames+LinkedGeoData+Движок_логического_вывода и выжать из всего этого лишь фильтрацию по городам и странам. Постараемся существенно улучшить этот компонент.
В-третьих, будут реализованы подписки, интерфейс которых будет очень похож на интерфейс расширенного поиска. Подписки лишат пользователей, желающих отслеживать те или иные события, "удовольствия" ежедневного ручного поиска, дав им возможность получать уведомления посредством email или RSS.
В-четвертых, добавим RDFa-разметку.
В-пятых, интегрируем MusicBrainz для музыкальных концертов.
В-шестых, предлагайте свои идеи - мы не оставим их без внимания :)
До запуска беты наши основные приоритеты - функционал и юзабилити, после - популяризация.
P. S. Спасибо ребятам из компании "Соционика" за помощь с дизайном и версткой.
PP. S. Отдельное "спасибо" хабрачеловеку LeeMiller. Взявшись за разработку дизайна и верстки BeAware, он начал за здравие, но после получения предоплаты его как будто подменили. В течение полутора месяцев он кормил нас "завтрками" и враньем на любой вкус, а в результате сорвал нам все сроки (особенно если учесть, что его мы искали после того, как нас кинул предыдущий дизайнер: видимо, была черная полоса). Я, быть может, и забил бы на эту ситуацию, но LeeMiller проигнорировал мои сообщения о том, что было бы неплохо вернуть предоплату - а значит это уже не халатное отношение к работе, а мошенничество. Уважаемый LeeMiller, в ваших интересах прислушаться к моим сообщениям раньше, чем мы не доберемся с постами о BeAware на Хабр.
суббота, 27 февраля 2010 г.
Впечатление о Карлсруэ
Я уже две недели как уехал в командировку в Карлсруэ, замечательный город на юге Германии. Сегодня решил написать о вещах, которые показались мне особенно примечательными на контрасте с Томском.
В Карлсруэ великолепная транспортная система, базирующаяся на трамваях. Причем трамваи ходят не только в пределах города, но и до пригородов, тем самым выполняя роль электричек. Это круто даже для Германии (особая гордость жителей Карлсруэ). Трамваи современные, быстрые, бесшумные, но поездки обходятся недешево. Одна поездка стоит два с небольшим евро (100 рублей), а это дороговато даже для местных жителей. Правда, есть абонементы, которые делают трамваи более доступными. Так уж сложилось, что я неравнодушен к поездам... а в эти трамваи я просто влюбился :)
Немцы очень трепетно относятся к воскресенью - право на отдых в последний день недели даже закреплено конституцией. Нравится это далеко не всем (вот недавно очередной замес был), но факт остается фактом: в воскресенье почти никто не работает. К тому, что будет закрыто абсолютное большинство магазинов, я был готов. А вот то, что неожиданно упавший воскресным утром интернет (недешевый, надо сказать, интернет) от Vodafone подняли только в понедельник, меня неприятно удивило (темная сторона отдыха в воскресенье). Трудно представить такое в США: засудили бы. Я на сутки остался без доступа к SVN-серверу стартапа, над которым сейчас работаю в свободное время - пожалел, что поднял SVN, а не GIT/Mercurial.
Здесь повсеместно применяются экономичные включатели света, выключающиеся самостоятельно по истечение некоторого промежутка времени. При этом включаются они, как правило, либо вручную, либо от датчика движения. Последний вариант используется у нас в холле. Дверь моей комнаты находится как раз посередине между двумя датчиками, и когда я выхожу из комнаты, ни один из них не срабатывает. И чтобы увидеть замочную скважину в темное время суток, приходится поболтать ногой в ту или иную сторону :)
Меня не перестает радовать отсутствие в Карлсруэ представителей бестолковых профессий вроде вахтеров и охранников. За время работы в государственной организации вахтеры, по обыкновению "одаренные" соответствующим синдромом, выпили не один литр моей кровушки, поэтому к ним у меня особое отношение. Вот, например, сегодня (в субботу) я пошел на работу. Большое здание, в котором расположены офисы нескольких крупных компаний; выходной; ни единой души, а для того чтобы попасть на рабочее место мне нужен лишь один ключ. Никаких вахтеров, никаких сигнализаций - лишь мораль да честное слово. Вот так в России не будет никогда (ну если только не введут смертную казнь за малейшее правонарушение...).
В Карлсруэ очень чисто на улицах. И воздух свежий: спасибо трамваям, платным парковкам и ограничению на проезд на машинах в центр. Выходишь с утра на работу - аж душа радуется.
Недостатки? Дайте подумать... Ну вот, например, купюры, начиная от 50 евро, широкие и не влазят полностью в мой кошелек :) А если серьезно, то я еще в первый день спросил у нашего PM, который бывал в Томске, есть ли, на его взгляд, у Карлсруэ какие-либо недостатки по сравнению с Томском. Он крепко задумался, а потом сказал, что здесь очень высокие налоги (даже на фоне других немецких городов). Но так ли уж это плохо? Ведь, во-первых, налоги здесь если и пилятся, то в гораздо меньших масштабах (по крайней мере невооруженным взглядом видно, на что тратятся деньги налогоплательщиков), а во-вторых, здесь и зарплаты раза эдак в три-четыре выше, чем в заМКАДье.
P. S. Хорошо там, где нас нет. И пока нас нет :) Не долго мне осталось наслаждаться жизнью в Карлсруэ - через 2 недели обратно. В Карлсруэ сейчас +10, а в Томске -30 - даже не верится.
В Карлсруэ великолепная транспортная система, базирующаяся на трамваях. Причем трамваи ходят не только в пределах города, но и до пригородов, тем самым выполняя роль электричек. Это круто даже для Германии (особая гордость жителей Карлсруэ). Трамваи современные, быстрые, бесшумные, но поездки обходятся недешево. Одна поездка стоит два с небольшим евро (100 рублей), а это дороговато даже для местных жителей. Правда, есть абонементы, которые делают трамваи более доступными. Так уж сложилось, что я неравнодушен к поездам... а в эти трамваи я просто влюбился :)
Немцы очень трепетно относятся к воскресенью - право на отдых в последний день недели даже закреплено конституцией. Нравится это далеко не всем (вот недавно очередной замес был), но факт остается фактом: в воскресенье почти никто не работает. К тому, что будет закрыто абсолютное большинство магазинов, я был готов. А вот то, что неожиданно упавший воскресным утром интернет (недешевый, надо сказать, интернет) от Vodafone подняли только в понедельник, меня неприятно удивило (темная сторона отдыха в воскресенье). Трудно представить такое в США: засудили бы. Я на сутки остался без доступа к SVN-серверу стартапа, над которым сейчас работаю в свободное время - пожалел, что поднял SVN, а не GIT/Mercurial.
Здесь повсеместно применяются экономичные включатели света, выключающиеся самостоятельно по истечение некоторого промежутка времени. При этом включаются они, как правило, либо вручную, либо от датчика движения. Последний вариант используется у нас в холле. Дверь моей комнаты находится как раз посередине между двумя датчиками, и когда я выхожу из комнаты, ни один из них не срабатывает. И чтобы увидеть замочную скважину в темное время суток, приходится поболтать ногой в ту или иную сторону :)
Меня не перестает радовать отсутствие в Карлсруэ представителей бестолковых профессий вроде вахтеров и охранников. За время работы в государственной организации вахтеры, по обыкновению "одаренные" соответствующим синдромом, выпили не один литр моей кровушки, поэтому к ним у меня особое отношение. Вот, например, сегодня (в субботу) я пошел на работу. Большое здание, в котором расположены офисы нескольких крупных компаний; выходной; ни единой души, а для того чтобы попасть на рабочее место мне нужен лишь один ключ. Никаких вахтеров, никаких сигнализаций - лишь мораль да честное слово. Вот так в России не будет никогда (ну если только не введут смертную казнь за малейшее правонарушение...).
В Карлсруэ очень чисто на улицах. И воздух свежий: спасибо трамваям, платным парковкам и ограничению на проезд на машинах в центр. Выходишь с утра на работу - аж душа радуется.
Недостатки? Дайте подумать... Ну вот, например, купюры, начиная от 50 евро, широкие и не влазят полностью в мой кошелек :) А если серьезно, то я еще в первый день спросил у нашего PM, который бывал в Томске, есть ли, на его взгляд, у Карлсруэ какие-либо недостатки по сравнению с Томском. Он крепко задумался, а потом сказал, что здесь очень высокие налоги (даже на фоне других немецких городов). Но так ли уж это плохо? Ведь, во-первых, налоги здесь если и пилятся, то в гораздо меньших масштабах (по крайней мере невооруженным взглядом видно, на что тратятся деньги налогоплательщиков), а во-вторых, здесь и зарплаты раза эдак в три-четыре выше, чем в заМКАДье.
P. S. Хорошо там, где нас нет. И пока нас нет :) Не долго мне осталось наслаждаться жизнью в Карлсруэ - через 2 недели обратно. В Карлсруэ сейчас +10, а в Томске -30 - даже не верится.
среда, 27 января 2010 г.
Чтобы понять рекурсию, нужно сначала понять рекурсию
Писал сегодня сообщение в буржуйский мейл-лист и решил проверить, правильно ли написал слово рекурсия (recursion). Ввожу в Гугл - смотрю и не могу понять:
Подозвал коллегу - тот посмеялся и говорит: "Это не баг - это фича". Тут до меня наконец-то дошло: Гугл так шутит. Оказывается, это известный трюк, который даже на Хабре проскакивал.
P. S. Мне кажется, на русском я бы не повелся. А в английском нет такой уверенности... Да, ищу оправдание :) Обычно в таких ситуациях все сваливают на "конец рабочего дня" и "бессонные ночи"... но я приберегу эти джокеры до следующего раза.
Подозвал коллегу - тот посмеялся и говорит: "Это не баг - это фича". Тут до меня наконец-то дошло: Гугл так шутит. Оказывается, это известный трюк, который даже на Хабре проскакивал.P. S. Мне кажется, на русском я бы не повелся. А в английском нет такой уверенности... Да, ищу оправдание :) Обычно в таких ситуациях все сваливают на "конец рабочего дня" и "бессонные ночи"... но я приберегу эти джокеры до следующего раза.
Подписаться на:
Сообщения (Atom)