quarta-feira, 28 de outubro de 2009

Minisaia na Uniban

http://www.youtube.com/watch?v=gWUyKgs0u-4

http://virgula.uol.com.br/ver/noticia/news/2009/10/28/226552-aluna-da-uniban-ameacada-de-estupro-no-campus-por-usar-minissaia

Para mim, a menina da minissaia é uma heroína, ao exercer a liberdade de escolher suas vestes, e destoar de uma regra implícita, velada por sociedade cínica e
hipócrita em que “estava” inserida.

As razões que explicam a reação dos estudantes vão muito além das simplificações sobre a qualidade da escola. A natureza humana é perversa, e mesmo submersos a um mundo de controle e disciplinas, carregamentos essa perversidade intrínseca em alguma parte de nossa mente.

Abaixo, trecho extraído da natureza do terrorismo:

“O terrorismo é uma manifestação da psique. A raiz psicológica do terrorismo é um ódio quase-psicótico do ressentimento fanático que origina nas profundidades da psique arquétipa.

Um exemplo literário clássico é de Melville, Moby Dick. O Capitão Ahab, com seu ódio fanático da baleia branca, é um paradigma do terrorista moderno. Os terroristas articulados expressam-se geralmente na terminologia (arquétipa) religiosa. O inimigo é considerado como o princípio de mal objetivo [“puta” em nossa versão da Uniban] e o terrorista percebe-se como herói, agente de justiça divina ou objetiva.

Para tratar o terrorismo eficazmente nós devemos compreendê-lo. Estes indivíduos não são criminosos e não são loucos embora tenham algumas qualidades de ambos. Vamos chamá-los de fanáticos. Os fanáticos são possuídos pelo arquétipos dinâmicos transpessoais que derivam-se da coletividade inconsciente.“

Para aqueles interessados em entender mais o assunto eu recomendo um estudo sério da psicologia de C.G. Jung.

sexta-feira, 23 de outubro de 2009

Bolsa Família - Além de Bom é Mágico ??? (2)

Uma longa discussão foi travada por conta de um artigo "científico" sobre se o bolsa família gera renda (veja post anterior). Para quem quiser conferir, o artigo está no link:

http://www.ipc-undp.org/publications/mds/33P.pdf

(Agradeço aqui Warrior e Delmar pelos esclarecimentos).

O objetivo do presente post e fazer uma análise desse artigo do senhor Paulo Henrique Landim Junior e seu prof. Dr. Naercio Aquino Menezes Filho:

A idéia do trabalho desses autores é confrontar dois grupos: aqueles que mais se beneficiaram com o bolsa família, e o os demais que servirão como grupo de controle aos dados observados.

“Para aprofundar esta análise, destacamos os municípios onde mais de 50% da população é beneficiada pelo Programa Bolsa Família. Esses municípios foram comparados com outros, onde uma parcela menor da população é beneficiada. Para isso foram criados e analisados os dois grupos de municípios: aqueles em que mais de 50% da população é beneficiada pelo PBF (grupo 1) e aqueles em que menos de 50% da população é beneficiada pelo PBF (grupo 2).” (página 10)

Feito essa divisão, é analisado, para cada grupo, o aumento do PIB e o aumento do bolsa família e constatado que com uma margem de confiança de 62,38% (ver regressão econométrica nas páginas 16 e 17) que o aumento do PIB e o aumento do repasse per capita nos municípios mais beneficiados são correlacionados.

Agora vamos refletir nesses números: por que eles são óbvios? A resposta é porque quase 62% da população ativa desses municípios recebeu o bolsa-família (página 11).

Sejamos mais radiciais para entender a questão. Vamos imaginar um outro cenário…Antes do bolsa-família, esses 62% da população não recebiam nada. Então, a partir de um certo ano, o governo passou a repassar o BF a essa população. Será que haverá alguma corelação do repasse com o PIB desses municípois? É evidente que sim, a população que contriui com o PIB do município quase triplicou.

O BF destinado a esses 712 municípios mais beneficiados não vieram deles (apenas uma fração ínfima – o PIB total desses municípios é de R$33.350.080.000,00 (página 11)), mas dos outros 4789 municípios da união. Isso chama-se repasse, e é o propósito do programa (transferir renda dos mais pobres para os mais ricos). O PIB influenciado pelo BF cresceu nessa região porque diminuiu (o PIB influenciado pelo BF) em outro lugar. É como tirar a água de um balde e jogar em outro, sugerir que como o primeiro balde está ficando seco, os baldes ficarão sem água.

Ainda, analisando o trabalho:
“Estimou-se um aumento de 0,06% no PIB per capita para cada aumento de 1% no valor de repasse per capita.”

Vamos aceitar a margem de confiança de 62% e concordar que para os 472 municípios mais beneficiados com o BF, ocorreu um aumento de 0,06% no PIB per capita para cada aumento de 1% no valor de repasse per capita, e, o que o estudo não fala, que nos demais municípios, de onde saiu esse dinheiro, o BF impactou negativamente no PIB. Daí, temos que é inaceitável concluir o seguinte:

“(..). Com base nessas informações é possível obter o benefício estimado da expansão do Programa Bolsa Família no ano de 2006. Para isso basta multiplicar 0,06 por 30,34. O valor obtido, 1,82%, é o impacto estimado do aumento de 30,34% no repasse per capita sobre o PIB dos municípios [TODOS]. Em 2006 o PIB brasileiro foi R$ 2.369.797.000.000 e, portanto um aumento de 1,82% neste significa um acréscimo de R$ 43.139.784.588,00.”

sexta-feira, 16 de outubro de 2009

Bolsa Família - Além de Bom é Mágico ???

Saiu no Estado de São Paulo os resultados de um estudo sobre o impacto da ampliação do Bolsa Esmola na Economia. Basicamente é o seguinte: com os 1,6 bilhão de Reais adicionais investidos no programa (de 2005 a 2006.), o governo impulsionou o PIB em 0,6% (43,1 bilhões de reais).


O significado disso é muito óbvio: de acordo com o estudo o estado não deveria perder seu tempo a não ser fazer algo que multiplica por 25 o dinheiro investido! O que não fica claro é como isso é possível. A explicação apresentada no jornal é o chamado multiplicador keneysiano. As pessoas inclusas no projeto fazem girar as engrenagens econômicas.

Bom, é díficil acreditar que demanda simplesmente gere renda... Existe um interessante post do Guilherme Stein "A Miséria do Multiplicador Keynesiano: A Lei de Say corretamente entendida", sobre esse problema. Talvez o programa tenha afetado a economia local (regiões com mais bolsas famílias distribuídas), e o jornal "estrategicamente" omitiu esse fato.

(Será? Bom houve uma longa discussão sobre o assunto no blog do JPK).

É até vazio dizer mais alguma coisa sem ter acesso ao trabalho (tive acesso e publicarei os resultado). Por outro lado, as pessoas que criticam o projeto (sem pesar seus benefícios) parecem que estão anos luz de conhecer os fatos; Simplesmente não dá para discutir se o projeto é ou não bom. Isso é ponto pacífico. Algumas discussões cabíveis: por que publicar que o bolsa família aumenta o PIB? Como melhorar o projeto?



quinta-feira, 24 de setembro de 2009

Bolsa Esmola - Melhor programa ever

Tomo esse post como uma nota mental: "o bolsa esmola é o melhor programa ever". Comecemos pelos básico... O governo é uma máquina pesada, pesadíssima. O imposto brasileiro incomoda, drena 40% da renda. Isso deveria tornar o país numa social democracia: duas pessoas trabalham para sustentar uma terceira. Mas, por "algum motivo" a renda não é distribuida.

Uma pessoa do grupo dos 1% mais ricos "pode gastar em três dias o equivalente ao que um brasileiro do grupo dos 10% mais pobres levaria um ano para gastar". Ou ainda, a riqueza dos 1% mais ricos corresponde a renda dos 45% mais pobres. Uau... Comparemos isso com outros países do mundo, e encontramos 11 países em situação pior (dos 212 países analisados pela ONU): Namíbia, Lesoto, Serra Leoa, República Centro-Africana, Botsuana, Bolívia, Haiti, Colômbia, Paraguai, África do Sul. Parece ruim, não é!? Bom, é pior.
A parcela de 1% mais rico da população é aquela que tem renda per capita igual ou superior a R$4500,00.

Então voltemos ao problema do governo.. O super estado com um monte de funcionários, escolas, universidades, etc... consumindo recursos e mais recursos, não consegue fazer o óbvio: tirar esses milhões de brasileiros da miséria (uma distribuição equalitária de 33% da renda seria suficiente para isso). Mas o que? Que absurdo! Sair por ai distribuindo o meu dinheiro suado!!! Deixa para lá... É mais justo o governo saquear 40% da renda para não fazer nada, né!?

quarta-feira, 13 de agosto de 2008

Do Browser para Impressora - Considerações Finais

Problemas com XML-FO
Solução Flying Saucer


Apesar de ser apreciável a iniciativa da Apache com o XML-FO, o Apache FOP não está suficiente maduro para ser utilizado em qualquer
ocasião. Uma interessante alternativa é outro projeto que realiza uma transformação XSL mas diretamente para PDF. Esse é o projeto Flying
Saucer, que contém entre outras coisas suporte para CSS3. Para o meu problema, O Flying Saucer tem mostrado como a melhor solução em termos de precisão além de contar com qualidades como flexibilidade e eficiência.

Podemos verificar no projeto que ele faz uso do iText para gerar o arquivo PDF, mas tem a possibilidade de utilizar renderizadores para arquivos de saída diferentes.

Procedimento necessário

  1. Instalar o Flying Saucer e suas dependências no Classpath do seu projeto. No caso de um projeto WEB, adicionar as bibliotecas no
    diretório WEB-INF.

  2. Utilizar o JAPX (The Java API for XML Processing ) para converter um arquivo XML num documento DOM (org.w3c.dom.Document).

    DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
    InputSource inputSource = new InputSource(new InputStreamReader(arrayInputStream, "ISO-8859-1"));
    builder.setEntityResolver(new CatalogResolver());
    Document doc = builder.parse(inputSource);
  3. Passar o documento para o Flying Saucer:

    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    ITextRenderer renderer = new ITextRenderer();
    renderer.setDocument(doc, rootPath);
    renderer.layout();
    renderer.createPDF(bos);
PROBLEMAS COM ANÁLISE SINTÁTICA
Solução XML Catalog

Cabe aqui uma observação sobre o uso do Docbuilder – o analisador sintático (parser) de XML da especificação JAPX. O comportamento padrão do DocumentBuilder é processar o arquivo de origem com base nos recursos descritos nele mesmo, incluindo seus descritores como o DTD ou
XSD. O problema que a declaração do tipo do documento (Document Type Declaration or Doctype) geralmente aponta para a URL do publicador. Por exemplo :


DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
E especificações grandes como o Xhtml são particionados em vários fragmentos dtd que apontam para outros resultando numa míriade de documentos virtualmente remotos.

Para que o Docbuilder faça a análise sintática, é necessário que o processo tenha acesso a essas localizações. Num servidor de aplicação, acessos remotos poderiam ser impedido por questões de segurança. Nesse caso é preciso ter uma cópia de cada recurso localmente e utilizar um proxy que converta as localizações virtualmente remotas para os arquivos locais.

Na verdade, seria possível abrir arquivo por arquivo e procurar as referências remotas e trocá-las por referências locais, mas isso poderia dar um trabalho demasiado grande e sujeito a erros.

XML CatalogO propósito do XML Catalog da Apache Foundation (explicado em detalhes nesse artigo) é servir de proxy para o analisador sintático encontrar os recursos descritos nos documentos com localizações universais. A solução é bem simples. Uma objeto (Factory) cria o proxy com base num arquivo properties localizado no mesmo nível que o classloader. Isso é feito de forma transparente, ao instanciar um objeto da classe CatalogResolver.

A solução passo a passo seria a seguinte:


  1. Procure o projeto catalog da apache. Coloque o resolver.jar no seu classpath... (WEB-INF,etc)

  2. Baixe o sgml-lib da w3c. Adicione o contéudo do sgml-lib no diretório de códigos-fonte da sua aplicação.

  3. Adicione também o arquivo Catalog.properties.

    relative-catalogs=no
    catalogs=sgml-lib/xml.soc
    verbosity=0
    prefer=system
    allow-oasis-xml-catalog-pi=no
    static-catalog=yes
  4. E adiciona o suporte ao catálogo no Parser.
    builder.setEntityResolver(new CatalogResolver());

Problemas com Mime Type
Solução: Especificar o Mime Type


Ter um arquivo PDF em memória, não garante sua renderização correta no cliente. Essa questão é resolvida com atributos MIME. Aespecificação dos Servlet descreve como os tipos MIME podem ser especificados na interface de resposta (Response) do Servlet.

 response.setContentType("application/pdf");
response.setHeader("Content-disposition", "attachment; filename=NotaFiscal.pdf");
response.setContentLength(bos.size());
OutputStream os = response.getOutputStream();
bos.writeTo(os);
os.flush();
os.close();
Problemas com o processo manual de imprissão
Solução: Incluir Javascript no PDF

Em casos extremos, fornecer um arquivo PDF para o usuário, com o Adobe Acrobat Reader instalado em sua máquina não é o suficiente paraque ele se sinta a vontade para imprimir o documento corretamente. Para evitar maiores transtornos com a parte de treinamente, é possível automatizar o processo de impressão.

Para isso, felizmente, o arquivo PDF permite a inclusão de scripts que, por sua vez, permitem a interação entre os recurso da máquinacliente e o documento a ser exibido/imprimido. É uma excelente oportunidade para demonstrar como a API do iText pode incluir Script em um PDF ao mesmo tempo que automatizo a ação de imprimir na máquina cliente. Para realizar tal tarefa é necessário duplicar o documento a ser imprimido.

 PdfReader reader = new PdfReader(bytes);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
com.lowagie.text.Document document = new com.lowagie.text.Document(new Rectangle(585, 936), 0 ,0 ,0 ,0);
PdfWriter writer = PdfWriter.getInstance(document, bos);
document.open();
PdfContentByte cb = writer.getDirectContent();
document.newPage();
PdfImportedPage page = writer.getImportedPage(reader, 1);
cb.addTemplate(page, 0, 0);

Agora, basta incluir o fragmento Javascript via PDFWriter:


writer.addJavaScript("this.print({bUI: false,bSilent: false,bShrinkToFit: true});" + "\r\n"+ "this.closeDoc();");
document.close();
return bos;

Ufa! Isso é tudo.

Do Browser para Impressora - Parte 3

Teoricamente, recuperar a saída de um Servlet (em geral um documento em texto como o HTML, mas pode ser qualquer arquivo incluso na resposta do servidor) mesmo que seja um JSP, deveria ser fácil. O JSP é convertido em uma classe Java que segue uma interface da especificação do Java Servlet com todas os métodos necessários para recuperar sua saída. Infelizmente, as classes geradas encontram-se em um contexto que o Classloader que executa os servlets não tem acesso. Então, para acessar as saídas dos JSPs é necessário uma abordagem mais indiretas. Na arquitetura J2EE, temos os seguintes recursos à nossa disposição:

  • Filtros: antes do envio da resposta ao cliente a cadeia de filtros intercepta a mensagem e pode enviar uma nova mensagem baseado na mensagem interceptada;

  • RequestDispatcher.include: esse (novo) método permite um servlet programaticamente adicionar o conteúdo de outro, o que é semelhante a tag jsp:include;

  • new URL(urlLocation).openStream: método que abre uma conexão com a localização urlLocation e retorna um stream de dados para leitura;


A solução utilizando url.openstream é simples, mas exige uma nova conexão para o servidor de aplicação proveniente dele mesmo. E é preciso tomar o cuidado utilizar a mesma sessão do usuário. Para isso, basta concatenar a url solicitada como jsessionId.


Adapter Pattern

O uso de filtros ou do include method exige o uso de classes que sigam assinatura HttpServletResponse e do ServletOutputStream e que ao mesmo tempo, guarde as informações das chamadas em algum tipo de repositório. Essa é uma interessante aplicação do Adapter Pattern. O Adapter Pattern pode ser sumarizado da seguinte maneira.


Problema: (Múltipla herança) É desejado o comportamento de um objeto que infelizmente não segue uma assinatura específica.

Solução: Criar uma classe que implemente a interface e direcione as chamadas de forma apropriada ao objeto cujo comportamento é desejado.


Sendo o repositório escolhido para informações, um vetor de bytes. Escolhemos o ByteArrayOutputStream, que pode ser visto como um OutputStream e cujo resultado é guardado no vetor de bytes. Isso nos permite criar um objeto adaptado a interface ServletOutputStream e cuja implementação fica a cargo do ByteArrayOutputStream. Facilita também, utlizar o PrintWriter que já realiza as operações de Writer do ServletOutputStream. Esse PrintWriter deverá escrever diretamente no objeto ByteArrayOutputStream. Isso é feito ao passarmos esse objeto no construtor do PrintWriter.


Uma vez que temos essa classe, implementar a classe ServletResponse é muito simples:


public class FakeServletResponse extends HttpServletResponseWrapper{

private ByteArrayOutputStream contentBuffer;

private PrintWriter writer;

private FakeServletOutputStream servletOutputStream;

public FakeServletResponse(HttpServletResponse response) {

super(response);

}


public PrintWriter getWriter() {

if(writer == null){

contentBuffer = new ByteArrayOutputStream();

writer = new PrintWriter(contentBuffer);

servletOutputStream = new FakeServletOutputStream(writer, contentBuffer);

}

return writer;

}

public ServletOutputStream getOutputStream() throws IOException {

getWriter();

return servletOutputStream;

}


public byte[] getData() {

getWriter().flush();

return contentBuffer.toByteArray();

}

}


E então podemos utilizar o include method:

private FakeServletResponse includeJsp(ActionMapping mapping, ActionForm form, HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {

request.getSession().setAttribute("geraNota", Boolean.TRUE);

FakeServletResponse fakeServletResponse = new FakeServletResponse(response);

BuscaNotaAction buscaNotaAction = new BuscaNotaAction();

buscaNotaAction.execute(mapping, form, request, fakeServletResponse);

RequestDispatcher requestDispatcher = request.getRequestDispatcher("/jsp/operacoes/notaFiscal/imprimeNota.jsp");

requestDispatcher.include(request, fakeServletResponse);

return fakeServletResponse;

}


quarta-feira, 23 de julho de 2008

Do Browser para Impressora - Parte 2

Ao invés de utilizar o browser para enviar um documento HTML para a impressora, podemos fazer uso de técnicas mais indiretas. Para isso, devemos utilizar um padrão que facilite manipulação de seu conteúdo. O padrão apropriado é o XHTML. Antes de explicar como o XHTML pode ser usado para transformação de um documentos em comandos de impressão, consideremos outros benefícios de se utilizar o XHTML no lugar do HTML.

XHTML

Uma das interessantes convergências tecnológicas é o padrão XML. O XML é uma especificação de texto com marcações derivado do SGML, que utiliza uma gramática mais restrita.

Por uma especificação de texto com marcações eu quero dizer que o XML possui marcadores que definem uma certa propriedade do texto: por exemplo que um certo fragmento é um paragrafo (

Isso é um parágrafo

), ou o nome de diretor de cinema(Tim Burton, etc. Por uma gramática mais restrita eu quero dizer que a definição do que pode e o que não pode no XML é mais simples. Para maiores informações veja: diferenças entre o HTML e o XML.

Essas características tornam mais fácil a construção de analisadores sintáticos. Por esse motivo, o XML é utilizado como base para uma gama de atividades relacionadas com troca de informações por arquivo texto. O XHTML foi criado para agregar, ao HTML, esses valores.

O XHTML é basicamente o padrão HTML como algumas adaptações para contemplar as restrições do XML. Nada muito complicado. E esse rigor trouxe algumas vantagens adicionais:
Adaptabilidade – o conteúdo é facilmente convertido para outros formatos;
Previsibilidade – enquanto existe um padrão definido para renderizar um documento HTML o mesmo não acontece para um documento mal-formatado. Um navegador ao renderizar um documento desse tipo entra no modo chamado quirks. Não existe um padrão para o modo quirks de tal sorte que o resultado pode variar em cada navegador. A fácil verificação que um documento é aderente a especificação do XHTML torna supérfluo a renderização por modo quirks. Também, os criadores de parser são guiados por uma especificação mais simples o que os leva a cometer menos erros;
Legibilidade – o documento é mais legível para máquinas e seres humanos devido a simplicidade da gramática;

Vejamos esse primeiro quesito. O XHTML permite o uso de uma família de linguagens de transformação chamado XSL (Extensible Stylesheet Language). O XSL é a definição da W3C que trata transformações no XML. Essa tecnologia define como um XML pode ser transformado para um XHTML, um arquivo texto qualquer ou num XSL-FO. É possível inclusive delegar aos navegadores essa tarefa de transformação. Muitos navegadores modernos, inclusive o Internet Explorer 5.0 suportam o uso do XSL para realizar transformações nos documentos.

XML-FO

XML-FO é um padrão de descrição para impressão. O XML-FO não possui todos os detalhes da impressão, mas é suficientemente rico para conter grande parte das descrições utilizadas na impressão. Note que o XML-FO é também um documento que segue a especificação XML. Basicamente, seu uso consiste de uma transformação subseqüente em que o documento é finalmente convertido para um de impressão: tipicamente o PDF.

No site da Antenna House é possível encontrar scripts de transformação do XHTML para fo ( xhtml2fo.xsl). Agora, com o uso de bibliotecas de manipulação do XML como o Xalan, é possível com um comando converter o XHTML para XSL-FO.

java -classpath $CLASSPATH org.apache.xalan.xslt.Process -IN -XSL xhtml2fo.xsl -OUT -tt

Docbook

Para exemplificar o mecanismo de transformação de um XML para PDF, vou utilizar um script Ant que utilizo para converter meus arquivos docbook para PDF. Para o XHTML o mecanismo é o mesmo, o que muda é o arquivo XSL responsável pela transformação.

Docbook que é uma linguagem própria para documentação cujo enfoque é a semântica. A filosofia básica por trás do Docbook é discriminar o valor semântico de cada parte de um texto. Por exemplo: para um computador o fragmento

título

não significa necessariamente o começo de uma seção ou capítulo; No Docbook é possível especificar exatamente esse tipo de informação (começo ou fim de uma seção, capítulos, ênfase, etc)... mas o padrão não fala nada sobre a formatação. Fica a cargo de outros mecanismos cuidarem para que elementos sejam corretamente formatados.

Um projeto para converter o docbook poderia conter os seguintes elementos:

Ambiente de desenvolvimento com Java 1.4, Apache Ant e Apache Fop (já inclui o Xalan e o Xerces) instalados.
Diretório src incluindo os fontes em docbook.
Diretório output onde serão gerados os arquivos em pdf.

Na raiz do projeto, poderia ser criado o script do Ant (build.xml) responsável por invocar as classes responsáveis pelo processamento. O Ant dispõe de mecanismos para invocar a máquina virtual do Java para executar um comando específico. Felizmente, nem mesmo isso é necessário, porque essas bibliotecas já dispõe de tags para que realizam a transformação do documentos:


xslt classpathref="xalan.classpath" style="${fo.stylesheet}" extension=".fo" basedir="${source.dir}" destdir="${fo.dir}"
include name="${target.name}.xml" /
/xslt

fop format="application/pdf" fofile="${fo.dir}/${target.name}.fo" outfile="${fo.dir}/${target.name}.pdf" /