Acabei de subir uma versão atualizada (com algumas correções e melhorias) do CFC para cálculo geodésico; enjoy!
Não faz muito tempo, o PHP sempre me despertou uma certa curiosidade em termos de desenvolvimento, não só pelo fato de ser gratuito, mas também por ser mais popular do que o CF.
Claro que toda essa visão um tanto poética tem um interesse prático e descarado: se por um lado o ColdFusion se mostra uma ótima RAD para desenvolvimentos relâmpagos, manutenção prática e fácil, sem maiores estripulias com compilações, etc, por outro, ele acaba sendo caro demais para alguns poucos clientes; daí a saída de sempre ter uma segunda carta na manga; carta essa que não deve ser necessaramente tão ruim ou que acabe estourando os prazos para desenvolvimento, mas que no mínimo seja compatível com o CF em termos de tempo de desenvolvimento/implementação e com um plus a mais: que não seja cara. Entretanto, para este último parágrafo, o PHP até pouco tempo atrás, se mostrava muito chato, demorado e complicado demais em certas ocasiões, sobretudo por suas peculiaridades em relação à sintaxe, estrutura de código, etc; mas como tudo na vida tende a melhorar e a inovar (CF 8 que o diga), o danado do PHP acabou encontrando outras vias para me conquistar: trata-se do CodeIginiter.
Para quem não sabe o CI, como é conhecido para os íntimos, é um framework open source, muito bem feito e estruturado para o desenvolvimento em PHP,ao mais famoso estilo MVC, patrocinado pela não tão conhecida ellisLab; ele possui um core bastante poderoso de classes, tornando fácil a automatização de tarefas óbvias e particularmente chatas: conexão com banco de dados, trace/dump de ações de back-end, entre outras coisitas mais, sendo possível inclusive, extender suas funcionalidades através de plugins e do desenvolvimento de suas próprias classes; ele lembra um pouco os conceitos do CF on Wheels em termos de implementação, o que ajudou bastante para assimilar muita coisa; diria que o CI está para o PHP como o CF está para o JAVA, mas de uma maneira bem mais transparente e compreensível, pelo menos para mim. E para não achar que tou puxando muita sardinha para o garoto, vale lembrar que o CI foi capaz até mesmo de arrancar elogios do próprio criador do PHP: "because it is faster, lighter and the least like a framework", segundo palavras do próprio Rasmus Lerdorf, numa recente conferência.
Novidades são sempre bem-bindas e devo confessar que as tags do CF estavam manjadas demais, e que eu precisava mudar um pouco a linha de codificação: tags, no more... (rsrsrsr, brincadeirinha, pessoal). A grande verdade é que no final das contas acabei alterando meu veredicto final para a escolha da minha segunda cartada, e que inclusive estou fazendo uso em um dos meus projetos; é esperar pra ver como vai ficar.
... para quem não começa de maneira fácil.
Se não fosse pelo fato de ter começado a programar em ColdFusion, diria que ao longo da minha jornada no mundo da programação, eu teria quebrado menos à cabeça para assimilar alguns paradigmas do desenvolvimento de software; e neste tocante, nem me apego à questão da curva de aprendizado ser muito curta, mas sim, ao fato do CF ser baseado em tags, o que foge à regra da maioria das linguagens para web e o que de certa forma, acabou deixando os recém desenvolvedores confusos sobre uma série de conceitos importantes.
Orientação à objetos, conceitos de acesso/leitura, de conexão OPEN/CLOSE, são alguns dos exemplos que o CF por ser tão "fácil", acabou meio que emburrando as pessoas em relação à eles.
Para sintetizar de maneira mais completa o que quero dizer, vale a leitura do post do Rodrigo Urubatan, que sem muita hipocresia desmascara a grande verdade para a maioria das pessoas que como eu, de uma maneira ou de outra começaram com linguagens fáceis, e tivemos que assimilar o conceito de OOP: nos ferramos!
Orientação a objetos é fácil, as pessoas é que complicam
Dica rápida: ao contrário do que muita gente imagina, a cláusula rownum do oracle - geralmente utilizada para limitar a quantidade de registros que uma query pode trazer - não funciona corretamente caso você considere a hipótese de que o atributo ROWNUM é uma propriedade da tabela.
Para ficar mais fácil o entendimento, imagine a seguinte query:
select * from <tabela> where ROWNUM > 1;
Caso você execute essa query, verá que registro nenhum será trazido; isso porque, a pseudo coluna ROWNUM somente passa a existir, depois do resultSet retornar do banco; neste caso, se a a intenção é limitar os itens de um determinado select, considerando algum tipo de ordenação a forma correta do select acima seria, no caso de limitar os resultados em apenas 5 itens seria este:
select *from (select * from <tabela> order by sal desc) where ROWNUM <= 5;
Como se pode ver, primeiro é necessário trazer os registro do banco (obter o resultsSet), para que depois disso, se possa limitar a quantidade de linhas, através do ROWNUM.
Uma ótima documentação para aprofundar o entendimento desse e de outros tipos de abordagens do ROWNUM, você pode conferir em: http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html
O Adobe ColdFusion a partir da versão 7, passou a ter a capacidade de gerar documentos PDF e FlashPaper de maneira "on the fly", tornando uma tarefa que antigamente era trabalhosa e chata (alguém lembra da custom CF_PDF? argh?!..) em algo simples na hora de gerar tais documentos.
A tal facilidade passou a ser um problema dia desses, quando implementei em um dos meus clientes a função de geração em formato PDF de documentos, para padronizar a impressão; pois bem, ocorre que por motivos de log dos arquivos que eram gerados, ficou definido que os mesmos, seriam salvos fisicamente no servidor, para que posteriormente fossem anexados e enviados por email; a intenção de salvar localmente os arquivos era tão somente por conta do envio desse log por e-mail; tanto, que na configuração da geração do arquivo .pdf, defini um valor padrão para o nome do arquivo, que seria substituído em request futuros, caso o arquivo já existisse.
O mecanismo até que funcionou perfeitamente por alguns dias, até que outros usuários, começaram à fazer uso da função, causando repentinamente em horários de pico de uso do sistema, uma lentidão considerável do application server e um erro estranho na tentativa de geração do documento:
ExceptionConverter: java.io.IOException: The document has no pages. at com.lowagie.text.pdf.PdfPages.writePageTree(Unknown Source) at com.lowagie.text.pdf.PdfWriter.close(Unknown Source) at com.lowagie.text.pdf.PdfDocument.close(Unknown Source) at com.lowagie.text.Document.close(Unknown Source) at coldfusion.tagext.lang.DocumentTag.doAfterBody(DocumentTag.java:1225)(...)
Depois de tanto alterar código, pensado que fosse algo ligado à performance da geração, ou até algum possível bug, com uma suposição com relação à escrita de arquivos em disco rígido, a primeira linha (ExceptionConverter: java.io.IOException: The document has no pages.) foi matadora para diagnoticar o que estava acontecendo: a condição de gravar o arquivo de log, sempre gerava o mesmo nome para o dito cujo: algo parecido com xyz.pdf. E era exatamente essa a condição errônea: deixar que dois usuários pudessem gerar um arquivo pdf com o mesmo nome em um mesmo diretório: erros de io geralmente são derivados de situações de escrita ou leitura, e permitindo que usuários tivessem acesso à essa geração sem qualquer tipo de controle, fazia com que o erro fosse lançado (o mecanismo de geração do PDF, simplesmente não conseguia criar dois documentos de forma simultânea), e deixasse o app server lento (enquanto o request, não era abortado, o CF aguardava a liberação de escrita).
A dica para resolver o problema ficou por conta de alterar a condição de nomeação dos arquivos para impedir esses tipos de acessos inválidos;
Entretanto, a mensagem "The document has no pages." possui uma outra causa, por conta de problemas na resolução de DNS quando se referencia arquivos externos no documento tais como imagens, etc. Encontrei durante minha pesquisa para solução do problema, um post que comenta em detalhes o motivo e a solução para este outro problema.
Terminei recentemente a implementação de um componente em ColdFusion para calcular a distância entre dois pontos, dados a latitude a longitude de ambos; para evitar que você passe pelo caminho das pedras para encontrar o cálculo, segue o fonte para downlod...
Desde já críticas e sugestões de novas implementações são bem vindas!
Enjoy!
Para quem se lembra dos vários outros blogs por onde já passei, cheguei à escrever alguns artigos em forma de tutorial para o pessoal novo que está chegando, ou que por algum motivo tem curiosidades de conhecer alguns meandros do Adobe ColdFusion, enquanto application server.
Fiz uma coleção desses artigos em uma sessão específica aqui no site da VIBE, só para isso; para galera que já leu, vale como consulta/referência e para os novatos, vale a pena a leitura.
Faaaaaaaaaaaaaaaaaaaaaala galera!
Pela vigésima oitava vez, aqui estou retornando ao mundinho da blogsfera para compartilhar minhas revoltas, descobertas e dúvidas com vocês; após uma longa pausa, aos poucos as coisas estão voltando à normalidade da não frenética correria.
Tão logo termine de organizar as coisas, volto à trocar idéia com vocês.
