Nesse sábado, dia 28/11/2009 aconteceu aqui em São Paulo (obviamente! ) o Dev In Sampa! Um evento para desenvolvedores em geral, sem foco em uma determinada linguagem de programação, ou seja, um evento bem legal e pragmatico!

Perdi um pouco a hora, portanto não assisti o começo da palestra do José Valim, que por sinal é um assunto que muito me interessa, portanto recorri aos vídeos do @agaelebe para assistir o comecinho. Para quem quiser ver os vídeos confira no blip.tv do agaelebe.

Agora vamos para  a programação e meus comentários:

José Valim – Tópicos de machine learning: classificação de textos

Como disse no começo do post, eu perdi o começo da palestra do Jose Valim por que eu me atrasei ( foi por um bom motivo ), mas compensei depois assistindo o vídeo. A palestra foi muito boa, e abordou um dos tipos de tema que eu gosto, machine learning é bem interessante! Essa é uma das coisas que eu pretendo estudar só por diversão, por que parece ser bem legal. O @josevalim fez sua tese sobre classificação de textos, portanto conhece bem do assunto e foi muito interessante ver as pesquisas dele consolidadas e simplificadas em uma apresentação.

Rodrigo Yoshima – Design de Software: As técnicas esquecidas…

O @rodrigoy fez uma palestra bem legal comentando sobre várias técnicas esquecidas sobre design de software, e muitos programadores que assistiram essa palestra devem ter se visto em várias situações por ele citadas ( eu fui um deles em alguns pontos ). Algumas das coisas citadas foram:

• Design incremental Nunca pense naquela história de “Preciso do pedido para poder fazer a tela de cadastro” sempre comece por aquilo que agrega mais valor. Faça as coisas sempre usando um pensamento incremental, criando testes para que quando você resolva um bug não crie mais outros por não saber as consequências de suas modificações. Sempre tomar cuidado com o design incremental para que ele não se torne um problema pelo mal crescimento da sua aplicação.

• Tomar cuidado com arquiteturas monolíticas / egípcias Arquiteturas difíceis de refatorar, que usam componentes pesados, quem ninguém sabe como foi feita e etc.
• Separar a função de cada unidade, não deixando que o produto tenha que saber sobre vendas, por exemplo.
• É melhor um design ruim com testes do que um design bom sem testes por que com testes você pode refatorar, agora sem testes a situação já muda bastante.

Entre outras coisas muito interessantes que eu não vou mencionar por que senão meu post vai ficar enorme, mas assista o vídeo e veja as dicas interessantes que ele dá.

Primeiro Coffee break para encontrar os amigos e bater papo! Tinha bastante gente do Guru-sp por lá ( @almeidaricardo, @shadow, @rafaelrosafu, @scalone, @bbcoimbra, @nelsonmhjr, @_bojak, @cassiomarques, @dcreq e mais um monte de gente! ), foi legal para bater um papo com os conhecidos. Só para constar, o Ronaldp Ferraz (@rferraz) veio falar comigo sem crachá e sem cavanhaque, e eu obviamente não conheci, tinha que se apresentar formalmente ( ou seja, com cavanhaque! O @tinogomes já aprendeu! haha ).

Ronaldo Ferraz – Criando sua própria linguagem de programação

Palestra muito boa do @rferraz! O assunto foi bem denso, mas bem interessante, ele mostrou alguns conceitos e informações interessantes sobre como criar e brincar com a sua própria linguagem de programação de uma maneira não tão difícil usando Treetop e Ruby. Como muitos já sabem o Ronaldo tem conhecimento infinito em linguagens de programação, portanto a palestra foi bem legal com vários exemplos em várias linguagens.

João S. O. Bueno – Desenvolvimento de jogos com Python

Puxa vida…Essa palestra foi um grande 417 ( Código de retorno do HTTP para Expectation Failed ), por que como muitos sabem eu adoro desenvolvimento de jogos, e fiquei muito feliz por ver uma palestra desse segmento nesse evento. Outra coisa que me entusiasmou bastante foi o fato de ser com Python, que assim como Ruby é uma linguagem que eu gosto bastante, mas em outra palestra que eu tinha visto ( no CONISLI 2008 ) o palestrante não foi muito feliz com o conteúdo. Enfim,  e fui com muita vontade de ver essa palestra.

No início da palestra quando falaram o nome do palestrante e eu o vi, percebi que parecia familiar, e por incrível que pareça…Era o mesmo do CONISLI 2008… Mas até aí tudo bem, agora o nível do pessoal é diferente e já se passou mais de 1 ano desde a ultima palestra, ou seja, essa prometia ser bem melhor.

Como puderam ver pelo começo do post, foi um grande engano meu, apesar de o palestrante falar que ia focar mais em jogos já que o pessoal já conhecia Python, ele ficou muito em Python e no finalzinho mostrou alguns joguinhos feitos em PyGame, como se a idéia da palestra fosse mostrar que Python é legal (que nós já sabemos! ) e dá para fazer jogos tambem. Enfim…Me decepcionou…

Intervalo para almoço

O Almoço foi meio corrido por que o evento estava meio atrasado, mas mesmo assim deu para conversar bastante com a galera do Guru-sp no shopping ( não me pergunte qual ).

Guilherme Silveira e Adriano Almeida – Do REST ao RESTFul

Na volta do almoço tivemos uma palestra teórica sobre REST e RESTful, que por sinal abriu muito a mente sobre o assunto. Mesmo o assunto sendo teórico o Guilherme Silveira e o Adriano passaram muito bem a idéia e souberam conduzir bem a palestra para manter o conteúdo bem dinâmico.

Nando Vieira – Escrevendo testes no JavaScript

Aqui um assunto que vem me interessando cada vez mais, testes! E como eu sempre gostei de Javascript, a palestra foi bem relevante. Infelizmente o Nando Vieira não conseguiu mostrar todos os exemplos que ele tinha planejado, mas foi bem interessante ver o live coding, e as amostras de testes para determinadas coisas. Gostei bastante da syntax do JSpec, não sei como fica a integração dele com o prototype ( que é o que eu estou usando atualmente no trabalho, mesmo preferindo JQuery ), mas pretendo dar uma chance para ele assim que possível.

Luis Cipriani – Web em tempo real com Ruby e XMPP

Bem legal o case que o Cipriani mostrou sobre a sua aplicação da maratona de basquete, achei muito interessante as ferramentas que ele usou, e vi que ele soube passar bem as informações sobre o XMPP que foram necessárias.

Coffee-break

Agora sim um coffee break que deu um tempinho para conversar com uma outra galerinha como o @rferraz, a @narwen, o @fabiokung e mais outra galera.

Ricardo Almeida – Buscas poderosas com Solr

Estava curioso desde o ultimo post do @dcrec sobre o Solr, e a palestra do Ricardo foi o ponto para tirar as minhas dúvidas. Vi muitas vantagens do Solr sobre o Sphinx e nenhuma do Sphinx sobre o Solr, acho que vale a pena tentar uma migração num futuro não tão distante.

Radamés Ajna – Arduino – Computação Física

A palestra do Radamés foi demais! Além do Arduino ser fantástico, o Radamés soube apresentar muito bem, mesmo com alguns problemas nos slides ele mostrou muito bem algumas coisas legais que dá para fazer com o Arduino, sempre com exemplos muito interessantes de coisas que já fizeram ou que ele pretende fazer. A interface para mexer com arduino realmente não parece ser tão complexa, e eu gostaria mesmo de ter algum conhecimento em eletronica nesses momentos, mas quem sabe algum dia eu tiro um tempinho para dar uma brincada.

Fabio Kung – Cloud Computing. E eu com isso?

Para fechar o evento tivemos uma palestra muito legal do Kung mostrando o que “ele acha” que é cloud computing, e os tipos de cloud computing que são oferecidos ( IaaS, PaaS e SaaS ). Ele mostrou como funciona e por que são usados os cloud computings atualmente, e como estão as experiencias dele com cluod computing atualmente. Achei a palestra bem legal, e é interessante ver as opiniões e experiências de alguem que realmente está vivendo essa parte de cloud computing.

Conclusão

O evento terminou bem atrasado ( mais de 20:00 ), mas valeu muito a pena ter ido. Há tempos estava sentindo falta de um evento que não levasse em consideração apenas uma linguagem de programação, algo que fosse mais pragmático mas que fosse totalmente voltado a desenvolvimento.

Parabens a todos os organizadores do evento e espero ver vocês novamente na próxima edição!

Há braços

Aqui começa uma série de artigos sobre por que eu gosto de usar o VIM para programar.

Uma das primeiras coisas que eu gostaria de comentar é sobre a quebra de paradigma que você deve ter quando começa a usar um editor como o vim que tem vários modos de operação, ou seja, não é mais apenas digitar, pois cada modo de operação tem o seu modo de agir. Os modos de operação são os seguintes:

• Inserção
• Visual
• Normal
• Comandos

Modo de inserção

O modo de inserção é um modo simples para se inserir texto sem nada muito complexo, você se sentirá usando um notepad se usar somente o modo de inserção.

Modo visual

Com o modo visual você pode selecionar facilmente trechos de texto, linhas inteiras e blocos de texto. Um exemplo bem legal de uso de blocos no Vim pode ser visto no blog do TaQ.

Modo normal

Agora sim as coisas ficam legais! No modo normal, que é o modo que você mais fica no Vim, você pode fazer as coisas mais interessantes!

Ok, falei…falei…e não mostrei o por que o modo normal é tão poderoso né? Bem, são coisas como essas:

• Dentro de aspas podemos dar um ci” e ele já excluiria todo o conteúdo que está dentro das aspas e deixaria você em modo de inserção para inserir um novo conteúdo
• Parar em cima do número 20 e quer adicionar 7? Apenas faça 7<ctrl+a> e ele fará a soma em cima desse número
• E se ao invés de soma vc quiser a subtração dos valores acima? Apenas faça 7<ctrl+x> e ele fará a soma em cima desse número
• É claro que você não vai ficar repetindo esse monte de coisas que você fez aí em cima se tiver várias ocorrências e você não quiser fazer um “find and replace”, por que você pode usar o . (ponto) para fazer a sua ultima ação novamente.
• Quer trocar as linhas de posição? Moleza! ddp ( sendo dd para excluir uma linha, que fica no buffer, e p para colar a linha do buffer )
• Está no começo da linha e quer ir para aquele parentese? f( e pronto, você já estará lá!
• Quer ir para um caracter antes do parentese? t( ta na mão!

Enfim…Tem muitas outras coisas legais a se fazer sem que você precise tirar a sua mão do teclado.

Modo de comandos

E o modo de comandos é onde você tem uma segunda linguagem de programação alem da que você está usando pra programar, e lá você pode tanto usar comandos de loop como:

:for i in range(1,10) | put ='192.168.0.'.i | endfor

OBS: créditos ao Sergio nesse post

Que imprime uma faixa de IPs de 192.168.0.1 até 192.168.0.10. Ou você pode alterar as funcionalidades e opções do editor utilizando :set ou outras comandos interessantes.

Use o Vim como ele foi feito para ser usado

Outra quebra de paradigma que deve ser usada é usar “hjkl” para se movimentar pelo texto, sempre usando os dedos indicadores sobre o “j” e o “f” que é o padrão de digitação, e você vai ser que você vai precisar tirar a mão do teclado para fazer outras coisas poucas vezes, e pelo menos para mim as coisas parecem bem mais fáceis. Isso lhe força a sempre usar <esc> ( ou <ctrl+[> ) após fazer alguma coisa, deixando o modo normal livre para uso.

Customização

O Vim pode ser facilmente incrementado com plugins, temas e outras coisas que tornam ele bem customizável, e você pode deixar ele com a sua cara. Atalhos são facilmente configuráveis no seu .vimrc, assim como configurações como highlight de busca, espaçamento para scroll, e mais muuuiiitas opções que obviamente não caberão nesse post.

Concluindo

A idéia desse post é falar que para se usar vim você precisa estar disposto a mudar muita coisa que você sabe, e a curva de aprendizado não é uma das mais fáceis, mas quando você está no meio dela você percebe o quanto é legal e acaba se viciando no negócio! hehe

Como o Vim é bem configurável pode acontecer de você ficar tentando implementar ele para ficar igual ao seu antigo paradigma ( modo de inserção para sempre ), mas isso não vai de ajudar muito e vai te abstrair toda a força do Vim.

É isso! Nos próximos posts sobre vim pretendo postar dicas, referências legais e falar bem mais aprofundadamente de algumas ferramentas.

Há braços

Como alguns sabem no final de semana passado ( dias 7, 8 e 9 ) eu participei do GameJam do Itaú cultural.

Nesse evento os participantes tinham que formar equipes de até 4 pessoas e fazer um jogo em 48 horas, sendo que o tema ao qual o jogo devia responder só seria passado na sexta feira as 19, e teríamos até as 19 horas do domingo para entregar o jogo pronto utilizando qualquer plataforma para desenvolvimento.

Pois bem, o que eu falei acima resume bem as regras do evento, agora vamos a minha situação. Fiquei sabendo na segunda feira pelo CrociDB que teria esse concurso e que tinha até quarta feira para se cadastrar, e eu tinha acabado de fazer uma mini-cirurgia para tirar um dente, portanto estava sentindo dores e tomando 4 tipos de remédios diferentes e não pude confirmar nada devido a esse motivo, mas a vontade era grande. Enquanto eu não confirmava o CrociDB ia procurando pessoas para a equipe.

Quarta feira ( ultimo dia para inscrição chega ) e eu já estava um pouco melhor e decidi me inscrever! Procurei por outras pessoas para compor a equipe, alguns descartei logo de cara por que sabia que ia ficar arrumando desculpinha para não participar, ou não teria peito o suficiente para aguentar a competição, então nem chamei, outros sabia que infelizmente não poderiam participar por motivo de força maior ( fez falta hein Rafael Masoni ), e teve ainda os últimos que eu achei que participariam e fui chamar mas me decepcionaram…

Início do contest

Sexta feira tudo preparado e lá vou eu as 19 para o Gamejam (que foi na faculdade Anhembi Morumbi), e após me perder um pouco ( para variar ) cheguei em cima da abertura e recebemos o tema:

“Maquinas inovadoras” “Maquinas e computadores podem tomar decisões inovadoras?”

E com isso lá se vai o nosso pensamento…Criar um robô em 2d no estilo side scroller? Criar um robô fazendo algum tipo de shooter? Criar um braço robô que faz algo? Como ele seria inovador? Ele seria inovador? Como são as decisões dos computadores atualmente?

E com essas várias perguntas chegamos a conclusão que um computador sozinho não pode tomar decisões inovadoras, ele apenas é programado para uma determinada finalidade, nunca cabe a ele as decisões finais com novas idéias. Com isso em mente nosso game foi baseado num braço robô que distribui caixas num armazém seguindo sua própria ordem, supostamente tentando uma maneira inovadora de organização de cores que pode ou não estar certa, e cabe ao jogador organizá-la da melhor maneira possível. Obviamente a idéia inicial não se fechou tão fácil, e fomos desenvolvendo ela de acordo com a evolução do game.

Com uma base inicial desenvolvida passamos para o desenvolvimento!

Preparamos o ambiente com Allegro e algumas classes que o CrociDB usa para facilitar algumas coisas e eu dei uma introdução sobre o workflow do Git para trabalhar utilizando controle de versão. Usamos um roteador para conectar os 2 notebooks e compartilhar um repositório para os códigos, por ssh mesmo, que infelizmente deixava a transferência muito ruim devido ao uso do Cygwin no Windows, mas não fui um grande empecilho, foi apenas chato.

Tenho que admitir que eu sou um zero a esquerda em Allegro e fui com a cara e a coragem participar desse contest, mas eu sabia que isso me traria muita experiência, por que eu sei que o CrociDB conhece bastante de Allegro e de desenvolvimento de games em si, e eu só comprovei isso durante todo o contest, ele já conhecia bem o conceito de desenvolvimento de games e tem bastante experiência com erros que podem acontecer.

Ficamos programando desde as 21 mais ou menos até as 5 da manhã e resolvemos ir para casa descansar para voltar no sábado a noite e ficar até terminar o game. A primeira vista achei o pessoal das outras equipes meio acuado, cada equipe isolada em suas mesas, excluindo apenas o pessoal que já se conhecia ou que era da faculdade.

Momento Hard work

Voltei no sábado as 19:30 para a programação e o CrociDB já estava por lá programando fazia alguns minutos e já tinha resolvido alguns probleminhas. Então já começamos a programar outras funcionalidades e fazer os desenhos para o jogo, que por sinal foi a parte mais difícil para nós, tendo em vista que nenhum dos dois tem a arte do desenho assim como as outras equipes tinham ( vi muitos desenhos e trabalhos legais ). Eu assumi uma boa parte dos desenhos para deixar o CrociDB mais focado na programação.

Durante o domingo tivemos vários problemas, como o não funcionamento do teclado do notebook do CrociDB, nos fazendo perder um tempo e ir para o laboratório usar um teclado USB, que levou a outro #fail, por que levamos o roteador e não prestamos atenção que a fonte não era bivolt, assim queimando a fonte do roteador…Ou seja…Nada de Git na parte final do projeto…

No laboratório conseguimos finalizar o jogo e encontrar umas midis legais até as 14:30 mais ou menos, quando preparamos as coisas para entregar o projeto final. Ao entregar o projeto e ver a organizadora testando percebemos que faltou uma dll para o allegro funcionar no Windows, e tivemos que pegar o projeto de volta umas 2 vezes para encontrar a dll certa, mas enfim funcionou.

Networking

Depois de entregar o projeto aproveitamos para fazer um Networking com alguma das outras equipes. Durante o evento estávamos sempre vendo algumas pequenas cenas dos outros jogos e algumas ferramentas, e uma que chamou bastante a atenção foi da equipe que estava ao nosso lado (Danilo, Gabriel, Theo e o Mario que eu não conheci) que estava desenvolvendo um game totalmente em blender! (assim que eles divulgarem o game eu posto o link aqui). O game deles ficou muito legal e o pessoal é muito gente fina também, foi muito válido conhecê-los!

Vi por cima mais alguns games que estavam em fase de produção ainda, e conheci algumas outras pessoas como o Danilo Vin (só conheço ele assim até agora…hahaha) que estava fazendo as artes do grupo dele, muito boas por sinal, mas não vi o jogo finalizado. Revi tambem o Speeder já tinha visto na campus party mas não tinha conversado muito.

Considerações

Finalizando, eu acho que esse contest foi muito legal,dormi apenas 40 minutos de sábado para domingo, mas foi minha primeira experiência com competição de desenvolvimento de games, meu primeiro contato mais próximo com Allegro, revi alguns conceitos de C++, conheci pessoas interessantes, vi alguns jogos serem criados do zero… Mesmo se nosso jogo não ganhar (o que é provável….hehe) esse contest valeu muito a pena!  O nosso game não ficou exatamente como queríamos por que além dos problemas, não conseguimos aplicar todas as idéias que tínhamos em apenas 48 horas.

Uma coisa que me deixou muito feliz foi ter conseguido fazer esse jogo usando apenas Software Livre! Utilizamos Inkscape, Gimp, Allegro e GNU/Linux. O Croci utilizou Windows para compilar a versão windows do jogo, e não tivemos sequer um problema de compatibilidade entre plataformas.

Para quem quiser dar uma olhada no nosso game, pode baixar ele no GitHub (o código não está um dos melhores, mas leve em consideração que foi um contest de 48 horas…hehe):

Código fonte

Download do pacote

• executáveis na pasta bin

Há braços

Mais um dos livros que eu consegui terminar de ler nas férias! O livro fala sobre performance de front end, como fazer as suas páginas carregarem mais rapidamente e fornecer uma melhor experiência para o usuário.

O livro começa explicando um pouco sobre o HTTP, seus métodos e utilizações, e depois inicia as sobre as 14 regras para ter um website mais performático. Eu vou tentar mostrar um pouco de cada uma das regras que o livro aborda, mas é claro que sem os grandes detalhes, comparações e exemplos que o livro dá, que são muito amplos e interessantes para se entender, mas vou dar uma visão geral de qual é o conteúdo da regra, para te chamar para comprar o livro e ler ( ou não…hehhe ).

As 14 regras são:

Faça menos requisições HTTP

Obviamente se tivermos menos requisições HTTP teremos páginas mais rápidas, então o livro recomenda várias técnicas legais como combinar imagens e usar estampas CSS, combinar scripts para evitar várias chamadas, assim chamando um script só, e tambem combinar folhas de estilo.

Use uma Rede de Distribuição de conteúdo

Distribua seu aplicativo de diferentes servers distribuídos geograficamente, pois assim você conseguirá entrega de pacotes mais rapidamente para determinados tipos de usuarios.

Adicione um cabeçalho expires

Sempre usar bem os cabeçalhos expires dos pacotes, para que o browser possa controlar de maneira correta o cache. Utilizando expires para datas futuras você cosegue um ótimo ganho de performance, por que não vai ser necessária outra chamada HTTP, pois o browser vai saber que seu cache não expirou e vai manter os arquivos já baixados.

Obviamente isso deve ser bem controlado para você saber o que deve ficar no cache e quando substituir determinadas coisas ( que podem ser substituidas alterando o nome, por exemplo ).

Componentes gzip

Sempre usar o mod de gzip ( se vc estiver usando apache ), pois os ganhos são muito grandes, e chegam a mais de 50% do total de tempo final de renderização da página.

Coloque as folhas de estilo no topo

Um argumento bem legal para esse! O autor do livro mostrou suas experiências com o arquivo CSS em outros lugares que não são o topo e percebeu que a página esperava pelo CSS para poder continuar renderizando a página, portanto reduz a experiência do usuário, que ficará com uma página em branco enquanto aguarda, sendo que poderia estar vendo aos poucos a página.

O que faz o browser esperar que o CSS seja carregado é o fato de ele não ter que renderizar duas vezes ( uma com o css padrão do browser e outra com o seu CSS personalizado ).

Coloque os scripts no final

O argumento para esse é que a pagina sempre para de carregar os outros componentes enquanto está carregando os scripts, por que eles podem alterar a página com algum document.write, e muitas a ordem precisa ser mantida, portanto com os scripts no final da página você vai retardar menos o carregamento, pois quando estiver carregando o script o usuário já vai ter uma boa parte da página para se intreter.

Lembrando que nem sempre é possível colocar o script no final da página, pois as vezes os elementos precisam do script carregado para fazer determinadas coisas, mas sempre que possível a sua performance pode ser melhorada com os scripts no final.

Exite expressões CSS

Todos sabemos que expressões CSS ( usando expression ) não é bom, e o livro demonstra alguns por que’s disso que não vou abordar, apenas digo: Não use!

Deixe o Javascript e o CSS em arquivos externos

Interessante essa parte, por que como eu pensava, realmente deixar o CSS e o Javascript embutidos na página é mais rápido, mas quando se tem Javascript e CSS em arquivos separados e com um expires configurado você tem uma melhor resposta por que os scripts seriam carregados uma vez só e depois mantidos em cache enquanto várias páginas ficariam menores para carregamento.

Reduza as pesquisas em DNS

Nesse capítulo ele fala um pouco do tempo que demora para resolver um DNS e que é possível fazer caches de DNS

Minimize o Javascript

É comentado um pouco de ofuscamento de Javascript, quando você tira todos os espaços e caracteres inúteis do seu javascript deixando ele funcional e mais leve. Quando se usa Gzip essa técnica ajuda pouco, pois o texto já vai ser compactado, mas mesmo assim ainda há ganho, e um comentário pessoal: Se você não altera esse javascript com frequência, por que não?

Evite redirecionamentos

Os redirecionamentos são reponsáveis por uma boa parte do tempo de uma requisição, deixando o usuário vendo uma tela em braco nesse meio tempo, portanto não são nada bons para um website. O livro trata de algumas formas para evitar redirecionamentos, como alias do apache por exemplo.

Remova scripts duplicados

Parece estranho a primeira vista mas realmente acontece dependendo do tamanho do seu código e a quantidade de CSS e Javascript que você possui em sua página. O autor resolveu colocar esse tópico analizando grandes sites da internet e percebendo que vários deles possuia esse problema, gerando requisições em vão.

Configure as Etags

Use-as ou deixe-as! As Etags podem ajudar bastante na performance se bem configuradas e o livro dá vários exemplos de como isso pode ser feito, alem de uma explicação legal do que são as Etags.

Faça com que o AJAX se aproveite do cache

O livro descreve alguns exemplos onde o cache pode ser utilizado para aplicações com AJAX ( utilizando expires com data futura ) e outros onde realmente é dinâmica demais para se usar um cache. É interessante para se descobrir maneiras diferentes de se lidar com a performance e como ela se aplica para o seu caso.

Analizando 10 grandes sites

Essa foi uma parte que eu gostei bastante de ler, por que ele mostra grandes sites que estamos acostumados acessar ( os sites analisados nesse capítulo são: Amazon, AOL, CNN, eBay, Google, MSN, MySpace, Wikipedia, Yahoo, Youtube ) e mostra as partes boas e ruim que foram implementadas, e assim você ve com ótimos exemplos o que poderia ser feito, juntamente com as ferramentas utilizadas para a medição de cada uma das funcionalidades, e você pode muito bem utilizar as mesmas ferramentas para medir o seu website.

Conclusão

O livro é muito legal para se saber como trabalhar bem uma performance de front para você proporcionar uma melhor experiência para o seu usuário, deixando uma navegação mais rápida. Algumas das coisas que o livro aborda são extremas ( necessárias para grandes sites, como no caso do autor, o Yahoo! ), e muito provavelmente não são totalmente úteis em pequenos websites, mas a grande maioria é totalmente aplicável.

Eu particularmente gostei bastante do livro, mesmo ainda não aplicacando tudo o que o livro fala, consegui ter uma boa noção de boas práticas e experiências de alguem que já trabalhou com isso e tem bons argumentos para lhe dizer por que isso seria uma boa escolha.

Eu recomendo!

Há braços

Esse vai ser um post rápido para relatar um problema que eu tive ( e ainda estou tendo ) para instalar gems do GitHub.

Por algum motivo bizarro ( nem tanto assim, parece ser dns, mas já tentei opendns e nada ) a página http://gems.github.com não abre de maneira nenhuma, enquanto a navegação continua normal sem nenhum problema…A consequência disso é que eu não consigo colocar o source do github nas minhas configurações do Rubygems.

Tendo em vista que eu não conseguiria utilizar gem install para nenhuma gem que vinha do GitHub tive que dar um jeito de instalar manualmente.

O que fiz foi acessar a página do GitHub referente a gem que eu queria instalar, que no caso é a kitabu do fnando, pegar o link de clone e clonar:

$ git clone git://github.com/fnando/kitabu.git

Mas ae que está o lance que eu demorei para encontrar ( noob ), para uma gem ser instalada localmente ela precisa estar empacotada, e no GitHub você baixa direto o código fonte. Para empacotar:

$ gem build kitabu.gemspec

Agora sim eu tenho o arquivo kitabu-0.3.3.gem que eu posso utilizar para instalar localmente! Para instalar é só utilizar o gem install padrão informando o arquivo a ser instalado:

# gem install kitabu-0.3.3.gem

E pronto! Lá está a minha gem instalada! Espero que isso seja útil para mais alguem que precise empacotar as suas gems.

Há braços

Æ!!

Nesse sábado aconteceu o quinto encontro do Guru-sp!

O encontro estava marcado para as 10 da manhã com uma seção para iniciantes e começou as 10:30 ( sempre atrasa um pouquinho né? hehe ), já com um bate papo legal coordenado pelo @rafaelrosafu após uma breve apresentação de todos os participantes.

Rails para iniciantes

Nessa primeira seção tiveram muitas conversas interessantes sobre algumas filosofias Rails, como DRY, REST, TDD, Test all the Fucking Time, Skynny Controllers and Fat Models e mais algumas outras coisas bem interessantes que fomentaram uma ótima discussão sobre quais os melhores padrões para se seguir quando se constrói uma aplicação Rails ( sim, falamos tomando como base uma aplicação Rails ), como utilizar plugins como o ResourceController ( que tem seus prós e contras ), manter seus scripts num lugar diferente da pasta scripts, que é a pasta padrão para scripts “internos” do Rails e tentar centralizar em uma pasta dentro de lib, além de usar Rake sempre que possível para essas tarefas ficarem organizadas e de fácil acesso.

Uma parada rápida para o almoço no Shopping e lá se vão mais de 20 programadores para comer a bater papo!

DataMapper

Após o almoço tivemos a palestra sobre DataMapper do @rafaelrosafu ( olha ele aí novamente! ) que explicou muito bem dando várias referências sobre o seu blog pessoal e como ele fez para utilizar o DataMapper ao invés do Active Record. O Rails é mais difícil de se sair do padrão, mas ficará mais simples de se escolher um ORM quando chegarmos ao Rails 3. Aproveitando o gancho de DataMapper eu falei um pouco de Sinatra dando alguns pitacos na condução do Rafael.

Git

Após a palestra de DataMapper passamos para uma palestra de Git com o Douglas ( qmx ), que foi muito interessante e participativa! Pegamos uma galera do grupo para fazer um scaffold e commitar no projeto para começar a ver coisas diferentes, como merges, rebases, mudanças de commit, e algumas outras coisas legais, como usar tags, procurar por um código em meio aos commits e outras coisas interessantes! =)

Levantamos a idéia de participar do Rails Rumble, aproveitando que o Diego Carrion estava conosco e comentou que a GoNow estava patrocinando 3 equipes para o evento, mas não conseguimos ter uma idéia legal para propor para o concurso.

Coding Dojo

E finalmente como ultima coisa do dia tivemos o nosso coding dojo, que era uma das coisas que eu mais estava esperando nesse econtro! O Vinicius Baggio  “se ofereceu” ( com um empurrãozinho meu…hahah ) para ficar com o notebook ligado no datashow e conduzir o código. O dojo foi muito divertido com participação de todos da sala, o que sempre trazia novas idéias para fazer um código melhor e agregava conhecimento para todos. Fizemos TDD para construir umas classes simples de usuário.

Conclusão

Gostaria de agradecer ao André e o pessoal da Voice Technology por todo o apoio ao evento e ao grupo, com local, organização, fotos e mais várias outras coisas! Guys you Rock!

Infelizmente algumas pessoas não puderam aparecer, e outras apareceram por pouco tempo ( o Marcelo Castellani ), por motivos pessoais, mas espero que estejam presentes no próximo!

O evento realmente valeu a pena e aprendi muita coisa por lá, alem de conhecer muita gente interessante tambem! Agora é marcar os próximos e esperar que o grupo cada vez cresça mais e podemos fortalecer as amizades e conhecimentos!

Há braços

Æ!!

Há tempos que eu estava querendo conhecer um pouco mais do Git e nos últimos dias estava procurando um livro legal, quando me deparei com esse livro. Fiz algumas perguntas para um pessoal no Twitter como pessoalmente sobre esse livro, alguns me recomendavam, outros me passavam outros também interessantes, e estava em dúvida entre comprar ou não, até que consegui emprestado e li em 3 dias.

O livro é bem interessante, aborda desde o mais básico até o nível intermediário, não abordando conteúdos tão avançados.

Começa abordando como é o fluxo de trabalho do git, mostrando com exemplos práticos como você faz para usar o git num projeto, modificando o arquivo, adicionando para o stage, fazendo commits e etc. E fica uma boa parte do livro mostrando um pouco sobre as formas com que você pode fazer as coisas, como:

• Adicionar arquivos como o git add -i para adicionar interativamente
• Usar git log -p para alem de ver as mensagens de commit ver tambem o que foi usado
• git log -2 para ver apenas as 2 ultimas mensagens de log
• git diff –cached para fazer o diff do que já está no stage
• E mais várias outras dicas úteis

Uma das coisas que eu achei interessante foi a apresentação de curiosidades interessantes como dizer que o Git usa um hash SHA1 que tem uma chance se se repetir de 2⁶⁹ .

Comentou sobre algumas ferramentas para se usar junto com o Git, como alguns mergetools para facilitar no processo de merge e o git gui ( que é feio que dói, mas funciona ) para quem gosta de brincar com algo no estilo tortoise.

Depois de explicar sobre a parte básica do Git ele começa a passar para algo mais intermediário, onde vem os merges e as modificações de commits localmente.

Nessa parte mais intermediária foi comentado sobre o git rebase e como você pode usá-lo para reorganizar os seus ultimos commits usando git rebase -i. É uma técnica bem interessante quando se faz um monte de commits locais mas quer enviar apenas um commit para o repositório.

Foi comentado tambem sobre tags e como é útil utilizá-las para marcar as versões do seu sistema, sendo que você pode adicionar commits apenas a uma tag e tal. Utilizando git tag 1.0 você já define que determinado commit marca a versão 1.0 do seu sistema. Você pode depois dar um git checkout na sua tag e ver ela como read-only ( sendo possível criar um branch e fazer modificações ).

Mais modos do git log foram apresentados tambem, como fazer um git log para ver os commits das ultimas 5 horas, ou desde as 10 horas usando –since ou –before, ou até mesmo usar um –pretty=format:”" e passar uma melhor maneira para formatar o seu log.

Conheci algums comandos interessantes que raramente são usados mas são muito úteis tambem:

• O git gc que compacta o seu repositório para que ele exclua tudo o que não está relacionado a nada, assim reduzindo o espaço que seu repositório ocupa.
• O git archive para você gerar um arquivo com seu repositório com a versão que quiser, sendo tag, passando o Head ou o que achar melhor.
• O git reflog para quando você precisa recuperar algum commit que não está mais no repositório, algo que estava em um branch que foi excluído ou coisas do gênero ( lembrando que se você usou o git gc isso não será possível )

O livro tambem comenta de vários outros comandos, como o git cherry-pick por exemplo, para você passar um commit para outro branch, e sem contar que mostra várias opções que os comandos normais tem, como o git diff para você ver os status a partir de uma tag e tal.

Concluindo, achei o livro interessante e recomendaria para muita gente! O que eu tenho a dizer é que ele não é um livro para alguem que quer ver algo avançado em git, e sim alguem que não conhece ou sabe apenas o bem básico, pois assim vai conhecer algumas coisas bem legais.

Participei nesse sábado do EDTED ( Encontro de Design e Tecnologia Digital ), e vou postar as minhas impressões sobre o evento, focando as palestras que assisti:

CMS’s livres: não reinventado a roda no desenvolvimento web

A palestra foi conduzida por Paulino Michelazzo da Fábrica Livre, e foi uma palestra interessante!

O palestrante soube levar bem a palestra, com momentos engraçados ( várias brincadeiras com Java e Windows, que obviamente não devem ser levadas a sério ), e apresentando como é fácil criar uma loja virtual utilizando o Joomla. O que achei legal da palestra foi ele não focar apenas o Joomla, e sim izer que você não precisa reinventar a roda, e pode usar várias ferramentas para isso como o Drupal, WordPress, e obviamente o Joomla, cada um para sua determinada finalidade.

Crédito para o palestrante: Falou que uma parte do valor que eles conseguem com os projetos eles doam para os softwares livres que eles usam, e isso sim é devolver o que você conseguiu gratuitamente! Parabens a Fabrica Livre.

Scrum

Encontrei um amigos como o Ricardo ( Guitarrista do Megadriver e programador Web ) e fiquei networkeando conversando por um bom tempo sobre diversas coisas, portanto acabei chegando na metade da palestra.

A palestra foi conduzida por Fabiano Milani, em nome da Caelum, e pelo que consegui assistir foi aquele overview geral sobre o Scrum ( que eu tambem já tinha visto ), e teve uma parte de dúvidas bem legal, com várias pessoas perguntando como poderia implementar Scrum, ou se estava implementando Scrum corretamente, com boas respostas do palestrante.

Para quem nunca tinha visto uma palestra de Scrum deve ter gostado bastante da palestra.

SEO – Search Engine Optimization

Tambem já tinha assistido outras pelestras sobre esse tema, e elas geralmente são iguais, portanto para mim não teve muita novidade. De modo geral, o palestrante Fabio Ricotta da Mestre SEO conduziu bem a palestra, deu dicas interessantes sobre como organizar a sua página semanticamente, mostrou várias ferramentas úteis para utilização em SEO, e várias outras dicas bem interessantes.

Uma coisa legal para enfatizar: SEO não é algo que você faz e pronto, e sim algo que deve ser mantido e atualizado com o tempo, pois você não vai ter sempre alta relevância se você aplicou SEO e ficou bem nas buscas, pois isso vai caindo com o tempo, e você precisa continuar mantendo isso com boa semântica.

Desenvolvimento web ágil: ferramentas, arquiteturas e princípios

O Guilherme Chapiewski falou sobre muita coisa legal, avaliando linguagens e frameworks como Python / Django. Ruby / Rails, Java, PHP / CakePHPe mais outras coisas. Foi abordado alguns gostos pessoais e experiência própria do Chapiewski sobre as linguagems e frameworks, inclusive algumas considerações sobre Rails e Scala ( ¬¬ ), mas a abordagem disso foi com dicas de como poderia ser resolvido de meios diferentes, com problemas que são conhecidos e poderiam ser tratados para ajudar.

Ele comentou de 7 métodos que ele usa como um programador ágil:

• Soluções a longo prazo
  • Sempre pensar no que pode acontecer futuramente. Ele usou um exemplo bem legal sobre um cara que não documentou um sistema por que não tinha tempo, quando futuramente 3 pessoas perderam cada uma 2 dias para entender o que aquilo fazia…Ou seja no fim das contas foi perdido mais tempo do que ganhado nesse caso.
• Elimine desperdícios
  • Usar um framework que cria tudo facilmente e você pode portar ele facilmente para outras features
• Qualidade não é negociável
  • Aqui outro bom exemplo…O médico está limpando o paciente após uma cirurgia e o paciente fala para ele deixar isso por que está atrasado para alguma coisa, e é claro que o médico vai te ignorar  e limpar, por que ele sabe o que é o certo para se fazer, ele não negociaria a qualidade do trabalho por causa do seu tempo.
• Não esconda os problemas do cliente
  • O cliente é um cara legal e sua solição simplista pode ser o suficiente para ele
• Use a melhor ferramenta para cada problema
  • E lá vamos com bons exemplo: Um marceneiro não usaria um martelo para cortar uma mesa sendo que ele poderia usar uma serra para isso. Portanto use sempre o mais adequado para cada situação
• Documente menos e simplifique mais
  • Foi mostrado um bom exemplo de código, que você olhava e intuitivamente sabia o que ele fazia.
• Reflita sempre sobre o que você faz e melhore comtinuamente
  • Não fique apertando parafuso para sempre, sempre renove seus conhecimentos.

Os argumentos do Chapiewski sobre Java ser o novo COBOL é bem interessante! Ele diz que o JAVA antigamente tinha ótimos motivos para ser adotado, e assim muitas empresas começaram a utilizar, e atualmente temos sistemas monstros desenvolvidos e vários programadores programando em Java, portanto para sair da linguagem não vai ser tão fácil assim, e foi isso que aconteceu com o COBOL. O Chapiewski falou que só usa Java hoje em dia se tiver um sistema que é obrigado a integrar com Java, por que ele não ve um bom motivo para usar Java, sendo que ele pode usar coisas que ele considera melhor e com mais benefícios.

The Rails Way – Como Ruby on Rails pode te tornar um programador pior

O Carlos Brando falou e muito bem sobre o Ruby! Falou muita coisa que eu tinha vontade de dizer sobre Ruby != Rails utilizando um exemplo de miojo e macarronada, como seu o miojo fosse o framework para o suposto cozinheiro!

Vários exemplos com código para mostrar como o Ruby é parecido com a nossa lingua, e não com a lingua do computador, inclusive usando uns exemplos simplificados do Why. Teve alguns exemplos de metaprogramação para saciar a vontade de quem já conhece um pouquinho de Ruby tambem!

Gostei bastante da ideia da palestra e o por que de você se tornar um programador pior ( você saindo de uma outra linuguagem que você se considerava bom, para uma outra coisa que você não sabe nada ), e ainda mais mostrando os facilitadores dos frameworks que ajudam você, mas abstrai um pouco da sua felicidade em desenvolver um pouquinho mais low.

Mercado de trabalho em TI

Foi uma “mesa redonda” com todos os palestrantes, discutindo sobre assuntos sugeridos pelo pessoal que estava assistindo o evento. Foi discutido sobre os valores de trabalho no mercado, apoio as universidades pelo governo, scrum, software livre e outras coisas.

Considerações finais

Gostei bastante do evento, consegui conversar várias pessoas legais por lá, como o Caue Linden da HostNet, Maujor do Maujor.com.br, Hugo Borges, Rafael do Ruby Inside, Ricardo que é guitarrista da banda Megadriver ( ouça por que é muito foda! ), Guilherme Chapiewski, Carlos Brando e mais um monte de gente!

O Evento foi muito legal quanto a palestras e networking! Quem não foi perdeu!

Há braços

Æ!!

Estou postando para anunciar que foi lançada a versão 1.0 do meu plugin para WordPress chamado anti-IE6-army!

A idéia do plugin é juntar um exército de campanhas contra o Internet Explorer 6 que estão perdidas pela internet em um único plugin, para que todos que possuem blogs com WordPress possam usar facilmente, sem precisal alterar HTML, ou abrir qualquer arquivo de código!

Aqui no blog tem uma página só para falar do Plugin, e lá você pode obter mais informações.

Espero o comentário de vocês sobre o Plugin, e se quiserem contribuir com código, o projeto está no GitHub!

Esse foi o meu Call to Arms, agora espero que vocês realmente usem!

English Version

I’m posting here to announce my anti-IE6-army WordPress Plugin!

The idea behind this project is unite a lot of campaigns against Internet Explorer 6 that are splitted on the internet on one single wordpress plugin, so everybody with a WordPress blog will can use it easily, without change any HTML, or open a single code file!

You can read more about this plugin on the plugin page at this blog.

I’m waiting your comments about the plugin, and if you want to contribut with code, the project is on GitHub!

This post is my Call to Arms! Now i hope you really use this plugin.

Há braços

Æ!!

No mes de fevereiro eu estive envolvido com um projeto bem interessante na empresa que estou trabalhando ( ainda vamos trabalhar mais em nosso site ),  que foi feito em Python / Django e deveria gerar páginas estáticas ( exigencia do projeto ).

Tivemos um prazo muito curto para tudo que deveria ser feito, o que gerou uma grande quantidade de trabalho fora do horário e dos dias comuns. Entre o começo e o fim do projeto, tínhamos o carnaval, portanto tivemos que deixar nossos espíritos carnavalescos guardados e partir para o trabalho árduo no feriado até horas indeterminadas.

O ambiente de trabalho era bem legal, trabalhamos onde chamávamos de The Rubens, que tinha tudo o que precisávamos para nos sentir a vontade:

Obviamente nada melhor do que instrumentos ( para uma leve descontraída antes de voltar ao trabalho árduo ), pessoas motivadas, barrinhas de cereal,  livros ( vários nomes interessantíssimos nessa biblioteca! ) e programação! A única coisa que não tínhamos era tempo o suficiente para fazer tudo tranquilamente, mas aproveitamos bastante o tempo.

Trabalhamos todos os dias durante o carnaval, sábado, domingo, de madrugada, e em qualquer outro horário que fosse possivel ( hehe ). Nosso repositório Git já estava bem legal no gráfico de Network do GitHub, entre emaranhados coloridos!

Durante o caminho tivemos que enfrentar alguns contratempos, como o calor infernal, a falta de energia elétrica, a quantidade de novidades para lidar, tanto com o Python / Django, como com o Git e outras coiasas mais!

Nenhum dos contratempos pode nos barrar muito! Com o calor vieram os ventiladores, com a falta de energia veio o nosso local de trabalho provisório ( só durante aquele dia ), e o prazo curto nós conseguimos vencer com muitas barrinhas de cereal e horas de trabalho.

Ahhh! É claro que no meio de toda a correria tinhamos que ter tambem o nossos momentos de descontração, alem do nosso amigo Darth Vader que aparecia na hora dos conflitos do merge… hehehe

Entre nossas descontrações ( geralmente pouco antes de ir embora, 22:00h ) tinhamos sessão violão e sitar, ou momento Guitar Hero,  ou jogo de alvo + dardos, um pouco de tiro com o Open Arena entre outras coisinhas.

Estavamos trabalhando com  2 Macs, 1 Windows e 1 Linux, portanto sempre tinha as boas e velhas conversas sobre o melhor sistema operacional, que é claro que o Linux é o melhor ( haha, pelo menos aqui eu sou o root para dizer isso…hehehe ).

Enfim…Foi um projeto corrido, dormimos pouco, trabalhamos muito, consideramos feriados e finais de semana como dias normais de trabalho, mas…Como diria o Rubens ( algo parecido com isso ):

“É dos projetos mais difíceis que ficam as suas ótimas recordações”

Portanto, na minha humilde opinião, se você tiver a oportunidade de entrar naquele projeto difícil com bons amigos, faça que vai valer a pena!

Update: Bem lembrado pelo Nelson! Nós temos o nosso vídeo de comemoração, quando terminavamos nossas features:

<

p style=”text-align: center;”>

Há braços