Дело в том что все скрипты на Python при первом запуске пишутся интерпретатором в виде байткода в файлы с расширением .pyc (это не рус типа РУСский или что-нибудь в этом роде, это PYthonCompiled - т.е. скомпилированый Python код). Интерпретатор Python по умолчанию пытается запускать именно эти файлы, а если он не существует, то использует исходный код после чего записывает этот же pyc-файл. Эти файлы можно создать, так сказать, вручную перед распространением файлов.

Делается это так

>>> import py_compile
>>> py_compile.compile('megascript.py')

В результате рядом с megascript.py будет создан файл megascript.pyc который вы и будете продавать. Удачной разработки, и больших заработков!

Links: PEP 304 - Controlling Generation of Bytecode Files

Понравилось? помогло? – Подпишись на RSS!

Общем во сне я был в Минске, и мне позвонил знакомый чел пригласил поиграть в баскет в каком то зале. Так вот я ему ответил что вчера тоже играл в баскет (а это так и было в действительности), и через пару дней, в субботу, должен буду играть на, так называемом, баскетбольном марафоне (о нем чуть ниже), и лишний раз потренироваться мне не помешало бы. И марафоне я тоже буду играть в эту субботу.

Получается что я во сне расказал события и планы из реальной жизни. Прикольно как то получилось, у кого-нибудь бывали и бывают ли такие случаи?

Баскетбольный марафон это такая штука когда местные организовывают команды с 2-х соседних городов и играют друг против друга 8 часов нон стоп в первую субботу декабря. Представляете 8 часов баскета? в прошлом году я первый раз попал на это событие и играл за местную команду, и даже (хвастаюсь) занял второе место по количеству набранных очков среди двух команд :). Нет там не какие то ламеры играли, у всех довольно хорошего уровня баскет. В этом буду второй и наверно последний раз, потому что к следующему году к декабрю я уже свалю отсюда куда то дальше. Хотя возможно приеду просто поиграть если не буду далеко где-то.

У программистов иногда стоит задача скриптами отправлять почту ( я не про спам ), это может быть как контактная форма, так и какая то служебная информация от скриптов. Например скрипт оповещает о завершении какой-либо задачи, это могут быть какие то периодические отчеты, либо в случае ошибки отправлять письмо с данными о “происшествии”.

Так вот для последнего в Python есть такая библиотека которая называется, как не сложно догадаться, logging. У нее есть много возможностей, но основная ее задача это логирование сообщений со скриптов. Вот так выглядит простейшее использование этой библиотеки:

import logging
logging.basicConfig(level=logging.DEBUG,
                    filename='/tmp/my_demo.log',
                    filemode='a')

Потом в любом месте скрипта делаем так

import logging
logging.debug('My demo log string...')

и в файле /tmp/my_demo.log мы увидем строчку

DEBUG:root:Demom log string...

Так вот когда я сказал что у модуля logging есть много возможностей, я не имел ввиду что логировать так как показано в примере это круто. По умолчанию да, сообщения логируются просто в файл. Но изначально существуют обработчики, назовем их логерами.

• StreamHandler посылает логируемое сообщение в поток (файл подобные объекты).
• FileHandler – в файл на диске.
• BaseRotatingHandler - это базовый класс для обработчиков которые “ротируют” лог файлы. Не рекомендуется использовать его напрямую, используйте вместо него TimedRotatingFileHandler.
• RotatingFileHandler - сообщения пишутся в файл на диске, ротируются по достижении указанного размера файла.
• TimedRotatingFileHandler тоже самое что и предыдущий, только ротируется при определенных временных интервалах.
• SocketHandler пишет сообщение в TCP/IP сокет.
• DatagramHandler – в UDP сокет.
• SMTPHandler отправляет сообщение по на почту.
• SysLogHandler отправляет сообщение демону syslog в Unix, возможно и на удаленную машину.
• NTEventLogHandler посылает сообщение логу событий Windows NT/2000/XP (о винде даже позаботились, хотя зачем ей это ).
• MemoryHandler пишем в буфер в памяти который сбрасывается при определенных критериях.
• HTTPHandler отправляет сообщение в виде “GET” или “POST” HTTP запроса на сервер.

Вот какой богатый набор. Но и этого бывает недостаточно иногда. Об этом сегодня и говорим, и мне недостаточно стандартного SMTPHandler, т.к. у него есть один недостаток - он не может авторизоваться на сервере. Но и для того чтобы отсылать через smtp сервер gmail, нужно еще небольшое дополнение.

Все что нам потребуется, это расширить стандартный SMTPHandler, немножко дописав метод __init__ чтобы он принимал наши логин и пароль, и переписать метод emit, так, чтобы он правильно отправил сообщение через гмыло. Вот что получилось.

#! /usr/bin/env python
# -*- coding: utf-8 -*-
 
import logging, logging.handlers, types, smtplib
from email.MIMEText import MIMEText
 
class GmailHandler(logging.handlers.SMTPHandler):
    def __init__(self, mailhost, fromaddr, toaddrs, subject, *args, **kwargs):
        """
        Initialize the handler.
 
        Initialize the instance with the from and to addresses and subject
        line of the email. To specify a non-standard SMTP port, use the
        (host, port) tuple format for the mailhost argument.
        """
        logging.Handler.__init__(self)
        if type(mailhost) == types.TupleType:
            host, port = mailhost
            self.mailhost = host
            self.mailport = port
        else:
            self.mailhost = mailhost
            self.mailport = None
        self.fromaddr = fromaddr
        if type(toaddrs) == types.StringType:
            toaddrs = [toaddrs]
        self.toaddrs = toaddrs
        self.subject = subject
 
        # added this lines
        self.auth_username = kwargs.get('auth_username', None)
        self.auth_password = kwargs.get('auth_password', None)
        if self.auth_username and self.auth_password:
            self.auth_required = True
        else:
            self.auth_required = False
 
    def emit(self, record):
        try:
            msg = MIMEText(self.format(record), 'html', 'utf-8')
            msg['Subject'] = self.getSubject(record)
            msg['From'] = self.fromaddr
            msg['Sender'] = self.fromaddr
            msg['To'] = ','.join(self.toaddrs)
 
            port = self.mailport
            if not port:
                port = smtplib.SMTP_PORT
 
            session = smtplib.SMTP(self.mailhost, port)
            session.ehlo()
            # TLS
            session.starttls()
            session.ehlo()
            if self.auth_required:
                session.login(self.auth_username, self.auth_password)
            session.sendmail(self.fromaddr, ','.join(self.toaddrs), msg.as_string())
            session.quit()
        except (KeyboardInterrupt, SystemExit):
            raise
        except:
            self.handleError(record)

Пользоваться вот так

import logging
from gmail_logging_handler import GmailHandler
 
rootLogger = logging.getLogger('')
gmail_handler = GmailHandler(('smtp.gmail.com', 587),  'from_email@gmail.com', 'to_email@gmail.com', "Error at site.com", auth_username="GMAIL_EMAIL", auth_password="PASSWORD")
rootLogger.addHandler(gmail_handler)
 
logging.error('This is an error message that should be sent by mail.')

Естественно вам надо вставить свои логин и пароль на гмыле.

Скачать GmailLoggingHandler одним файлом.

Пользуйтесь наздоровье.

Вот тут например есть реализация обработчика который отсылает сообщения на Jabber аккаунт (он же Google Talk). А куда вам еще надо отсылать лог сообщения?

#!/bin/bash
curl --basic --user USERNAME:PASSWORD \
--data status="$*" http://twitter.com/statuses/update.xml -o /dev/null;

где USERNAME и PASSWORD должны быть заменены вашими данными. Сохраните файл с именем twit (ну или как вам захочется). Этот файл должен лежать внутри $PATH (незнаю как это умно сказать), например /usr/local/bin/twit или /bin/twit. Скрипт готов к употреблению.

twit "Тестим постинг в twitter из командной строки"

Вот и все. У меня на маке работает, на любом линуксе тоже должно работать (должен стоять curl). Хотя нет, не все. Мы же не хотим так просто светить свои логин и пароль на твитер. Поэтому совершим еще несколько телодвижений.

sudo chmod 551 /bin/twit
sudo chmod +s /bin/twit
sudo chown root /bin/twit

Теперь контент этого скрипта сможет читать только root, а запускать может кто угодно.

Stay tuned for more! 

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

SaaS (Software-as-a-Service) - это бизнес модель предполагающая, попросту говоря, сдачу софта в виде вебсервиса в аренду. Т.е. это веб приложения доступные как правило из браузера имеющего доступ в интернет, и хостятся они на серверах провайдера. Отсюда и название Software-as-a-service — “Софт как сервис”. Ярким представителем этой бизнес модели является SalesForce, так же считается что эта компания является первооткрывателем этого направления.

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

Стоит заметить что SaaS это не web 2.0. Web 2.0 это больше про социальные сети, блоги, генерируемый пользователями для других пользователей контент, разукрашеные дизайны и AJAX интерфейсы и т.д. Хотя в SaaS проектах AJAX интерфейс в любом случае приятен потому что он прост и быстр. SaaS это ваши традиционные бизнес приложения работающие через интернет и размещенные на ресурсах провайдера.

Главное что делает SaaS такой крутой штукой так это возможность совместной работы и коммуникации. Простой наглядный пример это Google Docs. Попробуйте писать в нем документ совместно с вашими друзьями или сотрудниками и вы поймете эту мощь. Больше нет необходимости редактировать документы, отсылать их прикрепленными к емейлу и т.д. Вот она красота, на ладони. Более того, вам больше нет необходимости держать свои сервера и персонал который будет их обслуживать. Все делают провайдеры.

Но не все так сладко как показалось на первый взгляд. О преимуществах и недостатках этой бизнес модели, о ярких представителях, о проблемах создания а так же использования SaaS проектов и о многом другом я расскажу вам в следующихстатьях.

MacFUSE

Недавно открыл для себя такую штуку как MacFUSE и сильно упростил себе жизнь и работу. Некоторые блогеры называют MacFUSE технологией будущего.

Проект  MacFUSE, созданный разработчиком из Google Amit Singh, произошел от линуксового проекта FUSE, который позволяет создать файловую систему из любого контента любого сервиса или приложения.

Примеров использования этой технологии полно. Например подключение виндовой файловой системы в линуксе для всякого рода манипуляций с файлами и папками. Банально? А как вам создание файловой системы из RSS лент где папки это сами ленты, а файлы внутри этих папок это посты в RSS фиде которые можно редактировать, удалять, перемещать и т.д. Не юзабельно? Кому как. А более приближенный к реальности пример файловой системы на основе Google Docs где документы этого сервиса доступны в файловой системе? Фантастика, не так ли? Вот здесь или здесь можно посмотреть примеры использования MacFUSE.

Я пока что воспользовался только утилитой SSHFS которая мне позволила иметь локальное зеркало сервера, за счет чего я могу копировать файл на сервер просто перетянув файл из одной локальный папки в другую, могу редактировать серверные файлы как локальные и т.д. Очень удобно. В планах вмонтировать Google Docs в свою файловую систему.

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

Мне например нужен был этот функционал чтобы работал мой плагин к jQuery (который совершает хитрые манипуляции со скролами) как было задумано. Сам плагин расшарю немножко попозже, когда убежусь что он работает как надо и посчитаю что уже можно выложить :). Возможно кому то тоже такое пригодится. 

Код функции выглядит вот так:

function getScrollBarWidth () {
	var inner = document.createElement('p');
	inner.style.width = '100%';
	inner.style.height = '200px';
 
	var outer = document.createElement('div');
	outer.style.position = 'absolute';
	outer.style.top = '0px';
	outer.style.left = '0px';
	outer.style.visibility = 'hidden';
	outer.style.width = '200px';
	outer.style.height = '150px';
	outer.style.overflow = 'hidden';
	outer.appendChild (inner);
 
	document.body.appendChild (outer);
	var w1 = inner.offsetWidth;
	outer.style.overflow = 'scroll';
	var w2 = inner.offsetWidth;
	if (w1 == w2)
		w2 = outer.clientWidth;
	document.body.removeChild (outer);
 
	return (w1 - w2);
};

Пример можно посмотреть здесь и оценить размер своего …. кхмм… скролла. У кого какие размеры? у меня 15.

Stay tuned for more….

День начался очень рано и с приключениями. Как некоторые мои читатели уже знают я живу не в Праге, а на самом юге Чехии. Поэтому мне пришлось встать в 3 часа утра (надо же, более привычно ложиться спать в это время) чтобы быть в праге в 8 утра. Так вот так получилось что поезд, который по расписанию прибывает в 7:53 чудесным образом добрался до Праги примерно в 11:30. Незнаю на самом деле что произошло, но по пути поезд стал, и простоял на одном месте 2.5 часа, никаких автобусов все это время на подмену пригнать не могли – как говорили их небыло, но потом появились. Вообще с чешскими драгами (Ceske Drahy, аналог БЧ, РЖД) часто случается что поезд задерживается. Я всегда думал что это обусловлено глобальным ремонтом нашего направления дороги, но слышал много от кого что это не только в нашем направлении (впринципе даже поезд Москва - Прага, на котором мы сюда ездим обычно, тоже иногда с большими опозданиями приходит). Таким образом я приехал к обеду получается. Хотя успел попасть на 15 минут на сессию об Open Social так ничего интересного не услышав.

Сразу после регистрации выдали беджик, расписание сессий, небольшую книжечку по сервисам гугла, анкету, которую надо было сдать на выходе и получить кружку-термос с выгравированой надписью Google, и майку. Майка сразу скажу не очень понравилась – спереди логотип андроида выбился из стиля остальных 3-х логотипов, да и цвет майки не очень приятный.

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

Не очень понравилось что в последний день были внесены изменения в программу. Хотя при регистрации на сайте об этом предупреждали. Так, например, была убрана сессия и практический семинар о Google Gears на которые я хотел сходить, можно сказать из-за которой ехал сюда. Из практических семинаров было только по Google App Engine, на которую я не пошел, потому что сомневаюсь что узнал бы что-либо нового.

Advanced Python.
На эту сессию пошел можно сказать от безысходности, т.к. остальные сессии которые проходили паралельно были не очень привлекательными для меня. Да и углубить свои знания Питона никогда не против, темболее речь шла действительно об advanced python. Многие вещи я уже знал, а некоторые поверхностно знал, в результате какие то знания улучшились, чего-то нового услышал, ну и просто посмотрел на умных людей из гугла в живую. Кстати, эта же сессия у меня есть на винте, но более обширная, но и кое чего в ней небыло из того что услышал на GDD.

Gadgets Best practices.
На этой сессии речь конечто же шла про гаджеты iGoogle. На этот раз парочка хитрых парней из местной конторы подсунулись и читали это дело на чешском, решив пропиариться за счет гугла. Начиналось все совсем с основ типа страницы состоят из HTML, JS, CSS, о том что JS может делать запросы на сервер и лучше всего данные получать в формате JSON а не XML (кто бы мог подумать). Дальше показали скелет виджета гугла, рассказали что они много виджетов наделали которыми пользуются во всем мире, и показали как они пользуются Aptana Studio для минификации JS и CSS файлов. Парни решили не подкачать и в “дрес коде”. Один из них видно специально к этому событию по дороге прикупил белую рубашечку, а потому и погладить не удалось. На груди у него вырисовывался прямоугольник :).

Intro to Android. Android Application.
По андроиду было 2 сессии, но я их обобщу в одну, т.к. они об одном и том же, одна продолжает другую, и читали одни и те же люди. Андроид это хорошо. Я так предполагаю что когда мне встанет кокретно нужда подобного коммуникатора,  вероятнее всего придется выбирать iPhone vs. Android, и я предпочту устройство на основе андроид. Да первое устройство T-mobile G1 немножко корявое по дизайну, но 1) это всего лишь первое устройство, и неизвестно сколько и какие они будут к тому моменту когда у меня встанет такой вопрос, 2) по отзывам первых реальных пользователей в реальности он намного приятнее чем на картинках (как, впринципе, с большинством качественных девайсов).
Конкретно по этой сессии сказать сложно что-либо интересное. Довольно специфический вопрос, да и все что рассказывали там это создание приложений, архитектура, история появления этой ОС и т.д. Едиственное что не понравилось так это то, что эта сессия была тоже на чешском. Другие свежеиспеченные фанаты андроида тоже решили пропиариться со своей тоже свежеиспеченной конторой. Не то чтобы я там нчиего не понял, моего уровня хватило чтобы понять что там рассказывали, но хотелось совершенствовать свой английский.
Теперь жду когда я всетаки сяду делать андроид клиент для своего проекта, а ведь в первую очередь надо сделать iPhone клиент. Еще далеко до сравнения размеров аудитории этих двух устройств, хотя первая мутная статистика показывает что аудитория Android более привлекательная для моего проекта.

Теперь немножко в общем о конференции и моих ощущениях. Проходила она в довольно таки большом и современенном отеле, в котором целый этаж предусмотрен для проведения конференций. Что касается организации — 5 баллов, хотя не совсем это уж сложное мероприятие, да и гугл уже имеет большой опыт в этом (Сам Google Developer Day проходил и проходит уже не первый десяток раз в разных городах). Само мероприятие было бесплатным куда входили не только теоретические и практические семинары, но и еда, питье и подарки.

Relax Zone
Основное что приметилось, это созданный в стиле гугла зал который назывался Relax zone, предназначен понятно для чего. Чтобы тупо не описывать словами, вот оно. Чесно признаться мне понравилось. Играет легенький музончик, довольно таки приятная обстановка, каждый занимается тем чем хочет. Попробовать поработать впринципе не удалось, поэтому реальных ощущений нет. Но я думаю что мне бы понравилось вылезть из повседневного рабочего места в офисе, и поработать часок другой в таком зале. Мне кажется что это от большого зала, ничего не давит по бокам, ничего не напрягает, все чем то заняты, из-за наличия музыки ты не слышишь разговоров других людей и т.д.

В заключение хочется сказать что я не получил большую пачку знаний которых небыло, чего я, впринципе, и не ожидал от его посещения, но зато поимел опыт участия в подобных мероприятиях. Не так давно уже посещал onAIR Tour от Adobe.

Мои фотки;
Вот тут коллега уже успел рассказать о том как проходил Google Developer Day в Москве.

I love Google. Stay tuned… 

Идея в том что браузер может загружать только 2 файла (запроса) в один момент времени с одного домена. Это требование спецификации HTML 1.1 которой подчиняются браузеры. Таким образом если мы сможем загружать паралельно больше файлов, мы загрузим всю страницу быстрее. В этом случа используется лазейка в определении “с одного домена”. Таким образом на практике можно распределить картинки, файлы таблиц стилей, JavaScript файлы, статические HTML страницы по разным субдоменам которые будут отличаться от основного домена.

Тем не менее вы должны учитывать что не рекомендуется использовать очень много субдоменов, т.к. каждый субдомен заставляет браузер делать поиск по DNS. Коллеги из Yahoo провели небольшое исследование на эту тему и пришли к выводу что вы должны использовать оптимально 2, но не больше 4 субдоменов. Я, например, в последнее время разделяю статику и динамику на 2 субдомена.

Источники: Circumventing browser connection limits for fun and profit; Optimizing Page Load Time;

За время отсутсвия я немного изменил отношение к своему блогу, и теперь попробую отнестись к нему более внимательно, писать более полезные вещи в надежде что они будут кому-либо полезны или просто интересны. Хотя я и решил по другому отнестись к своему блогу, понятие блогов в моем понимании не изменилось, т.е. я думаю что блоги не должны быть такими как они сейчас есть. О своем понимании блогов я думаю напишу в будещем.

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

Так же произошли некоторые изменения в расположении блога. Раньше он был на домене blog.prudnikov.com, а теперь я перенес его на головной домен http://prudnikov.com/. Поэтому если кто-то оставался подписаным на RSS летну блога, прошу проверить адрес – для блога он должен быть таким http://feeds.feedburner.com/prudnikov. А мой микроблог (Powered by tumblr.com) сейчас находится на http://tumblr.prudnikov.com/ (RSS), перекочевав из домена prudnikov.com. Прошу извинить за такие миграции и обновить адреса в своих RSS ридерах.

А зачем вести и блог и микроблог? Отвечаю. Микроблог на tumblr удобен для постинга мелких вещей типа полезные линки, интересные видеоролики, фотки, цитаты – мне это удобно, особенно расшаривать линки. Я часто там расшариваю линки которые считаю полезными и интересными, поэтому рекомендую подписаться и на микроблог. В блоге же я решил писать полезные вещи по профессиональной теме. Так что подписываемся и на блог

Stay tuned.