Pois bem. Após quase três anos de serviços prestados e vários projetos desenvolvidos ao longo desse tempo, chegou a hora de me despedir de meu principal cliente, a GSP, uma das maiores loteadoras do Brasil. Um abraço aos amigos que ficaram, e aos que já não estão mais lá. Foi um prazer!

A principal tecnologia com que eu trabalhei nesse período foi Java, com uma pitada de Python aqui e ali. Mas, como irremediável curioso que sou, não pude deixar de brincar com outras coisas também.

Agora, no entanto, é hora de pensar no futuro. Se você precisa de um profissional com o meu perfil, ou conhece alguma empresa que precise, entre em contato comigo ou passe o link deste post adiante. Busco trabalhar com empresas ou pessoas que:

1. Tenham projetos não convencionais;
2. Tratem a tecnologia com a devida atenção;
3. Contem com equipes multi-disciplinares, com gente que ama o que faz e que busca melhorar a todo instante.

Apesar de morar no interior de São Paulo, estou aberto a propostas de outras cidades, de preferência em tempo integral.

Valeu!

Felizmente, Django é um dos poucos frameworks web que tornam este um problema simples de solucionar.

Como resolvemos este problema

Um jeito simples é criar um módulo settings.py separado para a versão “mobile”. Isso nos permite rodar dois sites diferentes reusando a mesma base de código. Além disso, cada versão pode ter seu próprio diretório de templates, configurações de URL, etc.

Vamos fazer isso. No diretório-raíz do projeto, crie um arquivo m_settings.py com o seguinte conteúdo:

# Arquivo: myproject/m_settings.py
 
"""Configurações para a versão "mobile" do website.
"""
 
# Carrega as configurações padrão
from settings import *
 
# Domínio "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Usado em outras partes do código para determinar qual versão está rodando
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs para a versão mobile
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates para a versão mobile
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Outras configurações...

O fato de os dois sites compartilharem a mesma base de código não significa que eles devem ter as mesmas configurações de URL. Aliás, o normal é que versões próprias para dispositivos móveis sejam mais simples, com uma quantidade reduzida de mapeamentos de URLs.

Para definir as configurações de URL da versão mobile, crie um arquivo m_urls.py com o seguinte conteúdo:

# Arquivo: myproject/m_urls.py
 
"""Mapeamentos de URL para a versão "mobile".
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# URLs
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Apps internas
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Outras configurações...
)

Perceba que, neste exemplo em particular, a app Admin não é acessível através da versão mobile. Isso apenas serve para mostrar que temos total liberdade para estruturar ambas as versões de diferentes formas, sem muitas dificuldades.

Desenvolvendo

Você certamente já sabe como rodar o servidor de desenvolvimento para a versão padrão. O que a maioria dos desenvolvedores desconhece, entretanto, é que é possível escolher qual a porta e/ou módulo settings.py deve ser usado pelo script, o que nos permite rodar um servidor para cada versão do nosso site:

# Terminal 1: versão padrão
$ python manage.py runserver 8000
 
# Terminal 2: versão mobile
$ python manage.py runserver --settings=m_settings 8001

Pronto, agora é só continuar com o desenvolvimento da forma que você já está acostumado.

Testando

Você provavelmente notou que temos duas configurações que podem ser usadas para determinar qual versão do site está rodando, DEFAULT_VERSION e MOBILE_VERSION.

Por isso, é só uma questão de checar tais configurações quando for necessário fazer coisas diferentes em cada uma das versões do site. Isso é particularmente útil quando você tem uma app usada em ambas as versões e quer criar testes para cada uma das versões:

# Arquivo: myproject/myapp/tests/__init__.py
 
"""Testes para MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Testa a versão padrão
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Testa a versão mobile
    from mobile_models_tests import *
    from mobile_navigation_tests import *

Você pode rodar os testes para cada versão de uma forma semelhante a que fizemos com o comando runserver:

# Versão padrão
$ python manage.py test [appname...]
 
# Versão mobile
$ python manage.py test --settings=m_settings [appname...]

Colocando em produção

Apesar do que você possa achar, esta é a parte fácil.

Uma vez que a forma recomendada de colocar Django em produção é com Apache e mod_wsgi, é possível que você já tenha um arquivo WSGI parecido com o seguinte:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Tudo que precisamos fazer é configurar um outro sub-domínio WSGI no nosso servidor (ex: m.mywebsite.com) que referencia o seguinte arquivo de configurações WSGI:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # Esta linha
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

A única diferença entre esses dois arquivos WSGI é que cada um aponta para um módulo settings.py diferente. E não, você não precisa ter uma cópia do site para cada versão, afinal estamos usando a mesma base de código para ambas as versões, lembra?

Minimizando o tráfego

Por incrível que pareça, nem todo mundo dispõe de conexões ultra-rápidas. Por isso, é muito importante que você mantenha seus sites tão leves quanto possível.

Existem vários projetos open source que podem ajudar nessa parte. Um deles é o django-compress, uma app Django que fornece um sistema automatizado para compressão de arquivos CSS e JavaScript.

Aliás, não importa se seus websites são para dispositivos móveis ou não; você deve sempre tentar minimizar o tráfego.

O que falta?

Ainda temos um pequeno problema: quando alguém visita a versão padrão do site através de um dispositivo móvel, ou vice-versa, eles não são redirecionados para a versão apropriada. Mas isso é assunto para um próximo artigo!

Fortunately, Django is one of the few web frameworks that makes this an easy problem to solve.

How we solved it

A simple way is to create a separate settings module for the mobile version. Doing this, we’re able to run two different webapps while reusing the existing codebase. Also, each version can have its own template directory, URL root configuration, etc.

Let’s do this. In the project root directory, create a file m_settings.py with the following content:

# File: myproject/m_settings.py
 
"""Django settings for the mobile-specific website.
"""
 
# Load the default settings
from settings import *
 
# Domain "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Used elsewhere to determine which version is running
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs for the mobile version
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates for the mobile version
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Other settings...

These two webapps share the same codebase, but that doesn’t mean they have to use the same URL root configuration. In fact, websites suitable for mobile devices are usually simpler, with fewer URL mappings.

To define separate URL root configuration for the mobile version, create a file m_urls.py with the following content:

# File: myproject/m_urls.py
 
"""Mobile-specific URL definition.
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
# Error page handlers
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# Root URL patterns
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Internal apps
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Other settings...
)

Note that, in this particular example, the Admin app isn’t accessible from mobile version. This just shows that we can structure each webapp differently without too much trouble.

Developing

You already know how to run the development server for the default version. Most people don’t know, however, that it’s possible to choose a different port number and settings module, which allows us to launch one development server for each webapp version:

# Terminal window 1: default version
$ python manage.py runserver 8000
 
# Terminal window 2: mobile version
$ python manage.py runserver --settings=m_settings 8001

Just develop your stuff and see the results in both versions right away. Easy peasy.

Testing

You probably noticed that we have two settings that can be used to identify what webapp version is being run, DEFAULT_VERSION and MOBILE_VERSION.

So it’s just a matter of checking those settings when you need to do different things in each webapp version. This is particularly useful when you use an app in both versions and want to create separate tests for each version:

# File: myproject/myapp/tests/__init__.py
 
"""Unit tests module for MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Tests the default version
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Tests the mobile version
    from mobile_models_tests import *
    from mobile_navigation_tests import *

We can run the tests for each version in a similar way we did before with the runserver command:

# Default version
$ python manage.py test [appname...]
 
# Mobile version
$ python manage.py test --settings=m_settings [appname...]

Deploying

Despite what you may think, this is the easy part.

Since deploying Django with Apache and mod_wsgi is the recommended way to get Django into production, it’s likely that you already have a WSGI file like this:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

All we need to do is configure another WSGI-enabled subdomain on our server, e.g. m.mywebsite.com, that refers to another WSGI file like this one:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # This line
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

The only difference between these two WSGI files is that each one points to a different settings module. And no, you don’t need to have a separate copy for each version. We are using the same codebase for both versions, remember?

Minimizing the traffic

Amazingly, not everyone has access ultra-fast internet connections on their devices, so it’s very important to keep your sites as lightweight as possible.

There are several open source projects that try to address this problem. One of them is django-compress, a Django app that provides an automated system for compressing CSS and JavaScript files.

In fact, doesn’t matter if your websites target mobile devices or not; you should always try to minimize the amount of traffic.

What’s left?

There’s one small problem though: when someone visit the regular website from a mobile device, or vice-versa, they are not redirected to the appropriate version. But this is a topic for another article!

Sim, eu disse que o Django 1.2 traz incluso um framework de “mensagens”. Bom, né? Django realmente precisava vir acompanhado de uma app para resolver essa questão. Isso não significa, no entanto, que Django-Flash será descontinuado ou abandonado.

Então, se você usa Django-Flash em seus projetos, não se preocupe! Nada mudará. Django-Flash já é compatível com Django 1.2, e nós ocontinuaremos a mantê-lo por algumas razões.

A primeira delas é que nos importamos com quem usa nosso software. Nós não quebraremos seus projetos se você decidir fazer o upgrade para uma versão mais recente do Django – ou se decidir continuar usando uma versão anterior.

A outra é a liberdade de escolha. Você sabe, não existe uma única forma de se resolver todos os problemas. As pessoas devem ser livres para escolher a ferramenta apropriada a uma determinada situação.

Por exemplo, baseado nas minhas primeiras impressões, existem algumas coisas que eu realmente não gostei no novo framework de “mensagens”:

1. Ele é verboso mesmo nos casos de uso mais simples
2. Ele associa mensagens a números de prioridade, encorajando os usuários a usá-lo como um framework de logging/debugging. Quero dizer, um framework de “mensagens” não é um framework de logging/debugging, certo?

Mas essa é apenas a minha opinião. Talvez seja isso que faz do open source algo tão formidável!

Yes, I said Django 1.2 comes with built-in user “messages” framework. Great, isn’t it? Django really needed a built-in contrib app to solve this problem. This doesn’t mean, however, that Django-Flash will be discontinued or abandoned.

So, if you use Django-Flash in your projects, don’t worry! Nothing will change. Django-Flash is already compatible with Django 1.2, and we’ll keep improving Django-Flash for a number of reasons.

First of all, we care about the people who use our software. We won’t break your stuff if you decide to upgrade to a newer version of Django – or if you decide to keep using the previous version.

Also, freedom of choice is a good thing. You know, there’s not only one true way to solve every problem. People should be free to choose whatever tool they think is right in a given situation.

For example, based on my first impressions, there are a couple of things I didn’t like at all about the new user “messages” framework:

1. It’s verbose even for the simple cases
2. It ties messages to priority numbers, encouraging you to use it like a logging/debugging framework. I mean, a user “messages” framework is not a logging/debugging framework, right?

But that’s just my opinion. I guess this is what makes open source so great!

No fim das contas eu acabei com um Nokia 5800 XpressMusic, um smartphone relativamente barato e com features interessantes. Especificamente, o fato de poder rodar aplicações Python nesse aparelho foi um fator decisivo!

Mas, o que exatamente podemos fazer com Python para S60? Eu decidi implementar uma aplicação não trivial para ver exatamente o que pode ser feito com ele. A aplicação em questão é um controle remoto Bluetooth chamado Pytriloquist. (veja também screenshots e vídeo de demonstração.)

O que é Bom

Independência de Plataforma. A SDK para S60 só roda em Windows (que novidade). Isso obviamente é ruim para quem costuma usar outros sistemas operacionais. Felizmente, você não precisa de uma SDK gigante para desenvolver e distribuir aplicações para S60 se você escrevê-las em Python; tudo o que você precisa é do Python para S60, um editor de texto e um aparelho para testes.

Linguagem e Biblioteca Padrão. Python é uma linguagem excelente: compacta, bonita, poderosa e tem uma biblioteca padrão sensacional. A boa notícia é que a maioria dos módulos rodam bem no S60. Por exemplo, é possível até localizar suas aplicações usando o módulo gettext!

O que é Ruim

Trabalho em Andamento. Python para S60, até onde me consta, é um trabalho em andamento. Isso significa que a linguagem em si funciona bem, mas você pode dar falta de certos módulos ou encontrar bugs na biblioteca padrão. Por exemplo, enquanto eu escrevia o código Bluetooth para minha applicação, eu dei de cara com um bug muito chato onde você só pode chamar btsocket.bt_discovert() uma vez!

Código Multi-Módulos. Se você está testando sua aplicação com Python ScriptShell, tudo irá funcionar de cara desde que você mantenha todo o código dentro de um único — e enorme — módulo. Se você quebrar seu código em vários módulos (ou pior, pacotes), você não poderá ter módulos importando uns aos outros, a menos que você ajuste o PYTHON_PATH de acordo.

Documentação Incompleta e Desatualizada. Existem alguns PDFs e algumas documentações de API disponíveis, mas elas estão incompletas e desatualizadas, o que é ruim quando se trata de uma linguagem dinâmica; nós não temos um compilador para nos dizer o que há de errado com nosso código. Esse é o motivo pelo qual desenvolvedores Python são tão cuidadosos com documentação pra começo de conversa.

O que é Feio

Acesso Limitado a Recursos Nativos. Especialmente em se tratando do sistema de UI nativo: você não pode mudar o texto das duas soft keys padrão, nem adicionar soft keys, nem adicionar mais que duas abas, nem ter um Listbox vazio, nem um monte de outras coisas. Você pode escrever UIs simples sem muito esforço, isso é verdade, mas essas deficiências todas tornam Python para S60 simplesmente inutilizável em projetos mais complexos.

Inatividade do Projeto. O projeto parece estar em modo “stand by”. Novos bug reports são enviados de tempos em tempos, mas nenhum bug foi fechado há mais de seis meses.

Conclusão

Espero que as coisas mudem para melhor após o último anúncio feito pela Fundação Symbian, mas, enquanto isso, se você pretende criar aplicações sérias para S60, o faça em C++.

I ended up with a Nokia 5800 XpressMusic, a relatively cheap smartphone with a nice feature set. Specifically, what took me for granted was the ability to run Python applications in it!

But what exactly can we do with Python for S60? Well, to answer that question, I decided to implement a non-trivial app to see exactly what it has to offer. The app in question is a Bluetooth remote control called Pytriloquist. (see also screenshots and a video demonstration.)

What’s Good

Platform Independence. The S60 SDK is for Windows only (what a surprise). This is obviously bad for those who use other operating systems. Fortunately, you don’t need a massive SDK to develop and deploy S60 apps if you write them in Python; all you need is Python for S60, a text editor, and a device for testing.

Language and Standard Library. Python is a terrific language: compact, beautiful, powerful, and have an amazing standard library. The good news is that the most popular modules work great on S60. For example, it’s even possible to localize your apps using the gettext module!

What’s Bad

Work in Progress. Python for S60, as long as I know, is a work in progress. This means the language itself works fine, but you can expect missing modules or some bugs in standard library. For example, when writing the Bluetooth client code for my app, I encountered a very annoying bug in which you can only call btsocket.bt_discover() once!

Multi-Module Code. If you are testing your app with Python ScriptShell, everything will work out-of-the-box as long as keep your whole code inside a single massive module. If you break up your code into several modules (or worse, packages) you won’t be able to have modules importing each other unless you adjust the PYTHON_PATH accordingly.

Incomplete and Outdated Documentation. There are some PDFs and API documentation pages available, but they are incomplete and outdated, and this is a bad thing when it comes to dynamic languages; we don’t have a compiler to tell us what’s wrong with our code. This is why Python programmers are so careful about documentation in the first place.

What’s Ugly

Limited Access to Native Features. Specially regarding the native UI system: you cannot change the label of the two standard soft keys, nor add other soft keys, nor add more than two tabs in a tabbed UI, nor have an empty Listbox, nor lots of other things. You can write simple UIs without much effort, that’s true, but those shortcomings just make Python for S60 unusable for more complex projects.

Project Inactivity. The project appears to be on hold. New bug reports are submitted every now and then, but no bugs are closed for six months.

Conclusion

Let’s hope things change for the better after the last announcement made by the Symbian Foundation, but in the meantime, if you pretend to create serious apps for S60, do it in C++.

A lot of things happened during those 48 hous. The Ticketmaster staff had trouble to keep the website on-line, and due to the enormous load, it’s possible that only a few thousands of people had enough luck to buy their tickets via the website.

Also, Ticketmaster admits that the notification e-mails may not reach, which means we cannot rely on those to follow our orders. In fact, they recomend that customers check their orders manually once a day. Oh boy…

I hate to do certain tasks manually, specially the ones that can be automated. So, in this post I’ll show you a very simple Python-based command-line tool that displays the status of your Ticketmaster¹ orders on the screen², using a technique known as web scraping.

The code, which is also on Github, can be seen below:

#!/usr/bin/env python
#-*- coding:utf-8 -*-
 
import urllib
import urllib2
import pynotify
 
 
_BASE_URL  = 'https://ticketing.ticketmaster.com.br'
_LOGIN_URI = '%s/shwLogin.cfm' % _BASE_URL
_ORDER_URI = '%s/shwCompraDetalhe.cfm?pedidoID=%%s' % _BASE_URL
 
_ORDERS_LINK = '<a href="%s">More...</a>' % _LOGIN_URI
 
_PRIORITY_LOW      = pynotify.URGENCY_LOW
_PRIORITY_NORMAL   = pynotify.URGENCY_NORMAL
_PRIORITY_CRITICAL = pynotify.URGENCY_CRITICAL
 
_NOTIFICATION_TITLE = 'Ticketmaster Order %s'
_STATUS_CODES = {
    'Livre'      : ('Not processed yet'      , _PRIORITY_LOW),
    'StdReserva' : ('Reserving your tickets' , _PRIORITY_NORMAL),
    'StdCobranca': ('Charging your tickets'  , _PRIORITY_NORMAL),
    'VendaOk'    : ('Billed'                 , _PRIORITY_CRITICAL),
    'Recusada'   : ('Rejected'               , _PRIORITY_CRITICAL)
}
 
 
def initialize_notification_system(app_title):
    if not pynotify.init(app_title):
        import sys
        sys.exit(1)
 
 
def display_message(title, message, priority=_PRIORITY_CRITICAL):
    message = pynotify.Notification(title, message)
    message.set_urgency(priority)
    message.show()
 
 
def check_orders(email, password, order_ids):
    try:
        opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
        login(opener, email, password)
        try:
            for order_id in order_ids:
                show_order_status(opener, order_id)
        except:
            title = _NOTIFICATION_TITLE % order_id
            display_message(title, 'Cannot check status')
    except:
        display_message('Ticketmaster', 'Login failed')
 
 
def login(opener, email, password):
    params = urllib.urlencode({'email': email, 'senha': password})
    response = opener.open('%s?tentaLogin=1' % _LOGIN_URI, params)
 
    # Invalid credentials check
    if response.read().find('senha incorreta') >= 0:
        raise Exception
 
 
def show_order_status(opener, order_id):
    response = opener.open(_ORDER_URI % order_id)
    content = response.read()
 
    # Search for the order status codes
    for key, value in _STATUS_CODES.items():
        if content.find(key) >= 0:
            title = _NOTIFICATION_TITLE % order_id
            message = '%s. %s' % (value[0], _ORDERS_LINK)
            display_message(title, message, value[1])
            break
    else:
        display_message(_NOTIFICATION_TITLE % order_id, 'Status not found')
 
 
def main():
    initialize_notification_system("Ticketmaster Order Status")
 
    import optparse
    p = optparse.OptionParser()
 
    # Required command line options
    p.add_option('--email'    , '-e',
        help='E-mail address used in your Ticketmaster credentials.')
    p.add_option('--password' , '-p',
        help='Password used in your Ticketmaster credentials.')
    p.add_option('--order-ids', '-o',
        help='Order IDs to be checked, separated by collons.')
 
    options = p.parse_args()[0]
    if not options.email or not options.password or not options.order_ids:
        p.print_help()
    else:
        order_ids = map(lambda s: s.strip(), options.order_ids.split(','))
        check_orders(options.email, options.password, order_ids)
 
 
if __name__ == '__main__':
    main()

The reason I’ve used web scrapping is because the brazilian Ticketmaster doesn’t seem to provide an API the way Flickr does, for example. Nevertheless, the code is quite simple.

As you can see, it first fires a HTTP request to the login URI in order to validate the user credentials. If the authentication succeeds, our cookie-aware opener will get the session cookies from the server and use them on the following requests, which extract the current order status for each order ID.

Now, let’s give it a spin:

Current order status

Finally, add a new entry to your crontab to run the script whenever you want (e.g. every 10 minutes):

*/10 * * * * python ticketmaster_order_status.py --email=your@email.com --password=passwd --order-ids=1234

Good luck and let there be rock!

Muita coisa aconteceu nessas 48 horas. O pessoal da Ticketmaster teve trabalho para manter o website no ar e, em razão da enorme carga, é possível que apenas poucos milhares de fãs tenham sido sortudos o bastante para comprar seus ingressos através da internet.

Além disso, a Ticketmaster admite que os e-mails de notificação podem não ser enviados, o que significa que não podemos depender deles para acompanhar nossos pedidos. Na verdade, eles até recomendam que seus clientes chequem os pedidos diariamente, na mão. Caramba…

Eu odeio fazer certas tarefas manualmente, especialmente as que podem ser automatizadas. Então, neste post eu mostrarei uma ferramenta escrita em Python que mostra a situação dos seus pedidos Ticketmaster na tela¹, usando uma técnica conhecida como web scraping.

O código, que também está disponível no Github, pode ser visto abaixo:

#!/usr/bin/env python
#-*- coding:utf-8 -*-
 
import urllib
import urllib2
import pynotify
 
 
_BASE_URL  = 'https://ticketing.ticketmaster.com.br'
_LOGIN_URI = '%s/shwLogin.cfm' % _BASE_URL
_ORDER_URI = '%s/shwCompraDetalhe.cfm?pedidoID=%%s' % _BASE_URL
 
_ORDERS_LINK = '<a href="%s">More...</a>' % _LOGIN_URI
 
_PRIORITY_LOW      = pynotify.URGENCY_LOW
_PRIORITY_NORMAL   = pynotify.URGENCY_NORMAL
_PRIORITY_CRITICAL = pynotify.URGENCY_CRITICAL
 
_NOTIFICATION_TITLE = 'Ticketmaster Order %s'
_STATUS_CODES = {
    'Livre'      : ('Not processed yet'      , _PRIORITY_LOW),
    'StdReserva' : ('Reserving your tickets' , _PRIORITY_NORMAL),
    'StdCobranca': ('Charging your tickets'  , _PRIORITY_NORMAL),
    'VendaOk'    : ('Billed'                 , _PRIORITY_CRITICAL),
    'Recusada'   : ('Rejected'               , _PRIORITY_CRITICAL)
}
 
 
def initialize_notification_system(app_title):
    if not pynotify.init(app_title):
        import sys
        sys.exit(1)
 
 
def display_message(title, message, priority=_PRIORITY_CRITICAL):
    message = pynotify.Notification(title, message)
    message.set_urgency(priority)
    message.show()
 
 
def check_orders(email, password, order_ids):
    try:
        opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
        login(opener, email, password)
        try:
            for order_id in order_ids:
                show_order_status(opener, order_id)
        except:
            title = _NOTIFICATION_TITLE % order_id
            display_message(title, 'Cannot check status')
    except:
        display_message('Ticketmaster', 'Login failed')
 
 
def login(opener, email, password):
    params = urllib.urlencode({'email': email, 'senha': password})
    response = opener.open('%s?tentaLogin=1' % _LOGIN_URI, params)
 
    # Invalid credentials check
    if response.read().find('senha incorreta') >= 0:
        raise Exception
 
 
def show_order_status(opener, order_id):
    response = opener.open(_ORDER_URI % order_id)
    content = response.read()
 
    # Search for the order status codes
    for key, value in _STATUS_CODES.items():
        if content.find(key) >= 0:
            title = _NOTIFICATION_TITLE % order_id
            message = '%s. %s' % (value[0], _ORDERS_LINK)
            display_message(title, message, value[1])
            break
    else:
        display_message(_NOTIFICATION_TITLE % order_id, 'Status not found')
 
 
def main():
    initialize_notification_system("Ticketmaster Order Status")
 
    import optparse
    p = optparse.OptionParser()
 
    # Required command line options
    p.add_option('--email'    , '-e', \
        help='E-mail address used in your Ticketmaster credentials.')
    p.add_option('--password' , '-p', \
        help='Password used in your Ticketmaster credentials.')
    p.add_option('--order-ids', '-o', \
        help='Order IDs to be checked, separated by collons.')
 
    options = p.parse_args()[0]
    if not options.email or not options.password or not options.order_ids:
        p.print_help()
    else:
        order_ids = map(lambda s: s.strip(), options.order_ids.split(','))
        check_orders(options.email, options.password, order_ids)
 
 
if __name__ == '__main__':
    main()

A razão pela qual eu optei por web scrapping é porque a Ticketmaster não fornece uma API da mesma forma que o Flickr fornece, por exemplo. Ainda assim, o código é bastante simples.

Como você pode ver, ele primeiro envia uma requisição HTTP para a URI de login com o objetivo de validar as credenciais do usuário. Se a autenticação for bem sucedida, nosso opener receberá os cookies de sessão do servidor e os usará nas requisições seguintes, que buscam a situação de cada um dos pedidos informados.

Rodando o script agora:

Current order status

Finalmente, inclua uma nova entrada no seu crontab para que o script rode sempre que necessário (ex: a cada 10 minutos):

*/10 * * * * python ticketmaster_order_status.py --email=seu@email.com --password=senha --order-ids=1234

Boa sorte e let there be rock!

Infelizmente, coisas assim estão acontecendo por aqui com uma certa frequência. Por isso, resolvi escrever o script abaixo, cuja função é mostrar uma mensagem de notificação sempre que algum dos sites pré-determinados saiam do ar: ¹

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import httplib
import pynotify
 
def display_message(title, message):
    if pynotify.init('Website Status'):
        n = pynotify.Notification(title, message)
        n.show()
 
def check_status(*websites, **kwargs):
    timeout = kwargs.get('timeout', 5)
    for website in websites:
        conn = httplib.HTTPConnection(website, timeout=timeout)
        try:
            conn.request('GET', '/')
            response = conn.getresponse()
            if response.status != 200:
                raise Error()
        except:
           display_message(website, 'Web site could not be reached!')
 
if __name__ == '__main__':
    check_status('www.awebsite.com', 'www.anotherwebsite.com')

O script em funcionamento:

Exemplo de notificação

Para completar, se você deseja que esse script seja executado uma vez a cada 5 minutos, basta inserir a linha abaixo no seu crontab:

*/5 * * * * /path/to/script.py

Pronto! Agora, se o seu serviço de hosting continuar deixando a desejar, talvez a melhor solução seja mesmo mudar para outro lugar…