Arquivo → January, 2010
Off:como transformar o seu Macbook em um adaptador wireless para Xbox 360
Enquanto digito este post meu XBox 360 está baixando atualizações da Internet. Tudo normal se não fosse por um pequeno detalhe: meu “adaptador wireless” para o Xbox é o meu Macbook. Se você não quer gstar uma fortuna naqueles adaptadores, pode usar o seu notebook para este fim. Acredito que com algumas pequenas alterações o mesmo poderá ser feito usando um notebook com Windows ou Linux.
Sendo assim, aqui segue o passo a passo:
1. Conecte o seu XBox 360 ao seu Macbook usando um cabo de rede qualquer.
2. Configure o seu MacBook para compartilhar a sua conexão de Internet wireless usando sua conexão Ethernet
Em preferências do sistema selecione o seu adaptador Ethernet e configure o seu endereço IP manualmente com os seguintes parâmetros:
Endereço IP: 10.0.0.1
Máscara de rede: 255.255.255.0
Em seguida, vá em “Compartilhamentos” e selecione a opção “Compartilhamento de Internet”
Em seguida, marque a opção “Para computadores usando” -> Adaptador Ethernet (en4)
3. Configure seu XBox 360
No Dashboard, vá para a aba “Configurações do Sistema”
Em opções de rede, configure-a manualmente com os seguintes dados:
Endereço IP: 10.0.0.2
Máscara de rede: 255.255.255.0
Gateway: 10.0.0.1
Em seguida, altere suas configurações de DNS definindo como servidor de DNS o endereço do seu roteador wireless.
Voilá! Você acaba de economizar 400 reais!
Gradle: um sistema de build MUITO agradável
Recentemente resolvi experimentar o Gradle em um projeto. Para aqueles que não o conhecem, trata-se de um sistema de build baseado em Groovy que trás a expressividade desta linguagem para o mecanismo de build, o que torna nossos scripts muito mais legíveis e fáceis de escrever. Sou fã do Ant, porém sempre me incomodou o fato de escrever meus scripts usando XML ao invés de uma linguagem estruturada.
Entre as principais vantagens que pude observar foram:
- Aprendizado mais fácil: como meus scripts são basicamente Groovy (que já conheço bem), tudo o que precisei aprender foram basicamente 3 coisas: como definir dependências, as tarefas default e uma ou outra task presente na API.
- Código mais fácil de ser compreendido: frequentemente me pego perdido em meus scripts do Ant conforme meus processos vão se tornando mais complexos.
- Escrita muito mais fácil: enquanto no Ant eu preciso ficar o tempo inteiro pesquisando a documentação em busca de quais tasks fazem o que, com Gradle tudo o que preciso consiste em escrever código Groovy.
Neste post irei expor o que já aprendi a respeito da ferramenta que, apesar de muito pouco, já supriu 100% das minhas necessidades.
Primeiro passo: instalação
Básicamente o mesmo processo de instalação do Groovy ou Grails.
- Baixe os binários em http://gradle.org
- Descompacte-os em um diretório de sua preferência
- Crie uma variável chamada GRADLE_HOME que aponte para o diretório no qual se encontra a sua instalação
- Adicione o diretório GRADLE_HOME/bin ao path do seu sistema.
- Execute o comando gradle em sua linha de comando. Se aparecer uma mensagem diferente de “comando não encontrado”, você já pode começar a trabalhar.
Segundo passo: escrevendo seu primeiro script
Assim como no Apache Ant, o núcleo dos scripts de build do Gradle são as tarefas (que chamaremos daqui pra frente de tasks). O script mais bobo que podemos criar é o abaixo:
task bobagem << {
println "Sou uma bobagem"
}
Tudo o que estiver entre << { e } é código Groovy. Em nosso caso, a task irá simplesmente imprimir o texto “Sou uma bobagem” em nossa linha de comando.
Para executar o script, lembre-se de salvá-lo como build.gradle (é o nome default dos scripts usado pela ferramenta, mas pode ter também outros nomes, desde que você utilize o parâmetro -b seguido do nome do arquivo) e em seguida executar o comando gradle -q bobagem. O parâmetro -q indica qual task deverá ser executada.
Caso nenhum comando seja passado ao script, será exposta uma mensagem de erro nos informando de que não há uma task default definida em nosso script.
Como definir uma task padrão
Definir uma task padrão é muito simples. Basta incluir na primeira linha do seu script o seguinte comando:
defaultTasks 'bobagem'
Executando novamente o script (desta vez sem parâmetros) a task bobagem será executada.
Se você quiser, pode também definir uma sequência de tasks a serem executadas, tal como no exemplo abaixo:
defaultTasks 'bobagem', 'mais_bobagem'
Neste caso, a task bobagem será executada e, em seguida mais_bobagem.
Definindo dependências entre as tarefas
Se é um sistema de build, dependências devem poder ser definidas. Em nosso caso, é simples, tal como no exemplo abaixo:
defaultTasks: 'mais_bobagem'
task bobagem << {
println "Sou boba"
}
task mais_bobagem(dependsOn: bobagem) <<
println "Mas eu sou ainda MAIS boba!"
}
E a saída de nosso script será
Sou boba Mas eu sou ainda MAIS boba!
Abusando do Groovy
E basicamente isto é tudo o que você precisa saber para começar a trabalhar. Para tornar a utilização do Gradle mais nítida, achei que seria interessante expor aqui um script que escrevi para fazer o backup de uma das minhas bases de dados:
defaultTasks 'backup'
def dataAtualString = {
java.text.SimpleDateFormat formatadorData = new java.text.SimpleDateFormat("dd_MM_yyyy___hh_mm_ss")
return formatadorData.format(new java.util.Date())
}
def arquivoBackupMySQL = {
return file(diretorioBackup.getAbsolutePath() + "/gctbd_${dataAtualString()}.sql")
}
task backup << {
println "Executando backup do MySQL..."
def arquivoBackup = arquivoBackupMySQL()
println "Gerando arquivo ${arquivoBackup.getAbsolutePath()}"
"mysqldump -u loginQuente --password=quente --databases bd_quente >> ${arquivoBackup.getAbsolutePath()}".execute()
println "Backup do MySQL executado com sucesso"
}
Repare que além da minha task backup tenho dois métodos: dataAtualString (que me retorna uma string contendo a data formatada) e arquivoBackupMySQL (que me retorna o arquivo aonde desejo salvar o meu backup.
Tudo o que preciso fazer consiste em chamar estes métodos assim como faria em Groovy dentro da minha task. Um processo muito mais simples do que aquele com o qual estava acostumado com Groovy.
Mas nem tudo são flores
Gradle ainda é novíssimo: pelo que pude ver, sua lista de discussão foi criada na segunda metade de 2008, e o projeto ainda está na sua versão 0.8 (nem logotipo direito possui!). Sendo assim, ainda é pouco conhecido e, consequentemente, possui bem menos material a seu respeito do que mecanismos mais tradicionais como o Apache Ant ou o (argh!) make.
Outro ponto negativo que encontrei foi a performance, que é bem aquém do Ant. No entanto, não tenho dados para comprovar esta queda na performance. Sendo assim, nada impede que trate-se apenas de impressão minha.
Tirando estes dois poréns (ambos temporários), acredito que o Gradle venha a se tornar cada vez mais popular como uma alternativa ao Ant pelo fato de adotar a linguagem Groovy como lingua franca. Recomendo!
PS:
sim, eu já conhecia o GANT, mas quis experimentar o Gradle para ver como era. :)
Adobe Flex – recursos para iniciantes
Visto que tanta gente se interessou pelo meu post anterior sobre Flex (“Por que resolvi largar o HTML e partir para o Flash (Flex na Realidade)”), achei que seria uma boa idéia publicar aqui os recursos que venho utilizado no meu aprendizado. Assim, quem sabe, vocês não me dão algumas sugestões também, não é mesmo?
Fonte primária: Developer Network da Adobe - http://www.adobe.com/devnet/flex/
Esta é a mais óbvia de todas, certo? A Adobe documenta suas tecnologias maravilhosamente bem, e na DevNet podemos encontrar básicamente tudo o que precisamos para começar a “por a mão na massa” de fato. No entanto, há alguns pontos que gostaria de destacar:
Adobe Flex in a Week - http://www.adobe.com/devnet/flex/videotraining/ – Uma série de vídeos nas quais são explicados os principais conceitos por trás do Flex. O único porém é que para assistir a estes vídeos é necessário baixar o Adobe Media Player: trata-se de um player voltado únicamente para os vídeos disponibilizados pela Adobe. Soa meio chato à primeira vista, mas uma vez instalado é pouca a chance de você se arrepender, pois o conteúdo veículado é simplesmente fantástico.
Adobe Flex Cookbook - http://cookbooks.adobe.com/flex – Fenomenal, como o próprio nome diz, trata-se de inúmeras “receitas de bolo”, nas quais podemos encontrar soluções para os problemas mais (e menos) frequentes relacionados ao desenvolvimento de aplicações em Flex. É práticamente imprescindível para aquelas dúvidas que julgamos ser tolas (mas que não são) quando estamos aprendendo uma linguagem nova.
Live Docs - http://livedocs.adobe.com/flex/3/html/index.html – Assim como em Java temos os Javadocs, na plataforma Adobe temos os Live docs. Se você tem dúvida com relação aos métodos e propriedades de alguma classe, este é O local para se pesquisar.
Download da documentação completa (quer um único link? é este!) - http://livedocs.adobe.com/flex/3/flex3_documentation.zip – É possível fazer o download da documentação completa do Flex (incluindo os LiveDocs, óbvio) neste link. O arquivo contém os live docs e alguns PDF’s, dentre os quais destaco:
- Adobe Flex Language Reference - o PDF que me fez ficar apaixonado com ActionScript. Maravilhosamente escrito, neste documento encontra-se a descrição da linguagem ActionScript, que é quem liga os pontos por trás do Flex. Pelo que pude ver até agora, saber ActionScript é FUNDAMENTAL para quem quiser aprender Flex: sendo assim, vale muito à pena gastar um tempinho com este PDF.
- Flex 3 Developer Guide - assim como o PDF acima, é também incrívelmente bem escrito. Neste caso, estão listados todos os recursos fornecidos pelo Flex no formato de mini tutoriais.
- Live Docs – Apesar de existir o conteúdo online, é uma mão na roda ter estes documentos armazenados no seu desktop também.
Livro: Flex 3 in Action – Tariq Ahmed – Editora Manning
Assim como todos os livros da coleção “in Action”, é mais uma leitura bastante agradável. Pode ser considerado o resumo do PDF “Flex 3 Developer Guide” que mencionei acima. Se você está em dúvida com relação à viabilidade do Flex em seus projetos, a introdução deste livro é altamente recomendada, pois explica o porquê do RIA e quais os problemas que o conceito busca resolver.
Flex.org – http://flex.org
O site da comunidade Flex também é excelente. Recomendo demais o RSS (http://feeds.feedburner.com/flexorg) para aqueles que queiram ficar informados a respeito da tecnologia.
Finalizando
Série “Grails: do Groovy à Web” começa a ser publicada na Java Magazine
A partir deste mês estarei publicando na Java Magazine uma série de artigos chamada “Grails: do Groovy à Web”, na qual exponho com detalhes os principais conceitos por trás do framework.
A primeira parte já se encontra disponível na edição 75 publicada este mês, e o tema é a linguagem Groovy. Farei uma introdução à linguagem, o que considero fundamental visto que baseado na minha experiência com outros usuários do framework percebo que a esmagadora maioria dos problemas encontrados são decorrentes do não conhecimento da linguagem.
Claro, não irei expor todos os recursos da linguagem, mas sim aqueles que considero de fundamental importância para a o aprendizado do framework.
Após este artigo, serão publicados mais quatro, cujos temas serão:
Edição 76 – Uma visão panorâmica do Grails – Será exposto o modo de trabalho adotado no framework. É fundamental para que o leitor possa ter uma noção clara do que de fato vêm a ser o framework.
Edição 77 – A camada de controle – Como funcionam os controladores do Grails. Será visto qual a lógica por trás das URLs, assim como a utilização de recursos como redirecionamentos, filtros, etc.
Edição 78 – GORM – Veremos com detalhes o funcionamento da camada de persistência do Grails.
Edição 79 – A camada de visualização – Aqui iremos ver os principais recursos que o GSP nos oferece, assim como as facilidades oferecidas pelo framework, como por exemplo templates, ajax, etc.
Aguardo o feedback de vocês!
Por que resolvi largar o HTML e partir pro Flash (Flex na realidade)
No decorrer de 2009 iniciei um projeto cujo principal objetivo técnico consistiu em levar ao extremo o que consigo fazer atualmente usando Grails na camada de controle e domínio e a dobradinha HTML/CSS/Javascript na camada de visualização (atualmente, só de ver uma interface 100% baseada em campos textuais e caixas de seleção já começo a bocejar).
Na camada de visualização quis ver o quão próximo do desktop eu conseguiria chegar usando HTML, CSS e Javascript (muito JQuery neste caso). Nos primeiros momentos, fiquei bastante surpreso com o que estava conseguido: muito drag and drop e uma interface bem diferente do feijão com arroz que estava habituado a produzir. Porém, conforme o projeto progredia, algo ficava nítido pra mim: na camada de visualização estava usando ferramentas erradas. Sendo assim, parei de me auto enganar e resolvi aceitar um fato: HTML não foi feito para se criar aplicações ricas.
É importante que nos lembremos das raízes históricas da web: sua estrutura foi construída ao redor do que se intencionava ser um mecanismo de distribuição de documentos, e não para se criar aplicações (só pra lembrar, é Hypertext Transfer Protocol). Resumindo: faz muito sentido usar HTML para se expor conteúdo textual, mas muito pouco para se criar aplicações com interfaces ricas (o que é o meu caso).
O pesadelo do HTML (os tais “web standards”)
A verdade é: usar HTML para criar aplicações com interfaces ricas ainda é (e vai continuar sendo por um bom tempo) um pesadelo.
Sim, é verdade que as coisas estão melhorando, e temos alguns bons indícios disto:
- Google tá puxando o HTML 5 no Chrome, e o Firefox e Internet Explorer já estão começando a oferecer algum suporte
- O maldito Internet Explorer 6 está começando a desaparecer
- Bibliotecas como jQuery conseguem minimizar a discrepancia entre as diferentes implementações do JavaScript presente nos navegadores
- Aplicações como Google Maps expõe que de fato é possível criar aplicações ricas usando “apenas” HTML, CSS e muito JavaScript
Yeap: mundo lindo né? Só que tem alguns “pequenos” problemas.
Microsoft Internet Explorer ainda domina
Ainda não sairam as estatísticas do quarto trimestre de 2009, mas é fato: até o terceiro trimestrede 2009 quase 70% das pessoas ainda usam o maledeto IE. (fontes: NetApplications, W3Counter, StatCounter). O IE8 é mais próximo dos padrões do W3C, é verdade, porém sabendo um pouco de história, fica nítido que será temporário, e em pouco tempo a Microsoft irá incluir novas “features” no seu navegador. (pior: IE6 ainda é o browser mais usado (fonte: NetApplications).
Os browsers ainda não são todos 100% compatíveis com os padrões web
Se você quer criar uma aplicação rica usando apenas web standards, ou seja, HTML, CSS e Javascript, no mínimo os navegadores devem ser compatíveis com o padrão, certo? Atualmente apenas o Chrome 2 e o Safari 4 conseguem passar no Acid3 (fonte). Juntos correspondem atualmente a algo em torno de no máximo uns 9% do mercado. (só pra “animar”, o IE8 conseguiu passar com nota 10/100).
HTML 5 ainda está longe de se tornar realidade
O HTML 5 cuja especificação começou em 2004 vai ter a sua primeira versão candidata publicada (talvez) em 2012 E vai ser recomendado pelo W3C a partir de 2022 (fonte). Ok: então se o mundo não acabar em 2012, teremos de esperar “apenas” mais 10 anos.
Claro, nada impede que os navegadores comecem a implementar o padrão, certo? De novo, não é lá muito animador, basta ver o que temos hoje (fonte (yeap: Wikipédia mesmo, porém as fontes indicam ser um post confiável)). Seu cliente topa esperar todo este tempo?
Nada contra os web standards (muito a favor!), desde que sejam usados no lugar certo
Se o seu trabalho não exige uma interface rica (com drag and drop, multimídia de fato e interação que vá além de meros campos textuais e caixa de seleção), e serve apenas para expor conteúdo, web standards é o canal (aliás, o único que conheço), pois apresenta diversas vantagens:
- Maior compatibilidade entre navegadores (sempre relativa)
- Carregamento mais rápido
- Facilidade de indexação por motores de busca
- Código limpo
Quer usar apenas web standards para criar aplicações ricas? Ok! Faça um jogo que valha à pena usando apenas Javascript, HTML/CSS compatível com todos os navegadores e depois ma apresente. :)
Como acabei optando pela plataforma Flash
O caminho natural para o meu caso, que sou especializado de fato na plataforma Java seria o JavaFX. No entanto, alguns fatores pesaram muito a favor da solução da Adobe:
- Flash é uma tecnologia madura
- 98% dos computadores possuem o Flash Player instalado (fonte)
(multiplataforma e PADRÃO é ISTO) - É lingua franca entre designers (com os quais a cada dia que se passa, tenho tido de interar mais e mais), pois é completamente integrado às ferramentas gráficas da Adobe (que são as melhores)
- ActionScript é uma linguagem que se mostrou surpreendentemente poderosa para mim, que até então a esnobava com a maior tranquilidade (bem feito pra mim!)
- Foco na parte visual
- Flex é agora completamente open source (se não o fosse, estaria usando JavaFX agora)
- Flex e Air
O que me fez realmente me apaixonar de fato, confesso, foi o Flex. Conforme ia estudando a tecnologia, fiquei fascinado com a riqueza que ela me oferece. Basicamente, é o Flash, porém com uma roupagem mais próxima da que desenvolvedores de aplicações como eu estamos acostumados. O projeto que mencionei no início deste blog está sendo atualmente refeito em Flex: e o resultado está sendo maravilhoso.
Com Flex consigo acessar via HTTP (e também por WebServices, bancos de dados, etc) de uma forma MUITO simples tudo o que preciso, ou seja, é fácililimo de integrar com meu código legado. Existe inclusive um plugin para Grails bastante interessante (fonte). Ou seja, continuo trabalhando no backend com as mesmas ferramentas que usava antes: a única diferença é que agora uso Flex na camada de visualização quando preciso de algo mais elaborado.
Além disto, outro fator importantíssimo foi o Air, que nos permite transformar a nossa aplicação web em uma aplicação desktop de uma forma incrívelmente simples.
Conclusões
A conclusão que chego é a seguinte: se sua interface será simples, e não requer nada que vá além do que o HTML 4 de hoje com JavaScript e CSS podem te oferecer, fique com os padrões web de hoje. Eles te atenderão perfeitamente. Abrace-os e defenda-os com unhas e dentes.
No entanto, se sua aplicação requer uma interface rica, que vá além dos controles HTML, e não é algo cujo principal propósito seja expor informação textual ou pictórica, opte por alguma tecnologia RIA (Silverlight, JavaFX e Chrome Frame (considero o Frame uma plataforma RIA, visto que é um plugin assim como os demais) são MUITO interessantes também), pois irá lhe poupar MUITO tempo e, querendo ou não, é a ferramenta certa para este tipo de trabalho.
Acredito em um meio termo: nada impede misturar web standards com algum framework RIA, pois no caso do projeto que mencionei, é exatamente o que estou fazendo neste momento.
Neste ano estou apostando no Flex. Aguardem por vários posts a respeito conforme me aprofundo na ferramenta e, mais importante: Feliz 2010!
PS: agora, por caridade: não empolgue e faça seu blog ou página corporativa usando apenas algum framework RIA ok? Assim você quebra a bicicleta! :)
