Após remover a partição e tentar ligar o computador, dou de cara com o GRUB reclamando que não encontrou nada para conseguir iniciar normalmente, coloquei meu pen-drive e reiniciei a máquina, o Windows 7 oferece no canto inferior esquerdo a opção de reparar o computador, fiquei surpreso que ao acessar o modo de reparo o Windows já notou que havia problema com o boot e me informou que tinha arrumado a situação e que eu podia reiniciar.

Para minha surpresa nada aconteceu e o GRUB estava lá, lindo, leve e solto, me impedindo de utilizar meu computador. Reiniciei novamente o computador com o pen-drive com Windows e dessa vez fui direto na linha de comando, outra surpresa me aguardava, os tradicionais fixboot e fixmbr não se encontravam no diretório aberto no prompt.

Por sorte e com acesso a outro computador, descobri através do Google que os arquivos se encontram em:

X:\windows\system32\bootrec.exe /FixMbr

Executado o comando e pronto, computador funcionando novamente sem GRUB, o susto valeu o post no blog.

Eu não gosto de queimar DVD e por sorte minha faculdade tem parceria com a Microsoft, então após baixar a ISO do Windows 7 eu tive que ir a caça de como fazer um pen-drive “bootável”. Atualmente há diversas alternativas, apesar de gostar de linha de comando, tem coisas que eu prefiro que sejam práticas e rápidas.

Para encurtar o seu tempo procurando por uma solução descomplicada e após visitar mais de dez blogs e fazer diversas buscas, segue a dica.

1. Baixe o aplicativo ABUSB aqui, se por acaso o link estiver quebrado me avise por comentário ou e-mail. Importante: Não sou o autor do aplicativo.
2. De posse de seu CD/DVD ou de seu ISO do Windows, abra o aplicativo.
3. Next, next, next, espere, espere tranquilamente, no caso do Windows 7 por exemplo, tem um arquivo install.wim que possui 2.7 Gb parece que o programa trava no 6% por causa disso, mas depois que ele termina de mandar esse arquivo, vai direto para 90% concluído.
4. Agora é só colocar a sua BIOS para dar boot pelo pen-drive e instalar o Windows.

Foto do aplicativo, para você ver como a interface é simples:

Esse post é resultado de passar mais tempo procurando sobre como colocar o Windows no pen-drive do que esperando ele terminar de instalar.

Atualização: Meu colega de turma me avisou pelo Buzz que a Microsoft liberou uma ferramenta oficial para fazer esse tipo de preparo sem dor de cabeça, segue o link:
http://store.microsoft.com/Help/ISO-Tool

E você, está contando os dias também?

Se esse caminho não possuir espaços, tudo será tranquilo, você provavelmente irá utilizar %1 e receberá o argumento corretamente, mas se o caminho possuir espaços, você vai colar aspas duplas pra passar o parâmetro corretamente e surpresa não vai conseguir concatenar esse caminho com nada.

Depois de muita pesquisa do google fica a dica então: %~1 retira as aspas do caminho facilitando para você fazer algo do tipo:

"%~1\programa.exe"

Lembrando que segundo a fonte isso vale apenas para NT 4 (SP6) pra cima.

Fonte: http://www.robvanderwoude.com/parameters.php

Instalá-lo é muito fácil, se você possui easy_install é só executar:

sudo easy_install winpdb

Se você não tem easy_install, mas tem apt-get:

sudo apt-get install winpdb

Se você não tem nada disso ainda dá pra baixar pelo site[3] e funciona no Windows também, mas eu não testei.

Usarei como exemplo o código criado pelo post anterior, é um projeto bem simples com apenas uma view para atestar o poder do debug.

Lembra da nossa view, ela é simples assim:

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como o winpdb possui a funcionalidade de adicionar breakpoints eu tirei aquele código de debug do pdb senão eles conflitariam entre si.

Abra o winpdb:

A interface dele é bem simples, ficará mais clara quando estivermos executando alguma coisa.

Vá até File->Launch e na janela aberta escolha o manage.py do projeto que vamos depurar, por fim adicione runserver --noreload no comando e então clique em OK para iniciar o servidor.

O seu winpdb deve ficar parecido com a imagem abaixo, além de um terminal que será aberto pelo próprio winpdb.

Antes de continuar qualquer coisa, vá até File->Open Source e na janela aberta escolha o arquivo views.py, adicione um breakpoint na linha a = 2 clicando à direita do número da linha. Tente acessar a URL que executa a view hello e volte ao winpdb, você verá algo como abaixo (a diferença é que eu já andei duas linhas no código):

Essa imagem é bem interessante pois mostra valores das variáveis, um console escondido abaixo do código, o arquivo em que o debugger se encontra, controles de avanço do debug, etc.

Avance com Control->Next até a chamada de soma e entre com Control->Step Into, avance duas linhas e você ficará assim:

As variáveis do escopo local mudaram, o debugger continua no views.py mas agora dentro da função soma, dê Control->Return para ir até antes da função retornar pro escopo de hello.

Com Control->Next vá até antes da linha que executa return response e vamos brincar um pouco com o console que se encontra abaixo do código-fonte:

Como você pode ver na imagem, o comando v (de eval) seguido de uma expressão retorna o valor da expressão, já o comando x (de exec) seguido de uma expressão executa a expressão informada.

Vamos fazer igual ao post anterior e verificar as propriedades de response:

Na imagem acima, executamos um dir na variável response, exibimos seu content com v, alteramos o content com x e por fim com Control->Go visualizamos o resultado no navegador:

Para saber de mais funcionalidades que o winpdb pode te oferecer dê uma olhada no tutorial[4] (bem completo por sinal) que se encontra na própria wiki[5] deles.

[1] – http://blog.danilocabello.com/arquivo/debugando-no-django/
[2] – http://docs.python.org/library/pdb.html
[3] – http://winpdb.org/
[4] – http://winpdb.org/cgi-bin/moin.cgi/WinpdbTutorial
[5] – http://winpdb.org/cgi-bin/moin.cgi/FrontPage

Primeiramente, debugar um projeto em Python[2] e debugar um projeto em Django não tem muita diferença, a coisa toda é muito parecida, você só precisa do pontapé inicial para se virar dali pra frente.

Para aprender como utilizar o pdb[3] (vulgo Python Debugger) crie um novo projeto chamado djdebug, logo em seguida crie um arquivo vazio chamado views.py na própria raiz do projeto, ficando com a seguinte estrutura de arquivos:

djdebug
  - __init__.py
  - manage.py
  - settings.py
  - urls.py
  - views.py

No arquivo views.py cole o seguinte código:

from django.shortcuts import HttpResponse

def soma(a,b):
    arg1 = a
    arg2 = b
    soma = arg1 + arg2
    return soma

def hello(request):
    a = 2
    b = 3
    c = [1,2,3]
    c.pop()
    d = soma(3,4)
    response = HttpResponse("Hello World")
    return response

Como podemos ver o arquivo contém uma função soma, que não faz nada de muito complexo e uma função hello que retorna uma response com o conteúdo "Hello World".

No arquivo urls.py importe a view hello e adicione uma URL para podemos acessá-la:

from views import hello

urlpatterns = patterns('',
    ...
    (r'^hello', hello),
)

Execute o servidor de testes, navegue até http://localhost:8000/hello e verifique que está tudo funcionando:

./manage runserver

Suponha que há um bug em alguma parte da view hello e então adicione o código para possibilitar o debug:

def hello(request):
    a = 2
    import pdb
    pdb.set_trace()
    ...

Apenas para esclarecer, o import pdb importa o Python debugger, já o pdb.set_trace() serve pra colocar um breakpoint no código, há maneiras de se colocar um breakpoint no código sem alterá-lo através do próprio pdb[3].

Execute o servidor de testes mas desta vez adicione o parâmetro necessário para evitar recarregamento automático do código-fonte:

./manage runserver --noreload

Abra novamente a view hello no seu navegador, ela ficará parada e no terminal que você iniciou o servidor o pdb[3] estará parado esperando por comandos:

> /home/.../djdebug/views.py(13)hello()
-> b = 3
(Pdb)

Vamos começar, temos um comando interessante que é o l (de list, lista o código na região do debugger) que lista onde se encontra o debugger:

(Pdb) l
  8
  9  	def hello(request):
 10  	    a = 2
 11  	    import pdb
 12  	    pdb.set_trace()
 13      ->  b = 3
 14  	    c = [1,2,3]
 15  	    c.pop()
 16  	    d = soma(3,4)
 17  	    response = HttpResponse("Hello World")
 18  	    return response

É importante notar que o debugger se encontra no exato momento antes de executar a linha apontada pela seta, isto é, se executarmos p (de print, imprime a expressão passada como argumento) para inspecionarmos a variável b, ela não estará definida:

(Pdb) p a
2
(Pdb) p b
*** NameError: NameError("name 'b' is not defined",)

Vamos para próxima linha com n (de next, segue para a próxima linha):

(Pdb) n
> /home/.../djdebug/views.py(14)hello()
-> c = [1,2,3]
(Pdb) p b
3

Agora sim b já possui valor, vamos avançar até a chamada da função somar:

(Pdb) n
> /home/.../djdebug/views.py(15)hello()
-> c.pop()
(Pdb) <enter>
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

A partir do primeiro n, enter executará n novamente. Como nós não sabemos se o problema da view hello é a função somar, vamos entrar na função somar com s (de step into, entra na função, ou seja, passo a dentro) e verificar se está tudo certo:

(Pdb) s
--Call--
> /home/.../djdebug/views.py(3)soma()
-> def soma(a,b):
(Pdb) l
  1  	  from django.shortcuts import HttpResponse
  2
  3     -> def soma(a,b):
  4  	      arg1 = a
  5  	      arg2 = b
  6  	      soma = arg1 + arg2
  7  	      return soma
  8
  9  	  def hello(request):
 10  	      a = 2
 11  	      import pdb

Como podemos ver o debugger se encontra na entrada da função soma, damos uma “olhada por cima” e saímos da função com up (de up, sobe uma chamada na pilha):

> /home/.../djdebug/views.py(4)soma()
-> arg1 = a
(Pdb) n
> /home/.../djdebug/views.py(5)soma()
-> arg2 = b
(Pdb) n
> /home/.../djdebug/views.py(6)soma()
-> soma = arg1 + arg2
(Pdb) u
> /home/.../djdebug/views.py(16)hello()
-> d = soma(3,4)

Como podemos ver, voltamos a view hello, vamos avançar até antes de retornar a resposta da requisição e atestar umas coisinhas:

(Pdb) n
> /home/.../djdebug/views.py(17)hello()
-> response = HttpResponse("Hello World")
(Pdb) n
> /home/.../djdebug/views.py(18)hello()
-> return response
(Pdb) dir(response)
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_charset', '_container', '_convert_to_ascii', '_get_content', '_headers', '_is_string', '_set_content', 'close', 'content', 'cookies', 'delete_cookie', 'flush', 'get', 'has_header', 'items', 'next', 'set_cookie', 'status_code', 'tell', 'write']
(Pdb) response.content
'Hello World'
(Pdb) response.content = 'Django debugado'
(Pdb) c

Como podemos verificar, o pdb[3] fornece um shell do Python[2] você pode executar dir, verificar valores de variáveis e até mudar conteúdo de variáveis (poder e perigo andando juntos), por fim executamos c (de continue, para continuar a execução), veja o resultado no seu navegador, a mensagem "Hello World" foi trocada por "Django debugado".

Recomendo a leitura do paper “Debugging in Python”[4] para mais alguns detalhes do pdb[3]. É muito interessante saber “brincar” com o shell do Python e do Django, com essas ferramentas fica mais fácil rastrear o chato do bug.

[1] - http://www.djangoproject.com/
[2] – http://www.python.org/
[3] – http://docs.python.org/library/pdb.html
[4] – http://www.ferg.org/papers/debugging_in_python.html

A aplicação é muito completa, possui testes e exige o mínimo de conhecimento em Django que é saber criar templates. Ao baixar a aplicação eu pensei que iria ter que adaptar um monte de coisa para se encaixar na minha aplicação, que nada, a aplicação está no limite da plugabilidade que o Django investe.

Give a try.

[1] – http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth
[2] – http://bitbucket.org/ubernostrum/django-registration/

Dê uma olhada na documentação[1], que é bem completa e no exemplo abaixo, para ver o quão prático é utilizar este módulo.

def fatorial(n):
    resultado = 1
    while n > 0:
        resultado = n*resultado
        n -= 1
    return resultado

if __name__ == '__main__':
    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option('-a', '--arquivo',
                      dest='arquivo', help='arquivo com os fatoriais desejados')
    parser.add_option('-v', '--valor', type='int',
                      dest='valor', help='valor a ser calculado')
    (options, args) = parser.parse_args()

    if options.valor and options.arquivo:
        parser.error("opcoes -v e -a sao mutualmente exclusivas")
    elif options.valor:
        print "fatorial(%s) = %s" % (options.valor, fatorial(options.valor))
    elif options.arquivo:
        for linha in open(options.arquivo):
            linha = int(linha)
            print "fatorial(%s) = %s" % (linha, fatorial(linha))
    else:
        parser.error("nenhuma opcao foi escolhida, execute com -h para ajuda")

[1] – http://docs.python.org/library/optparse.html

Acessando-se o site do programa, o acesso ao download é simples, embora o arquivo baixado não seja um instalador, sendo o aplicativo pronto para o uso. Sem uma instalação, a criação de atalhos para o uso deve ser feita manualmente, o que dificulta o uso para os mais leigos.

As primeiras informações que se tem ao iniciar o programa nos dizem a respeito de tutoriais – altamente recomendados, já que o programa dá a impressão de ter mais opções do que se saiba mexer.  Iniciando-se o primeiro tutorial, temos os passos básicos da aplicação, sendo exibidos de forma clara, e as opções não usadas no momento não são acessíveis, facilitando a aprendizagem.

Os tutoriais são simples e bem informativos.  Seguindo-se passo a passo por uma série de ferramentas,  não há muito onde errar.

Embora algumas orientações possam ser mal implementadas, de forma que a opção selecionada não é a requerida. Neste caso, o tutorial pára, mesmo que você saiba que fez o que é certo.

Neste caso, a saída parece “forçar” o tutorial a continuar, clicando-se no Next na parte superior da tela (mesmo este aparentando não ser acessível). Isso se apresenta com pouca freqüência, nos quatro tutoriais disponíveis.

Cumprindo os tutoriais, tentamos caminhar por conta própria dentro do programa, embora o excesso de informações disponível ainda seja um pouco confuso. Mesmo assim, com certa facilidade as animações podem ser montadas, embora se encontre limitações, sendo essas do próprio programa ou porque não se sabe como resolvê-las – não há um arquivo de ajuda, só animações pré-prontas, onde se poderia verificar a existência de novas funcionalidades.

Iguais quanto ao uso, diferentes quanto a forma

Dentro do próprio ramo computacional, as interfaces estão presentes em áreas completamente distintas. Um circuito integrado deve ser visto como uma caixa preta pelo resto do sistema, que age nesta abordagem como o usuário ou cliente dos serviços oferecidos por tal módulo. Saindo do baixo para o alto nível encontramos as telas touch e hologramas fisicamente manuseáveis, que são duas tecnologias até a pouco tidas como futuristas mas que atualmente tornaram-se quotidianas.

Mais incrível ainda é notar que tais interfaces inovadoras – sejam programas ou físicas – não estão mais confinadas ao computador pessoal (desktop ou laptop), o que obrigava a forma de apresentação da interface estar adaptada ao equipamento. Hoje a situação se inverteu. Primeiro temos a definição do tipo de interface adequada para uma dada aplicação e daí os hardwares são desenvolvidos de forma a oferecer recurso computacional para aquela demanda. Tal tratamento do objetivo inovador fornece recursos para aquela que se mostra a área mais carente em termos tecnológicos: a acessibilidade. Indubitavelmente a sociedade tem sido omissa – e não raras vezes preconceituosa – com o tratamento daqueles que não possuem as mesmas capacidades da maioria dos homens.

Interessante saber que é justamente no atendimento dessas minorias que o design de interfaces se mostra mais promissor. A capacidade da máquina de interpretação de gestos, fala e escrita em braile fornece um mundo de informação e interatividade para tais usuários. Na verdade, os transforma em usuários, já desde muito tempo eles não tecnologicamente inclusos.

Por Plínio Sandes dos Santos