Первая встреча по Lisp'у, я считаю, удалась.
Попробуем еще раз: http://www.developers.org.ua/calendar/event/f2hv5cnvjg2uj3qqtk43r2fv7s/.
Тема: кодогенерация.
2009-08-03
2009-06-12
О микроплатежах
Написано для: Лига.Блоги
В своем предыдущем комментарии я затронул тему того, что до сих пор ни в Украине, ни в мире не появился удобный и получивший широкое распространение сервис микроплатежей. Вообще, под микроплатежами можно понимать разные вещи. Я имею в виду платежи, которые незначительны настолько, что человеку проще перелатить даже до 10-20% от их суммы, зато произвести их быстро и без лишних забот. Понятно, что для каждого это разные суммы, но в среднем это платежи, комиссия по которым не превышает пары десятков гривен (для нашей страны в данное время). В общем, современная экономика говорит, что главная проблема — это транзакционные издержки и их нужно стараться минимизировать. Эти издержки складываются из финансовых, временных, а также усилий и рисков. Микроплатежи находятся в той части спектра экономической активности, где увеличение финансовых издержек наименее нежелательное из перечисленных пунктов.
Еще раз, зачем нужны микроплатежи?
* Для оплаты товара в Интернет-магазинах. Иногда да, хотя в данном случае, поскольку имеет место акт передачи товара из рук в руки, можно применять оплату наличными (как, собственно, у нас в основном и делаеют). К сожалению, как в анекдоте, что заказывать товары при коммунизме можно будет по телефону, а получать по телевизору — у нас пока не получается. Микроплатежи отлично могли бы применяться при доставке товаров по почте, но таких товаров у нас, традиционно, не много.
* Для переводов небольших сумм между людьми. Однозначно, это намного проще, чем банковские или мгновенные переводы. И они в этой сфере уже применяются, но пока по-серому.
* Для оплаты различных услуг: коммунальных, виртуальных и некоторых реальных. Это основное применение для микроплатежей. На самом деле, как раз отсутствие такой полноценной возможности тормозит развитие очень большого числа мелких услуг (в первую очередь виртуальных).
На мой взгляд, единственный путь появления полноценных микроплатежей — через операторов мобильной связи. По сути дела, сейчас они предоставляют такую возможность, но только в ограниченной форме: пополнение счета другого человка (*125*...) И этой возможностью некоторые уже сейчас пользуются даже для организации оплаты мелих услуг. Это типичные мироплатежи, в которых комиссия составляет до 25% (и не смотря на такой высокий процент, люди пользуеются этой услугой).
В чем ограниченность? Главное, нельзя использовать переведенные деньги для оплаты чего-то иного, кроме услуг самого оператора и его афиллированных компаний, нельзя, что называется, "вывести деньги из системы". Второй, менее значительный недостаток: сейчас суммы платежей должны быть кратны 10 (а ведь нет никаких проблем снизить кратность до 1).
Осталось сделать последний шаг: упразднивший эти недостатки. И тогда каждый человек с мобильным телефоном сможет без помощи банков переводить деньги другому. Каждый предприниматель получит удобный и надежный способ получать оплату за свои услуги. Оператор, сделавший такой шаг первым, сможет переманить к себе большое количество абонентов, это не говоря о комиссионных доходах, которые он будет получать от работы этой системы.
Так почему же этого не делается? Загвоздки:
* Юридические. При этом оператор становится банком? Не совсем. Всего лишь расчетной системой. Скорее всего подобная деятельность требует лицензирования и согласования. Однако операторам и так приходится заниматься подобными вещами постоянно. Использование системы для ухода от налогов? Во-первых, не больше, чем при расчете наличными :) Во-вторых, есть пути мимимизации этого: например, обязательная регистрация для мерчантов (тех, кто хочет использовать систему для получения оплаты за товары или услуги). А так ведь, всё прозрачно — наоборот удобно для налоговой.
* Издержки при вводе денег в систему: условно говоря, человек покупает карточку предоплаты на 30 гривен, выпуск и распространение которой стоит 1 грн. Эта гривна — это 3%, которые не сможет компенсировать комиссия за вывод денег из системы (которая тут должна быть не больше тех же 2-3%). Но ее можно компенсировать введя комиссию на каждый платеж: ту же гривну или даже 50 копеек.
* Мошенничество. Для микроплатежей этот вопрос стоит на последнем месте. Ведь никого не смущают возможности мошенничества при пополнении чужого мобильного счета: такая функция намного полезнее, так ведь?
* Организационные. Безусловно, построение подобной системы — это серьезный проект. Однако, он менее серьезен, чем построение самой сети оператора, с чем они успешно справляется.
В общем, как по мне, неразрешимых проблем здесь нет: все упирается лишь в наличие видения и желания у руководства любого из общенациональных мобильных операторов. Микроплатежи — это естественная смежная область, развитие бизнеса в которую для мобильных телекомов дало бы толчек и их развитию в целом, и было бы несомненно полезно для общества.
А в перспективе подобная система может стать вообще глобальной и составить конкуренцию таким фирмам как Visa и MasterCard.
В своем предыдущем комментарии я затронул тему того, что до сих пор ни в Украине, ни в мире не появился удобный и получивший широкое распространение сервис микроплатежей. Вообще, под микроплатежами можно понимать разные вещи. Я имею в виду платежи, которые незначительны настолько, что человеку проще перелатить даже до 10-20% от их суммы, зато произвести их быстро и без лишних забот. Понятно, что для каждого это разные суммы, но в среднем это платежи, комиссия по которым не превышает пары десятков гривен (для нашей страны в данное время). В общем, современная экономика говорит, что главная проблема — это транзакционные издержки и их нужно стараться минимизировать. Эти издержки складываются из финансовых, временных, а также усилий и рисков. Микроплатежи находятся в той части спектра экономической активности, где увеличение финансовых издержек наименее нежелательное из перечисленных пунктов.
Еще раз, зачем нужны микроплатежи?
* Для оплаты товара в Интернет-магазинах. Иногда да, хотя в данном случае, поскольку имеет место акт передачи товара из рук в руки, можно применять оплату наличными (как, собственно, у нас в основном и делаеют). К сожалению, как в анекдоте, что заказывать товары при коммунизме можно будет по телефону, а получать по телевизору — у нас пока не получается. Микроплатежи отлично могли бы применяться при доставке товаров по почте, но таких товаров у нас, традиционно, не много.
* Для переводов небольших сумм между людьми. Однозначно, это намного проще, чем банковские или мгновенные переводы. И они в этой сфере уже применяются, но пока по-серому.
* Для оплаты различных услуг: коммунальных, виртуальных и некоторых реальных. Это основное применение для микроплатежей. На самом деле, как раз отсутствие такой полноценной возможности тормозит развитие очень большого числа мелких услуг (в первую очередь виртуальных).
На мой взгляд, единственный путь появления полноценных микроплатежей — через операторов мобильной связи. По сути дела, сейчас они предоставляют такую возможность, но только в ограниченной форме: пополнение счета другого человка (*125*...) И этой возможностью некоторые уже сейчас пользуются даже для организации оплаты мелих услуг. Это типичные мироплатежи, в которых комиссия составляет до 25% (и не смотря на такой высокий процент, люди пользуеются этой услугой).
В чем ограниченность? Главное, нельзя использовать переведенные деньги для оплаты чего-то иного, кроме услуг самого оператора и его афиллированных компаний, нельзя, что называется, "вывести деньги из системы". Второй, менее значительный недостаток: сейчас суммы платежей должны быть кратны 10 (а ведь нет никаких проблем снизить кратность до 1).
Осталось сделать последний шаг: упразднивший эти недостатки. И тогда каждый человек с мобильным телефоном сможет без помощи банков переводить деньги другому. Каждый предприниматель получит удобный и надежный способ получать оплату за свои услуги. Оператор, сделавший такой шаг первым, сможет переманить к себе большое количество абонентов, это не говоря о комиссионных доходах, которые он будет получать от работы этой системы.
Так почему же этого не делается? Загвоздки:
* Юридические. При этом оператор становится банком? Не совсем. Всего лишь расчетной системой. Скорее всего подобная деятельность требует лицензирования и согласования. Однако операторам и так приходится заниматься подобными вещами постоянно. Использование системы для ухода от налогов? Во-первых, не больше, чем при расчете наличными :) Во-вторых, есть пути мимимизации этого: например, обязательная регистрация для мерчантов (тех, кто хочет использовать систему для получения оплаты за товары или услуги). А так ведь, всё прозрачно — наоборот удобно для налоговой.
* Издержки при вводе денег в систему: условно говоря, человек покупает карточку предоплаты на 30 гривен, выпуск и распространение которой стоит 1 грн. Эта гривна — это 3%, которые не сможет компенсировать комиссия за вывод денег из системы (которая тут должна быть не больше тех же 2-3%). Но ее можно компенсировать введя комиссию на каждый платеж: ту же гривну или даже 50 копеек.
* Мошенничество. Для микроплатежей этот вопрос стоит на последнем месте. Ведь никого не смущают возможности мошенничества при пополнении чужого мобильного счета: такая функция намного полезнее, так ведь?
* Организационные. Безусловно, построение подобной системы — это серьезный проект. Однако, он менее серьезен, чем построение самой сети оператора, с чем они успешно справляется.
В общем, как по мне, неразрешимых проблем здесь нет: все упирается лишь в наличие видения и желания у руководства любого из общенациональных мобильных операторов. Микроплатежи — это естественная смежная область, развитие бизнеса в которую для мобильных телекомов дало бы толчек и их развитию в целом, и было бы несомненно полезно для общества.
А в перспективе подобная система может стать вообще глобальной и составить конкуренцию таким фирмам как Visa и MasterCard.
2009-06-02
k-nucleotide benchmark
Read the discussion on k-nucleotide benchmark in debian shootout (http://groups.google.com/group/comp.lang.lisp/msg/d50c86053c9000b7) and decided to play with it a little: to use as hash-table keys numbers in base 4 instead of gene strings. That gave a speed gain of around 30%: http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&lang=sbcl&id=3.
But still 12 times slower, than the C++ variant. Perhaps native strings (instead of full unicode) would have given 2-2.5 times additional speedup. But what else can be improved?
But still 12 times slower, than the C++ variant. Perhaps native strings (instead of full unicode) would have given 2-2.5 times additional speedup. But what else can be improved?
k-nucleotide бенчмарка
Почитал дискуссию о k-nucleotide бенчмарке в debian shootout'е (в c.l.l.) и решил немного с ней поиграться: вместо строк генов в качестве ключей хеш-таблицы использовать соответствующие числа в базе 4. В результате удалось улучшить время выполнения примерно на 30%: http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&lang=sbcl&id=3.
Но все равно медленнее С++ аналога в 12 раз. Допустим, если отнять unicode-строки, то получится ускорение еще в 2-2,5 раза. А что еще можно улучшить?
Но все равно медленнее С++ аналога в 12 раз. Допустим, если отнять unicode-строки, то получится ускорение еще в 2-2,5 раза. А что еще можно улучшить?
2009-05-27
Идеи по поводу tedxkyiv
@tagline
У оригинального TED обычно есть какие-то большие темы (по 3-4 на конференцию), например: "зеленое будущее", "переосмысление бедности", "сознание" и т.д. Наверно, было бы неплохо, чтобы и у TEDx тоже была какая-то объединяющая тема. И посколько в последнее время Украина как-то не дает таланты, являющиеся глобальными лидерами мысли (у нас сейчас хорошо получаются только футболисты и боксеры), то и тему можно выбрать только локальую, украинскую. Мне сразу приходит на ум "Как нам модернизировать Украину?"
@speakers
Ну и, в соотвествии с темой должны подбираться докладчики. Я так понимаю, что формула TED: известная личность + видение. В этом плане у нас тоже не густо: во всяком случае трудно выделить среди известных политиков, бизнесменов, ученых или гиков тех, у кого действительно есть видение, которое бы было шире их личных интересов и касалось хотя бы всей Украины, не говоря уже о мире в целом.
Единственный хороший пример, который мне приходит на ум -- это Татьяна Монтян. Она известный человек с вполне конкретными достижениями (была адвокатом в нескольких резонансных делах, создала блог "Инфопорн", признанный лучшим коллективным блогом Украины на BlogCampCEE'08), и у нее есть видение: от коррупции нас спасет введение всеобщих открытых реестров недвижимого имущества и переход к титульной системе учета прав на него.
Другие известные люди, теоретически могущие иметь видение, которые приходят на ум:
* Вячеслав Брюховецкий, бывший ректор Киево-могилянской академии
* Михаил Згуровский, ректор КПИ
* Михайло Свистович (создатель сайта maidan.org.ua и один из инициаторов Гражданской кампании "Пора") и его жена Мирослава, бывшая мером Ирпеня
* из бизнесменов можно упомянуть разве что Романа Хмиля, директора компании "GlobalLogic"
Наверное, есть смысл устроить брейншторм на тему докладчиков, потому что кандидатур (во всяком случае, на первый взгляд) совсем не много.
Также в рамках этой темы можно было бы пригласить выступить кого-то из украинцев, добившихся выдающихся результатов за рубежом, чтобы он мог рассказать о видении нашей страны оттуда. Очень кстати также было бы выступление кого-то из иностранцев, работающих у нас. Например, на ум приходит Нико Ланге, директор фонда Конрада Аденауэра в Украине, запомнившийся своими откровенными статьями в Украинской Правде.
У оригинального TED обычно есть какие-то большие темы (по 3-4 на конференцию), например: "зеленое будущее", "переосмысление бедности", "сознание" и т.д. Наверно, было бы неплохо, чтобы и у TEDx тоже была какая-то объединяющая тема. И посколько в последнее время Украина как-то не дает таланты, являющиеся глобальными лидерами мысли (у нас сейчас хорошо получаются только футболисты и боксеры), то и тему можно выбрать только локальую, украинскую. Мне сразу приходит на ум "Как нам модернизировать Украину?"
@speakers
Ну и, в соотвествии с темой должны подбираться докладчики. Я так понимаю, что формула TED: известная личность + видение. В этом плане у нас тоже не густо: во всяком случае трудно выделить среди известных политиков, бизнесменов, ученых или гиков тех, у кого действительно есть видение, которое бы было шире их личных интересов и касалось хотя бы всей Украины, не говоря уже о мире в целом.
Единственный хороший пример, который мне приходит на ум -- это Татьяна Монтян. Она известный человек с вполне конкретными достижениями (была адвокатом в нескольких резонансных делах, создала блог "Инфопорн", признанный лучшим коллективным блогом Украины на BlogCampCEE'08), и у нее есть видение: от коррупции нас спасет введение всеобщих открытых реестров недвижимого имущества и переход к титульной системе учета прав на него.
Другие известные люди, теоретически могущие иметь видение, которые приходят на ум:
* Вячеслав Брюховецкий, бывший ректор Киево-могилянской академии
* Михаил Згуровский, ректор КПИ
* Михайло Свистович (создатель сайта maidan.org.ua и один из инициаторов Гражданской кампании "Пора") и его жена Мирослава, бывшая мером Ирпеня
* из бизнесменов можно упомянуть разве что Романа Хмиля, директора компании "GlobalLogic"
Наверное, есть смысл устроить брейншторм на тему докладчиков, потому что кандидатур (во всяком случае, на первый взгляд) совсем не много.
Также в рамках этой темы можно было бы пригласить выступить кого-то из украинцев, добившихся выдающихся результатов за рубежом, чтобы он мог рассказать о видении нашей страны оттуда. Очень кстати также было бы выступление кого-то из иностранцев, работающих у нас. Например, на ум приходит Нико Ланге, директор фонда Конрада Аденауэра в Украине, запомнившийся своими откровенными статьями в Украинской Правде.
2009-05-25
Встреча по Lisp'у
Устраиваю в эту пятницу встречу пользователей Lisp в Киеве.
Подробности: http://www.developers.org.ua/calendar/event/531khsfol4dujub66mkc4cet74/
Подробности: http://www.developers.org.ua/calendar/event/531khsfol4dujub66mkc4cet74/
Мыслекарты для планирования трат
Написано для: habrahabr.ru
Инструмент Mind Map довольно нов: настолько, что у него нет даже устоявшегося русского названия. Обычно его называют интеллект-картами, картами памяти, сознания или мозга, и даже ментальными картами. Как по мне, довольно громоздкие и не удобные имена, в которых, что самое главное, не четко передается суть понятия (мне в них слышатся какие-то анатомические оттенки: вот тут левое полушарие, тут правое, а тут мозжечок… :) А ведь это, если максимально упростить, картинки, изображащие понятия и логические связи между ними. Можно было бы сказать карты понятий, но тоже звучит громоздко, а вот карты мыслей — проще. Ну и, следуя по традиции словообразования в русском языке: мыслекарты![1]
Мыслекарты помогают лучше осознать какие-то сложные и/или состоящие из многих компонентов системы за счет подключения визуального канала восприятия и, соответственно, образного мышления. Говорят, что в среднем человек может удерживать в оперативной памяти лишь 7 отдельных объектов. Но это в том случае, если эти объекты слабо связаны в сознании друг с другом. А вот, если добавить ассоциации, то потенциальные возможности работы с ними в уме и запоминания неимоверно расширяются. В книге "Основы практики на пианино" утверждается, что именно на этом построены методы людей, практикующих фотографическую память...
Но я отвлекся. При чем мыслекарты к личным финансам? Не считая, конечно, того, что оба эти явления как-то касаются темы личного развития :), связь нам подсказал один из пользователей нашего сервиса по учету финансов[2]. А что если применить эти карты к планированию трат на ближайшее будущее? Например, можно задумать траты, которые могут потенциально выйти за рамки семейного бюджета, но чтобы это понять, нужно посидеть с карандашом и блокнотом и прикинуть свои будущие расходы и доходы, добавить ингридиенты сбережений и незапланированных трат, и щепотку везения, а на выходе получить прогноз, удастся ли осуществить запланированное. В общем-то, в этом может неплохо помочь учетная система: ведь в ней есть уже почти вся нужная информация. Другой вопрос, что ее нужно показать так, чтобы человек не утонул в этом океане цифр. Вот тут на помощь и приходит наглядность и простота мыслекарт. Но, как говорится, «лучше один раз увидеть, чем сто раз услышать», поэтому попробую показать, что имеется в виду.
Вот так выглядел оригинальный набросок, присланный мне:
А вот такой вышла наша первая реализация:
Попробую кратко описать ее работу. Сейчас можно планировать во временных горизонтах месяца, квартала и года. Для пользователя за предыдущий период, заканчивающийся сегодняшним днем, подсчитываются его траты и доходы. Эти суммы и есть прогноз на период планирования. На основании этого прогноза, а также баланса на текущий момент считается прогноз баланса в конце срока, а разница между планируемым доходом и тратами — это накопленный/потраченный остаток конкретно за период. Поскольку наши карты служат прежде всего для планирования трат[3], то траты разбиваются по нескольким самым большим категорям. Человек может прикинуть, по каким из них что-то изменится (например, можно сэкономить) и внести эти изменения прямо на карту. Какие-то категории можно вообще убрать. (Кроме того, можно перейти по ссылке и посмотреть на все траты по каждой категории). Естественно, все изменения мгновенно отражаются на суммах расхода, остатка и баланса. Также можно поменять и ожидаемый доход. Человек может добавить на карту свои планы и сразу увидеть, насколько остатка денег за период хватит, чтобы покрыть каждый из них в отдельности, а также их общую сумму. Наконец, определившись с какими-то из планов, их можно «добавить в корзину» (подтвердить). И только тогда они внесут свою лепту в сумму расходов за период. Собственно, это пока и все.
Стоит отметить, что в данном случае у нас получается не совсем классическая мыслекарта: пока что мы не реализовали показа по желанию пользователя подкатегорий, хотя это, наверно, и не принципиально. Кажется, в этой информации нет большой ценности, а вот сделать карту перегруженной она вполне способна.
Что касается технической стороны, то это тема для статьи в другом блоге. Замечу лишь, что карта полностью реализована на языке Javascript, подручным материалом выступала незаменимая библиотека jQuery (беру свои слова назад: это не костыль :). Конечно, большим недостатком использования исключительно DOM является отсутствие возможности изображать произвольные объекты: наверно, еще пару лет придется пользоваться различными хаками, пока не станет повсеместно распространенным тег CANVAS. В данном случае, например, вместо рисования линий показываются масштабируемые готовые картинки. Это позволяет добиться сравнительно небольшой нагрузки на браузер, однако иногда приводит к мини подвисаниям (в момент переключения между картинками).
В общем, не знаю, конечно, станет ли эта функция действительно полезным инструментом для управления своим бюджетом или же останется лишь красивой игрушкой. Надеюсь увидеть примеры первого. Для меня она стала интересным экспериментом в визуализации финансовой информации. Возможно, этот метод применим и в других финансовых сферах, например, в системах управленческой отчетности предприятия или программах для биржевых трейдеров. А что вы думаете?
[0] Сообщество LiveJournal по теме мыслекарт
[1] А еще, выражаясь научным языком, наверно, их можно отнести к семантическим сетям
[2] Приятно, что в этом отношении сбывается то, о чем я написал в анонсе fin-ack.com: многие интересные идеи приходят от пользователей
[3] Впрочем, ничто не мешает использовать их для планирования доходов или еще чего-то
Инструмент Mind Map довольно нов: настолько, что у него нет даже устоявшегося русского названия. Обычно его называют интеллект-картами, картами памяти, сознания или мозга, и даже ментальными картами. Как по мне, довольно громоздкие и не удобные имена, в которых, что самое главное, не четко передается суть понятия (мне в них слышатся какие-то анатомические оттенки: вот тут левое полушарие, тут правое, а тут мозжечок… :) А ведь это, если максимально упростить, картинки, изображащие понятия и логические связи между ними. Можно было бы сказать карты понятий, но тоже звучит громоздко, а вот карты мыслей — проще. Ну и, следуя по традиции словообразования в русском языке: мыслекарты![1]
Мыслекарты помогают лучше осознать какие-то сложные и/или состоящие из многих компонентов системы за счет подключения визуального канала восприятия и, соответственно, образного мышления. Говорят, что в среднем человек может удерживать в оперативной памяти лишь 7 отдельных объектов. Но это в том случае, если эти объекты слабо связаны в сознании друг с другом. А вот, если добавить ассоциации, то потенциальные возможности работы с ними в уме и запоминания неимоверно расширяются. В книге "Основы практики на пианино" утверждается, что именно на этом построены методы людей, практикующих фотографическую память...
Но я отвлекся. При чем мыслекарты к личным финансам? Не считая, конечно, того, что оба эти явления как-то касаются темы личного развития :), связь нам подсказал один из пользователей нашего сервиса по учету финансов[2]. А что если применить эти карты к планированию трат на ближайшее будущее? Например, можно задумать траты, которые могут потенциально выйти за рамки семейного бюджета, но чтобы это понять, нужно посидеть с карандашом и блокнотом и прикинуть свои будущие расходы и доходы, добавить ингридиенты сбережений и незапланированных трат, и щепотку везения, а на выходе получить прогноз, удастся ли осуществить запланированное. В общем-то, в этом может неплохо помочь учетная система: ведь в ней есть уже почти вся нужная информация. Другой вопрос, что ее нужно показать так, чтобы человек не утонул в этом океане цифр. Вот тут на помощь и приходит наглядность и простота мыслекарт. Но, как говорится, «лучше один раз увидеть, чем сто раз услышать», поэтому попробую показать, что имеется в виду.
Вот так выглядел оригинальный набросок, присланный мне:
А вот такой вышла наша первая реализация:
Попробую кратко описать ее работу. Сейчас можно планировать во временных горизонтах месяца, квартала и года. Для пользователя за предыдущий период, заканчивающийся сегодняшним днем, подсчитываются его траты и доходы. Эти суммы и есть прогноз на период планирования. На основании этого прогноза, а также баланса на текущий момент считается прогноз баланса в конце срока, а разница между планируемым доходом и тратами — это накопленный/потраченный остаток конкретно за период. Поскольку наши карты служат прежде всего для планирования трат[3], то траты разбиваются по нескольким самым большим категорям. Человек может прикинуть, по каким из них что-то изменится (например, можно сэкономить) и внести эти изменения прямо на карту. Какие-то категории можно вообще убрать. (Кроме того, можно перейти по ссылке и посмотреть на все траты по каждой категории). Естественно, все изменения мгновенно отражаются на суммах расхода, остатка и баланса. Также можно поменять и ожидаемый доход. Человек может добавить на карту свои планы и сразу увидеть, насколько остатка денег за период хватит, чтобы покрыть каждый из них в отдельности, а также их общую сумму. Наконец, определившись с какими-то из планов, их можно «добавить в корзину» (подтвердить). И только тогда они внесут свою лепту в сумму расходов за период. Собственно, это пока и все.
Стоит отметить, что в данном случае у нас получается не совсем классическая мыслекарта: пока что мы не реализовали показа по желанию пользователя подкатегорий, хотя это, наверно, и не принципиально. Кажется, в этой информации нет большой ценности, а вот сделать карту перегруженной она вполне способна.
Что касается технической стороны, то это тема для статьи в другом блоге. Замечу лишь, что карта полностью реализована на языке Javascript, подручным материалом выступала незаменимая библиотека jQuery (беру свои слова назад: это не костыль :). Конечно, большим недостатком использования исключительно DOM является отсутствие возможности изображать произвольные объекты: наверно, еще пару лет придется пользоваться различными хаками, пока не станет повсеместно распространенным тег CANVAS. В данном случае, например, вместо рисования линий показываются масштабируемые готовые картинки. Это позволяет добиться сравнительно небольшой нагрузки на браузер, однако иногда приводит к мини подвисаниям (в момент переключения между картинками).
В общем, не знаю, конечно, станет ли эта функция действительно полезным инструментом для управления своим бюджетом или же останется лишь красивой игрушкой. Надеюсь увидеть примеры первого. Для меня она стала интересным экспериментом в визуализации финансовой информации. Возможно, этот метод применим и в других финансовых сферах, например, в системах управленческой отчетности предприятия или программах для биржевых трейдеров. А что вы думаете?
[0] Сообщество LiveJournal по теме мыслекарт
[1] А еще, выражаясь научным языком, наверно, их можно отнести к семантическим сетям
[2] Приятно, что в этом отношении сбывается то, о чем я написал в анонсе fin-ack.com: многие интересные идеи приходят от пользователей
[3] Впрочем, ничто не мешает использовать их для планирования доходов или еще чего-то
2009-04-11
42
Кстати, об основополагающем вопросе... Это число, наверно, следующее по количеству упоминаний после фразы "Hello world" и foo-bar-baz в различных тюториалах по программированию. Когда-то я перевел отрывок из книги, в котором рассказывается о его истории, на русский. Вот от.
В целом, Дугласа Адамса, наверно, стоит почитать каждому -- в нем столько злободневного и в то же время вечного...
В целом, Дугласа Адамса, наверно, стоит почитать каждому -- в нем столько злободневного и в то же время вечного...
2009-04-05
correcting Transfer-encoding:chunked problem in nginx
While Igor Sysoev is thinking on how to properly (i.e. robustly and efficiently) implement handling of Content-encoding:chunked with unset Content-Length in nginx, I needed to hack a quick workaround (for those, who need it "here and now"). I decided to post it here for those who may need it:
In the mean time I've sorted out for myself the server's internals. What can I say? First of all the event-driven architecture is complicated. Especially, when there's no high-level description, who is calling what. And especially under virtually complete absence of comments in the code.
And about C and Lisp (based on examining the source of the two HTTP-servers: nginx and Hunchentoot). Lisp is clay, shape whatever you want with all the connected advantages and shortcomings. C... There's a children's construction set from metal bars and corners. It's fun to play with them. And, generally, everything is quite clear, it's possible to assemble good, solid constructions. But making a vase with rounded corners — it's for the geeks...
--- old/ngx_http_request.c 2009-04-05 20:41:18.000000000 +0300
+++ new/ngx_http_request.c 2009-04-05 20:38:33.000000000 +0300
@@ -1403,16 +1403,6 @@
return NGX_ERROR;
}
- if (r->headers_in.transfer_encoding
- && ngx_strcasestrn(r->headers_in.transfer_encoding->value.data,
- "chunked", 7 - 1))
- {
- ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
- "client sent \"Transfer-Encoding: chunked\" header");
- ngx_http_finalize_request(r, NGX_HTTP_LENGTH_REQUIRED);
- return NGX_ERROR;
- }
-
if (r->headers_in.connection_type == NGX_HTTP_CONNECTION_KEEP_ALIVE) {
if (r->headers_in.keep_alive) {
r->headers_in.keep_alive_n =
--- old/ngx_http_request_body.c 2009-04-05 20:41:39.000000000 +0300
+++ new/ngx_http_request_body.c 2009-04-05 20:34:45.000000000 +0300
@@ -54,11 +54,6 @@
r->request_body = rb;
- if (r->headers_in.content_length_n < 0) {
- post_handler(r);
- return NGX_OK;
- }
-
clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
if (r->headers_in.content_length_n == 0) {
@@ -180,7 +175,8 @@
} else {
b = NULL;
- rb->rest = r->headers_in.content_length_n;
+ rb->rest = r->headers_in.content_length_n >= 0 ? r->headers_in.content_length_n
+ : NGX_MAX_SIZE_T_VALUE;
next = &rb->bufs;
}In the mean time I've sorted out for myself the server's internals. What can I say? First of all the event-driven architecture is complicated. Especially, when there's no high-level description, who is calling what. And especially under virtually complete absence of comments in the code.
And about C and Lisp (based on examining the source of the two HTTP-servers: nginx and Hunchentoot). Lisp is clay, shape whatever you want with all the connected advantages and shortcomings. C... There's a children's construction set from metal bars and corners. It's fun to play with them. And, generally, everything is quite clear, it's possible to assemble good, solid constructions. But making a vase with rounded corners — it's for the geeks...
исправляем проблему с Transfer-encoding:chunked в nginx
Пока Игорь Сысоев думает над тем, как правильно (т.е. надежно и быстродейственно) реализовать обработку Content-encoding:chunked при не заданной Content-Length в nginx, мне пришлось сделать workaround (для тех, кому это нужно "здесь и сейчас"). Решил его выложить, может, кому-то кроме меня это тоже будет нужно:
Мимоходом, разобрался немного во внутренностях этого сервера. Что можно сказать? Во-первых, event-driven архитектура — это сложно. Особенно, когда нет общего описания, кто кого вызывает. И особенно при почти полном отсутствии комментариев в коде.
Ну и про С и Lisp (по итогам копания в коде двух HTTP-серверов: nginx и Hunchentoot). Lisp — это глина, лепи себе, что заблагорассудится, со всеми вытекающими плюсами и минусами. C... Есть такие конструторы из металлических планок и уголков. Интересно с ними играться. И, в общем-то, довольно понятно все, можно собрать хорошие, надежные конструкции. Но вот сделать из этого какую-нибудь вазу с закругленными углами — это для фанатов...
--- old/ngx_http_request.c 2009-04-05 20:41:18.000000000 +0300
+++ new/ngx_http_request.c 2009-04-05 20:38:33.000000000 +0300
@@ -1403,16 +1403,6 @@
return NGX_ERROR;
}
- if (r->headers_in.transfer_encoding
- && ngx_strcasestrn(r->headers_in.transfer_encoding->value.data,
- "chunked", 7 - 1))
- {
- ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
- "client sent \"Transfer-Encoding: chunked\" header");
- ngx_http_finalize_request(r, NGX_HTTP_LENGTH_REQUIRED);
- return NGX_ERROR;
- }
-
if (r->headers_in.connection_type == NGX_HTTP_CONNECTION_KEEP_ALIVE) {
if (r->headers_in.keep_alive) {
r->headers_in.keep_alive_n =
--- old/ngx_http_request_body.c 2009-04-05 20:41:39.000000000 +0300
+++ new/ngx_http_request_body.c 2009-04-05 20:34:45.000000000 +0300
@@ -54,11 +54,6 @@
r->request_body = rb;
- if (r->headers_in.content_length_n < 0) {
- post_handler(r);
- return NGX_OK;
- }
-
clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
if (r->headers_in.content_length_n == 0) {
@@ -180,7 +175,8 @@
} else {
b = NULL;
- rb->rest = r->headers_in.content_length_n;
+ rb->rest = r->headers_in.content_length_n >= 0 ? r->headers_in.content_length_n
+ : NGX_MAX_SIZE_T_VALUE;
next = &rb->bufs;
}Мимоходом, разобрался немного во внутренностях этого сервера. Что можно сказать? Во-первых, event-driven архитектура — это сложно. Особенно, когда нет общего описания, кто кого вызывает. И особенно при почти полном отсутствии комментариев в коде.
Ну и про С и Lisp (по итогам копания в коде двух HTTP-серверов: nginx и Hunchentoot). Lisp — это глина, лепи себе, что заблагорассудится, со всеми вытекающими плюсами и минусами. C... Есть такие конструторы из металлических планок и уголков. Интересно с ними играться. И, в общем-то, довольно понятно все, можно собрать хорошие, надежные конструкции. Но вот сделать из этого какую-нибудь вазу с закругленными углами — это для фанатов...
Subscribe to:
Posts (Atom)
