Novidades sobre a palestra Python para Série 60

Finalmente o dia chegou. Apresentei a palestra/curso sobre o PyS60, tudo correu bem, a audiência tinha nível *muito* bom, o que torna tudo mais interessante.

Eu tinha solicitado uma extensão de tempo, pois o tema Série 60 é cheio de detalhes e 3 horas é pouco para falar e demonstrar tudo que era preciso, e ainda por cima fazer uma sessão hands-on. Aí um outro palestrante teve problemas familiares e não pôde vir. Limão vira limonada, e o Python para Série 60 ganhou tempo extra na sexta de manhã, uma solução conveniente a todas as partes.

Embora eu acredite que os arquivos das palestras vão ser armazenadas em definitivo no site Python Brasil, disponibilizo a palestra aqui, para quem estiver interessado:

Palestra em formato OpenOffice

Palestra em formato PowerPoint (com probleminhas de conversão)

É engraçado como sempre fica alguma coisa para a última hora. Fora a correria de quarta-feira para instalar o emulador Symbian em todas as máquinas do laboratório (25 ao todo), só tive acesso à webcam hoje de manhã. (Nesta apresentação a webcam ajuda muito pois permite mostrar o que está acontecendo na tela do celular de verdade, tem coisas que o emulador simplesmente não faz.) Precisei conectar a webcam no Linux para descobrir o fabricante e então achar o driver para Windows...

A infra-estrutura, pelo menos para mim, estava muito satisfatória; tive tudo que precisava e os computadores do laboratório são realmente bons (sem o que seria impossível usar emulador Symbian; deve ser o aplicativo mais pesado do universo conhecido.) Não há wireless nos laboratórios, mas não fez muita falta pois os computadores tinham acesso à Internet.

Todo evento tem seu probleminha "du jour", o nosso problema ficou por conta das questões geográficas. A SOCIESC é *enorme* e a PyCon está acontecendo em 2 ambientes distantes entre si (anfiteatro e bloco X). Faltaram algumas plaquinhas ou cartazes de orientação, bem como instruir as guaritas sobre o evento. E também avisar as pessoas de fora que a SOCIESC é mais bem conhecida pelo antigo nome de "Escola Técnica Tupy", isso facilita muito na hora de pedir informações aos locais :)

Incidentalmente há um bom lugar para se comer ao lado da SOCIESC -- a Associação Atlética Tupy. Engraçado que eu mesmo nunca tinha almoçado lá :) apesar do meu pai ter trabalhado 20 anos na Fundição Tupy. Outra boa novidade: vários amigos do Instituto Nokia e até da UFCG baixaram à terrinha da chuva para prestigiar o evento, o que me deixou sobremaneira contente.

É uma pena não poder assistir às demais palestras justamente por estar envolvido no evento, mas compensarei isso depois vendo os vídeos.

No mais, o evento chama a atenção da comunidade de software livre nacional para Joinville/SC -- um dos maiores celeiros de desenvolvedores do Brasil e sede de centenas de empresas de software, que "aparecem" pouco porque têm mais foco em ERP.

Na mão contrária, esperamos despertar a atenção dessa comunidade local para o Python, uma ferramenta incrível inclusive para desenvolvimento de ERP -- visto que diversas empresas estão ainda relutando entre adotar Java e .NET sabendo dos problemas de ambas.

Python para Série 60 na PyCon Brasil

A PyCon Brasil está chegando perto: começa dia 30 deste mês. Vai acontecer em Joinville/SC, na SOCIESC. Ou seja, na região onde moro, na faculdade onde dou aula. Eu iria lá de qualquer jeito para rever os amigos, mas na verdade vou ter participação ativa no evento, ministrando um treinamento de Python para Série 60.

Série 60, ou Series 60 (em inglês), é uma família de celulares smartphones, poderosos, meio grandões, rodando sistema operacional Symbian. A maioria deles é fabricada pela Nokia. O site www.s60.com tem a lista completa. E esta classe de dispositivos roda um port do Python (PyS60).

Não será um treinamento estilo tutorialzinho, onde os participantes fazem uma bolinha pular. Formatei-o "profissional", ou seja, destina-se a quem já sabe Python e quer usar PyS60 a sério. A idéia é passar o máximo possível de informações relevantes, como por exemplo:

* Detalhes técnicos da Série 60 e do sistema operacional Symbian, que afetam o Python

* Revisão e hands-on dos módulos Python específicos para Série 60

* Acesso ao dispositivo via USB e Bluetooth

* Uso do Python dentro do emulador Symbian

* Como tornar o script Python um pacote facilmente instalável pelo usuário

* Como fazer um novo módulo de extensão C/C++ para o PyS60

Graças ao patrocínio do INdT e ao suporte da SOCIESC, o laboratório do curso vai ser muito completo, com computadores rápidos e vários celulares, cabos USB e dongles Bluetooth. Ou seja, vai rolar muito "hands on" e somos limitados apenas pela curiosidade e disposição dos participantes.

O único inconveniente é o horário: 8 da manhã do dia 30/8, uma quinta-feira. Ou seja, na primeiríssima hora do evento. Também é pena que sejam apenas quatro horas ao total.

Penso que tanto o meu curso quanto os demais têm valor muito grande, pois abordam assuntos "da crista da onda", sobre os quais não há livros bons para comprar, nem se encontra documentação organizada no Google. E tudo isso de graça, exceto pela taxinha de inscrição do evento.

E-burocracia com Office

Estou para escrever um artigo sobre isso há tempos, mas como não tenho encontrado um bloco contínuo de tempo para fazer isso do jeito certo, vou publicar uma opinião prévia e coletar os comentários.

Aquilo que convencionamos chamar de Office é um conjunto de quatro softwares que surgiram separadamente: editor de texto ("Word"), planilha eletrônica ("Excel"), banco de dados ("Access") e apresentação em slides ("Powerpoint"). A popularidade do Microsoft Office pespegou ao pacote o apelido genérico de "Office", bem como batizou os aplicativos individuais de forma indelével. Quase ninguém mais chama planilha de planilha eletrônica, mas sim "planilha do Excel", ou "documento Excel". Mesmo quem usa OpenOffice usa esta nomenclatura. É como chamar lâmina de barbear de Gilette (ou o contrário).

O Office teve como público-alvo inicial aquelas pequenas empresas que não podiam arcar com um ERP tradicional, nem com os caros mainframes (e depois com os servidores UNIX). Antes do Office, a alternativa comumente empregada era um ERP tabajara feito em Clipper por algum adolescente. Muitos de nós começaram a carreira sendo esses adolescentes :)

O fato é que muitas empresas caíram vítimas de programas mal-feitos, de programadores que sumiram sem deixar o código-fonte, e de outras mazelas que tornavam os sisteminhas inflexíveis. Tudo isso fez a (injustificada) má fama do Clipper e marginalizou a profissão de desenvolvedor. Isso foi espantando os informatas para outras especialidades. A atual escassez de desenvolvedores no Brasil pode muito bem dever-se a isso.

Sem dúvida o melhor dentre os softwares Office é o Excel. A idéia da planilha eletrônica já é incrível por si só, mas o Excel ergueu essa idéia a outro nível de excelência. Um ex-chefe meu, o Adoniz, era tão entusiasmado a respeito do Excel que costumava dizer que "deviam ganhar o prêmio Nobel".

Já o Access não parece ter alcançado grande sucesso, embora parecesse em 1993 o mais promissor dos componentes Office. Um outro ex-patrão (o Roberto) chegava a prever a morte de outras linguagens de programação, antevendo o Access dominando como ferramenta no lado cliente, e servidores SQL no lado servidor. Ele considerava que o Excel estava sendo usado em excesso, em tarefas que o Access seria mais adequado.

Fazer alguma coisa em Access exige fazer um mínimo de modelagem dos dados e processos. Bem ou mal, os sisteminhas em Clipper exigiam que se pensasse o workflow da empresa. Já uma planilha Excel não exige, a priori, esse tipo de preparação. Qualquer um consegue fazer uma planilha. Talvez ela fique bem modelada, talvez fique mal modelada. Mais provavelmente mal modelada.

E o uso dessas ferramentas, antes coisa de empresa pequena, foi contaminando as empresas/entidades de tamanho maior. Assim como os sistemas em Clipper foram amaldiçoados, os mainframes também o foram, tanto que a IBM balançou forte nos anos 90 por conta dessa demonização da computação centralizada.

E aí começa o drama da e-burocracia.

Como não existe necessidade de pensar, e como o Office é mais ou menos de conhecimento universal, começa a proliferação de documentos Word e Excel, com um e outro Powerpoint no meio (e infelizmente nenhum Access). Assim como governos e empresas grandes faziam no passado, qualquer nova necessidade é "resolvida" pela criação de um novo e-formulário.

O problema do formulário, seja ele de papel ou eletrônico, é que ele transfere ao cliente do birô o trabalho de tabular os dados. Ao invés do financeiro da empresa pegar os seus comprovantes de despesa e digitar, é você quem digita, soma e apresenta a conta no formato normatizado. Muitas vezes, talvez até mesmo no caso do exemplo citado, seja mesmo interessante delegar parte do processo burocrático ao cliente. Mas existem formas e formas de fazer isto.

Se você digitar os comprovantes de despesa num formulário Web, é bom para todo mundo, pois desobriga o birô de contratar um digitador, e os dados podem ser impressos e consolidados pelo birô do jeito que ele quiser. Só é preciso que o birô tenha criado um sistema Web para isto.

Por outro lado, se você é forçado a usar uma planilha, e o que é pior, em muitas vezes precisa *imprimir* o resultado e mandar o *papel* para o birô, o computador serviu como uma máquina de escrever bastante cara. Mas para o birô este foi o método mais "fácil" pois não exigiu pensar o workflow nem construir um sistema. Criou-se a ilusão de ordem e automatismo, mas na verdade não há nenhum dos dois.

Desconsiderando o pior caso onde o birô pede as versões impressas, ainda assim você acaba com uma biblioteca de milhares de arquivos, entre modelos e documentos preenchidos. Para esses documentos serem minimamente úteis, eles precisam estar num sistema de arquivos organizado e com controle de versão, o que quase nunca acontece. E mesmo quando acontece, é ainda praticamente impossível fazer qualquer consolidação ou processamento dos dados contidos dentro dos formulários.

Ainda outro problema, que eu enfrentava e.g. quando era professor: os formulários mudam. Aí eu tinha de transcrever manualmente os dados do e-formulário velho para o novo a cada semestre, embora os dados eles mesmos não mudassem em quase nada.

Ainda assim, reluta-se em criar um sistema específico para o workflow, em parte devido aos traumas de inflexibilidade que citei anteriormente, em parte por preguiça ou incapacidade de se modelar o workflow.

E o aspecto estético também sofre. Muito. Via de regra os tais e-formulários são verdadeiros pesadelos visuais, com uso liberal de negritos, itálicos, vermelhos, todos os tamanhos e tipos de fonte disponíveis no Windows. Coisas impressas em velhas impressoras de mainframe (naqueles formulários zebrados) ou mesmo em máquinas de escrever afiguram-se muito mais claras, legíveis e bonitas. Os universitários redescobrem o LaTeX pelo simples fato que o resultado final sai mais bonito com menos esforço. Meu amigo Rudá diria que "o brega é o sintoma do doente".

A própria preponderância da forma sobre o conteúdo, a proliferação de "modelos oficiais", mesmo quando de bom gosto, é outro sintoma da doença. Primeiro, como eu já citei antes, modelos mudam com o tempo, e isso exige transplante de dados. Segundo, a obrigatoriedade de um modelo sugere que se use um sistema automatizado que imponha aquele modelo.

É a grande vantagem do LaTeX para geração de monografias: a escola exige um determinado formato, mas fornece o pacote LaTeX para aquele formato -- o aluno gera o documento "oficial" com esforço zero. É bem verdade que também existem templates Word, mas os templates LaTeX são caixas-pretas, e o modelo caixa-preta, que separa rigidamente conteúdo de apresentação, acaba provando melhor.

Mas qual é a solução? Obviamente não é o caso de "banir" o Office. As ferramentas Office são incrivelmente úteis, até mesmo na modelagem de sistemas.

O caso talvez seja mais o de "não alimentar os trolls". Ou seja, a direção da entidade tem de ser conscientizada da e-burocracia, para que ela seja combatida de cima para baixo. Tarefa difícil, pois hoje o PowerPoint é a lingua franca da comunicação gerencial...

Aliás, sobre PowerPoint, as pesquisas científicas têm reiteramente mostrado que é a pior forma de didatismo. Isso eu senti na pele no meu último semestre como professor. Achei que estava melhorando a qualidade da minha aula, fazendo slides ao invés de falar livremente e usar o quadro-branco -- e os alunos ficaram 30% mais sonolentos.

Talvez seja ainda outro caso de mau uso. O protótipo da má apresentação PowerPoint é o palestrante ficar "lendo" os slides, de costas para o público, demonstrando desconhecer o tema falado, e gastando metade do tempo descrevendo o slide de índice. (Dica do Osvaldo Santana: nunca inclua um slide de índice ou TOC numa apresentação. Comece no assunto e toque pra frente.)

Nesse estado de coisas, a Web 2.0 é uma agradável moda, pois é um retorno à computação centralizada. Sistemas baseados em Web são muito mais "caretas" em termos de arquitetura do que eram os sistemas cliente/servidor baseados em SQL.

O próprio Office vai se deslocando para direções completamente inéditas, como a edição cooperativa e concomitante de documentos, como a do Google Apps. Muita gente pensa que tais coisas não passem de brinquedos. Eu vejo elas como o resgate da utilidade original do Office -- a prototipagem informal.