Olá a todos.
Acabei de criar um repositório no github com o código fonte de um pequeno jogo que criei usando Action Script 3 e a biblioteca flixel. O nome do jogo é DarkMatters.
O jogo é bem simples e criei com a intenção de aprender mais sobre o processo de desenvolvimento de um jogo. Infelizmente o código não é de grande qualidade mas espero que possa ajudar alguém interessado no assunto.
Mostrando postagens com marcador programação. Mostrar todas as postagens
Mostrando postagens com marcador programação. Mostrar todas as postagens
segunda-feira, 28 de janeiro de 2013
domingo, 25 de novembro de 2012
A Essencial e Difícil Arte de se Ler Código
Nas minhas andanças pela internet encontrei um artigo bem interessante chamado:
Most Programmers Can't Read Code
Ou seja "A maioria dos programadores não conseguem ler código". Na verdade o que o autor do artigo realmente enfatiza é que a maioria dos programadores não conseguem ler código e compreendê-lo de modo efetivo.
No artigo são citadas várias razões para esta conclusão como a percepção de que é mais fácil escrever código do que lê-lo. Ou que na hora de se ler o código temos que manter muito mais coisas em nossas mentes como as varáveis, estruturas de dados e o design do código em geral. Ainda temos o caso onde a diferença de experiência entre o programador que escreveu o código e o programador que está lendo-o entra em jogo.
Eu realmente acho a atividade de se ler código legado, ou seja, código que não foi escrito por você ou que você escreveu a mais de uma semana, muito difícil de ser dominada de modo efetivo. Quando eu encontro um trecho de código que acho particularmente difícil de se compreender, seja por eu não se tão esperto quanto o cara que o escreveu ou o contrário, eu sempre achei a ajuda de debuggers providencial. A possibilidade de se ver a execução das instruções linha por linha, acompanhar as mudanças nos valores de variáveis e também acompanhar o fluxo de execução torna a carga mental muito mais amena. Não importa qual linguagem de programação você usa, aprenda a usar um debugger para ajudá-lo nestas horas. E claro, pratique suas habilidades lendo muito código!
E você? Tem alguma técnica particular que usa na hora de ler código?
Most Programmers Can't Read Code
Ou seja "A maioria dos programadores não conseguem ler código". Na verdade o que o autor do artigo realmente enfatiza é que a maioria dos programadores não conseguem ler código e compreendê-lo de modo efetivo.
No artigo são citadas várias razões para esta conclusão como a percepção de que é mais fácil escrever código do que lê-lo. Ou que na hora de se ler o código temos que manter muito mais coisas em nossas mentes como as varáveis, estruturas de dados e o design do código em geral. Ainda temos o caso onde a diferença de experiência entre o programador que escreveu o código e o programador que está lendo-o entra em jogo.
Eu realmente acho a atividade de se ler código legado, ou seja, código que não foi escrito por você ou que você escreveu a mais de uma semana, muito difícil de ser dominada de modo efetivo. Quando eu encontro um trecho de código que acho particularmente difícil de se compreender, seja por eu não se tão esperto quanto o cara que o escreveu ou o contrário, eu sempre achei a ajuda de debuggers providencial. A possibilidade de se ver a execução das instruções linha por linha, acompanhar as mudanças nos valores de variáveis e também acompanhar o fluxo de execução torna a carga mental muito mais amena. Não importa qual linguagem de programação você usa, aprenda a usar um debugger para ajudá-lo nestas horas. E claro, pratique suas habilidades lendo muito código!
E você? Tem alguma técnica particular que usa na hora de ler código?
sábado, 18 de agosto de 2012
Velocidade em PHP
O comando foreach é mais lento do que um simples for? Usar aspas duplas ou simples para strings faz muita diferença no tempo de execução? isset() é mais rápido do que empty()? Este tipo de discussão é realmente útil?
Um cara chamado Chris Vincent criou um site chamado The PHP Benchmark para te ajudar a achar respostas para estas questões. Ele apresenta vários exemplos com uma breve descrição, os resultados obtidos por ele e o código usado em cada exemplo para que você possa testar você mesmo.
Mas lembre-se! Geralmente seu maior gargalo de performance não está no seu código e sim na entrada e saída (bancos de dados, webservices, redes, sistemas de arquivos...)!
Um cara chamado Chris Vincent criou um site chamado The PHP Benchmark para te ajudar a achar respostas para estas questões. Ele apresenta vários exemplos com uma breve descrição, os resultados obtidos por ele e o código usado em cada exemplo para que você possa testar você mesmo.
Mas lembre-se! Geralmente seu maior gargalo de performance não está no seu código e sim na entrada e saída (bancos de dados, webservices, redes, sistemas de arquivos...)!
sexta-feira, 4 de maio de 2012
Coisas que você não deve colocar no Banco de Dados
Em minhas andanças pela internet eis que me deparo com um ótimo artigo chamada "Três coias que você nunca deve por no banco de dados". É um ótimo artigo, recomendo a leitura.
Basicamente ele fala que evitar armazenar dados binários(imagens, arquivos...), dados efêmeros (informações que são usadas por um curto período de tempo) e logs.
Eu concordo com o que é dito no artigo. Mas venho aqui falar de outra coisa que jamais em hipótese alguma você deve armazenar no banco de dados. Estou falando de CÓDIGO. E aqui estou falando de código mesmo, o mesmo código que você escreve quando está criando uma aplicação.
"O quê? Armazenar código? Isso é totalmente estúpido, quem em sã consciência faria isso?" Devem ser perguntas que permeiam sua mente agora. Mas me pesa muito dizer que já vi isso no mundo real, em uma aplicação web, e o pior de tudo é que eu tive que dar manutenção neste pesadelo.
Veja, com uma parte do código de sua aplicação armazenada no banco de dados coisas simples e corriqueiras como testar sua aplicação, corrigir um pequeno bug, versionar a aplicação, atualizá-la e simplesmente ler o código se tornam tediosas, demoradas e tremendamente propensas a erros.
Quando ocorre um erro no seu código o erro está no código que está dentro ou fora do banco de dados? Ou é um erro que depende de mudanças nos dois códigos? Quando você quiser ler o código para saber o que está errado você tem que manter sua IDE ou editor de texto abertos juntamente com um cliente de banco de dados. A cada novo trecho de código que você quiser ler você tem que fazer uma consulta no banco de dados. E quando você fizer uma alteração no código armazenado no BD você necessitará fazer uma operação de atualização no BD e depois rodar sua aplicação, torcendo para que não tenha cometido nenhum erro de sintaxe ou vai ter que refazer todo este processo. E como desenvolver em conjunto com uma equipe? Os desenvolvedores vão trabalhar juntos em um mesmo banco de dados e correr o risco de um sobrescrever alterações do outro? Ou cada vai ter seu banco de dados e depois sabe-se lá como eles vão sincronizar os códigos de cada um.
Olha eu já vi ideias ruins na área de TI, e algumas delas são minhas mesmo, mas isso de armazenar código da aplicação no banco de dados é de longe a mais abominável de todas. Aqui fica o aviso amigos.
Basicamente ele fala que evitar armazenar dados binários(imagens, arquivos...), dados efêmeros (informações que são usadas por um curto período de tempo) e logs.
Eu concordo com o que é dito no artigo. Mas venho aqui falar de outra coisa que jamais em hipótese alguma você deve armazenar no banco de dados. Estou falando de CÓDIGO. E aqui estou falando de código mesmo, o mesmo código que você escreve quando está criando uma aplicação.
"O quê? Armazenar código? Isso é totalmente estúpido, quem em sã consciência faria isso?" Devem ser perguntas que permeiam sua mente agora. Mas me pesa muito dizer que já vi isso no mundo real, em uma aplicação web, e o pior de tudo é que eu tive que dar manutenção neste pesadelo.
Veja, com uma parte do código de sua aplicação armazenada no banco de dados coisas simples e corriqueiras como testar sua aplicação, corrigir um pequeno bug, versionar a aplicação, atualizá-la e simplesmente ler o código se tornam tediosas, demoradas e tremendamente propensas a erros.
Quando ocorre um erro no seu código o erro está no código que está dentro ou fora do banco de dados? Ou é um erro que depende de mudanças nos dois códigos? Quando você quiser ler o código para saber o que está errado você tem que manter sua IDE ou editor de texto abertos juntamente com um cliente de banco de dados. A cada novo trecho de código que você quiser ler você tem que fazer uma consulta no banco de dados. E quando você fizer uma alteração no código armazenado no BD você necessitará fazer uma operação de atualização no BD e depois rodar sua aplicação, torcendo para que não tenha cometido nenhum erro de sintaxe ou vai ter que refazer todo este processo. E como desenvolver em conjunto com uma equipe? Os desenvolvedores vão trabalhar juntos em um mesmo banco de dados e correr o risco de um sobrescrever alterações do outro? Ou cada vai ter seu banco de dados e depois sabe-se lá como eles vão sincronizar os códigos de cada um.
Olha eu já vi ideias ruins na área de TI, e algumas delas são minhas mesmo, mas isso de armazenar código da aplicação no banco de dados é de longe a mais abominável de todas. Aqui fica o aviso amigos.
sábado, 29 de outubro de 2011
Escapar saída html em PHP
Você está escapando a saída de todo o conteúdo inseguro nos seus scripts PHP? E por conteúdo inseguro eu digo tudo o que não for interno da aplicação como qualquer informação enviada pelos usuários, dados de outros servidores, webservices, banco de dados etc.
Uma boa notícia é que se você usa algum dos modernos frameworks php (Code Igniter, Symfony, Cake PHP) corretamente ele provavelmente já está cuidando disso para você, mas é bom você checar só por precaução. O problema é que muitos de nós desenvolvedores PHP temos sites ou sistemas que já tem um bom tempo de estrada e não usam nenhum framework.
Agora, você deve estar se perguntando, o que é este negócio de escapar a saída (output escape)?! Bem, como você deve saber desde os primórdios da internet a principal função de um browser web é exibir documentos html. E um documento html nada mais é do que um arquivo de texto, formado por tags html e texto puro. Aqui vai um exemplo de um típico trecho de um documento html:
Como você pode ver neste trecho de html temos um pouco texto comum, mas também temos as nossas famosas tags. As tags nada mais são do que comandos para o browser. Insira um imagem aqui, uma parágrafo aqui e crie uma div neste ponto...
Como o browser identifica estas tags? Através de caracteres especiais como < e >. Existem alguns outros caracteres importantes como ', " e &. E o que isso tem a ver com escape de saída? Bom imagine que em um blog um dos usuários insira um comentário com um conteúdo como este:
O que você acha que vai acontecer? Bom o browser de qualquer visitante que exibir este comentário vai executar o que quer que esteja no script perdeu_mane.js. Podem ser ações desde de redirecionar o usuário, exibir anúncios, quebrar o layout do site, roubar senhas e cookies, e até mesmo fazer com que usuários logados com previlégios de administrador executem ações no site. Isso meu amigo, é o famoso ataque XSS(Cross-site Scripting).
Escapar a saída nada mais é do que exibir aqueles caracteres especiais de uma forma representativa fazendo com que o browser não execute nenhuma ação disparada por tags. Neste caso < e > são escritos como < e >.
Uau! E como eu faço isso? Bom, escapar exibição de html em PHP não é particularmente difícil.
Exibir texto simples em uma página web:
Exibir text simples dentro de uma tag html:
Se você sempre usa aspas-duplas " nas suas tags, como por exemplo <input type="text" name="nome aqui" /> você pode usar ENT_COMPAT ao invés de ENT_QUOTES. ENT_COMPAT diz para a função transformar apenas as aspas-duplas, ENT_QUOTES vai transformar tanto aspas-duplas quanto aspas-simples.
Importante! Quando escapar a saída?
Você deve estar pensando que ao invés de ficar sempre chamando a função htmlspecialchars na hora de exibir o conteúdo você pode chamá-la apenas uma vez na hora de salvar o conteúdo? Talvez não seja uma boa ideia, hoje em dia é muito provável que você não vai exibir seu conteúdo apenas em páginas html, você também tem rss, json, csv, arquivos texto, emails e outras opções. Para cada uma destas opções de exibir conteúdo o processo de escape é diferente. Se você quiser salvar processamento você pode armazenar uma versão inalterada do conteúdo junto com versões já escapadas de acordo com sua necessidade.
Por enquanto é isso pessoal, espero que o artigo seja útil a vocês.
Uma boa notícia é que se você usa algum dos modernos frameworks php (Code Igniter, Symfony, Cake PHP) corretamente ele provavelmente já está cuidando disso para você, mas é bom você checar só por precaução. O problema é que muitos de nós desenvolvedores PHP temos sites ou sistemas que já tem um bom tempo de estrada e não usam nenhum framework.
Agora, você deve estar se perguntando, o que é este negócio de escapar a saída (output escape)?! Bem, como você deve saber desde os primórdios da internet a principal função de um browser web é exibir documentos html. E um documento html nada mais é do que um arquivo de texto, formado por tags html e texto puro. Aqui vai um exemplo de um típico trecho de um documento html:
Como você pode ver neste trecho de html temos um pouco texto comum, mas também temos as nossas famosas tags. As tags nada mais são do que comandos para o browser. Insira um imagem aqui, uma parágrafo aqui e crie uma div neste ponto...
Como o browser identifica estas tags? Através de caracteres especiais como < e >. Existem alguns outros caracteres importantes como ', " e &. E o que isso tem a ver com escape de saída? Bom imagine que em um blog um dos usuários insira um comentário com um conteúdo como este:
O que você acha que vai acontecer? Bom o browser de qualquer visitante que exibir este comentário vai executar o que quer que esteja no script perdeu_mane.js. Podem ser ações desde de redirecionar o usuário, exibir anúncios, quebrar o layout do site, roubar senhas e cookies, e até mesmo fazer com que usuários logados com previlégios de administrador executem ações no site. Isso meu amigo, é o famoso ataque XSS(Cross-site Scripting).
Escapar a saída nada mais é do que exibir aqueles caracteres especiais de uma forma representativa fazendo com que o browser não execute nenhuma ação disparada por tags. Neste caso < e > são escritos como < e >.
Uau! E como eu faço isso? Bom, escapar exibição de html em PHP não é particularmente difícil.
Exibir texto simples em uma página web:
Exibir text simples dentro de uma tag html:
Se você sempre usa aspas-duplas " nas suas tags, como por exemplo <input type="text" name="nome aqui" /> você pode usar ENT_COMPAT ao invés de ENT_QUOTES. ENT_COMPAT diz para a função transformar apenas as aspas-duplas, ENT_QUOTES vai transformar tanto aspas-duplas quanto aspas-simples.
Importante! Quando escapar a saída?
Você deve estar pensando que ao invés de ficar sempre chamando a função htmlspecialchars na hora de exibir o conteúdo você pode chamá-la apenas uma vez na hora de salvar o conteúdo? Talvez não seja uma boa ideia, hoje em dia é muito provável que você não vai exibir seu conteúdo apenas em páginas html, você também tem rss, json, csv, arquivos texto, emails e outras opções. Para cada uma destas opções de exibir conteúdo o processo de escape é diferente. Se você quiser salvar processamento você pode armazenar uma versão inalterada do conteúdo junto com versões já escapadas de acordo com sua necessidade.
Por enquanto é isso pessoal, espero que o artigo seja útil a vocês.
segunda-feira, 18 de janeiro de 2010
Sem ideias então links!
Já faz um tempinho que não posto nada aqui, eu queria poder falar que isso é excesso de trabalho com meu site ou falta de tempo. Geralmente o primeiro leva ao segundo, mas este não é meu caso. Como não estou com uma boa ideia sobre o que escrever resolvi compartilhar alguns links que tenho de livros gratuitos ou livres sobre informática e computação. Será que sou somente eu que junta links e mais links de livros mas acaba não lendo quase nenhum? Se eu lesse 10% de todo o material que achei, exisitiria uma foto minha na Wikipedia no termo programação e eu seria considerado mais legal que o allien do reddit.
Tomara que vocês sejam menos preguiçosos do que eu, aí vai a lista.
Tomara que vocês sejam menos preguiçosos do que eu, aí vai a lista.
- Acrobat Planet - De tudo um pouco.
- Stack Overflow - Várias sugestões postadas em uma questão do site.
- E-books directory - Muita coisa entre outras programação, algoritmos, estruturas de dados e até livros de matemática e engenharia.
- Meiobit - Um post no meiobit, os comentários tem muitos links também.
- Free IT Books - Tem até material sobre robótica.
- Python para Desenvolvedores - Para quem já sabe programar e quer aprender python em português.
- Free Computer Books - Este aqui pode esgotar seu hd.
- Reddit - Canal dentro do reddit, sempre estão adicionando alguma coisa.
- Bill the Lizard - Post deste blog com vários livros. O blog é bom também.
- Coderholic - Outro post de blog e nos comentários tem material extra.
Assinar:
Postagens (Atom)