Делал я недавно доклад (на Percona Live). И как-то ночью (jet-lag все-таки) подумал, что неплохо бы как-нибудь видеть свои комментарии к слайдам — подсказки — и переключать слайды не подходя к ноутбуку. Чудо-устройства, чтоб и слайды переключало и комментарии показывало, у меня не было. Но был смартфон с Андроидом. Гугл-маркет разочаровал. Большинство подобных приложений работало только с PowerPoint, для LibreOffice я нашел только одно, платное, и выглядело оно как-то не так.

Но есть простое решение — браузер. Можно поднять http-сервер на ноутбуке, зайти с телефона, и по ссылкам переключать слайды. И будет работать не только с Андроидом, а и с яблочными, и с виндофонами. Да вообще смартфон не нужен, можно хоть через WAP заходить, или с другого ноутбука.

Никак не могу дописать документацию по Grab:Spider — это часть библиотеки Grab — для написания асинхронных пауков. Подумал выкладывать куски документации на хабрахабр. Думаю, с некоторым фидбэком дело быстрей пойдёт. На данный момент в документации есть лишь введение, описывающие в общих чертах, что за это за зверь такой Grab:Spider. Его и выкладываю.

Всем привет!

Я активный пользователь open-source фрэймворка Grab (itforge уже писал о нем здесь и здесь) и 1/2 проекта GrabLab (который занимается собственно коммерческой эксплуатацией фрэймворка). Т.к. парсим сайты мы часто, помногу и задания как правило совершенно не похожи друг на друга, хотелось бы поделится своим опытом в вопросе построения типичного парсинг проекта.

Немного про инструментарий который помогает мне в работе

В качестве рабочего браузера я использую FireFox с плагинами HttpFox (анализировать входящий/исходящий http трафик), XPather (позволяет проверять xpath выражения), SQLite Manager (просмотр sqlite таблиц), код набираю в emacs, где активно использую сниппеты (YASnippets) для часто встречающихся конструкций.

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

В пятницу, не смотря, что она была еще и 13 апреля, команда создающая PyCharm, передовую IDE для Python от JetBrains, выпустила очередное обновление своего продукта — версию 2.5.
В этот релиз вошли важные нововведения по работе с Python-окружением и не только:

Предисловие

Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.

Тут другое дело. PHP не просто неудобен в использовании, плохо мне подходит, субоптимален или не соответствует моим религиозным убеждениям. Я могу рассказать вам много хороших вещей о языках, которых я стараюсь избегать, и много плохих вещей о языках, которые мне нравятся. Вперёд, спрашивайте! Получаются интересные обсуждения.

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

Вам когда-нибудь хотелось добавить поле в класс dict? Вы мечтаете написать action.name.len() вместо len(action.name)? Вы хотите добавить гибкости любимому Python-у? Вам говорят, что это невозможно? Тогда давайте погрузимся в некоторые детали объектной модели Python!

После публикации статьи о модуле nginx, предназначенном для борьбы с ботами я получил множество откликов, в которых люди спрашивали о поддержке Flash.
Я был уверен, что при должных усилиях желающие могли реализовать эти функции самостоятельно, как сторонние приложения, без изменения кода самого модуля, но никто этого не сделал, поэтому пришлось сделать PoC.

20-21 октября 2012 состоится украинский Пайкон: ua.pycon.org
Если желаете выступить с докладом или мастер-классом — пишите на <andrew.svetlov@gmail.com>.

И снова доброго времени суток всем читателям!
Спасибо, за проявленый интерес к первой части перевода, надеюсь, вторая вас так же не разочарует.

Итак, в первой части данной статьи мы совершили базовое знакомство с декораторами, принципами их работы и даже написали свой вручную.
Однако, все декораторы, которые мы до этого рассматривали не имели одного очень важного функционала — передачи аргументов декорируемой функции.
Что ж, исправим это недоразумение!

Привет. Была поставлена задача реализовать геолокацию (google maps v3) для пользователей в одном из проектов на django, хочу поделиться своим решением.

Необходимый функционал:

1. Вывод карты с маркером текущего положения, возможность перемещать маркер (dragged), ставить по click событию
2. Поиск по адресу (autocomplete)
3. Сохранение как координат, так и самого адреса (если он имеет место быть)

На Хабре множество раз обсуждалась тема декораторов, однако, на мой взгляд, данная статья (выросшая из одного вопроса на stackoverflow) описывает данную тему наиболее понятно и, что немаловажно, является «пошаговым руководством» по использованию декораторов, позволяющим новичку овладеть этой техникой сразу на достойном уровне.

Итак, что же такое «декоратор»?

Впереди достаточно длинная статья, так что, если кто-то спешит — вот пример того, как работают декораторы:

def makebold(fn):
    def wrapped():
        return "<b>" + fn() + "</b>"
    return wrapped
 
def makeitalic(fn):
    def wrapped():
        return "<i>" + fn() + "</i>"
    return wrapped
 
@makebold
@makeitalic
def hello():
    return "hello habr"
 
print hello() ## выведет <b><i>hello habr</i></b>

Я очень далёк от желания устраивать «cвященные войны» на тему языков программирования. Всё равно мы будем использовать те языки программирования, которые сочтём подходящими для своих задач. Когда я писал эту заметку, я предполагал, что она вызовет негативную реакцию. Меня она совсем не удивит.
Когда я впервые познакомился с ruby, я был приятно удивлён-элегантный и внятный синтаксис языка, мультиплатформенность и много всяких вкусностей.Но пользуюсь я до сих пор python, совсем не потому что python лучше чем ruby. Совсем по другим причинам.

Добрый день.

Часто возникает необходимость иметь пользовательские (административные) настройки сайта, которые не могут быть определены в settings.py по двум простым причинам: настройки из settings.py не могут быть изменены без перезапуска сервера; и — самое главное — они могут быть изменены только программистом.

Модуль django-dbsettings (бывш. django-values) призван избавить Вас от этих ограничений: он предоставляет механизм хранения пользовательских настроек в базе данных, а также удобные виды для их редактирования.

И вроде бы все отлично… НО! Что же делать, если в качестве настройки нужна будет картинка: например, логотип сайта? Как выяснилось, django-dbsettings не поддерживает такого типа значений.

О том, как я добавлял поддержку ImageValue в django-dbsettings, я и собираюсь поведать.

Сегодня неожиданно понял, что скрипты — это сила (спустя несколько месяцев использования fabric). На самом деле 30 минут потраченные на написание адекватного сценария избавляют от многих совокупных часов повторения ненужных действий. Для упрощения жизни адептов python'а существует такой прекрасный модуль как fabric. И я хочу поделиться парой кусков своего fab-файла как пример упрощения жизни девелопера.

Это будут функции: «умный» комментатор локальных файлов и git-коммитер.

Апрельская скидка на PyCharm. До 16 апреля 30% скидка.

Mock на английском значит «имитация», «подделка». Модуль с таким названием помогает сильно упростить тесты модулей на Питоне.

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

Такое поведение — уже не надувные ракетные установки, а целая надувная земля, вокруг которой могут летать испытуемые ракеты и самолёты.

Наверное всем, кто хоть раз интересовался Python, известно про GIL — его одновременно и сильное и слабое место.
Не мешая однопоточным скриптам работать, он ставит изрядные палки в колеса при многопоточной работе на CPU-bound задачах (когда потоки выполняются, а не висят попеременно в ожидании I/O и т.п.).
Подробности хорошо описаны в переводе двухгодичной давности. Побороть GIL в официальной сборке Python для настоящего распараллеливания потоков мы не можем, но можно пойти другим путем — запретить системе перебрасывать потоки Python между ядрами. В общем пост из серии, «если не нужно, но очень хочется» :)
Если вы знаете про processor/cpu affinity, пользовались ctypes и pywin32, то ничего нового не будет.

В прошлой статье я рассказал о возможном способе снимать централизованные резервные копии конфигураций с маршрутизаторов MikroTik. Казалось бы на этом можно и успокоиться, но для некоторых филиалов руководство требует сиюминутного восстановления работы в случае выхода из строя любого участка сети. Первое, что приходит в голову — само собой, нужно иметь рядом две одинаковые железки. Однако вторая логичная мысль — использовать VRRP не подходит в силу ряда причин, одна из которых использование IPSec. Значит нужно снова шаманить костыль и синхронизировать конфигурацию в полуручном режиме, то есть скриптоваться.

Пользователь eyeofhell недавно написал статью Python vs Ruby.
Знатный холивар получился. Не могу не поддержать. Сначала думал написать в комментарии — но ответ вышел слишком объемным.

Недавно захотелось вспомнить свое «шпионское» детство и хотя бы базово изучить разные методы шифрования. И первым выбор пал на шифр Виженера. Сам по себе он не является чрезвычайно сложным, но достаточно долго считался криптоустойчивым. Века эдак с XV и к самому XIX, пока некто Казиски полностью не взломал шифр.
Однако ограничим цитирование Википедии только описанием самого алгоритма.

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