Categoria: programação


Muito boa a QCON2011. Palestras de qualidade e com bastante utilidade para o ambiente de trabalho do dia a dia. Abaixo segue o link para algumas paletras apresentadas no evento. Caso eu tenha me esquecido de alguma, favor comenta-la que eu irei adicionar assim que puder.

Para mim, um diferencial entre programadores são os padrões de projetos, mais conhecidos por designer patterns. Como a própria wikipédia descreve padrões de projeto: “…descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos”. Ou seja, programadores com conhecimento em Padrões de Projeto aplicam soluções em programação que facilitam a manutenção e o ciclo de vida do software. Infelizmente percebo que entre programadores PHP a utilização de padrões de projeto ainda não está tão bem difundida quanto em outras linguagens, como o java, por exemplo. Um pouco disso se deve ao fato de a linguagem ter ganhado um caráter orientado a objeto “recentemente”, cerca de 5 anos atrás, em sua quinta versão. Além disso, um outro problema que existe com relação a padrões de projeto em PHP é a literatura, que não está bem difundida para a linguagem. São bem poucos os livros que tratam de padrões de projeto utilizando PHP, mais raros ainda se forem procurados em nossa língua. Portanto caso um programador deseje conhecer mais a respeito de padrões de projeto, terá que estudar os tais em uma outra linguagem, mais especificamente, java. Para java existe uma gama inimaginável de livros que tratam do assunto. Outra fonte de informação importante sobre padrões de projeto é o website de Martins Fowler (http://martinfowler.com/). Ele trata de diversos padrões, principalmente voltado ao desenvolvimento de soluções corporativas. Além disso, trata de soluções de refatoração de código, tarefa que quase não acontece na vida de um programador =p . Entretanto, vale lembrar que nem todos os padrões podem ser efetivamente portados para o PHP sem sofrer alguma mudança. Cito, por exemplo, os padrões que utilizam polimorfismo para evitar-se condicionais no código (strategy). Pode-se ver exemplos desse tipo neste website: http://sourcemaking.com/design_patterns . Ele mostra como funciona os padrões em diversas linguagens e como muda a implementação entre uma linguagem e outra.

Aqui está um assunto polêmico. Existem dois grupos óbvios nesta discussão: Os que defendem o desenvolvimento de sistemas em PHP utilizando a linguagem pura e criando componentes a partir desta e os que defendem que todo desenvolvimento deve ter um framework comercial como apoio para o sistema. Pelo tema deste post, eu estou no ultimo grupo.

O grupo que utiliza a linguagem pura e busca o desenvolvimento de seus próprios componentes utiliza vários argumentos para tanto. Segurança, performance da aplicação, designer de sistema proprietário, etc. Muitas vezes pessoas deste grupo montam seus próprios framework visando agilizar o desenvolvimento de softwares em busca da reutilização.

Eu, como defensor dos framework comerciais para o desenvolvimento cito algumas vantagens de se utilizar destes:

  • Existe uma maior facilidade para a detecção de erros, visto que frameworks são peças mais concisas de software.
  • Podemos nos concentrar mais com a abstração de soluções do problema que estamos tratando.
  • Torna mais eficiente a resolução dos problemas.
  • Como todos os itens acima ocasionam uma maior produtividade, podemos garantir que também teremos um maior lucro, pois teremos uma antecipação da entrega, e uma maior satisfação dos clientes.
  • Otimização de recursos

Os pontos descritos acima foram retirados da wikipedia. Vou listar os meus pontos além dos citados acima:

  • Padronização do sistema: Um sistema com a utilização de um framework tem um “esqueleto” no qual se apoiar, facilitando a padronização do desenvolvimento do sistema nos diversos pontos.
  • Baixo acoplamento entre componentes: Sistemas que utilizam frameworks tem por natureza um baixo acoplamento. Isto se dá pelo fato de os desenvolvedores de frameworks serem bem genéricos para o desenvolvimento visando atingir um número maior de soluções.
  • Documentação: Um ponto importante de um framework comercial é a sua documentação. Dado determinado problema no sistema, pode-se consultar uma documentação onde o problema é detalhado e é apresentado uma solução para o tal. Frameworks “caseiros” carecem de documentação em sua grande maioria, dificultando a reutilização de seus componentes.

Existe uma certa preocupação com relação a performance de aplicações que utilizam framework e essa preocupação é válida. Martins Fowler, em seus diversos livros comenta que aplicar designer patterns e refatoração podem impactar em performance da aplicação. Entretanto, ele próprio comenta que essa preocupação pode ser deixada de lado até que o sistema esteja desenvolvido e que ela realmente seja um problema. Nestes casos, em um sistema bem desenvolvido utilizando orientação a objetos e designer patterns de maneira correta, refatorações visando a performance da aplicação são rápidas e fáceis de serem realizadas. É claro que estamos falando de problemas de performance simples que não sejam requisitos do sistema. Por exemplo, uma query que demora 1 min para execução sendo que o tempo máximo deste requisito do sistema seja 3 segundos. Talvez uma refatoração nos leve ao ganho de alguns segundos na query. Entretanto este fator deve ser levado em conta na fase de análise do projeto. Talvez, neste ponto do sistema, uma solução de ORM de um framework seja menos efetiva. Mas a troca de uma solução de ORM para uma extração pura é bem simples. É claro que isso foi um exemplo simples. Existem outros problemas que podem aparecer com relação a performance de uma aplicação que utiliza framework. No entanto, tais problemas são bem pontuais.

Outro ponto que algumas pessoas alegam é com relação a segurança. Alguns dizem: “Vai que existe um bug comprometedor neste framework e a minha aplicação fique vulnerável a ataques”. Bem a afirmação é válida e tem importância sim. Mas essa preocupação é a mesma para quaisquer sistemas e aplicativos existentes na infraestrutura da empresa. Por exemplo, digamos que exista uma vulnerabilidade no mod_rewrite do apache. Posso desativar o módulo ou trocar o meu servidor web. Da mesma maneira, com frameworks posso desativar determinado componente. Posso trocar o framework ou, posso até mesmo consertar a vulnerabilidade. Afinal na maioria dos casos tem-se acesso aos fontes de um framework podendo dessa maneira corrigir a vulnerabilidade e/ou evitar que esta seja utilizada.

É uma tendência a utilização de framework em desenvolvimento, principalmente desenvolvimento WEB. Portanto, caso tenha algo contra, reexamine o porquê e veja se vale a pena perder todas as vantagens listadas aqui.

Fontes: http://pt.wikipedia.org/wiki/Framework

Em uma distro Linux proveniente de uma distribuição Debian (ubuntu, kurumim, etc) para se montar um servidor AMP (Apache, Mysql e PHP) é necessário apenas uma linha de código:

  • apt-get install apache2 php5 libapache2-mod-php5 php5-mysql mysql-server mysql-client

Após rodar essa linha de comando, o seu servidor AMP estará pronto para uso.

Para montar um servidor AMP no Windows já é bem mais complexo. Primeiramente você deve baixar o pacote do apache. Logo após você deve baixar o PHP. Hoje já existe um instalador mas por padrão este instalador sempre dá pau. Depois disso você deve baixar o Mysql. No final das contas, leva-se no mínimo duas vezes mais tempo montando um servidor AMP no Windows do que no Linux. Pior ainda se estiver utilizando uma versão de Windows que seja diferente do Windows XP (por exemplo o Windows Vista que tem um sistema de controle de permissões bem mal feito).

O php, apache e mysql forão feitos para rodarem nativamente em sistema UNIX. Por isso é muito mais simples instalar e configurar estes em uma maquina Linux do que em uma maquina Windows.

Mesmo com tudo isso, porque tanto desenvolvedor utiliza Windows para desenvolver? Digamos que é cômodo utilizar Windows. Todo mundo usa Windows e muita gente acha que Linux é coisa de hacker, nerd ou cientista. Só que na grande maioria dos casos, o servidor onde vai rodar a aplicação é Linux. Ou seja, na grande maioria dos casos o desenvolvedor deverá ficar se preocupando com as incompatibilidades de sistema ao invés de se preocupar com a aplicação. Nos próximos artigos abordaremos algumas ferramentas que facilitam a migração do usuário de Windows para Linux além de auxiliar no desenvolvimento.

Nestas ultimas semanas passei por uma experiência interessante com a infraestrutura de TI da empresa na qual presto consultoria. Tudo começa por volta das duas horas da tarde. Estava trabalhando normalmente e percebi uma mensagem de erro no meu email. Erro de autenticação. Estranhei, mas como estava entretido com o trabalho não dei muita importância. Passado uma hora depois disso acusou cabo de rede desconectado. Pensei comigo que a rede havia caido. Comecei a questionar as estações de trabalho do meu lado e todo mundo estava com a rede ok. Me levantei e fui questionar o pessoal da infraestrutura que o meu cabo de rede estava desconectado. A resposta, para a minha surpresa, foi para eu ir falar com o meu diretor. Chegando na sala do diretor, ele me disse que para eu obter acesso a rede, e-mail corporativo, svn, etc, eu necessitaria desinstalar o Ubuntu da minha maquina. Questionei o porque e a resposta foi que uma estação de trabalho com linux é uma ameaça a segurança.

Trabalho com linux a dois anos como estação de trabalho para desenvolvimento. É muito mais produtivo desenvolver em linux por diversos fatores, principalmente para desenvolvimento web, afinal de contas a sua maquina é muito parecida com o servidor final da aplicação. Além do mais, existem diversas opções no shell do linux de são um verdadeiro canivete suiço.

Mas porque então o pessoal de infraestrutura diz que linux é uma ameaça a segurança da rede? Simples, porque eles não sabem lidar com ele. A infraestrutura da empresa é toda composta por maquinas Windows. Administrar uma maquina windows é bem simples: Cria-se um usuário sem permissões administrativas, libera alguma opções administrativas para se poder trabalhar e acabou. Teoricamente você tem uma estação de trabalho segura. Mas e com uma estação de trabalho linux? A grande questão de segurança de uma rede não está em limitar o sistema operacional do usuário. Ainda mais um profissional de TI. Por exemplo, existe uma galera de Delphi na empresa. O que impede de criar uma aplicação que cria pacotes e roteia os pacotes através do proxy de maneira criptografada? Mesmo com PHP dá para fazer isso. Com C, com Java. A partir do ponto em que se está em uma estação de trabalho onde existam desenvolvedores de softwares, estes tem o poder de criar a aplicação que quiserem, independente do sistema operacional, e que estas aplicações furem a segurança da rede.

Então uma rede com desenvolvedores é uma rede insegura? Não. Um administrador de rede bom consegue manter uma rede segura mesmo com desenvolvedores utilizando diversos sistemas operacionais. Conheço diversas empresas que tem área de desenvolvimento e não tem nenhum problema de segurança.

Agora, vamos analisar a discussão principal desta matéria: O perfil profissional do pessoal de infraestrutura da empresa. Vou listar os pontos abaixo para facilitar a leitura:

  • Não notificaram o usuário: Ao invés de alguém chegar em mim e dizer assim: “Cara, você está usando linux e isso pode furar a segurança da rede.” ou “O que você acha de tentar adequar a sua maquina ao padrão da empresa”, o pessoal de infraestrutura arranca o cabo de rede.
  • Só conseguiram bloquear o usuário via puxar o cabo de rede: Qualquer júnior de administrador de rede consegue bloquear determinado IP de ter acesso a rede via software. Quando os caras só conseguiram me bloquear por completo via desconectar o cabo de rede, eles provaram qual o nível de profissionalismo deles.
  • Só conseguem administrar estações de trabalho de determinado SO: Administrar a rede administrando as estações de trabalho e a maneira mais burra que se tem para administrar uma rede. Principalmente quando esta rede é composta por desenvolvedores de software. Conforme já disse acima, qualquer desenvolvedor tem o poder de criar um aplicação que possa furar a segurança da rede ou, até mesmo, escalar privilégios da estação de trabalho. Ter uma postura restritiva só piorá a situação.

O mais engraçado é que a empresa vende o serviço de infraestrutura e o serviço de segurança de rede. Conforme um colega meu disse, comam no meu restaurante mas não visitem a minha cozinha.

Eu já divulguei nas diversas listas e IRC sobre a qualidade da infraestrutura da empresa.

Existe no mundo de desenvolvimento web a figura do sobrinho. Este personagem se caracteriza por ter conseguido modificar uns scripts daqui, entender alguns códigos e conseguir montar um “site”. Chamam de sobrinho porque na estória ele desenvolve o site para a empresa do tio e o tio fica orgulhoso de saber que o sobrinho dele, sem curso nenhum, conseguiu fazer aquele site. Então o tio pensa “para que pagar um programador de verdade sendo que o meu sobrinho consegue fazer um site.” O pior, o sobrinho se acha programador e começa a fazer as famosas POG’s nos diversos sistemas web que existem por ai. Cobra uma miséria e quem não conhecem a figura paga o valor solicitado achando que está fazendo um tremendo negócio. O sobrinho cobra barato porque ele pensa que está aprendendo quando está fazendo esses sites.

A estória acima é encontrada, conforme já citado, em diversos segmentos do desenvolvimento web, principalmente em linguagens onde fazer um Hello World é uma tarefa bem simples (ex: PHP). A questão está quando o sistema ou site que foi desenvolvido pelo sobrinho passa por pelo menos duas situações. A primeira é quando o site necessita crescer. Adicionar um novo módulo, fazer uma modificação na base de dados, ou simplesmente trocar o layout do site. Como ele não sabe programar escreve os famosos códigos macarrônicos. Códigos macarrônicos são aqueles que unem diversas partes que deveriam ser separadas em uma única parte. Extração de dados do banco, html, javascript, css, tudo no mesmo arquivo. Qualquer modificação levará pelo menos 5 vezes mais tempo do que uma modificação atual. Se houver um aumento da demanda de modificações no site, em pouquíssimo tempo o preço pago ao sobrinho vai ficar muito mais caro que se um programador tivesse desenvolvido. E se necessitar de uma modificação maior, o sistema terá que ser reescrito. A segunda questão acontece quando o site está no ar e esse site é invadido . Existem milhares de falhas que se podem ser cometidas pelo pouco conhecimento de desenvolvimento. Essa característica é peculiar ao desenvolvimento web. Mas ai alguém pode falar: “Mas é só um site, se invadirem e só substituir os arquivos e acabou”. Talvez, mas usando uma vulnerabilidade no site, todas as aplicações que rodam naquele servidor ficarão expostas. Serviços de e-mail, sistemas de controle de arquivos, banco de dados, e sabe-se lá o que mais podem ser destruídos ou utilizados para fins malignos. Uma boa parte dos spams que recebemos são formulários mal feitos que pessoas mal intencionadas utilizem para disseminar mensagens.

Portanto, caso você esteja pensado em ter um site ou um sistema. Procure alguém que saiba fazer. Busque referência profissional, procure saber os trabalhos realizados pelo profissional. Conforme o texto acima mostrou, em quase todas as vezes o barato sai caro.

Para os sobrinhos….

Este texto não tem a intenção de desencorajar quem está aprendendo. Todos nós, programadores, estamos sempre aprendendo. Eu grifei a palavra curso no texto porque muitas pessoas pensam que fazer um curso de programação e já sabe tudo. Sinceramente, para ser um bom programador necessita de dedicação em estudar e estudar e estudar. Leia sobre diversos assuntos. Aprenda as tecnologias recentes do mercado. Não pense que um Hello World é tudo. Existem muitas coisas além dele que são fundamentais para fazer um sistema com um ciclo de vida alto e com um bom grau de segurança….

Diferentemente do que muitas pessoas pensam, o planejamento e desenvolvimento de um projeto de software constitui-se uma ciência inexata. Gerentes estabelecem um prazo para determinado desenvolvimento e lançam para o desenvolvedor “se virar”, sendo que este irá sacrificar a qualidade do software, incluindo as chamadas POG’s ao projeto em caso de um projeto mal planejado. 

Com relação ao custo do projeto, o calculo do valor do projeto sempre é acrescido de uma “gordura” para contemplar os casos de atraso , fazendo com que o projeto tenha um custo um pouco mais alto que o real necessário.

Para resolvermos estes problemas, está começando no Brasil a metodologia ágil para desenvolvimento de software. Nesta metodologia o projeto é dividido em splits, isto é, módulos de tempo determinado, quase sempre de duas ou quatro semanas. Dentro de um split há um planejamento para dividir as tarefas necessárias para completar o split. Estas tarefas ficam a vista dos desenvolvedores que podem realizar qualquer destas tarefas.  Caso haja dificuldade para a realização da tarefa, em uma reunião rápida de 15 min, realizada todo dia, são discutidos o andamento das tarefas, as dificuldades, soluções, e outros fatores relevantes ao desenvolvimento.

Uma outra caracteristica interessante é a utilização de testes automáticos e o conceito de programação orientada a testes, em que todo módulo desenvolvido é testado automaticamente por frameworks e testes planejados. Este provavelmente será o tema do proximo post.

Dizem que a simplicidade é a alma do negócio. Se isto estiver certo, o Konana é a descrição absoluta desta frase. Simples, leve e cumpre a tarefa de um framework PHP.

Dentre as suas funcionalidades, podemos listar o auxilio para desenvolvimento de soluções MVC, o ORM, mapeamento objeto relacional, diversos helpers para a as diversas tarefas, entre elas, helpers para sessions, databases, forms, captcha, etc.

Um ponto que ele ainda peca é na documentação. Eu pessoalmente acho que a documentação deveria conter mais exemplos práticos. Entretanto, isso será solucionado com o tempo.

Sistemas WEB.Acessem www.ismaelvacco.com.br

O jquery apresenta inúmeras vantagens para o desenvolvimento de aplicações AJAX. Dentre todas as vantagens, uma vantagem bem interessante é a utilização de plugins para as mais diversas tarefas. Carregar tabelas, combobox, efeitos em imagens, efeitos de menus, drag-drops, gráficos ou seja, uma infinidade de recursos disponíveis para a utilização.
Recursos que iriam consumir dezenas, senão centenas de linhas de código javascript são feitos com apenas uma ou duas linhas.
Para uma lista completa de plugins, visite o site do Jquery e clique em plugins.

Dentre as várias funcionalidades existentes no Zend Framework, a que mais me chamou a atenção foi o módulo Zend PDF. Existem algumas classes para a criação de arquivos pdf, como a FPDF, por exemplo. Mas o módulo Zend PDF, além de criar documentos PDF, ele edita e cria documentos a partir de um template já pronto. Esta funcionalidade é bem interessante para a criação de sistemas de controle de documentos. Um formulário qualquer pode ser preenchido eletronicamente e enviado para alguém para ser aprovado ou coisa do gênero. A aprovação pode ser feita mediante uma assinatura eletrônica que o sistema gera (essa assinatura pode ser um número que pode ser conferido no sistema para verificar a autenticidade). O único trabalho seria gerar os formulários e documentos em PDF, mas existem diversas ferramentas que geram arquivos pdf a partir de um documento no Word e Excel.

Além disso, o módulo implementa um controle de revisão ds documentos, o que também é muito interessante para controlar documentos gerados.

exemplos de utilização do móduloZend PDF podem ser encontrados na documentação do Zend Framework. Mais à frente postarei um exemplo prático da implentação deste módulo editando documentos pdf.

Ismael Vacco

www.ismaelvacco.com.br

Blog no WordPress.com. | Tema: Motion até volcanic.
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.