thegoodfellas/blogset-br huggingface dataset:
plano de abatimento destas, parcelado ou nao. Deste modo voce nao tornara o seu time, a proxima Grecia da TI.Ps - E importante ressaltar que estou chamando de gambiarra aqui, solucoes que nao sao as mais rapidas ou mais recomendadas mas que geram um produto que apresenta os resultados esperados, sejam logicos ou matematicos. Entregar intencionalmente um produto que informa dados invalidos, que so parece que funciona, nao e apenas uma gambiarra, e trapaca! pra la de bandidagem. Nesse cenario e melhor jogar limpo com o cliente que nao e possivel entregar o produto no prazo do que entregar uma fraude.
mascaras para entradas de valores em dinheiro, entradas de datas, etc., pense seriamente no impacto de alterar essa sua mascara para funcionar num navegador novo, por exemplo.Um outro problema frequente e que os programadores nao se preocupam tanto com a qualidade do HTML gerado. Basta tentar validar o seu projeto com alguma das ferramentas disponiveis, tais como o http://validator.w3.org/ para perceber isso. E muito comum que o HTML valido que o designer passa para a equipe de programacao, e alterado varias vezes pela equipe de programacao, ate que passa a apresentar varios erros de HTML, que sao simplesmente ignorados pelos programadores. A complexidade de algumas solucao de Template, dificultam ainda mais o controle sobre o HTML desenvolvido. Uma solucao classica de cabecalho e rodape gera um problema muitas vezes dificil de resolver. Nao sera intuitivo, para quem for dar manutencao nos seus arquivos, saber qual e, de todos os arquivos que contem HTML, aquele que fecha a tag da tabela que e aberta no arquivo atual. Finalmente uma camada de Template pode facilitar a utilizacao de solucoes complexas de modo mais transparente e padronizado. Por exemplo, transformar um formulario de submissao tradicional POST em Ajax pode ser automatizado pela ferramenta desde que informado algum atributo especifico. Evita-se assim a criacao de varias solucoes diferentes para o mesmo problema que alem de serem um problema para a manutencao do projeto e um desperdicio do tempo de desenvolvimento do programador. Mais argumentos sobre isso voce pode encontrar aqui.Smarty ja nao e bom o bastante?Entre as solucoes disponiveis de Templates para PHP, o Smarty certamente e a mais popular. O Dwoo intenta ser uma versao um pouco mais moderna do Smarty, mas mantendo o maximo possivel de compatibilidade e mantem tambem varios dos problemas descritos abaixo. As outras solucoes encontradas, tais como o Sigma, Twig, Haanga tambem apresentam alguns dos problemas citados no caso do Smarty.Os principais motivos que nos levou a decidir nao utilizar o Smarty foram:Nao disponibilizar validacao do HTML gerado; Para o Smarty, assim como no PHP nativo, o resultado gerado e um texto. Se o texto gerado e um HTML ou nao, e um controle que e feito apenas pelo programador. Deste modo, caso o HTML gerado nao seja valido, o Smarty nao ira fazer nenhum tipo de alerta a respeito, deixando o resultado invalido ser entregue ao usuario.Nao ser XML; Praticamente qualquer IDE e capaz de fazer uma validacao de XMLs. O padrao XML e conhecido tanto por designers quanto por programadores e e o formato padrao em que o XHTML e escrito. Nada faz mais sentido de que o proprio Template seja tambem em XML.Nao ser flexivel para novas funcionalidades; O Smarty, segundo a avaliacao da nossa equipe, se mostrou pouco flexivel para a criacao de novas funcionalidades. Chegamos ate a editar algumas das expressoes regulares do Smarty para tentar deixar o comportamento dele mais flexivel antes de decidirmos partir para uma solucao propria.Nao ser orientado a objetos.Por ter sido desenvolvido para PHP4. O Smarty nao faz uso dos recursos de orientacao a objetos do PHP5. Um componente de
valores de outras tags, a media dos valores, etc. sem exigir conhecimento de javascript.Uma das ideias das proximas e viabilizar a "adequacao" do html de resultado para o navegador do cliente. O programador / designer continuara escrevendo HTML5 e sera de responsabilidade do framework fazer as "correcoes" necessarias para funcionar nos browsers nao modernos.Por ultimo, tendo em vista que temos uma versao server side da pagina do usuario, podemos armazena-la na sessao, e entao fazer uma sincronia das alteracoes usando ajax. Em outras palavras, podemos fazer manipulacoes server side no objeto tela, a partir de eventos de tela enviados ao servidor, que depois e sincronizado no cliente via ajax. Esse passo ainda esta em iniciacao no Inep Zend mas no Coruja Php Framework ja conseguimos isso com sucesso. Chegamos a desenvolver uma planilha similar ao Excel / Calc utilizando esta tecnica com toda logica de negocio necessaria para a interpretacao das formulas e alteracao em cascata do valor dos campos no Server Side.Alem de tudo, nao obrigamos nossa equipe a utilizar esse template o tempo todo. Conforme foi dito mantemos a compatibilidade do tudo que ja funcionava no Zend, inclusive o phtml. Entao, caso numa pagina ou layout o uso do template se mostre desnecessario ou inadequado, o programador pode fazer uso da solucao padrao do Zend. Pode-se ate pensar de maneira invertida, utilizando sempre phtml e ter essa ferramenta de template caso se deseje fazer alguma pagina de maior complexidade.Espero ter esclarecido,Thiago Mata.Rafael Barbosa disse...Caro Thiago,posso postar no seu blog esse comentario depois sem problema.Eu entendo o embasamento que voce teve de outras ferramentas, e acho valida a iniciativa de querer melhorar as ferramentas de trabalho. O que me preocupa e o tempo gasto com algo que, a meu ver, tem muito mais desvantagens do que vantagens.A parte da validacao de markup nao deveria ser responsabilidade da framework e pode ser remediada de N formas. A mais simples delas e exigir a validacao das paginas com as ferramentas da w3c na rotina de testes/homologacao do seu sistema. Isso e muito simples de justificar e eu julgo necessario mesmo tendo a validacao interna no pre-processamento da requisicao. Logo, esse problema de validacao tem uma solucao que nao necessita escrever 1 linha de codigo.O custo da transformacao do markup para objeto se torna linear se vc usar algum ferramenta (por mais simples que seja) de cache. Eu nao disse que o custo era ALTO e sim DESNECESSARIO (usei o termo OVERKILL). O que voce vai ter com isso e mais um ponto de falha, mais um modulo para dar manutencao e mais um pedaco da sua arquitetura para documentar e testar sem ter o ganho que isso deveria te proporcionar.Quanto as tags personalizadas elas ja existiam no Smarty (apesar de ser um inferno extender aquilo) e existem no Twig (que na minha humilde opiniao e a melhor engine de template que existe) e em outras ferramentas. Talvez o que exista no seu caso seja uma preferencia em usar tags fechadas por <> (o que eu nao acho legal, mas entendo ser outra questao),
nesse caso basta alterar uma dessas bibliotecas para utilizar as tags como voce gosta, assim voce nao precisa reinventar a roda.Guardar a pagina do usuario em sessao e atualizar via ajax. Isso realmente e algo que voce deveria repensar antes de implementar. Alguns motivos para isso:1 - Voce ja tem todo o DOM bonitinho na tela do seu usuario ( em JavaScript). Ter isso em sessao e simplesmente duplicar uma informacao, uma vez que o servidor nao pode fazer muita coisa com ela.2 - Tudo que existir na tela (client) vai ter que de alguma forma sincronizar de volta com o servidor. Isso e completamente desnecessario, visto que o browser ja armazena o estado da tela e em ultimo caso voce pode armazenar isso em um cookie via javascript e poupar uma requisicao.3 - Quando voce mandar do servidor de volta todo o markup pra tela do cliente voce vai precisar carregar de novo todos os binds de objetos no javascript (inclusive os que nao mudaram), o browser vai ter que renderizar de novo a pagina toda. (O cache ajuda, mas nao vai fazer milagre)4 e mais importante: Se voce, de alguma forma, for atualizar pedacos da interface com a resposta do servidor em vez de atualiza-la por completo, qualquer framework de javascript faz esse trabalho de forma stateless/rapida e ainda te permite alterar o history do browser com o pushState sem quebrar o botao de voltar.A parte de corrigir o markup de acordo com a versao do browser faz sentido, mas dificilmente voce vai esbarrar com uma situacao em que alterar o html resolva uma incompatibilidade que voce nao consiga resolver com alguma camada de abstracao pronta em javascript/css.Mais uma vez, eu aprecio a iniciativa e pelo nivel de complexidade de uma ferramenta dessas eu acredito que voce e os membros da sua equipe sejam otimos programadores, mas acho que a forca de trabalho de voces deveria ser utilizada pra construir algo novo e melhor e nao ficar reescrevendo ferramentas que ja existem.Da uma olhada do que tem sido feito nos projetos da sensio-labs. Especialmente o Symfony 2 e o Doctrine 2. Eles estao escrevendo as bibliotecas mais avancadas em php 5.3 que existem. Vale a pena dar uma olhada e tentar participar dessa evolucao da das ferramentas e da linguagem junto com a comunidade.Atenciosamente,Rafael BarbosaThiago Mata responde...Gostei dos seus comentarios como sempre,Eu entendo o embasamento que voce teve de outras ferramentas, e acho valida a iniciativa de querer melhorar as ferramentas de trabalho. O que me preocupa e o tempo gasto com algo que, a meu ver, tem muito mais desvantagens do que vantagens.Ainda nao vi tantas desvantagens. Replicar as tags do HTML foi um trabalho massante, de fato, mas feito com baixa complexidade e em relativamente pouco tempo. Bastou lermos a especificacao do Mozilla http://developer.mozilla.org/en/HTML/Element/ e como eu te falei nao tem tanto impacto na performance. A complexidade do codigo nao e tao grande e pretendemos fazer bons testes com ele com PHPUnit o que deve reduzir consideravelmente a chance de algum erro. Entao nao vi as desvantagens. A
parte da validacao de markup nao deveria ser responsabilidade da framework e pode ser remediada de N formas. A mais simples delas e exigir a validacao das paginas com as ferramentas da w3c na rotina de testes/homologacao do seu sistema. Isso e muito simples de justificar e eu julgo necessario mesmo tendo a validacao interna no pre-processamento da requisicao. Logo, esse problema de validacao tem uma solucao que nao necessita escrever 1 linha de codigo.Estou certo que nao preciso te lembrar que todas as paginas sao dinamicas e testar todas as combinacoes pode ser um trabalho sem fim. Garantir continuamente a qualidade do HTML e um ponto positivo. O teste de validacao vai continuar existindo mas sera feito sempre em algumas poucas das saidas possiveis. Alem do que as mensagens de erro do Framework podem ser mais claras do que a validacao externa como mostrar em qual arquivo de Template o erro aconteceu. Lembrando que essa validacao de atributos obrigatorios, valores default, etc. deve existir para as tags personalizadas entao estamos reaproveitando esse recurso para validar tambem as tags do HTML.Quanto as tags personalizadas elas ja existiam no Smarty (apesar de ser um inferno extender aquilo) INFERNO!!!e existem no Twig (que na minha humilde opiniao e a melhor engine de template que existe) e em outras ferramentas. Talvez o que exista no seu caso seja uma preferencia em usar tags fechadas por <> (o que eu nao acho legal, mas entendo ser outra questao), nesse caso basta alterar uma dessas bibliotecas para utilizar as tags como voce gosta, assim voce nao precisa reinventar a roda.Ate onde eu sei. O Twig ainda segue uma linha de templates de arquivos incluindo arquivos que ja vi varias vezes fugindo de controle. Mas prometo que vou avalia-lo mais a fundo. Se ele se mostrar uma solucao que venha a atender nossas necessidades nos poderemos passar a utiliza-lo ou deixa-lo como uma opcao de template alternativa.Guardar a pagina do usuario em sessao e atualizar via ajax. Isso realmente e algo que voce deveria repensar antes de implementar. Alguns motivos para isso:1 - Voce ja tem todo o DOM bonitinho na tela do seu usuario ( em JavaScript). Ter isso em sessao e simplesmente duplicar uma informacao, uma vez que o servidor nao pode fazer muita coisa com ela.2 - Tudo que existir na tela (client) vai ter que de alguma forma sincronizar de volta com o servidor. Isso e completamente desnecessario, visto que o browser ja armazena o estado da tela e em ultimo caso voce pode armazenar isso em um cookie via javascript e poupar uma requisicao.3 - Quando voce mandar do servidor de volta todo o markup pra tela do cliente voce vai precisar carregar de novo todos os binds de objetos no javascript (inclusive os que nao mudaram), o browser vai ter que renderizar de novo a pagina toda. (O cache ajuda, mas nao vai fazer milagre)4 e mais importante: Se voce, de alguma forma, for atualizar pedacos da interface com a resposta do servidor em vez de atualiza-la por completo, qualquer framework de
javascript faz esse trabalho de forma stateless/rapida e ainda te permite alterar o history do browser com o pushState sem quebrar o botao de voltar.1. Ter 100kb a mais para cada sessao de cada usuario logado nao e exatamente um problema terrivel. Lembre-se que essa pagina ja existe como arvore de objetos no servidor entao eu so serializo e salvo na sessao. No ambiente de producao muitas vezes os "arquivos" da sessao ficam numa area da memoria RAM. Entao fica muito realmente rapido. Podemos tambem guardar esse dado serializado em outros lugares alem da sessao como no banco ou num arquivo separado, etc.2. Nao entendi. Tenho a impressao que voce nao entendeu exatamente como nos fizemos essa sincronia. As operacoes nesse contexto vao acontecer no servidor. Veja GWT, que e algo muito similar a isso.3. Nao vamos mandar de volta uma versao toda nova da tela. Apenas receber um json com o que mudou em quais tags. Novamente recomendo voce dar uma boa olhada no GWT.4. Pretendo sim utilizar algum framework Javascript para fazer essa comunicacao com o servidor. Mas isso nao impede de precisamos de um servidor capaz de receber o evento e saber quais tags devem ser alteradas e quais devem ser seus novos conteudos etc.Thiago Mata.Rafael Barbosa disse...Caro Thiago,Ainda nao vi tantas desvantagens. Replicar as tags do HTML foi um trabalho massante, de fato, mas feito com baixa complexidade e em relativamente pouco tempo. Bastou lermos a especificacao do Mozillahttp://developer.mozilla.org/en/HTML/Element/ e como eu te falei nao tem tanto impacto na performance. A complexidade do codigo nao e tao grande e pretendemos fazer bons testes com ele com PHPUnit o que deve reduzir consideravelmente a chance de algum erro. Entao nao vi as desvantagens. Ter testes unitarios vai mesmo reduzir bugs e te ajudar a dar manutencao, o que nao quer dizer que essa manutencao deixe de existir. Como eu disse, como qualquer parte do sistema, tem que ter uma razao pra estar la senao nao vale o esforco de manutencao.Estou certo que nao preciso te lembrar que todas as paginas sao dinamicas e testar todas as combinacoes pode ser um trabalho sem fim. Garantir continuamente a qualidade do HTML e um ponto positivo. O teste de validacao vai continuar existindo mas sera feito sempre em algumas poucas das saidas possiveis. Alem do que as mensagens de erro do Framework podem ser mais claras do que a validacao externa como mostrar em qual arquivo de Template o erro aconteceu. Lembrando que essa validacao de atributos obrigatorios, valores default, etc. deve existir para as tags personalizadas entao estamos reaproveitando esse recurso para validar tambem as tags do HTML.Manter o HTML valido sempre e interessante, mas eu acho que isso deveria ser uma tarefa executada ao empacotar sua aplicacao e nao a cada request. Uma solucao mais limpa (e que nao exigiria a recriacao das views da sua aplicacao) seria a criacao de testes de aceitacao pra cada uma das funcionalidades onde, alem de executar o teste de aceitacao da especificacao voce utilizasse os webservices da W3C para validar o markup gerado
ao final do teste. Da um pouco de trabalho adaptar o PHPUnit pra fazer esse tipo de teste mas o tempo que isso vai te poupar a longo prazo e absurdo!Ate onde eu sei. O Twig ainda segue uma linha de templates de arquivos incluindo arquivos que ja vi varias vezes fugindo de controle. Mas prometo que vou avalia-lo mais a fundo. Se ele se mostrar uma solucao que venha a atender nossas necessidades nos poderemos passar a utiliza-lo ou deixa-lo como uma opcao de template alternativa.Como todo codigo extensivel (e isso inclui o proprio php) se voce nao definir um padrao de uso os arquivos vao fugir do controle. Como exemplo o ministerio da saude migrou de phtml para twig. Os arquivos em si nao mudaram, so o conteudo, o twig nao exige nenhuma extensao especifica. Dessa forma a sanidade em relacao aos arquivos foi mantida.1. Ter 100kb a mais para cada sessao de cada usuario logado nao e exatamente um problema terrivel. Lembre-se que essa pagina ja existe como arvore de objetos no servidor entao eu so serializo e salvo na sessao. No ambiente de producao muitas vezes os "arquivos" da sessao ficam numa area da memoria RAM. Entao fica muito realmente rapido. Podemos tambem guardar esse dado serializado em outros lugares alem da sessao como no banco ou num arquivo separado, etc.2. Nao entendi. Tenho a impressao que voce nao entendeu exatamente como nos fizemos essa sincronia. As operacoes nesse contexto vao acontecer no servidor. Veja GWT, que e algo muito similar a isso.3. Nao vamos mandar de volta uma versao toda nova da tela. Apenas receber um json com o que mudou em quais tags. Novamente recomendo voce dar uma boa olhada no GWT.4. Pretendo sim utilizar algum framework Javascript para fazer essa comunicacao com o servidor. Mas isso nao impede de precisamos de um servidor capaz de receber o evento e saber quais tags devem ser alteradas e quais devem ser seus novos conteudos etc.1 - Nao e um problema terrivel se voce precisar mesmo disso. Eu ainda nao entendi a vantagem de se passar a logica do cliente para o servidor.2 e 3 - Realmente eu tinha entendido diferente. Dessa forma realmente faz sentido.4 - Nesse caso depende muito do que voce vai precisar fazer. Eu acho que apesar de nao existirem grandes problemas, a priori, de manter a pagina em sessao acredito que para boa parte dos casos nao existe essa necessidade. Movimentar coisas na tela por exemplo nao precisaria chegar no servidor. Pode ser que para o tipo de aplicacao que voce desenvolva ai isso faca sentido e eu esteja falando besteira =)Atenciosamente,Rafael BarbosaThiago Mata responde...Gostei dos seus comentarios como sempre,Acredito que voce tenha entendido muito bem a solucao. Sei que ela apresenta uma complexidade relativamente alta que pode em alguns casos nao compensar o uso. Mas conforme voce mesmo citou existem casos e casos. Nao digo que essa solucao precisa / deva ser utilizada em qualquer caso. Na verdade, nao acredito que nenhuma solucao deva ser utilizada em qualquer caso, num complexo de
"bala de prata". Mas conforme os exemplos ja citados de GWT, JSF, JLIBS, SEAM, etc. existem contextos onde fazer essa conversao se justifica. Existem ainda cenarios que utilizar essa solucao nao e necessario mas pode parecer interessante. Com o framework maduro e ja bem otimizado, utilizar essa solucao em contextos mais simples pode ser uma boa opcao, pensando-se nos ganhos ja citados. Novos pontos positivos serao criados a cada dia conforme enriquecemos a solucao. Certamente tera pontos negativos, como qualquer decisao. Talvez quando eu tiver exemplos da interacao entre os arquivos de template sem os muitos includes, fique mais claro outros ganhos que a utilizacao desse tipo de solucao venha a apresentar. A solucao em SEAM, com componentes personalizados, foi muito bem aceita pela equipes, por exemplo, aumentou a produtividade, a padronizacao e a qualidade dos softwares desenvolvidos. Estamos tentando aprender com as solucoes que deram mais certo e errado dentro do nosso cenario e gerar solucoes adequadas ao mesmo.Resumindo, o que estamos oferecendo aqui e uma opcao de solucao que temos desenvolvido para se adequar a nossa demanda e ao nosso cenario. Acreditamos que ela pode vir a ser util em outros cenarios tambem. Certamente ela nao sera a melhor solucao em qualquer cenario mas talvez venha a ser uma boa opcao para um cenario que voces venham a encontrar.Atenciosamente,Thiago Mata.
do seu controle de versao, o que possibilita se saber de novos erros existentes no sistema assim que eles surgem, tornando seu sistema mais confiavel e a manutencao facilitada.As ferramentas mais conhecidas de teste unitario sao o JUnit e o PHPUnit e um exemplo de saida do PHPUnit pode ser vista aqui.Padroes da WebConhecer os padroes da W3C deveria ser o ponto de partida de qualquer programador web. Infelizmente, isso nao e nem de longe a regra. Eu, quando dou aula de programacao, sempre me dedico a falar sobre o que e um XML, Schema e DTD, ensino os meus alunos a desenvolverem XHTML e falo um pouco sobre as validacoes da W3C. Para auxiliar no aperfeicoamento das suas paginas desenvolvidas eu recomendo mais um plugin do firefox chamado Web Developer alem do Relaxed e o Html Validator que infelizmente ainda nao funciona no linux.Para quem esta realmente comecando, um dos melhores sites em portugues e o Tableless.com.br. O w3schools e outra excelente referencia em relacao ao assunto.PrototipagemPrototipo, WireFrame, Rascunho de Tela, etc. Todos esses nomes sao para desenhos das telas que devem guiar os designers na criacao do desenho final da tela. Esse rascunho sera comparado com o fluxo de teste planejado e deve ser apresentado ao cliente antes de se iniciar a construcao real do sistema. E natural que, com o desenvolvimento do sistema, alteracoes sejam feitas nas telas. Mas, ainda assim, o prototipo auxilia muito a reduzir a quantidade futura de alteracoes ja dando um ponto de partida confiavel para o desenvolvimento do sistema.Algumas empresas fazem prototipo de tela em ferramentas nao especializadas como powerpoint ou ate mesmo no photoshop ou gimp mas existem muitas ferramentas feitas especialmente com este proposito. Dentre as gratuitas, a que eu mais recomendo e o Pencil Project, um plugin para firefox muito bom para prototipagem.Modelagem de bancoSaber modelar bem um banco de dados e compreender um modelo e essencial para um bom sistema. Ao meu ver, a ferramenta gratuita mais popular e o DBDesigner4, mas, eu nao a considero a melhor opcao. Algumas outras opcoes, ainda gratuitas, que eu recomendo sao o JDeveloper e o Power Architect. Mas, e essencial estudar como fazer uma boa modelagem de banco de dados, nao se restrigindo apenas as ferramentas. E importante estudar como deve ser uma boa modelagem de banco de dados, e existem muitos bons livros gratuitos para leitura como o Data Modeling FundamentalsModelagem de Processos de Negocio - BPM Uma das ( muitas ) maneiras de se modelar um processo antes de implementa-lo e pelo bpm. Uma representacao grafica do negocio a ser implementado utilizando uma notacao padrao. Quanto a ferramentas gratuitas para geracao de bpms, recomendo o BizAgi apesar de nao funciona no linux ( sem wine ou vbox ). Estou testando recentemente algumas aplicacoes novas, dentre elas o BonitaSoft, mas, ainda estou as estudando.UML Muito se fala de UML e existem muitos livros sobre o assunto, principalmente os livros de Engenharia de Software como o Sommerville. Nao querendo entrar na discussao ideologica do assunto, um bom programador precisa conhecer os diagramas UML.Dentre