Игорь Артамонов

Погоняв Google App Engine пару месяцев расскажу о впечатлениях от него.
Платформа несомненно интересная, и будет очень полезна startup’ам, т.к. позволяет сосредоточится на решении своих конкретных задач, отдав все что не является конкурентым преимущество на откуп платформе и её сервисам.

К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.
Читать далее »»

Кто нибудь занимается datamining, textmining, ir и прочими делами с большими массивами данных? Вот запустил небольшой сервис: datasetpublisher.com – торрент трекер для коллекций данных. Т.е. чтобы не качать очередные 5G дампа википедии со скоростью 70Kb/s (докачается как раз к моменту когда выложат новый дамп), а скачать с нормальной скоростью через торрент.

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

Проект запущен на Google App Engine, что собственно и послужило причиной его появления. Уж очень я в последнее время заинтересовался этой платформой, и решил поэксперементировать. А так как я очень не люблю что-то делать «в корзину», и считаю что подобные эксперименты, помимо исследовательской цели, должны принести конкретный применимый сейчас результат. И вспомнил разговор с Иваном Бегтиным, незадолго до этого, о том что неплохо бы иметь подобный ресурс. Теперь он есть. И с GAE разобрался, на него еще посмотрю как вести себя будет, и напишу свое мнение.

В минувшую субботу, на rupy 2007 возникло небольшое обсуждение с Андреем Таранцевым по поводу скорости вычисления числа из ряда фибоначи в ruby/jruby, что было одним из тестов производительности языков. Проблема возникла в том что последний очень медленно считал, в сотни и тысячи раз медленней java. JRuby вычисляет 40 элемент за 26 минут, а java 1,7 секунды. Python тоже не быстр, но ближе к java.
Андрей предположил что это связано с тем что язык динамический, все можно переопределять, и т.д., поэтому мат. операции такие медленные. Я вот проверил, у меня возникло подозрение что вина в рекурсии, посчитал время вычисления для разных языков:

Если тоже самое вычислять итеративным алгоритмом, то время резко падает и остаётся в районе миллисекунд, без особого видимого роста, по крайней мере на таком объеме. Я знал что рекурсия это не очень быстро, но честно говоря никогда не замерял насколько, и очень удивлён что такое огромное влияние.
Вот такое вот разочарование Если на чистоту то и java тоже не любит часто любимую мной рекурсию, даже такую простую, т.к. тоже не имеет tail call optimization, и даже в любой момент может упасть по OutOfMemoryException из-за рекурсии, я уже спотыкался на этом когда то.

PS: на самом деле для ruby, а точнее Ruby on Rails, все это насчёт рекурсии совсем неважно, но иметь ввиду все же надо.

Привыкнув к Java, с её идеей о том что все строки всегда хранятся в Unicode, я сильно парюсь в Python.

Гдето чтото не так написал, или не сконвертировал из нужной кодировки в другую нужную, и все, и все полетело Вот тут, в Django, например, чтобы заменить регекспом строку на русском, надо делать так:

#-*- coding: cp1251 -*-

import re
instr = unicode(req.POST['param'], 'utf-8')
pat = re.compile(u'этоубрать', re.U)
instr = re.sub(pat, '_', instr)

а при выплевывании на страницу надо так

messages.append(unicode('Наше сообщение', 'cp1251').encode('utf-8'))

А я все то там, то тут пропускаю, то unicode() то encode() не в том месте, а они все поочереди идут, на выходе непонятно что получается Теперь разобрался вроде.