Здание, в котором мы находимся, исчезнет с лица земли через десять минут. Возьмите одну часть 98%-ной дымящей азотной кислоты, и смешайте с тремя частями концентрированной серной кислоты. Делать это надо на ледяной бане. Затем добавляйте глицерин по капле из глазной пипетки. Вы получили нитроглицерин.

Я знаю это, потому что это знает Тайлер.

Смешайте нитроглицерин с опилками, и вы получите отличный пластит. Некоторые предпочитают смешивать нитроглицерин с ватой и английской солью. Это тоже дает неплохой результат. А некоторые мешают нитру с парафином. Но при этом получается ненадежная взрывчатка.

Мы с Тайлером находимся на вершине небоскреба “Паркер-Моррис”. Ствол пистолета засунут мне в рот. Издалека доносится звук бьющегося стекла.
Загляни за край крыши. День пасмурный, даже на этой высоте солнца не видно. Это самое высокое здание в мире, так что на вершине его холодно даже летом.

Чак Паланик, «Бойцовский клуб»

Сегодня я решил ещё раз взглянуть на всё это разнообразие, и оказалось, что сам разработчик django-bootstrap уже забросил его развитие, и рекомендует django-crispy-forms. django-crispy-forms — это продолжение развития django-uni-form. django-uni-form в своё время хвалили в докладе Advanced Django Form Usage на DjangoCon 2011, на который я уже ссылался. Если вы этот доклад не видели — очень советую посмотреть, там рекомендуют довольно много чего полезного.

В общем, взглянув на описание django-crispy-forms, мне даже лень стало углубляться в различия django-bootstrap-form и django-bootstrap-toolkit. Оба можно поставить через pip, оба добавляют template filter для вывода формы (кстати, django-bootstrap вместо этого определял свои Form-классы). Но django-crispy-forms умеет всё это, плюс позволяет удобно управлять группировкой элементов форм, определять кнопки непосредственно в коде, поддерживает различные CSS-фреймворки и вообще выглядит как must-have пакет.

Или вот в прошлом году выпустили поддержку Python 2.7, а вместе с ней — поддержку нескольких полезных библиотек (в том числе PIL) и возможность обрабатывать запросы одним инстансом в несколько потоков (что довольно важно, поскольку чем больше инстансов запускается, тем дороже обходится сайт). Казалось бы, можно радоваться? Как бы не так, перейдя на новую версию Python’а разработчики с удивлением обнаруживают, что время выполнения скриптов увеличивается в 2-3 раза, а когда для ответа на запрос AppEngine запускает новый инстанс, то это может занимать 30 секунд и больше для тяжёлых фреймворков, вроде Django-nonrel. Вот этот ответ на StackOverflow отлично описывает ситуацию. Главная проблема в том, что использование многопоточности должно было сгладить увеличение расходов из-за новой модели ценообразования, введённой в прошлом году, но в результате от Python 2.7 толку до сих пор немного.

Есть и другие проблемы — тормозной SDK, отсутствие поддержки SSL и некоторые смешные баги, вроде такого.

При всём этом, AppEngine по-прежнему остаётся во многом интересной и перспективной платформой. Но скорость, с которой его разработчики решают все эти проблемы, сильно настораживает.

Один из основных компонентов AppEngine — это хранилище данных. Стандартным для новых приложений является High Replication Datastore, о нём и пойдёт речь. Замечу, что есть ещё Google Cloud SQL (по сути — «MySQL в облаке»), но он пока что находится на стадии тестирования, и сколько он будет стоить через год, ещё неизвестно довольно дорогой, да и кому этот SQL нужен (шутка). Модель рассчётов за использование хранилища данных такова:

В приведённой выше таблице под операцией чтения или записи имеются в виду низкоуровневые операции. К примеру, выполнение запроса к базе — это одна операция чтения + операция чтения на каждую возвращённую запись. Если же делать запрос, возвращающий не записи, а только ключи, то это будет посчитано как операция чтения + малая операция на каждую запись. Создание новой записи — это 2 операции записи + 2 операции записи на каждое индексированное поле + 1 операция записи на каждый композитный индекс.

Тут мы приходим к интересному выводу: если вы пробуете делать различные «игрушечные» проекты на AppEngine (чем я занимался в последнее время), и не хотите выходить за пределы бесплатных квот, то приходится довольно сильно ограничивать себя в количестве объектов, которые хочется поместить в базу: стоит туда запихнуть какую-то тысячу записей, как вы уже приближаетесь к суточному пределу операций записи. А если эти объекты ещё и должны несколько раз обрабатываться в течении дня, то уж точно нужно задумываться о переходе на платную модель.

Для серьёзных проектов, конечно, желательно приблизительно знать, с каким объёмом данных вам придётся работать в течении дня, и во сколько это будет обходиться. В принципе, можно очень приблизительно прикинуть, что запись несколько тысяч объектов (в пределах одной Django-модели) будет обходиться в 10 центов, что в принципе не так уж и много. Учитывая, что перейдя на платную модель, приходится тратить не менее 8 долларов в месяц, в пределах этого бюджета можно оперировать довольно большими объёмами данных.

На самом деле, при определённых объёмах данных (несколько тысяч записей) довольно легко хранить их в обыкновенных списках и словарях, которые можно сериализовать в JSON или pickle-объекты, и хранить в memcache, время от времени сохраняя в базу. Для волатильных данных такой подход будет очень даже актуален.

Самое главное — данная модель ценообразования основана на принципе «плачу за то, что использую». Если в один день у вас большой поток данных, то на следующий вы вполне можете уложиться в бесплатные квоты, никакие настройки при этом менять не надо. Amazon Dynamo DB, к примеру требует резервировать определённый набор ресурсов, и постоянно за них платить. Если на том же Amazon EC2 хостить инстансы с MongoDB, то принцип тарификации будет тот же. В итоге, использование AWS требует определять максимальную нагрузку, и всегда её оплачивать, с AppEngine’овским же датастором вы задаёте лимиты, но платите только за те ресурсы, которые потребили.

Новый канал Фелиши Дэй и её друзей

Advanced Task Killer
Многие говорят, что это самое нужное приложение на андроиде :) Если честно, я от его использования особой разницы в «тормозах» не заметил. Выключить-включить обычно надёжнее :) (а ещё лучше просто удалить виновное приложение)

Angry Birds
Птички, куда же без них.

AlarmDroid
Настраиваемый будильник

BeyondPod
Подкаст-фетчер, бесплатная версия не умеет сама по расписанию проверять и скачивать подкасты, и ограничена одной закачкой одновременно. У меня на Оптимусе ощутимо подтормаживает, но какое-то другое приложение для подкастов, которое я пробовал, было ещё тормознее, а скачивать вручную и слушать встроенным плеером — неудобно.

Burn the Rope
Прикольная игрушка. В принципе, я редко играю на мобильнике, но если что-то и запускаю — то обычно именно её

Chrome to Phone
Или же Khrome to Phone
Приложение + экстеншн для Хрома для быстрого открытия ссылки из «большого» браузера на телефоне. Первый был почему-то недоступен для установки, но второй замечательно у меня работает

Собственно, экстеншн для Хрома брать тут

Compass
Компас. Duh.

Cut the Rope
Ещё одна игрушка. Я её ставил из какого-то альтернативного аппстора, там она по акции раздавалось бесплатно.

Dolphin Browser HD
Альтернативный браузер, есть вкладки и поддерживает экстеншены. Собственно, поставил я его ради экстеншена LastPass for Dolphin HD (LastPass — сервис для хранения и синхронизации паролей)

Слышал, как хвалили/ругали андроидную Оперу, не пробовал

FBReader
Читалка

GO Weather
Красивый виджет с погодой. Также умеет менять фон «рабочего стола» в зависимости от погоды и времени суток

Google Goggles
Фотопоиск. Умеет сканировать штрихкоды, решать судоку и теоретически находить информацию о чём угодно, на что ты направил камеру. Лично я немного с ним поигрался и оставил как сканер QR-кодов

MX Video Player
Проигрыватель видео со своими кодеками. Нужен, потому что встроенный плеер понимает далеко не все видеоформаты/кодеки (скажем, DivX). Естественно, на смартфоне с маленьким экраном и слабым процессором особо не насмотришься, но при желании (и везении) — можно :)

Paper Toss
Игрушка

Privat24
Мобильная версия Приват24. У приложения гвоздями прибит портретный режим, из-за этого очень неудобно набирать пароль (а возможности запомнить нет), поэтому почти не пользуюсь

Skype
Skype для андроида. В своё время были проблемы с устновкой через маркет, так что пришлось качать пакет с форума 4pda.ru. У меня он тормозил и иногда просто зависал, так что не пользуюсь

Tariff Plan Optimizer UA
Анализирует статистику звонков/смсок и показывает, сколько бы ты денег потратил на разных тарифах.

USSD Checker
Проверяет состояние счёта через USSD-запрос и выводит на виджет. Платная версия может автоматически обновлять счёт после каждого исходящего звонка/SMS, бесплатная проверяет только раз в сутки в 23:55 (можно проверить вручную в любой момент в два касания)

Ну и на выбор две киноафиши:
PopCornUA
Яндекс.Киноафиша

Преимущество PopCornUA — он умеет загрузить информацию на телефон, и потом работать без подключения к интернету. Для Яндекс.Киноафиши постоянно требуется инет, зато она более удобная, красивая, и от православного Яндекса

Во-первых, JS и CSS-файлы можно собирать в «бандлы» — проще говоря, множество файлов можно собрать в один, что уменьшит необходимое количество запросов. При этом прозрачно поддерживаются всевозможные SASS, CoffeeScript и прочие «улучшатели» CSS и JS, вплоть до того, что итоговый CSS файл можно собрать из комбинации нескольких файлов CSS, SASS, LESS и т.д. Заодно при генерации итогового файла для заливки на продакшн-сервер его можно автоматически сжать YUICompressor или другим компрессором (на отладочном сервере они так и будут отдаваться как множество файлов и без всякой компрессии)

Во-вторых, абсолютно все файлы версионируются. Другими словами, больше не будет ситуации когда заказчик после обновления сайта по-прежнему видит старый дизайн, поскольку, к примеру, main.css в одной версии автоматически переименовывается в main-4f3fcb40.css, а в следующей — уже в main-390ba896.css. Заодно можно указать в настройках кэширования, чтобы файлы в каталоге со статическими файлами никогда не устаревали

При этом на отладочном сервере вся «магия» происходит через middleware и генерируемые файлы никуда не складируются, а перед установкой на продакшн достаточно запустить manage.py generatemedia.

Увы, пока что django-mediagenerator имеет кучу проблем, если пытаться использовать его на серьёзных проектах.

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

Во-вторых, к отдельным CSS и JS-файлам по идеологии django-mediagenerator просто так не обратиться, нужно обязательно определять бандл. А бандл, к тому же, можно задавать только в корневом settings.py проекта, что усложняет написание повторно используемых приложений.

Ну и в-третьих необходимость особым образом работать с именами всех статических файлов (а не просто добавлять {{ STATIC_URL }} в путь) добавляет головной боли. В конечном итоге, я прикинул, как бы мне добавить поддержку django-mediagenerator в django-tinymce, и очень быстро раздумал это делать :)

Всё те же разработчики сделали CMS All Buttons Pressed (поскольку другие CMS на Django не совместимы с Django-nonrel), в которой, конечно же, использовали django-mediagenerator. Примечательно, что статических файлов с ней идёт немного, и вместо WYSIWYG-редактора предполагается использовать разновидность вики-разметки. Сейчас я переделываю эту CMS под себя, и уже использую staticfiles и django-tinymce.

Ну и самое главное — авторы Django-nonrel совсем недавно объявили, что прекращают заниматься своими Django-проектами. Для самого Django-nonrel уже нашёлся новый мейнтейнер, но будут ли дальше развивать ABP и mediagenerator, пока непонятно

Добавка: расписал на StackOverflow, как правильно использовать staticfiles c Django-nonrel/djangoappengine

Но нереляционные БД — это не только денормализация табличек, это ещё и дополнительные ограничения. Например, через некоторое время работы с AppEngine, я наткнулся на вот такое:

Запрос может использовать фильтры неравенства (<, <=, >=,>, !=) только по одному свойству среди всех своих фильтров.

Дело в том, что в разрабатываемом мной сайте есть несколько моделей с полями вроде date1 и date2, и, соответственно, время от времени нужно выводить список объектов по дате date, у которых date1 <= date <= date2. Спрашивается, как это делать используя не более двух операций неравенства?

Я решил воспользоваться тем, что BigTable поддерживает поля типа ListProperty (Django-nonrel, соответственно, поддерживает поля типа ListField, вот только документации по нему нет ^^), при этом вхождение в список в GQL проверяется вовсе не оператором IN (который ограничен 30-ю значениями), а оператором ‘=’

Непосредственно в джанго-приложении это выразилось таким кодом:

# models.py

def _date_range(date1, date2):
    result = []
    while (date1 <= date2):
        result.append(date1)
        date1 += datetime.timedelta(1)
    return result

class MyModel(models.Model):
    # ...
    date1 = models.DateField('Дата начала')
    date2 = models.DateField('Дата окончания')
    date_range = ListField(models.DateField(), blank=True)
    # ...
    def save(self):
        self.date_range = _date_range(self.date1, self.date2)
        super(MyModel, self).save()

# views.py

def transp(request, day, month, year):
    # ...
    objects = Transport.objects.order_by('-updated')
    if (day):
        the_date = datetime.datetime(int(year), int(month), int(day))
        objects = objects.filter(date_range__exact = the_date)
    # ...

Тут есть один странный подводный камень -- нужно использовать именно datetime.datetime, а не datetime.date (не смотря на то, что у меня везде DateField, а не DateTimeField).

На первый взгляд кажется, что такое представление данных -- очень неэффективно. Но если посмотреть на эту модель с точки зрения того, каким образом будут работать индексы, то окажется, что поиск с такой моделью будет работать быстрее! Не случайно в AppEngine ограничены именно фильтры неравенства: фильтр равенства сводится к простой и эффективной выборке по определённому индексу.

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

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

Число строк кода сократилось с 9 до 6, и форма инстанцируется всего в одном месте. Ниже я привёл несколько полезных сниппетов из того же доклада:

# view with a form

def my_view(request, template_name='myapp/myform.html'):
    form = MyForm(request.POST or None)
    if form.is_valid():
        do_x()
        return redirect('home')
    return render(request, template_name, {'form': form})

# view with files

def my_view(request, template_name='myapp/myform.html'):
    form = MyForm(request.POST or None, request.FILES or None)
    if form.is_valid():
        do_x()
        return redirect('home')
    return render(request, template_name, {'form': form})

# view for editing a model instance

def my_model_edit(request, slug=slug, template_name='myapp/my_model_form.html'):
    mymodel = get_object_or_404(MyModel, slug=slug)
    form = MyModelForm(request.POST or None, instance=mymodel)
    if form.is_valid():
        mymodel = form.save()
        // ...
        mymodel.save()
        return redirect('home')
    return render(request, template_name, {'form': form, 'mymodel': mymodel})

# view for creating a model instance

def my_model_add(request, slug=slug, template_name='myapp/my_model_form.html'):
    form = MyModelForm(request.POST or None)
    if form.is_valid():
        form.save()
        return redirect('home')
    return render(request, template_name, {'form': form})

# forms overloading

class MyModelForm(forms.ModelForm):
    def __init__(self):
        super(MyModelForm, self).__init__(*args, **kwargs)
        self.fields['name'].required = True
        self.fields['age'].required = True
        self.fields['profession'].required = True
        self.fields['profession'].help_text = _('Hi professor')

    class Meta:
        model = MyModel  

# dynamically adding fields to a form

def my_view(request, template_name='myapp/my_model_form.html'):
    form = MyModelForm(request.POST or None)

    # Let's add a field on the go, needs to be done before validating it
    form.fields['favorite_color'] = forms.ChoiceField(
        ...
    )

    if form.is_valid():
        # Let's get user's favorite color,
        # you can do whatever you want with it
        favorite_color = form.cleaned_data['favorite_color']

        form.save()
        return redirect('home')

    return render(request, template_name, {'form': form})

Добавлено: render и redirect импортятся, конечно же, из django.shortcuts. Обратите внимание, что render добавлен в Django 1.3 (и его удобно использовать вместо render_to_response и direct_to_template).

Экран, конечно, не идеально белый, и требует хорошего освещения (впрочем, как и обычные книги). Но читать с него приятно. Размер 6″ меня вполне устраивает — для чтения PDFов всё равно лучше накопить на планшет. Для художественных книг в PDF также помогает вот эта программа (см. также эту заметку)

Управление не идеальное, ибо в 2011 году устройство без тача кажется слегка устаревшим. Но совсем неудобным его не назвать. Наверное, в следующем Kindle будет тач, но учитывая периодичность выхода новых поколений Kindle (кроме DX) — они сменяются примерно раз в полтора года, так что следующий Kindle нужно было бы ждать ещё год (купил я его в марте).

Кожаная обложка смотрится весьма солидно, хорошо держится на креплении, и главное — имеет выдвижной фонарик, который питается от самого устройства. Этой подсветки почти хватает для комфортного чтения (всё-таки правый верхний угол освещён хорошо, а левый нижний — слабо). За такую обложку не жалко и 60$… Почти :) Не хватает только надписи «DON’T PANIC»

(Есть варианты обложки подешевле, но без встроенной подсветки)

Браузер действительно позволяет бесплатно смотреть любые сайты. Даже если там есть куча джаваскрипта и анимация. Естественно, анимация выглядит весьма забавно на таком экране, прокрутка экрана ощутимо тормозит, а ссылки приходится выбирать джойстиком. Но всё равно — иметь возможность бесплатно выйти в интернет по всему миру — это просто круто. Можно проверять почту и писать в твиттер. Наверняка можно общаться через какой-нибудь GTalk, хотя я не пробовал.

Понятное дело, скачать никакие файлы не дают. Но самое неприятное другое — из-за отсутствия вкладок браузер не переваривает ссылки, которые должны открываться в новой вкладке/окне. Потому, например, если вы пришлёте себе ссылку по электронке, а затем на Киндле попробуете зайти на GMail и «кликнуть» по этой ссылке, то увидите только окошко с ошибкой. Та же проблема — и с Google Reader.

Зато чем хорош Google Reader — так это своим клавиатурным управлением: j/k для предыдущей/следующей заметки (или n/p для выбора и o для отрытия), u для скрытия панели со списком каталогов/лент — и читать из него становится относительно удобно. Но только если в соответствующих лентах тексты заметок отдаются полностью. Мне как раз в одно время с покупкой Kindle брат показал вот этот блог, я подписался на него в Google Reader, занёс все заметки в starred, и большую часть прочитал именно на Kinde’е.

Шрифт, правда, на большинстве веб-сайтов всё-таки мелковат для долгого чтения. Можно, конечно, увеличить его до 150%, но на том же Google Reader тогда сильно расползается вёрстка и браузер начинает ощутимо тормозить.

«Умной» подгонки ширины текста в многоколоночной вёрстке, как на современных мобильных браузерах, тоже нет. Так что на некоторых сайтах (к примеру, TeamLiquid), если не сделать приближения, то текст будем слишком мелким, а если приблизить — часть текста будем обрезана по левому или правому краю.

Kindle Store вполне удобен. Что касается цен — вот, например, Design Patterns: Elements of Reusable Object-Oriented Software в печатном виде на Amazon’е стоит $59.99 ($41.56 при доставке по Штатам), а в версии для Kindle — $28.39. Конечно же, с DRM, и конечно, байты не пощупать и не понюхать, но — разница налицо. Правда, видел упоминания в блогах, что некоторые книги — наоборот, неоправданно дороги (см. также заметку Макса Ищенко). Купленные книги в любой момент можно скачать из Амазона. Напомню также, что их можно читать с помощью приложений на куче разных платформ — Linux’а там, правда, нет, но не давно была запущена веб-версия.

Устройство видится с компьютера, как обычная флешка, но лучше всё-таки использовать Calibre — хотя бы потому, что форматов Kindle понимает мало, а Calibre их все умеет конвертировать. Также замечу, что гугл может помочь вам найти прошивки с русификацией и поддержкой русской клавиатуры — сам я их, впрочем, не пробовал.

В целом, если сравнивать с другими читалками, то недостатки Kindle явно менее критичные, чем его преимущества. Бесплатный доступ к интернету практически где угодно — это настолько killer feature, что даже объяснять как-то неудобно.

Обзор Mobile Review
Обзор Экслера