EPx.dict

N810 é o que há

2008-06-15T11:43:00.002-03:00

Tive a oportunidade de utilizar o N810 por alguns dias, deviido ao projeto em que estou trabalhnando. Depois de usar o N800 por bom tempo, posso dizer que o N810 é muito melhor. Se alguém pretende comprar um Tablet, recomendo fortemente o 810, pelos seguintes motivos:

1. Teclado. O mini teclado físico do 810 não é a oitava maravilha, mas é infinitamente melhor que teclado virtual. O grande problema do teclado virtual e que ocupa espaço precioso na tela. O reconhecimento de escrita tem o mesmo defeito. O N800 deveria ter seguido a filosofia Palm de deixar um espaço de tela sensível dedicada a reconhecimento de escrita. O teclado real mata essa discussão com tiro de canhão.

2. Acabamento. O aspecto externo é bem mais bonito e "liso". As teclas que já existiam no N800 estão em lugares mais lógicos, embora o controle de volume do 770 ainda era o melhor.

3. Memória flash interna. Como essa memória contém o swap, é muito interessante que ela tenha boa capacidade e não seja facilmente removível como é nos outros Tablets.

4. GPS embutido.

5. Vem com suporte para prender no automóvel.

6. A câmera continua sendo ruim mas está na fronte, não mais naquele pinguelo que salta para fora. Mais apropriado para o uso imaginado dela, que é videofone.

Desvantagens: não tem mais receptor FM, e o conector USB é micro ao invés do mini (menos padrão, por enquanto). O case rígido do 770 ainda era melhor que a capinha de couro. O carregador que veio na caixa ainda não é aquele bem pequeno do N95.

Palestra no evento SIRC da UNIFRA

2008-06-13T20:31:00.003-03:00

Nesta última quarta-feira (11/6) proferi uma palestra na UNIFRA (Centro Universitário Franciscano), em Santa Maria/RS. O tema foi "Python para dispositivos móveis".

O objetivo foi instigar o pessoal a desenvolver em Python, seja no PC, seja para dispositivos móveis que serão (ou são) a próxima onda da informática. Foi uma versão modificada da palestra que fiz em Manaus em novembro do ano passado, mas com mais foco em Python e menos em outras alternativas como OpenC, Mamona etc.

Desenvolver para mobile é difícil, por diversos motivos. Como parte da argumentação em favor do Python, menciono em detalhes o tipo de problema que o desenvolvedor mobile típico (usando C ou C++) enfrenta no seu dia-a-dia.

Pena que meu tempo estava curto e não pude preparar uma palestra mais elaborada, talvez até aproximando-se de um mini-curso. Quem sabe na próxima. Mas diversos alunos presentes na palestra já tinham experimentado Python em dispositivos Nokia, seja nos celulares Série 60 ou nos Tablets, então ao menos eu tinha "testemunhas" que atestavam a veracidade do que estava falando...

A UNIFRA é uma universidade mantida pela Igreja Católica, mais especificamente pelas Irmãs Franciscanas. O prédio onde ocorreu o evento SIRC (Simpósio de Informática da Região Centro de RS) é extremamente bonito. As escadarias da entrada pareciam coisa de novela, e fiz papel de bobo tirando várias fotos delas (além do que a câmera do celular não é grande-angular, então as fotos não fazem justiça ao local).

Tanto professores como alunos pareceram extremamente preparados e interessados, não sei como não ouvi falar deles antes, ainda mais estando relativamente perto.

Na verdade, eu também não conhecia a cidade. Santa Maria fica exatamente no meio de RS, e ocupa uma posição estratégica, em diversos aspectos: ferroviário, militar (parece que há um contingente de 7000 militares), e educacional, com diversas universidades entre elas a UNIFRA e a UFSM. Santa Maria tem em torno de 300 mil habitantes, tamanho semelhante a Blumenau/SC ou Jundiaí/SP. Boa parte da população é de fora, que vem estudar, ou então por ser militar.

O professor Cassal foi meu "cicerone", e me assistiu de forma extremamente atenciosa tanto na logística da viagem como durante a estada na cidade. Meus agradecimentos a ele.

Um aspecto curioso do evento foi que ocorreu um "momento cultural" imediatamente antes da abertura. Três alunos dos cursos relacionados a informática armaram-se de arcordeon, violão e bateria, e tocaram diversas músicas, desde gauchescas até MPB, passando por "Asa Branca". E eles tocaram bem à beça. Coisas do Rio Grande do Sul.

Finalmente, para ir de Porto Alegre à Santa Maria, é preciso pegar um vôo num pequeno turbohélice de 20 lugares. A maioria das pessoas deve ter medo disso; eu particularmente adorei, fazia muito tempo que não voava em avião de hélice, e quanto menor e mais lento, mais um avião balança, tornando a viagem muito mais divertida. O aviãozinho Let-410 fabricado no antigo bloco comunista tem muito empuxo e parece ser feito para pistas muito mais curtas do que as existentes em aeroportos "normais".

Carteira de identidade de uma conexão

2008-05-30T22:33:00.003-03:00

Cada conexão TCP/IP tem uma identificaação única na Internet. Esta id. é composta por quatro valores: os endereços IP das duas pontas, mais os números de porta que cada ponta atribuiu àquela conexão em particular.

Da minha experiência como professor, sei que o conceito de endereço é mais ou menos compreensível por todos, mas o conceito de porta fica no ar.

A porta é uma abstração criada pelo protocolo de transporte. O objetivo é permitir que um terminal possa manter diversas conexões abertas ao mesmo tempo, e mesmo várias conexões separadas entre os mesmos dois terminais. Sem a porta, seria necessário criar algum outro mecanismo que distinguisse os dados vindos de cada conexão.

Poddemos fazer uma analogia com os correios. Em geral, uma carta menciona o nome do destinatário, embora ele não seja necessário para a entrega da carta; bastaria o endereço. Mas aí, se mora mais de uma pessoa na casa, como saber para quem é a carta sem um nome? Seria necessário abrir a carta, e tentar inferir o destinatário pelo conteúdo.

A porta num pacote TCP ou UDP faz o mesmo papel do nome em uma carta. Mas a porta ainda tem uma utiilidade adicional na Internet, que é identificar os serviços. Por exemplo, um servidor Web sempre atende na porta 80. Isto facilita a vida dos clientes que não precisam descobrir a porta do serviço Web, basta saber o endereço.

Isto também significa que todas as conexões com este servidor Web terão metade de suas identidades sempre igual, já que endereço o porta do terminal servidor são sempre iguais. A distinção entre conexões fica totalmente dependente do endereço e porta do terminal cliente.

Bem, e qual vai ser o número de porta do lado cliente? Não importa, pois é do cliente a iniciativa de fazer a conexão, assim o servidor fica sabendo já no primeiro pacote qual é a porta do ooutro lado (para quem ele deverá mandar o pacotte de resposta).

Normalmente o cliente escolhe uma porta 'alta', ou seja, acima de 32000, que não costuma ser usada por servidores. O valor exato costuma ser escolhido pelo sistema operacional. Mas absolutamente nada impede que a própria aplicação cliente escolha sua porta, e pode escolher uma porta 'baixa', até mesmo a porta 80. Se não estiver em uso por outra conexão, nem houver um servidor Web rodando na mesma máquina, tá valendo.

A única exigência é o cliente escolher uma porta que ele mesmo já não esteja usando para outra conexão com o mesmo servidor.

Assim, não há nada esotérico a respeito das portas. É apenas um truque para que um terminal possa manter várias conexões abertas concomitantemente. E a convenção de o servidor atender sempre à mesma porta existe apenas para evitar a necessidade de fazer-se procura DNS também pela porta.

Aliás, o DNS suporta resolução de porta além de resolver eendereços. Alguns serviços como LDAP usam rotineiramente este método de resolução, pois não se sabe a priori nem o endereço nem a porta do servidoor LDAP responsável por um domínio.

Assim, ninguém precisa ficar assustado com a perspectiva futura dos serviços não terem mais portas fixas. O DNS dá jeito -- se estiver corretamente configurado...

Num próximo post, veremos como fica a identidade única das conexões na presença de um roteador NAT.

Comunicação "sem conexão" não existe

2008-05-27T10:55:00.004-03:00

Uma coisa que é rotineiramente ensinada aos novatos em protocolos de rede, e escrita em praticamente todos os compêndios a respeito do assunto, é que TCP é um protocolo "com conexão" e UDP é um protocolo "sem conexão".

Num contexto maior, também ensinamos que antes da comunicação baseada em pacotes de dados (que hoje é prevalente), havia a comunicação baseada em circuitos, ou seja, linhas telefônicas (mediante discagem ou privativas). Também existe a tendência de dizer que linha telefônica é uma conexão, enquanto na comunicação por pacotes 'não há' conexão.

O primeiro exemplo didático que se costuma dar para comunicação por datagrama ("sem conexão"), é a carta enviada pelo correio, que não tem garantia de entrega, e o tempo de entrega é apenas melhor esforço (ou seja, depende do bom humor do Correio).

Agora, quem disse que não há conexão entre remetente e destinatário? É claro que há. A questão é que o Correio não toma conhecimento dela; apenas transmite cartas. E isto não é ruim; pelo contrário, é bom, pois eu posso mandar cartas para milhares de pessoas diferentes sem que eu precise dizer ao Correio porque estou fazendo isso.

O mesmo aplica-se a diferença entre linha telefônica (privada ou comutada) e pacotes de dados. Quando dois terminais comunicam-se usando pacotes de dados, é claro que existe uma conexão entre esses dois terminais. De outro modo, por que eles estariam trocando dados, se não houvesse interesse mútuo nisso?

A diferença é que, numa ligação telefônica, a companhia telefônica "sabe" que essa conexão existe, e é diretamente responsável por ela. Além disso, cada conexão serve apenas para uma dupla (ou tupla) de terminais. Se João precisa falar com Maria e também com José, precisa estabelecer duas conexões separadas. Mesmo que ele use cada uma delas 50% do tempo, ele paga por minuto, pelas duas ligações.

Já num serviço de pacotes de dados, a infra-estrutura é análoga à do Correio: ela só promete entregar pacotes ao destino, sem confirmação, na base do melhor esforço. O serviço de dados não quer nem saber se dois terminais vão trocar 1 ou 1 milhão de pacotes entre si. A responsabilidade de criar e manter as conexões é do terminal, não do serviço. Isto sobrecarrega o terminal. Por outro lado, a maioria dos serviços de dados custa o mesmo, esteja você comunicando com 1, 10 ou 1000 interlocutores diferentes.

No caso dos protocolos TCP/IP, a responsabilidade de manter a conexão é sempre do terminal. Resta saber que parte do software que roda no terminal (sistema operacional ou aplicação) vai tomar conta disso.

No caso do TCP, o sistema operacional é o responsável por manter a conexão entre os terminais. Isto facilita a vida da aplicação. Por exemplo, quem desenvolve um browser não precisa tratar coisas como perdas de pacotes e retransmissões. Isto é muito conveniente, evita muita duplicação de código, e o protocolo TCP é utilizado sempre que possível.

Já o protocolo UDP transfere a responsabilidade da conexão para a aplicação. Isto torna o desenvolvimento da mesma bem mais complicado, e bem mais difícil de "fazer direito". Por outro lado, há situações em que isto é necessário e conveniente.

Por exemplo, quando um serviço atende milhões de clientes num curto espaço de tempo, trocando mensagens curtas, UDP é muito melhor que TCP, pois em geral os sistemas operacionais têm limites no número de conexões TCP, enquanto uma aplicação pode usar memória virtual e controlar milhões de conexões UDP sem maiores problemas. É por isso que serviços como DNS utilizam UDP.

Outro motivo para usar UDP é delegar o controle de congestionamento à aplicação. TCP faz controle de congestionamento, mas o faz de um jeito que é inadequado para serviços como multimídia e voz sobre IP. UDP permite delegar tal controle à aplicação.

O último motivo para utilizar-se UDP em vez de TCP é o uso de multicast/broadcast. Analogamente a uma ligação telefônica, TCP "custa" muito para conectar com diversos clientes ao mesmo tempo. E quando o serviço manda dados majoritariamente numa única direção, é mais econômico utilizar broadcast e multicast, pois permite atingir inúmeros destinatários, custando uma única transmissão ao remetente.

Existem tentativas de adicionar-se suporte a multicast a protocolos confirmados, caso do XTP. Mas está longe de ser algo largamente adotado.

Mas o fato é que é errado rotular UDP de um serviço "sem conexão". A conexão sempre existe; a questão é quem toma conta dela.

De modo geral, quanto mais empurra-se a responsabilidade da conexão para a aplicação que roda no computador do usuário final, mais barato é o serviço, menor é sua confiabilidade, e mais flexível é o seu uso.

Assim, temos os serviços a seguir numa ordem decrescente de responsabilidade pela conexão:

* broadcasting (TV ou rádio);

* linha privada implantada pelo próprio usuário (raro);

* linha privada da telecom;

* linha discada ou ISDN da telecom;

* X.25 da Embratel;

* Internet, TCP;

* Internet, UDP.

A tendência geral é a migração de todo e qualquer serviço de dados para a Internet. Apesar da confiabilidade menor que as outras alternativas, é a mais flexível. E o contínuo investimento na Internet, tanto na melhoria do serviço em si quanto nos algoritmos que rodam nos terminais têm aproximado a qualidade de serviço das demais opções. Há uns oito ou nove anos atrás, VoIP era uma mera curiosidade, um brinquedo. Hoje em dia, todo mundo usa, até mesmo as telecoms.

Esta transferência de responsabilidade da conexão para o usuário do serviço é maravilhosa, pois é a liberdade de expressão ao extremo. Basta ter uma ADSL, e você pode comunicar-se com o mundo todo, em qualquer protocolo, sendo cliente ou servidor de qualquer serviço de dados. Talvez haja telecoms que registrem suas conexões TCP e UDP para fins forenses, mas isso tem antídoto fácil e rápido: criptografia e/ou protocolos exóticos. O gênio está fora da garrafa.

Por outro lado é algo assustador, pois existem inúmeros mecanismos sociais que perdem parte considerável da sua força num mundo assim. Quantos políticos já não foram "enquadrados" por conta das suas ligações telefônicas? E se eles estivessem usando VoIP? É bem verdade que provavelmente todos os serviços VoIP mantém registros das ligações, porém a tendência a longo prazo é o VoIP independer de serviços centrais (embora requisitar uma informação destas para a Skype que é sediada em Luxemburgo deva ser uma epopéia judiciária).

Skype funciona bem, mas no fundo é um subproduto dos roteadores NAT e da necessidade de conectar-se a telefones convencionais (SkypeOut). Num mundo ideal futuro, ("imagine all the people...") vamos usar IPv6 e usaremos telefones SIP que discam diretamente uns para os outros, sem necessidade de serviços intermediários.

Naturalmente, as autoridades policiais perdem uma ferramenta mas têm ganhado outra, que é o uso cada vez mais raro do dinheiro vivo em favor das operações on-line. Até alguém inventar o e-money. Na verdade o que falta ao e-money é disseminar seu uso, porque ele está inventado.

TV digital versus IPTV

2008-05-19T20:55:00.003-03:00

Muitas revoluções nos esperam. Todas elas são tecnicamente possíveis, todas as peças estão por aí, falta apenas juntar. É uma questão de tempo. É excitante fazer parte deste processo, e poder ser testemunha das mudanças que virão. Uma delas é a TV via Internet.

Na minha modesta opinião, a TV digital está condenada à irrelevância. O motivo primeiro é a escolha da tecnologia, sob medida para agradar as grandes empresas de TV. Depois falam que o mercado não sabe escolher padrões... a escolha óbvia era o sistema europeu, mas o governo foi lá e escolheu o sistema japonês, que só é usado no Japão.

O segundo motivo é que a TV via Internet está chegando aí. É inevitável. Alternativas simplórias como o YouTube já ganharam o público e comeram um bom pedaço do público da TV normal, demonstrando que há demanda e que as pessoas vão comprar uma TV via Internet assim que ela estiver disponível, por pior que seja.

Imagina se o YouTube dá um jeito de transmitir video em real-time daqui a 1 ou 2 anos... É fim de jogo. Diversas outras empresas (telecoms e provedores) estão testando tecnologias e/ou oferecendo produtos que, se evoluírem mais um pouquinho, preenchem os quesitos para serem denominados "televisão".

O principal problema hoje da TV via Internet é a necessidade de banda larga, em torno de 1 Mbps. Muitos clientes de "banda larga" não têm essa velocidade toda (o plano básico em muitos lugares ainda é 300kbps). Mas fatalmente os planos de banda larga vão migrar para velocidades mais altas. Aqui onde moro, os planos da BrasilTelecom para ADSL2+ são mais baratos que ADSL1, pelo simples fato que ADSL2+ gasta menos energia elétrica...

O IPTV vai ofuscar a mancada na escolha de padrão da TV digital. Na verdade, essa má escolha vai até beneficiar o IPTV, pois a penetração da TV digital ainda será pífia quando a infra-estrutura de banda larga chegar no ponto de poder oferecer IPTV trivialmente.

INdT no FISL, com competição em Python!

2008-04-14T17:28:00.000-03:00

Instituto Nokia de Tecnologia promove desafios em parceria
com Forum Nokia na Arena de Programação do FISL 2008

Vencedores serão premiados com dispositivos Nokia N95 e Nokia N800. Inscrições estão abertas no site do FISL 09

O Instituto Nokia de Tecnologia (INdT) participará, pela primeira vez, do Fórum Internacional Software Livre (fisl), que terá sua nona edição entre 17 e 19 de abril, em Porto Alegre. O instituto, em parceria com o Forum Nokia, comunidade on-line com mais de três milhões de desenvolvedores cadastrados, promoverá desafios na Arena de Programação do evento e premiará os vencedores com aparelhos Nokia N95 e Internet Tablets Nokia N800.

Os desafios consistem em disputas que levam em conta habilidades técnicas de programação e desenvolvimento. As competições, realizadas individualmente e em grupo, serão vinculadas a projetos open source para plataformas móveis.

Serão duas fases: qualifying e insanifying. No qualifying, tarefas mais simples ajudam os times a se familiarizarem com a linguagem Python para o sistema operacional Symbian S60 e com a API (Interface de Programação de Aplicativos) da plataforma. Aqueles com os melhores resultados passam para a etapa seguinte, quando usarão parte do conhecimento adquirido durante o qualifying.

O resultado será uma contribuição para um projeto de software livre com o qual os participantes poderão continuar colaborando mesmo após o FISLl.

Javascript HP-12C emulator

2008-02-18T18:31:00.005-03:00

For those who like the HP-12C calculator, this emulator may be of interest. It has been tested on Firefox 2 and Internet Explorer 7.

I have always liked the HP-12C calculator (in fact I have three of them), and always wanted to write a HP emulator. The current state of Web browsers and Javascript allowed it to be written as a Web application, so (hopefully) everyone can use it, using any client platform.

The emulator aims to be very faithful to the real thing, to the point that even most of the calculator's limitations are reproduced. The programming mode is fully implemented (though it needs to be tested in more depth). Most of the math has been checked against the real calculator, and should give the same results to the 8th or 9th decimal digit.

The main (intentional) differences are: the ON button behavior (which toogles between decimal point and comma) ; and program memory is not shared with number memory, so typing a 99-step program does *not* reduce number memory from 20 to 8 positions -- you can always use all 20 positions in the emulator. (IMHO it would be pedantic and pointless to reproduce that particular "feature" of the real calculator).

It seems not to work in IE6, so patches and suggestions are welcome.

Enjoy!

Fighting with web frameworks -- wrapup

2008-02-05T14:41:00.000-02:00

After several posts about my work with Turbogears (Python framework for Web applications) and Luca (my general ledger application). Each post presents some problems and some alternatives, none is conclusive. It's time to write a conclusion.

The spark of all my posts was my disappointment with some aspects of Luca development, the main one being the difficulty of introducing changes in UI in a productive way. Every controller has three XML templates, one for AJAX version and two for the "lite" version (Javascript-free, for old or incompatible browsers). So, in a sense, Luca has two separate UIs. So I wrote a template generator and wrote the "meta-templates" using Python syntax instead of XML. Now, every change in UI is leveraged (I only need to change the generator, and the templates will be affected at once).

But then I noted that most of the data that I put in the meta-template, already existed in several other places: the controller and the model. So, if e.g. a table gets a new column, I need to change the model, the controller and the meta-template.

Automated testing was another problem: it is easy to test the controllers in Turbogears (Luca has something around 92% test coverage) but it is almost impossible to test the views, I would have to write a HTML interpreter to do that. And, since there are several XML templates per controller, they certainly have bugs.

First I blamed Model-View-Controller pattern for my woes, then Turbogears, then myself. I found another design pattern called "naked objects", kind of an anthitesis to MVC, that seem to solve all my problems.

During Luca development, a "pattern" emerged in the controllers: the "data transmission line". Different levels of the controller deal with a different data representation, and data goes through a "transformer" when crossing from/to another level. Luca controllers have three explicit data presentations: Web (that go to the XML templates or are coming from the forms), Intermediate (manipulated by all non-trivial validation and business rules), and SQL (ready to be fed into SQLObject). In truth we have two more data representations, that fortunately we don't have to deal with: SQLObject (that translates to/from SQL) and pure HTML/form (that is translated by XML templates and by CherryPy respectively).

The 3 explicit data transformers are inside the controllers, but now I feel that intermediate-SQL transformer belongs to the Model, and the Web-intermediate transformer should belong to View. The controllers are swollen, and yet there is redundant information in model, view and controller.

All cards in the table, my conclusions are:

* Turbogears, as well as all other web frameworks that I have seen, mislead (and sometimes even forces) the developer into using MVC the wrong way.

* They establish that one SQL table == one Model class, making the Model a kind of passive element in their MVC interpretation. Models should be much more intelligent than a simple object-relational mapper. Just because the ORM frees the developer from writing SQL (which I don't perceive as so advantageous), it does not mean that a ORM-mapped table is a full-fledged Model.

The developer can easily avoid this problem by developing more intelligent Model classes that in turn manipulate the ORM classes, and setting up a controller that just forwards the requests to the model.

* Most frameworks establish that a XML template system is the "View", when the View should be a normal and almighty Python class. Since XML is obviously not a programming language, every XML template has a (bad) way to allow Python code into the XML. The result is an underpowered, ugly templating language which makes PHP look pretty in comparison.

This one is more difficult to solve, though most frameworks allow the developer to write their own view class. Turbogears specifies the View as a controller method decorator, so it clearly thinks that View is just a "data transformer", and not an intelligent class that can take intelligent decisions.

Turbogears tries to give more power to the XML templates by "widgets" -- Python classes that can generate XML snippets. Being Python classes, they can be much more intelligent than a XML template. It is a good initial idea, but widgets have some problems: they are INCREDIBLY difficult to understand, and they are sent to the page via the controller, so it is another source of contamination of View businesses into the Controller.

The real solution is to have Views as full-powered Python classes, which *in turn* can use some kind of XML templating system.

* As a result of previous items, the Controller ends up swollen with code. But unfortunately the centralization of activities in Controller does not exempt the developer of writing redundant code in Views and Models.

* Most frameworks map Web pages and Web requests into controllers' methods. This is nice except that Controller must mimic the Web site structure. And site structure should be exclusive business of View. If a different UI must be supported (i.e. a new View must be written), the controller will not be adequate.

It already happened in Luca, just because I support AJAX and non-AJAX pages. The AJAX pages call JSON controller methods, and non-AJAX pages call other methods. It is necessary since data from form submits are different than data sent directly via JSON. (The JSON methods are "more pure" since they are not contaminated by the form -- View -- details, so they can also be called by the mobile client that runs in cell phone).

* The antithesis of MVC -- naked objects -- solves most of the abovementioned problems by compulsory automatic generation of UI code. It is an utopia; it would never suffice everybody's needs, but it is worthwile to purse that utopia, up to a certain extent.

It translates to: we should write Views that derive their behaviour from Model introspection as much as possible. It ensures that all function points will look the same, and more important, an improvement or bugfix in View will yield profits to every function point.

The risk is, of course, going too far and giving our application that boring appearance of the 1980's when database-tied 4th generation languages ruled the world.

But if we go too far, it is easy to fall back and add customizations to selected Views. It is way easier to commit the opposite mistake: NOT to pursue any kind of automatic UI generation, and discover that you cannot fix the mistake anymore because you have hundreds of incompatible Views.

In short, Web frameworks should:

1) review their interpretation of MVC;

2) promote the development of much more powerful Model objects, instead of simple ORM classes;

3) make Views as real objects instead of simple "filters", which in turn can use XML templates;

4) Encourage and supply good tools for at least some degree of automatic UI generation.

Naked objects

2008-02-01T02:26:00.000-02:00

Parece que encontrei o pattern que eu estava procurando nos posts anteriores:
Naked Objects, considerado a antítese do Model-View-Controller. A idéia é implementar todas as regras de negócio num único objeto, o "objeto de domínio", que faz as vezes de Model mais Controller. A partir dele, todas as interfaces de usuário são geradas de forma automática.

A grande vantagem do Naked Objects é a centralização de informações. Alterar um ponto de função implica em mexer apenas num arquivo de código-fonte, ao invés de vários, e todas as interfaces refletem automaticamente a mudança. A desvantagem é obviamente a rigidez das interfaces geradas.

Na minha visão, o Naked Objects não é o "contrário" do MVC, é simplesmente um caminho diferente de chegar no mesmo lugar. Ao invés de desenvolver três classes (Model, View e Controller), desenvolve-se apenas uma (um Controller que açambarca ou pelo menos esconde o Model), e o View é gerado de forma automática.

Na verdade, pode ser preciso desenvolver também o gerador de Views, que vai ser apenas um por tipo de interface (Web, texto, GUI etc.). Na verdade é bom que o desenvolvedor tenha como modificar esse gerador, pois mitiga a desvantagem da rigidez.

Mais lamúrias sobre frameworks Web

2008-01-29T21:34:00.000-02:00

Continuando a fuçar "onde foi que eu errei" a respeito do Luca e dos frameworks para Web, cheguei a algumas conclusões parciais.

Primeiro, durante o desenvolvimento do Luca apareceu um pattern interessante: a "representação de dados" em formatos diversos, e a conversão de uma representação para outra por meio de filtros. O Luca lida com dados em 3 formatos distintos:

Representação SQL (RS): É a que pode ser oferecida diretamente ao Model, no caso o SQLObject. Por conseqüência, é praticamente pareada com a estrutura da tabela SQL. Também é o formato obtido quando se puxa dados via SQLObject.

Representação intermediária (RI): O controlador só manipula e valida dados nesse formato, portanto pode ser considerado o "principal". As demais representações só existem para satisfazer outros componentes.

Representação Web (RW): Formato que visa satisfazer ao template XML. Também é o formato que é obtido quando o usuário submete dados via formulário Web.

O controlador deve implementar os filtros de conversão entre RS, RI e RW,, mas ele herda filtros default suficientemente poderosos para as conversões triviais, de strings e inteiros, que são a maioria. Apenas os dados "excepcionais", cuja representação no SQL não tenha nada a ver com o apresentado na página HTML, precisam ser convertidos pelo controlador.

Com isso eu tentei isolar as "regras de negócio" do controlador ao máximo, tornando-as independentes tanto dos detalhes desagradáveis do SQLObject quanto dos dados vindos diretamente da Web (que podem estar sujos ou num formato não ideal). Também tentei economizar código, de modo que especificando as colunas numa única tabela molda todo o comportamento do controlador, evitando ter de repetir as mesmas variáveis um monte de vezes.

Infelizmente, as colunas ainda precisam ser especificadas novamente nos templates XML e nos validadores Turbogears (que no Luca são utilizados para apenas converter tipos, não para a validação completa). Este fato é uma das minhas principais broncas.

Então, pensando em termos de processamento de dados, tudo que é mostrado na Web vem de um banco de dados. De forma simétrica, tudo que o usuário faz no sistema tem como único objetivo final gravar dados no banco. Entra porco, sai lingüiça. O fluxo de dados de SQL para HTML é:

SQL -> Model -> RS -> Filtro SI -> RI -> Filtro IW -> RW -> XML -> HTML

O fluxo de dados do formulário até o SQL é um pouco diferente, na ponta Web:

Form -> Validador TG -> RW -> Filtro IW -> RI -> Filtro SI -> RS -> Model -> SQL

O problema da promiscuidade entre Model, View e Controller é que quase todos os blocos acima estão contidos no Controller: RS, Filtro SI, Ri, Filtro IW, RW e validador TG. O Controller está trabalhando demais.

O Model deveria, além de esconder o banco de dados SQL, também implementar a representação intermediária (RI). Ou seja, ele deveria fornecer e aceitar dados no formato predileto do Controller, inclusive fazendo a validação. O Model ideal é muito mais que um simples mapeamento SQL-objeto. Isso encurta o fluxo para:

Model -> RI -> Filtro IW -> RW -> XML -> HTML

O próximo problema é a representação Web. Como os templates XML são linguagens canhestras, o Controller tem de trabalhar mais, oferecendo dados "pré-mastigados" ao template. Daí a necessidade do filtro IW.

A rigor esse filtro deveria estar numa classe View separada do Controller; o que não é possível no Turbogears porque o View é apenas o mecanismo de template XML, e escrever um View "completo" exige código de verdade. Nesse cenário ideal, o fluxo fica

Model -> RI -> View{Filtro IW, RW, XML, HTML}

Até aqui, "consertar" o Luca demandaria as seguintes providências:

* Escrever Models melhores, que isolem completamente o SQLObject do resto da aplicação e interfaceiem dados no formato predileto dos Controllers -- o RI.

* Escrever decorators View mais poderosos, que aceitem diretamente dados RI e virem-se para transformar dados "puros" numa página Web.

Mas a contaminação dos Controllers não se resume ao fluxo de dados -- ela também ocorre nas chamadas a métodos. Por que?

Porque é justamente esta a idéia do CherryPy, componente do Turbogears: se você invoca uma página bla.com.br/bla/ble, isso provoca a chamada a um método "ble" do objeto Controller "bla". Sem dúvida é uma coisa boa, mas talvez o objeto "bla" não devesse ser um Controller no sentido MVC do termo...

Se os métodos do Controller são moldados de acordo com as páginas Web, é óbvio que o controlador vai ficar viciado com o jeito Web de ser. Se for necessária qualquer outra interface que não Web, já vai ficar complicado ou impossível usá-lo para atender outros tipos de cliente, como texto, GUI... ou mesmo AJAX.

O cliente AJAX é um caso interessante porque do ponto de vista do controlador ele não é Web, pois o cliente AJAX troca dados puros com o controlador (codificados em JSON), e não páginas ou formulários. Um controlador "viciado" para Web não servirá nem para AJAX. Será preciso criar novos métodos.

É exatamente o que acontece no Luca: há métodos JSON para as páginas AJAX, e há métodos de páginas Web para as páginas sem AJAX (utilizáveis em navegadores antigos ou incompatíveis). Funciona, mas duplica algum código e mistura conceitos.

O ideal seria haver um pré-controlador para Web, intimamente ligado ao View, que atendesse as páginas Web normais, e este por sua vez refurmulasse a requisição controlador "puro", agnóstico ao View, e implementa apenas as regras de negócio. Já as requisições JSON poderiam ir direto ao controlador "puro", pois trafegam dados puros (e podem servir a clientes GUI).

No Luca, há apenas um controlador "puro", que é responsável por comunicar-se com o celular (assim eu posso registrar minhas despesas no celular e fazer upload via Bluetooth). Por sua vez, este controlador invoca métodos de outros, pois diversas transações diferentes são levadas a cabo a cada sincronização celular-servidor. (Foi fácil chamar métodos de outros controladores pois todos já tinham suporte a AJAX).

Em resumo:

* No Turbogears e aparentemente nos demais frameworks, induz-se poluição dos Controllers devido à anemia dos Models e dos Views;

* Os Models "sugeridos" pelos frameworks são fracos pois são apenas uma casca fina sobre SQL, embora seja fácil implementar e usar Models mais adequados.

* Os Views dos frameworks são fracos pois restringem-se a encoders, como os templates XML, quando deveriam ser classes Python normais (e estas sim, por sua vez, poderiam usar algum mecanismo de template XML).

* Talvez eu esteja exigindo do Turbogears que sejam servidores de aplicação, não simples um framework Web que é afinal a sua proposta. (Mas, na minha opinião, um sistema AJAX tem características não-Web.)

* Minhas queixas contra o MVC estavam erradas, o problema dos frameworks poderia ser a má interpretação do pattern MVC.

Decepção com frameworks Web

2008-01-27T22:59:00.000-02:00

Depois de quase dois anos trabalhando no Luca, cheguei à conclusão que o Turbogears, e na verdade todos os frameworks Web da moda, são largamente inadequados para desenvolvimento de sistemas "sérios", no estilo ERP.

Os frameworks Web atuais têm, em minha opinião, o grande defeito de serem norteados por ideologia e não por necessidades reais. Alguns exemplos:

* Todos alegam ser "Model-View-Controller", porque MVC é dogma da orientação a objetos, e todo desenvolvedor sério sabe que desacoplamento total entre visão e controle é utopia, embora uma separação razoável seja saudável. Se MVC perfeito fosse perfeitamente possível, estaríamos usando para Web as mesmas linguagens e ferramentas GUI que usávamos nos anos 90 (afinal, se eram perfeitas, ainda serviriam).

A conseqüência mais visível no Luca dessa separação MVC despropositada é a duplicação de informações no código. Por exemplo, numa tela comum de cadastro, eu preciso especificar as colunas em diversos lugares diferentes:

- No modelo, em SQLObject-ês
- No template XML para AJAX
- No template XML para Web simples (sem AJAX)
- No controlador, para validar o que vem do navegador e repassar ao modelo

Eu estava trabalhando num gerador de templates XML para o meu aplicativo, de modo a diminuir a contagem de 4 para 3. Mas de repente percebi que o certo seria tomar providências para que a contagem caísse a 1. E isto provavelmente implica em usar outro framework que não o TurboGears.

Separar controle de apresentação é análogo a separar conteúdo de estilo. Quem desenvolve site sabe que HTML representa o conteúdo e CSS representa o estilo, mas é impossível separar completamente as duas coisas. Sempre é necessário mexer alguma coisa no HTML para atingir a apresentação final desejada.

* Muitos têm mapeamento objeto-relacional, porque SQL é "ruim" e deve-se usar classes ao invés da interface DBI -- até que a Revolução dos Objetos varra os bancos de dados em favor de bancos de objetos. O resultado é a perda do poder do SQL sem o ganho de poder que existiria num banco de objetos de verdade, e adicionam uma camada de software em cima do DBI, com seus próprios bugs, limitações e idiossincrasias.

Pessoalmente sofri muito com o SQLObject, que tem bugs de Unicode com o MySQL ainda não resolvidos. Qualquer consulta não trivial seria mais fácil fazer em SQL do que em SQLObject. A única possível vantagem de usar SQLObject é a portabilidade de banco de dados, mas mesmo isso é limitado. Às vezes, algo que funciona bem em MySQL não funciona em Postgres por um motivo totalmente obscuro, ou um nome de coluna que funciona no MySQL não funciona no Interbase/Firebird (e o SQLObject não resolve isso, é preciso trocar mesmo o nome da coluna).

Concluo que o ideal é tomar partido de forma clara: ou se usa SQL via interface DBI da sua linguagem predileta, ou se usa um banco de objetos nativo como ZODB. E dentre as duas opções, eu prefiro SQL, em particular se existe alguma chance de outros sistemas em outras linguagens terem de manipular esses mesmos dados. (Como um sistema escrito em Visual Basic vai acessar um banco de objetos ZODB?)

* Templates XML. É outra praga que contamina quase todos os frameworks. Uns poucos decidem ser "agnósticos a template" mas sempre deixam aberta a possibilidade de usar um template de terceiros. Nunca gostei de template XML, mas procurei aceitar a idéia durante o desenvolvimento do Luca, afinal eu poderia estar errado. Mas vejo que eu estava é certo.

XML não foi feito para ser produzido ou editado por humanos. Tanto é assim que o CSS não tem sintaxe XML, justamente porque ele será mais provavelmente editado por um designer, enquanto o HTML de conteúdo será mais provavelmente gerado por máquina e que (quase) nunca é editado por questões de estilo.

XML foi feito para representar dados passivos de forma hierárquica. Coisas como páginas dinâmicas não são bem representadas por XML. Toda linguagem de template acaba resultando em algo parecido com COBOL: uma linguagem rígida, pouco poderosa e desagradável de usar.

Para piorar, um template XML é praticamente um mapeamento de HTML, tanto que algumas linguagens alegam como "vantagem" o fato do XML ser renderizável no browser mesmo sem ser processado pelo framework. Ou seja, é praticamente inútil para renderizar qualquer coisa que não seja um HTML convencional. Isso inclui gerar um HTML mais apropriado para um dispositivo diferente do desktop comum (como sabem os designers, apenas trocar o CSS não é suficiente para tornar uma página boa para qualquer tamanho de tela).

Seria um pouco excessivo pedir que o XML de template fosse capaz de gerar interfaces diferentes de Web (e.g. interface texto ou GUI), afinal ele é justamente o View, e diferentes interfaces pedem diferentes Views. Por isso mesmo, os templates deveriam ser arquitetados de forma a ter pouca ou nenhuma informação sobre nomes de colunas e lógica de programação. Tais coisas pertencem à dupla Model e/ou Controller.

Ouso dizer que o PHP daria uma ótima linguagem de template para os frameworks. Não é uma boa linguagem de uso geral, apesar de infelizmente o PHP ser largamente usado como linguagem de desenvolvimento Web, lugar que na opinião de alguns caberia ao Javascript server-side. Mas como linguagem de template, ou seja, HTML com alguma inteligência embutida, PHP é a melhor. Eu não gosto de PHP mas uso-o no meu sítio Web, simplesmente porque as opções baseadas em Python são piores, para esse uso particular.

No gerador de templates XML que eu estava fazendo para o Luca, eu escrevia "meta templates", usando sintaxe Python convencional, mais ou menos assim:


t = SimpleTable()
t.append( TextField(name="bla", size=40) )

A idéia é usar sintaxe Python convencional, não usar XML e procurar pensar a interface num nível mais alto. O mesmo meta-template gera versões AJAX e não-AJAX da mesma página (no Luca, as duas versões podem ser consideravelmente diferentes). E poderia mesmo ser usado no futuro para gerar uma interface texto ou GUI. Na verdade, esse código poderia estar no próprio Controller ao invés de ser um template. O "View" passa a ser a biblioteca que implemente as classes SimpleTable, TextField etc.

---

Bem, os problemas estão explanados. Quais são as soluções, em particular para meu pet project, o Luca? Seria possível arrumar o Luca, usando técnicas mais adequadas, sem ter de reescrever tudo do zero? Seria possível fazer isso sem abandonar o TurboGears? Ou talvez abandonando o TurboGears mas usando CherryPy, principal componente do TurboGears, de modo a economizar reescrita?

Penso que o código do Luca está demasiadamente poluído pelos problemas do framework, e uma tentativa de reaproveitar muito código acabaria num trabalho mal-feito. Algumas partes muiti reaproveitáveis do Luca (e.g. cálculo do balanço) já são totalmente separadas dos Controllers, e desta forma foram "salvas" dos problemas do framework. Tais partes só teriam de ser reescritas se se trocasse a linguagem Python por Ruby, PHP, Javascript ou outra qualquer.

O Ruby on Rails seria uma coisa interessante de se tentar. Mas ele padece dos mesmos "pecados originais" que o TurboGears, fora que usa outra linguagem, o que significa reescrita total do Luca. Admito que o Ruby on Rails é mais bem-feito que o TurboGears, mas as benfeitorias do RoR não resolvem meu problema.

Em resumo, o framework ideal que procuro teria as seguintes características:

- Preferencialmente feito em Python;
- Não imponha mapeamento objeto-relacional;
- Não imponha templates XML
- Seja (mesmo que minimamente) aberto à possibilidade de Views diferentes de Web

Para atingir estes objetivos sem deixar de usar TurboGears, seria necessário fazer o seguinte:

- Não usar a autenticação nativa oferecida pelo TurboGears, já que este depende do mapeamento objeto-relacional;
- Modificar o código do Luca de modo a utilizar DBI ao invés de SQLObject
- Escrever um decorator @expose próprio, que gere HTML a partir dos meta-templates ao invés do Kid.

Black-Scholes calculator - Javascript version

2008-01-22T13:36:00.000-02:00

I took the Black-Scholes calculator for Maemo and converted to Javascript. The link is http://www.epx.com.br/ctb/bscalc.php.

Palestras em Joinville e Manaus

2007-11-27T00:48:00.000-02:00

Na última semana ministrei a mesma palestra em Joinville/SC (na SOCIESC, mais conhecida como "Escola Técnica Tupy") e em Manaus/AM (na UFAM), no contexto dos "Tech Days" promovidos pelo Instituto Nokia de Tecnologia (INdT).

Na falta de título melhor, a apresentação denomina-se "Desenvolvimento rápido para dispositivos móveis Nokia". O "powerpoint" no formato OpenOffice pode ser obtido aqui.

A idéia é mostrar os atuais problemas do desenvolvimento para mobile, e também o que a Nokia e o INdT têm feito para melhorar a vida do desenvolvedor. Tudo numa visão de 30 mil pés de altura, já que o tempo é curto e a platéia poderia ter perfil gerencial. Os Tech Days também ofereceram mini-cursos de desenvolvimento para Maemo em seguida às palestras, que sobejamente satisfez quem estava curioso em ver sangue e bits.

Do ponto de vista pessoal, Joinville transcorreu sem novidades, afinal é onde eu moro e o evento foi onde eu leciono. Já Manaus tem sido muito mais interessante, afinal eu nunca tinha vindo sequer ao Norte do Brasil.

Em primeiro lugar: é quente, e o calor é amplificado pela umidade. Embora eu já tenha pegado dias iguais ou piores em Joinville no verão, de modo que ainda estava dentro das minhas especificações. A dica é levar uma garrafa de água consigo, sempre.

Em segundo, deixa-se muitos espaços arborizados ao longo da cidade, floresta mesmo. Ajuda a diminuir a temperatura e embeleza muito. A vida selvagem faz parte do consciente coletivo. Quando estava chegando na UFAM, um bicho-preguiça simplesmente parou no meio da rua. Os motoristas de ambas as mãos *pararam* e um deles deu-se ao trabalho de tirar ela de lá.

De maneira geral, a cidade é bonita, não há aquelas std::favelas comuns nos grandes centros, e há um esforço nítido em "não deixar a peteca cair" em termos de aparência urbana: as casas estão pintadas, as calçadas estão em ordem...

Terceiro, foi interessante conhecer as indústrias da Zona Franca, bem como o Rio Negro, encontro das águas, o Teatro Amazonas (teto na foto ao lado), enfim, aquelas coisas que aparecem na TV ou vêm impressas nas caixas de inúmeros produtos. Independente de discussões sobre guerra fiscal, dá uma sensação de completeza saber "de onde vêm as caixas".

O pessoal do INdT/MAO foi muito gentil conosco em nos mostrar a cidade. Fiquei com consciência pesada por não ter feito o mesmo quando eles estiveram em Joinville (eu realmente precisava colocar o trabalho em dia para ter tempo de vir para cá). Mas haverá outras oportunidades para saldar este débito.

Uma reclamação comum de quem já veio para cá é a demora em serviços em geral. Mas não tive nenhum problema desse tipo. Juro. Com uma exceção: ontem pedi um bule de café no quarto (eu bebo café antes de dormir, e é *para* dormir bem, coisa de viciado mesmo. Como diz o meu amigo Rudá Moura, café é uma droga como qualquer outra) e demorou 2 horas e meia para chegar.

Vou pedir mais um bule hoje, agora. Veremos o que se sucede.

Desenvolvimento Série 60 para quem desenvolve em Linux - parte 3

2007-11-25T14:33:00.000-02:00

"Quer moleza, vai mastigar água de cabeça pra baixo!" -- Desenvolvedor Symbian respondendo à dúvida de um novato.

OpenC -- a luz no fim do túnel

O principal sintoma de que a API do Symbian é mais complicada do que seria razoável, é a baixa dinâmica da comunidade de desenvolvedores. É difícil encontrar software livre para Symbian, e é difícil encontrar respostas para dúvidas no Google. Isso para um sistema operacional que roda em 118 milhões de dispositivos.

Enxerga-se melhor o problema comparando com a comunidade Palm OS. O Palm é uma plataforma moribunda, muita gente diz que o conceito de PDA é obsoleto, mas apesar de tudo isso há uma comunidade muito atuante. Isso se conseguiu com decisões corretas lá no início do Palm: uma API com complexidade dentro do razoável, "parecida" com o que já existia (comunicação via sockets, por exemplo, é exatamente igual ao POSIX), e ferramentas de boa qualidade. O emulador do Palm já era bom desde a época que ele usava processador 68000. E sempre teve emulador e compilador Palm para Linux. De graça.

Enfim, parece que pelo menos a plataforma Série 60 enxergou o óbvio ululante, e lançou o OpenC - uma biblioteca que implementa a API POSIX, threads inclusive, mais o porte de algumas bibliotecas que são "padrão de fato" no mundo do software livre: libz, OpenSSL e GLib/GObject.

O OpenC é para Série 60, não para Symbian. Isso exclui dispositivos Série 80, Série 90 e UIQ. Mas como a Série 60 é a variante mais forte comercialmente, beneficia a maior fatia de usuários.

Posso dizer por experiência própria que o OpenC é um bom software. Tem demonstrado estabilidade e tenta oferecer o máximo possível de recursos do POSIX. Desta forma, o porte de uma aplicação ou biblioteca para OpenC é basicamente tranqüila. Tenho inclusive usando muitas threads, que em Symbian normal é considerado "heresia".

Alguns "issues" a serem considerados, ao menos os que me afetaram:

* O suporte a sockets do OpenC tem algumas peculiaridades. Não é possível obter a lista de interfaces da máquina, porque celular não tem interface de rede, tem "access point", que só é ativado na hora que realmente precisa, para economizar energia. O OpenC oferece chamadas ioctl() adicionais (fora do padrão POSIX) para lidar com access points.

* Ainda na parte de rede, há algumas diferenças na API. É preciso fazer bind() em todo soquete, seja conexão TCP ou UDP, do contrário não funciona. É na hora do bind() que aparece a janelinha perguntando que access point você quer usar (salvo você ter selecionado via ioctl() antes dentro do aplicativo).

* Ao criar um soquete UDP, é necessário passar socket(..., IPPROTO_UDP) no terceiro parâmetro. Se passar zero, não funciona (o comportamento POSIX correto é usar UDP como default). No caso de soquete TCP, o OpenC usa corretamente TCP como default, não é necessário passar IPPROTO_TCP.

* A versão atual do OpenC, que é um add-on para 3rd Edition FP1, não suporta multicast. O programa compila mas vai retornar erro no setsockopt(IP_ADD_MEMBERSHIP). O SDK 3rd Edition Feature Pack 2 beta já tem OpenC embutido e suporta multicast, mas não há nenhum celular com FP2 na praça ainda.

* Quando o select() retorna dizendo que há arquivos ou soquetes a serem lidos/gravados, o programa *tem* de tratar todos nessa oportunidade. Se o programa "esquecer" algum soquete, o próximo select() NÃO vai retornar indicando que aquele soquete ainda precisa ser tratado. Muito código POSIX por aí trata apenas um soquete de cada vez a cada retorno do select(); essa estratégia falhará no OpenC, então é bom ficar esperto.

* Não há como implementar sinais POSIX em Symbian, portanto o OpenC não oferece esta funcionalidade. Aplicativos que dependem de sinais para funcionar são os mais trabalhosos para portar. Em particular quando usam sinais para comunicação entre uma thread e outra. Também não há como criar subprocessos via fork().

* O OpenC não oferece nada em termos de interface gráfica, ainda. É possível fazer um aplicativo OpenC completamente livre da API Symbian, com ponto de entrada main() e tudo, mas ele não vai ter rosto. Para um aplicativo "normal", a solução é usar API Symbian para interface de usuário (naquele esquema cheio de classes do post anterior), e usar OpenC apenas na lógica.

Imagina-se que OpenC vá oferecer UI no futuro. Considerando que o OpenC já possui o GLib portado, que o Maemo é baseado no GTK+, e que o GTK+ é o "padrão de fato" no mundo do software livre, as apostas são que o OpenC ofereça GTK+ um dia. Tomara :)

* Não só UI, mas muita outra coisa cai fora da API OpenC. Para usar multimídia, câmera, GPS, discar um número, etc. você ainda terá de usar a API Symbian. Em comparação, o Python para Série 60 dá acesso a todos estes recursos.

Pior: o Python para Série 60 é assinado pela Nokia, e tem capabilities bastante extensas. Já um aplicativo OpenC tem de ser assinado por você, e isso implica em ter capabilities restritas, ou então ter de cair com o cobre para homologar seu aplicativo no Symbian Signed.

(Imagino que, um dia, o OpenC vá dar acesso a estes recursos de forma "organizada", não dando acesso a /dev/dsp, mas sim usando os padrões do freedesktop.org tal qual o Maemo. No caso de áudio, vídeo ou fotos, a API padrão de fato seria o GStreamer. Mas não tenho a menor idéia se é possível portar o GStreamer para Symbian.)

* A saída padrão (STDIO) ocorre dentro de um aplicativo separado (STDIO server), e não num console separado. Tem a vantagem de funcionar mesmo no celular (para o usuário final não ver as mensagens, basta remover o STDIO server do celular). E a desvantagem da tela ter pequeno tamanho, portanto é incômodo usá-lo para depuração (seria melhor poder jogar a saída num terminal do PC).

E finalmente, sempre temos de lembrar que o desenvolvimento em OpenC acontece dentro do contexto das ferramentas Symbian, o que implica em Windows e um emulador problemático. Assim, embora o OpenC seja vendido como um convite à comunidade de software livre a experimentar o Symbian, eu acho exatamente o contrário: o OpenC veio é para facilitar a vida dos desenvolvedores Symbian!

Resumindo, reconheço que há interesse da Nokia em construir a ponte Symbian-software livre. E aprecio a iniciativa. Mas, diferente do anunciado, eles começaram a construir a ponte pelo lado "de lá" do rio.

Desenvolvimento Série 60 para quem desenvolve em Linux - parte 2

2007-11-23T11:44:00.000-02:00

"O senhor é um fanfarrão!" -- Capitão Nascimento falando ao arquiteto do Symbian

A API do Symbian é um produto legítimo dos anos 90: baseia-se fortemente em design patterns C++. No caso de uma aplicação estilo 'Hello World' gerada pelo SDK, temos as seguintes classes (para uma aplicação chamada EPx):

CEPxApplication: representa a aplicação como um todo

CEPxAppUi: controla a UI, representa o "controller" do modelo MVC. Na prática, o grosso da aplicação vai ser codificada nesta classe, ou pelo menos é a partir desta classe que o resto do seu código é invocado.

CEPxAppView: representa uma "visão" da UI, pode haver várias visões. É obviamente o "view" do MVC.

CEPxDocument: representa o "Model" do modelo MVC.

O ponto de entrada da aplicação é a função E32Main() no código-fonte EPx.cpp. Neste mesmo arquivo há outra função chamada NewApplication(). A aplicação é carregada da seguinte forma:

* E32Main() chama EikStart::RunApplication(NewApplication).
* tendo recebido o endereço via RunApplication, o framework chama NewApplication().
* NewApplication() instancia um objeto CEpxApplication.
* O framework invoca CEpxApplication::CreateDocumentL(), que instancia um objeto CEPxDocument.
* O framework invoca CEPxDocument::CreateAppUiL() que cria um objeto CEPxAppUI.
* O framework invoca CEPxAppUi::ConstructL() que contém e instancia um objeto CEpxAppView.

Enfim, barroco ao extremo.

O próximo choque cultural do desenvolvedor não-Symbian é o "tratamento de exceções". Como as exceçòes e templates do C++ costumavam ter problemas de implementação em todos os compiladores, o Symbian criou um tratamento de exceção sui generis.

Funciona assim: se um método qualquer quiser lançar uma exceção, chama o método estático User::Leave(código_do_erro). Normalmente isto faz o programa fechar. Porém, se o chamador do método quiser capturar esta exceção, ele chama o método através da macro TRAPD(erro, método). Em caso de exceção, a variável erro conterá o código, e o chamador pode agir conforme.

Internamente, este mecanismo parece ser implementado usando longjmp(). CORREÇÃO: segundo o amigo Adenilson, o Symbian 9 utiliza exceções C++ padrão internamente.

Como convenção, todo método que pode causar uma exceção termina com L (de Leave, não de Loser :). Métodos como NewL, ConstructL, RunL têm esse nome pois podem "sair", e os chamadores têm de lidar com isso.

Nas exceções C++ nativas, se qualquer construtor lançar uma exceção, a memória eventualmente comprometida é automaticamente liberada. Mas a exceção Symbian é muito pobre para garantir isso. A solução foi dividir o processo de construção em duas fases: NewL e ConstrucL. NewL() cuida principalmente de alocar o objeto, lidando com a possibilidade da falta de memória. ConstructL() acaba de construir um objeto já alocado (por exemplo abrindo arquivos, conexões de rede que o objeto precise etc.).

Quem apenas usa uma classe, simplesmente chama classe::NewL() para obter um objeto. Quem implementa a classe precisa prover NewL() e ConstructL(), e invocar ConstructL() de dentro de NewL().

Um problema no tratamento de exceções de construção é a destruição de objetos em heap. Para facilitar isto, foi criada outra convenção: classes feitas para serem alocadas em heap têm o nome começando em C maiúsculo (daí os nomes CEPxApplication, CEPxAppUi...). Em tais classes, o construtor C++ deve ser privado (ou seja, proibido de ser usado diretamente) e o usuário da classe sempre chama a fábrica classe::NewLC() para obter novos objetos.

A propósito, esta é outra convenção: métodos que retornem um novo objeto em heap devem terminar com o nome em C, por isso NewL() vira NewLC(). Mas normalmente pode-se usar NewL() mesmo ppara tais classes (NewL simplesmente chama NewLC).

A outra avis-rara do Symbian é o "active object". Quase todas as operações não triviais do Symbian são assíncronas, ou seja, você chama e ela retorna imediatamente, sem o resultado que você quer. Por outro lado, não é recomendado usar threads para lidar com tais operações. A saída é usar um active object, que tenta ser uma espécie de thread "leve" (na verdade é multitarefa colaborativa).

Se você tem uma tarefa assíncrona, deve criar uma classe para ela, e esta classe deve ser descendente de CActive.Todos os active objects são controlados por um escalonador, que escolhe o active object de maior prioridade e chama RunL() para sua classe, quando nada mais importante há a ser feito.

Dentro de RunL() você faz a sua tarefa assíncrona, de preferência em pequenos pedaços e retornando para o escalonador assim que possível. Enquanto você não retornar de RunL(), o escalonador não terá chance de alocar tempo para outros active objects.

No caso de solicitar tarefas assíncronas a um "servidor", ou seja, a algum subsistema do Symbian, você terá de passar um objeto Observador, um design pattern que faz papel de callback. Normalmente isso implica que você torne uma classe do seu programa descendente do observador adequado àquele subsistema.

Se por exemplo você quer tirar uma foto, poderia fazer CEpxAppUi ser uma subclasse de MCameraObserver, e implementar o método CEpxAppUi::ImageReady(). Solicite a foto chamando CCamera::CaptureImage(), e quando ela estiver pronta, o subsistema câmera chamará seu método ImageReady().

Outro uso do observador é ser notificado quando uma tarefa delegada a um active object foi terminada. Supondo que deleguemos a gravação da foto a um active object. Essa gravação pode demorar a acontecer pois outros eventos mais prioritários acontecem (e.g. o usuário pode estar tirando mais fotos). Quando a gravação finalmente acaba, o active object chama o observador.

Parece interessante mas deixa o código extremamente engessado, devido ao observador ter de descender de uma classe. No caso de uma linguagem interpretada como Python, bastaria que o observador implementasse o método de nome FooBar(), não haveria necessidade de descender da class FooBarObserver.

Eu mencionei que o Symbian tem "servidores". Tendo seguido as modas dos anos 90, Symbian é microkernel, e cada serviço como: sistema de arquivos, rede, câmera, tela etc. é controlado por um processo separado. O kernel apenas cuida da memória virtual e coordena a troca de mensagens entre clientes e servidores. É um dos motivos pelo qual quase todo serviço é atendido assincronamente.

Parece bacana, e na verdade tem suas vantagens, mas implica que cada chamada de sistema implique em 2 trocas de contexto no mínimo (cliente para servidor e servidor para cliente) fora a "burocracia" na comunicação. Conforme os celulares ficam mais rápidos, a lentidão inerente ao Symbian fica mais aparente, em particular na interface de usuário.

Desenvolvimento Série 60 para quem desenvolve em Linux - parte 1

2007-11-20T15:19:00.000-02:00

Tendo enfrentado neste ano o desafio de desenvolver para Symbian e Série 60, vindo de longos anos de experiência anterior exclusiva em Linux, achei que seria interessante escrever algumas impressões, para quem pretende desenvolver algo em Série 60.

Em primeiro lugar, é uma filosofia completamente diferente. Ainda mais para quem está acostumado a desenvolver em terminal, usando make e vi. No Symbian, você vai usar um ambiente pronto, e o jeito é confiar nele.

Para começar, é preciso usar o Windows, pois as ferramentas são apenas para Windows. No site http://forum.nokia.com, obtenha os pacotes Carbide.c++ (versão 1.2 funciona bem, as anteriores não), e o SDK S60 C++ apropriada para seu celular. Presumindo que você tem um celular Série 60 3a edição, então seria o SDK S60 C++ for 3rd Edition Feature Pack 1, ou Feature Pack 2. Estas versões têm emuladores melhores que o 3rd Edition "original".

Além disto, você vai precisar do Active Perl e do Java Runtime Environment. As versões exatas recomendadas para o SDK que você está instalando serão informadas durante o processo de instalação.

Recomendo também obter o Open C, e instalar tanto no SDK quanto no seu celular. Infelizmente, OpenC existe apenas para S60 3a edição.

Para testar o ambiente e gerar rapidamente algo que possa ser instalável em seu celular, inicie o Carbide e gere um novo projeto usando o Wizard. Rodá-lo no emulador, gerar o pacote e instalá-lo no celular já vai ser um exercício, em particular para quem não está acostumado a Windows, Carbide, Symbian ou a lidar com seu celular...

Um projeto Symbian depende de inúmeras coisas estarem corretas para ele funcionar no celular. Por exemplo, cada programa tem três códigos UID (UID, UID2 e UID3). Um identifica a plataforma, outro identifica univocamente o programa, e o outro eu não sei até hoje :) Se o UID especificado no projeto não "bate" com o especificado nos arquivos de inclusão, o programa funciona no emulador porém não funciona no celular.
Começar um projeto a partir de um template do Wizard evita esse tipo de dissabor.

Gerar um projeto a partir do Wizard também permite explorar logo o esqueleto de um projeto Symbian, e a forma de construir projetos.

A (única) parte que eu realmente gostei do Symbian foi o esquema de construção de programas. Pelo fato da estrutura do código ser mais rígida, fica mais fácil tratar a questão da construção. Todo projeto Symbian tem uma estrutura de pastas semelhante a esta:

\group: contém os arquivoss específicos do Symbian, como BLD.INF e PROJETO.MMP

\src: fontes .cpp

\inc: arquivos de inclusão .h

\data: arquivos de inclusão com mensagens internacionalizadas e menus

\gfx: parte gráfica, como por exemplo o ícone da aplicação

\sis: onde o pacote final é jogado, geralmente contém o arquivo PROJETO.PKG

É possível mudar o nome destas pastas, mas usar os nomes padrão facilita a compreensã o do seu projeto para terceiros.

Todo o processo de compilação e empacotamento é gerenciado por apenas 3
arquivos-texto, dois da pasta \group e um da pasta \sis:

PROJETO.MMP: este é o principal deles. É neste arquivo que se especifica os UIDs (códigos numéricos) do programa, quais as pastas que contém arquivos de inclusão, quais os programas a serem compilados etc. Ele é análogo ao "Makefile.in" do software livre. Baseado neste arquivo, todo o esquema de construção e tratamento de dependências é levado a cabo. Exemplo:


TARGET            EPx.exe
TARGETTYPE        exe
UID               0x100039CE 0xE1BFA2A2

SOURCEPATH        ..\src
SOURCE            EPx.cpp
SOURCE            EPxApplication.cpp
SOURCE            EPxAppView.cpp
SOURCE            EPxAppUi.cpp
SOURCE            EPxDocument.cpp

SOURCEPATH        ..\data

START RESOURCE    EPx.rss
HEADER
TARGETPATH resource\apps
END //RESOURCE

START RESOURCE    EPx_reg.rss
TARGETPATH        \private\10003a3f\apps
END //RESOURCE

USERINCLUDE       ..\inc

SYSTEMINCLUDE     \epoc32\include \epoc32\include\stdapis \epoc32\include\stdapis\glib-2.0

LIBRARY           euser.lib
LIBRARY           apparc.lib
LIBRARY           cone.lib
LIBRARY           eikcore.lib
LIBRARY           avkon.lib
LIBRARY           commonengine.lib
LIBRARY           efsrv.lib 
LIBRARY           estor.lib
LIBRARY           expat.lib libc.lib libpthread.lib libglib.lib

LANG SC

VENDORID                  0
SECUREID              0xE1BFA2A2
CAPABILITY                LocalServices NetworkServices ReadUserData WriteUserData

BLD.INF: Define quais arquivos MMP serão invocados para construção, e também define, no caso de bibliotecas DLL, quais arquivos de inclusão devem esr copiados para Epoc32\include, para serem vistos por outros projetos. Exemplo:


PRJ_PLATFORMS
WINSCW ARMV5 GCCE

PRJ_MMPFILES

gnumakefile icons_scalable_dc.mk

EPx.mmp

PROJETO.PKG: define o empacotamento do programa para distribuição aos celulares. Essencialmente lista os arquivos que serão incluídos no pacote. Equivalente ao "debian/control" do Debian, ou ao "programa.rpm" do RedHat. Exemplo:


;Language - standard language definitions
&EN

; standard SIS file header
#{"EPx"},(0xE1BFA2A2),1,0,0

;Localised Vendor name
%{"Vendor-EN"}

;Unique Vendor name
:"Vendor"

;Supports Series 60 v 3.0
[0x101F7961], 0, 0, 0, {"Series60ProductID"}

;Files to install
;You should change the source paths to match that of your environment
; 
"$(EPOCROOT)Epoc32\release\$(PLATFORM)\$(TARGET)\EPx.exe"        -"!:\sys\bin\EPx.exe"
"$(EPOCROOT)Epoc32\data\z\resource\apps\EPx.rsc"        -"!:\resource\apps\EPx.rsc"
"$(EPOCROOT)Epoc32\data\z\private\10003a3f\apps\EPx_reg.rsc"    -"!:\private\10003a3f\import\apps\EPx_reg.rsc"
"$(EPOCROOT)Epoc32\data\z\resource\apps\EPx.mif" -"!:\resource\apps\EPx.mif"

; Add any installation notes if applicable
;"EPx.txt"        -"!:\private\E1BFA2A2\EPx.txt"

;required for application to be covered by backup/restore facility 
"..\sis\backup_registration.xml"                -"!:\private\E1BFA2A2\backup_registration.xml"

E isso é tudo. Esses 3 arquivos gerados 99% automaticamente, mais os fontes .cpp e .h, é tudo que se precisa para construir um programa Symbian, seja na linha de comando ou no IDE Carbide. É muito, mas muito mais simples do que o esquema automake/autoconf comum em software livre.

No Carbide, para importar um projeto, basta mandá-lo importar o BLD.INF, pois a partir deste arquivo ele acha os MMPs e por conseqüência todo o resto dos arquivos. O arquivo .PKG tem de ser escolhido manualmente no Carbide, mas isso é simples.

Na linha de comando, preparar um novo projeto para construção envolveria ir para a pasta group\, rodar


BLDMAKE BLDFILES

o que gera um script chamado ABLD.BAT. Dali para frente, basta chamar ABLD.BAT para reconstruir o projeto a cada mudança.

Black-Scholes Options Calculator for Maemo

2007-09-12T20:12:00.000-03:00

After so much time, I did something new for Maemo: a Black-Scholes call options calculator. It is useful for investors that are following the price of some call options and want to compare the theoretical (Black-Scholes) price with the market price, to buy them "cheap" or sell'em expensive.

You can download the source here. It is still a prototype, so there are a lot of things to do, and the first one is to make a installable Debian package.

Features of the current version:

-> Works in Python for Maemo as well as in Python for Linux. Does not depend on any special Python module. In fact this applet grew out of a Python sample from QuantLib, but I simply couldn't port QuantLib to Maemo, so I preferred to use the raw formulas.

-> Persistent data (all the values you chose are saved for the next session in a DBM file).

-> Can follow up to five call options at the same time.

-> Initial date is today (be sure to have the date/time settings correct!), expiration date is chosen in the Calendar widget.

-> The columns in the lower part of the screen are: 1) strike price, that you can choose; 2) Option value based on Black-Scholes formulas (with intrinsic value between parenthesis); 3) Delta; 4) Gamma; 5); Vega; 6) Theta.

I plan to add the following features in next versions:

-> Python for Series 60 version

-> Proper packages for all platforms

-> Automatic download of market quotes, underlying stock volatility etc.

-> Better UI with 'greeks' properly identified

-> Perhaps a Javascript version for Web.

The 'greeks' measure the sensitivity of option price to the elements, and are expressed in the following units:

-> Deltas are in %P/S -- how many % the option price (the premium, P) will change given a change in the underlying stock price (S). If delta is 15%, the option price will rise $0.15 for $1 of rise in stock price.

-> Gammas are in % delta/S -- how much the delta itself will change in % for a given change in stock price. If delta is 15% and gamma is 5%, delta rises to 20% if the stock raises $1.

-> Vegas are in % P/V -- how much % the premium will change for 1% change in volatility. Suppose a vega of 5%. If volatility was 18%/year and rises to 20%/year (2% points rise), the option price would rise 10% (5x2). Options are generally very sensitive to volatility changes.

-> Thetas are in %P/t -- how many % the premium will fall every day, given all other conditions equal. If theta is 14%, and option price is $1.00 today, tomorrow it will be worth $0.86. Theta is not the same during the lifetime of a call; it gets more and more negative for out-of-the-money calls as expiration gets closer.

I preferred to put all greeks "normalized" in %/premium, since I feel it's easier to understand them that way. Most financial textbooks show formulas that produce absolute-value greeks, so be aware of that if comparing results with this calculator.

Novidades sobre a palestra Python para Série 60

2007-08-30T20:45:00.000-03:00

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

2007-08-19T00:33:00.000-03:00

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

2007-08-02T14:43:00.000-03:00

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.

Some disilusionment with ATA

2007-04-14T13:30:00.000-03:00

Yesterday my ATA arrived (Linksys 3102) but quickly I have discovered that it is not "exactly" what I wanted. I have already put it for sale. Well, that's the way it works: it takes time and money to get knowledge and experience.

The ATA itself is pretty, does what it is meant to do and is full of features. Certainly it would be useful if I ran a business of some sort. For my personal use, it just didn't feel right:

1) I planned to configure it both with a Gizmo account for outbound dialing, as well as being able to receive calls directly in behalf of my domain. Both things worked separately, but not together; some configurations (including but not restricted to NAT configs) conflicted.

In order to do what I wanted to, I would need an Asterisk server running in the router (to get the public IP address). Working together with Asterisk, the 3102 ATA would be perfect since it also serves as PSTN gateway, even providing a separate SIP port to deal with PSTN.

2) Using 3102 as PSTN gateway led to some bad echo problems. After following several tutorials about echo problems, I reset the ATA to factory defaults and the situation improved a lot (probably I had messed with some configuration that increased echo).

The echo happens because 3102 effectively encodes FXS voice and decodes into FXO, creating a delay that makes echo noticeable. The echo is reencoded at FXO and decoded at FXS where it can be heard. Certainly the echo was being generated at FXO analog interface, so if I took the time to test all FXO impedance and gain options, probably the echo would disappear completely.

But it is something that scared me at first: never had echo in a normal telephone, and a basic problem like this appears in a very advanced ATA... This is again something that Asterisk server could be of help, because a computer can run a more powerful echo cancellation line (3102 line has only 8ms, the echo I was experiencing had 150ms or more).

3) Putting the ATA as the network router with PPPoE (i.e. getting the public IP address) improves VoIP a lot since all NAT problems disappear at once. But the 3102 router missed one crucial feature: DynDNS update, negating the advantage of having an ATA in the Internet, since I depend on DynDNS to redirect the SIP service to my ADSL.

A business would certainly get another ADSL line, a handful of publc IP addresses, and connect the ATAs to them. But it is something that I can't afford, and I don't use the phone that much, after all :)

4) The SIP phone just didn't feel right in a analog telephone. It doesn't have an alphanumeric display (even though mine has Caller ID so at least the Gizmo SIP number would appear), and you cannot type a true SIP address in the keyboard. I thought that it would feel better than a SIP softphone, but I was mistaken. The softphone is better.

Now I am convinced that a true VoIP phone must be an appliance especially designed for VoIP/SIP. This allows for the users to explore the full power of SIP telephony. ATAs work when you need to use an outbound SIP provider to make cheap international calls, but it is just one of the many, many possibilities of VoIP.

5) When you have to use SIP behind NAT, SIP is *way* too complicated, and not all SIP providers do the NAT thing correctly. SIP is clearly for the future, when IPv6 is there, or if you run an Asterisk server in the NAT router.

In short, to enjoy the SIP VoIP, you need an Asterisk server and a softphone (or a true SIP phone). The ATA helps if your wife or your children want to call grandma cheaply, and/or as PSTN gateway, but it doesn't run the show by itself.

6) The SIP providers' service is still below the Skype par.

The provider that gets the nearest is Gizmo, but the call-ou quality for Brazil numbers is not as good as Skype's. I still have some Gizmo credits so I will try to call USA or Finland someday, to see if quality improves. Gizmo is steadily improving its presence on Brazil and allows you to have call-in numbers in some major cities.

Vono SIP service (from GVT, a Brazilian telecom company) is very good, does the NAT thing right, but from the SIP point of view it is very limiting, since it does not allow you to call other SIP phones. It is just to make cheap calls and allows you to have a point of presence (i.e. a telephone number) in most big Brazilian cities. Also, it ceases to be cheap when you call numbers outside GVT area. Since I already have a telephone number, it does not interest me.

I contacted Voip55, a SIP provider that appeared in Google ads. They offer just call-out at cheap and pre-paid rates (cheaper than Vono). Seemed just like a good idea so I filled the form to receive further instructions to get a test account.

In the next day (too much time, IMHO) I received instructions to buy credits for a full account (that would cost around US$ 50, while the test would cost just US$ 5). I could see that e-mail was their workflow document. Attached to it was a query of my name to the Internal Revenue Service! Not very kind, and they wouldn't even hide the query from me. Rude and stupid.

I replied that I wanted a test account, not yet a full account, and the secretary replied with an one-liner "so fill the test account form at Web site". That was exactly what I had done. How the people expect to attract customers that way? Skype, Gizmo et al. sell credits via credit card, no questions asked.

So, now I'm back to Skype and Gizmo softphones, looking for a SIP phone in the future.

VoIP sickness progressing, now I have my own registar :)

2007-04-07T16:12:00.000-03:00

I was still at unrest because I couldn't have my own SIP registar. Yesterday I Googled a lot again, and again found the OpenSER software.

I had avoided OpenSER before since it has a reputation of being extremely difficult to configure, but this time I found a 'hot' information that OpenSER does NAT translation in belalf of users, and also found an "OpenSER" wizard to aid first configuration.

The main complaint is that parts of OpenSER configuration are scripts, not switches. Personally I found myself at ease with this.

Well, I used the wizard, configured the items that wizard cannot do for you e.g. creating the MySQL database and SIP users, and put it to run. Magic: it translates all SDP sessions transparently, you don't need to configure anything at client side (not even STUN server).

To say the truth, OpenSER does not do RTP relaying by itself, but it possesses all the needed "intelligence" for it, and can drive a relay software like RTPProxy. It is just a matter of installing rtpproxy and pointing OpenSER to rtpproxy control socket, the rest comes by itself.

Probably Asterisk can do the same as OpenSER does (and much more) but for an evening experience, it helped me to do what I wanted.

So now I have my own SIP domain and phone. I'm not sure if I will use it in place of Gizmo; my Gizmo account has dial-out and other nice capabilities. But I feel good :)

EPx.__dict__