Tag: Java

Categories
Etc.

Meu ambiente de trabalho em 7 itens

O Anderson Casimiro (@duodraco) começou um meme muito legal: “Seu ambiente de trabalho em 7 itens”. Nele você escreve sobre quaisquer 7 coisas do seu ambiente de trabalho que achar mais interessantes e em seguida indica de 3 a 5 pesoas para fazerem o mesmo. O Anderson passou o meme para o Ivo Nascimento (@ivonascimento), que depois mandou para o Bruno Roberto Gomes (@brgomes) e por fim para o Hélio Costa (@hlegius) que me colocou nesta roda.

Então vamos lá, as 7 coisas que mais gosto e acho importantes no meu ambiente de trabalho são:

1) Git + Github

O Git é uma fantástica ferramenta de controle de versão. Sua característica principal é ser um sistema de controle de versão distrubuído, o que significa que você pode criar repositórios locais independentes de um servidor central, por exemplo. Com isso você pode criar facilmente novos branchs e repositórios praticamente sem custo (ou seja, muito rápido). Outra coisa sensacional é que o Git praticamente resolve sua vida com relação a merges. Na maioria das vezes ele consegue “se achar” sozinho e resolver conflitos para você, o que poupa um bocado de tempo quando você está trabalhando em equipe com várias pessoas alterando a mesma base de código.

O Github faz o Git – que ja é fantástico – ficar ainda melhor. O Github mudou para melhor a forma de colaboração entre desenvolvedores em projetos open source. Basta você criar um clone remoto do projeto que deseja contribuir, fazer suas alterações e fazer um “pull request”. Você pode adicionar colaboradores nos seus repositórios ou até mesmo criar um time de colaboradores. Isso é mais ou menos o que as pessoas já faziam antes, o Github apenas entendeu esse processo e criou uma ferramenta excelente para suportá-lo com algumas melhorias. E isso tudo não serve apenas para projetos abertos não, você pode fazer como eu (e muita gente) e por alguns míseros dólares você terá seus repositórios privados para trabalhar nos seus projetos particulares. Hoje basicamente não tenho nada importante que não esteja no Github.

2) Google App Engine

O Google App Engine também é um absurdo. Com ele você pode desenvolver aplicações Python ou Java num estalar de dedos e colocá-las para funcionar numa infraestrutura bastante confiável e rápida. O App Engine oferece banco de dados, cache, storage e várias coisas úteis que te ajudam a focar na sua aplicação e esquecer a infraestrutura. Para os Railers que lêem este blog, o Heroku é um bom quebra galho (mesmo sendo bem mais simples que o App Engine).

3) VMWare Fusion

O VMWare Fusion me possibilita ter vários sistemas operacionais com diferentes browsers para testar minhas aplicações web em uma máquina só. Além disso, como trabalho muitas vezes desenvolvendo coisas que serão servidas com Red Hat Enterprise Linux ou CentOS, posso facilmente criar ambientes de desenvolvimento locais com esses sistemas operacionais e continuar trabalhando no conforto do meu Mac sem ficar com medo das coisas não funcionarem em produção.

4) TextMate

Todo mundo tem seu editor preferido, e o meu é o TextMate. Gosto dele porque é leve, fácil de escrever plugins e snippets e possui umas centenas de plugins disponíveis por aí para trabalhar com qualquer linguagem que já precisei até hoje, suportar sistemas de controle de versão, e por aí vai. Infelizmente não consigo usá-lo para todas as linguagens que trabalho. Por exemplo, quando programo em Java ainda prefiro usar o Eclipse, ou o XCode para brincar com iOS, mas para todo o resto uso o TextMate (ou, quando em servidores remotos, o Vim).

5) Shell

Não tem como sobreviver sem um shell. Eu costumo usar o Terminal do Mac OS X com algumas customizações, e como shell uso o Bash. Além de me possibilitar diagnosticar problemas em servidores remotos, ver logs e etc., também uso o shell para algumas tarefas de desenvolvimento como usar o Git (incluindo resolver conflitos, prefiro fazer manualmente), buscar arquivos, inspecionar minha máquina e por aí vai. Também costumo escrever shell scripts para fazer algumas tarefas pessoais como codificar vídeos com ffmpeg e fazer backups remotos.

6) MacBook + Mac OS X

Os Macs são computadores que simplesmente funcionam. É isso. Meu MacBook Pro é potente e tem um hardware excelente que não me deixa na mão. E quanto ao Mac OS X, ao invés de ficar no meu caminho me pedindo drivers para fazer qualquer coisa ele simplemente funciona e deixa o caminho livre para que eu possa trabalhar. Já se foi a época em que eu tinha tempo para comprar peça por peça e montar meu próprio computador, ou então ficar re-configurando meu xorg.conf a cada update de sistema operacional. 🙂 Hoje não dá mais, preciso focar em coisas mais importantes.

7) Monitor adicional de 24″, teclado e mouse

Nós que trabalhamos intensivamente com computadores não podemos nos dar ao luxo de não ter um teclado, mouse ou monitor confortáveis. O monitor de 24″ é o mais importante do meu setup de trabalho. Usar dois ou mais monitores me deixa muito mais produtivo, além de ser muito mais confortável do que o display do MacBook (porque é gigante). Se você nunca tentou usar dois monitores, não perca mais tempo e tente agora, você vai ver a diferença. Quanto ao mouse e teclado, durante muito tempo usei hardware Microsoft (aliás, isso eles fazem bem) mas recentemente tenho usado o Magic Mouse e um mini teclado sem fio, ambos da Apple.

E para continuar a brincadeira…

Indico mais 5 pessoas para participar:

Categories
Etc.

Que ferramentas você vai usar na hora de programar?

Há uns dois meses estava eu numa madrugada típica brincado de escrever códigos aleatórios, dessa vez usando o Google App Engine. Num determinado momento (acho que eu estava testando o versionamento de deploys – que é lindo demais) fiquei tão empolgado que soltei um daqueles posts meio aleatórios no Twitter dizendo: “Google App Engine kicks serious ass!“. Muita gente estranhou, incluindo o meu amigo Rodrigo Kumpera que prontamente respondeu: “@gchapiewski I thought you used to work for yahoo!“.

O mesmo “fenômeno” aconteceu no Yahoo! Open Hack Day que fizemos em São Paulo em março. Muitas pessoas acharam estranho e ficaram abismadas pelo fato do Yahoo! e seus funcionários mostrarem hacks que faziam uso de Google Maps, Twitter, Facebook e outros produtos que não são do Yahoo!.

Vamos lá, qual o problema? Sério mesmo, qual o problema? 🙂 Agora que eu trabalho no Yahoo! tenho que usar Y! Mail ao invés de Gmail? Ou então tenho que programar usando apenas YUI ao invés de jQuery? A política do Yahoo! é muito simples e na minha opinião bem coerente: a Internet está cheia de serviços excelentes e nós também temos alguns ótimos serviços. Porque não combinar o que há de melhor e fazer uma coisa melhor ainda?

Sempre falo isso e já até me falaram que parece meio “piegas”, mas é a pura verdade (e nunca é demais repetir): use a melhor ferramenta para resolver cada problema!

Esse modo de pensar é bem difícil nesse mercado. Muita gente acha que linguagens e tecnologias são como religiões, mas não é o que eu acredito. Não me importo de usar Java se for a melhor opção para resolver meus problemas – apesar de adorar programar em Ruby. Ou de aprender uma nova linguagem/ferramenta se ela se mostrar melhor para resolver alguma coisa (como quando eu precisei aprender ActionScript para fazer coisas legais para o Globo Vídeos – apesar de eu nunca ter tido simpatia por Flash).

Para pessoas da nossa área, acredito em um posicionamento profissional baseado em fatos e dados, não em preferências, traumas ou qualquer outro argumento sem lógica. No caso que comecei a contar no início desse post, eu estava programando um webservice REST em Python e o Google App Engine é o melhor lugar para ele estar hospedado. Aliás, eu usei Python já pensando em fazer o deploy lá, porque é super simples de usar, funciona muito bem e vai me liberar mais rápido para fazer outras coisas interessantes. É óbvio que todos temos nossas preferências de linguagens e tecnologias, mas o papel de um profissional é ser pragmático é fazer o que for mais adequado para cada situação.

Sempre que você está programando você precisa atingir um objetivo. Como eu ouvi falar esses dias, você “não senta e começa a programar igual a um cavalo”, você está desenvolvendo um produto ou alguma coisa maior e precisa ter isso em mente o tempo inteiro. Seu objetivo é entregar um software de qualidade, performático, bem testado, manutenível e que atenda ao seu cliente/objetivo. O seu objetivo não é usar as ferramentas da sua empresa ou as tecnologias que você gosta. Pense nisso.

Categories
Carreira

O segredo para ser bem sucedido

Já me perguntaram mais de uma vez qual é o segredo para ser um bom desenvolvedor de software. Mas será mesmo que tem um segredo? Não sei ao certo, mas eu tenho meu palpite.

Existem várias coisas que te levam a ser um ótimo profissional. Por exemplo, estudar muito e constantemente é uma delas. Não consigo ver como um desenvolvedor poderia sobreviver por muito tempo nessa profissão sem se atualizar profissionalmente e conhecer as últimas novidades do mercado. Entender inglês seria outra delas, visto que a maioria do conteúdo relevante nesta área está apenas em inglês e vários dos melhores profissionais da área só se comunicam/escrevem nessa língua. Também é preciso ser pró-ativo, esforçado, saber trabalhar em equipe, etc, etc, etc. Mas até agora, tudo isso é bem óbvio.

Na minha opinião o segredo é a paixão.

Veja só, eu não acordo todo dia e vou para o trabalho só porque quero ganhar dinheiro ou porque sou obrigado a fazer isso. Não fico até as 5 horas da manhã hackeando as “entranhas” do Rhino com Java porque alguém na minha empresa pediu ou espera que eu faça isso. Não fico pensando em separar um tempinho por dia para ler as últimas novidades ou testar novas APIs porque sei que preciso me atualizar senão vou ficar para trás. Faço tudo isso e muito mais simplesmente porque adoro o que eu faço. Não é um grande esforço ou uma obrigação, é simplesmente natural.

No meu modo de ver as coisas, o sujeito que vai para o trabalho “bater ponto” e não gosta do que faz tem poucas chances de ser um ótimo profissional. Ele pode até conseguir fazer as coisas que lhe pedem, mas será apenas mais um cara mediano no meio de muitos outros.

Olhando para trás e vendo os profissionais mais bem qualificados com quem já trabalhei ou trabalho, grande parte deles faz(ia) a diferença porque são apaixonados pelo que fazem. Eles não apenas fazem o que precisam para concluir o seu trabalho, mas são aqueles que se dispõem a ir além de onde todos os outros vão, porque querem exceder as expectativas e querem ser os melhores. Além da minha experiência pessoal, essas pessoas bem sucedidas me fazem acreditar ainda mais que a paixão é um dos fatores mais importantes para o sucesso profissional.

Empenhe-se e dê o melhor de si que os frutos virão com o tempo. Trabalhe com o que você ama e não tem como dar errado, você será bem sucedido!

Categories
Eventos

[Dev in Rio 2009] Balanço do evento

Ufa… Depois de uma semana de correria para o fechamento do Dev in Rio finalmente estou conseguindo escrever um post!

Mesmo tendo sido idealizado, planejado e executado em pouco mais de 20 dias, o Dev in Rio 2009 foi excelente, um sucesso total! Conseguimos reunir em plena segunda-feira cerca de 400 pessoas para falar de desenvolvimento de software, se divertirem no Dojo e terem um dia de muita diversão que terminou no maior #Horaextra de todos os tempos.

O Dev in Rio 2009 começou na hora programada quando eu e meu amigo Henrique Bastos abrimos o evento. Rapidamente falamos sobre o evento e sobre como seria o nosso dia. Tratamos de como achamos importante a interação entre comunidades e aprender com pessoas especializadas em tecnologias diversas. Aproveitamos também para agradecer muito aos nossos patrocinadores, apoiadores, comunidades e amigos que nos ajudaram muito mais do que vocês possam imaginar.

Dev in Rio 2009 - Abertura
* Henrique Bastos e eu na abertura do Dev in Rio.

Abrindo os trabalhos, disparamos as duas trilhas do Dev in Rio 2009. No auditório principal, aconteceriam as palestras programadas, enquanto no foyer seria realizado o Coding Dojo.

O Coding Dojo é uma arena de programação organizada pela turma do Dojo Rio em conjunto com o Dojo@SP. A idéia é atacar problemas simples e lúdicos, utilizando técnicas de programação como Test-Driven Development e Modelagem SOLID. Este definitivamente foi o gol de placa do dia – o Dojo funcionou muito melhor do que nós poderiamos imaginar (exceto o Dojo de Java que não foi lá muito popular, tenho que admitir).

Dev in Rio 2009 - Coding Dojo
* Coding Dojo do Dev in Rio: 3 metros de código na parede!

Dev in Rio 2009 - Coding Dojo
* Galera participando do Coding Dojo do Dev in Rio.

A primeira palestra foi a do Ryan Ozymek, que entrou em cena com seu famoso pinguim para falar de sua experiência com software livre e a comunidade Joomla! Ele detalhou o funcionamento de uma grande comunidade de desenvolvimento e deu sua visão de empresário sobre como usar software livre para alavancar os negócios da sua empresa.

Logo depois, Guilherme Silveira e Nico Steppat trataram de um tema bastante polêmico: Java está morto? Abordaram os fatos de que existem muitas coisas além da linguagem no mundo Java e que apesar da linguagem estar “caducando” a JVM ainda pode ser muito útil.

Depois do almoço, Fabio Akita não deu trégua para quem estava com sono e fez uma excelente apresentação sobre o ecossistema Ruby on Rails com direito a videos, screencast e bastante informação além do código. Ele não sabe mas tirou o fôlego das meninas da tradução simultânea!

Na sequência, o (praticamente carioca) Jacob Kaplan-Moss fez sua apresentação sobre Django, o framework web para perfeccionistas desenvolvido em Python. Ele falou dos conceitos e valores que guiaram o desenvolvimento do projeto, além de mostrar um pouco de código para dar uma idéia ao público de como usar o Django na prática.

A última palestra do dia foi feita por Jeff Patton, que falou sobre desenvolvimento de produtos com métodos ágeis. Utilizando como narrativa a história de um projeto realizado em conjunto com Obie Fernandez, diversos problemas comuns no desenvolvimento de software (e suas soluções) foram destacados.

No final, nosso grande amigo Vinicius Manhães Teles liderou um bate-papo entre palestrantes, comunidades e o público. Tivemos a impressão de que se não controlassemos o relógio a conversa teria varado a noite, pois não faltavam assuntos e perguntas interessantes. O público participou bastante e foram levantadas questões como empreendedorismo e polêmicas como a estúpida regulamentação da profissão de analista de sistemas.

Dev in Rio 2009 - Discussão
* Discussão liderada por Vinicius Teles. E antes que alguém pergunte, não, não é o cara do Myth Busters que está na foto, é o Jeff Patton.

Enquanto isso tudo rolava, eu, Henrique e o Gustavo Guanabara e a Flavia Freire (jornalista da Arteccom) passamos o dia gravando um gigantesco Podcast do evento, entrevistando o pessoal e filmando os bastidores. Falamos com palestrantes, patrocinadores e participantes sobre todos os assuntos abordados nas palestras! Guanabara, termina logo de editar esse treco porque eu tô ansioso pra ouvir! 🙂 Veja o “making of” de alguns dos Podcasts com o Ryan Ozimek, com Guilherme e Paulo Silveira e com Fabio Akita e Marcos Tapajós. Assim que finalizarmos as edições vamos divulgar todo esse material.

Dev in Rio 2009 - Gravação do Podcast
* Guanabara gravando Podcast com Fabio Akita e Marcos Tapajós (e datalhe: ao fundo Guilherme Silveira e Paulo Silveira fazem Pair Programming).

Como o evento foi realizado numa segunda-feira, fechamos o evento convidando todos os participantes (ao som de “Estamos todos bêbados” do Matanza e com coreografia de Sylvestre Mergulhão e Henrique Andrade) para uma edição épica do #Horaextra no Lapa 40º. A entrada era gratuita para quem apresentasse o crachá do Dev in Rio 2009 e assim realizamos o maior #Horaextra de todos os tempos:


* Veja mais videos do Dev in Rio 2009.

Tenho certeza de que esse post não consegue transmitir 0,001% do que foi o Dev in Rio 2009 e a minha felicidade de ter conseguido realizá-lo. Gostaria de agradecer mais uma vez o apoio fundamental de toda a galera da Globo.com que viabilizou o evento, dos nossos patrocinadores Caelum, Locaweb e D-Click e de todos que nos apoiaram de alguma forma: Associação PythonBrasil, Fábrica Livre, Myfreecomm, OpenSourceMatters, Arteccom, DojoRio, Dojo@SP, #Horaextra, PythOnRio, RioJUG, RubyInside Brasil, Guanabara.info e todas as pessoas que participaram do Dev in Rio 2009. Sem vocês nada disso teria sido possivel.

Dev in Rio 2009 - Galera no final
* Participantes da mesa redonda do Dev in Rio.

Se você não foi no Dev in Rio, tenho duas coisas para te dizer: (1) você perdeu uma farra das melhores mas (2) em breve vamos disponibilizar os vídeos das apresentações para amenizar sua dor. 🙂

E que venha 2010!

Categories
Etc. Eventos Notícias Scrum

Dev in Rio 2009: eu vou!

É com muito orgulho que apresentamos o Dev in Rio 2009, uma conferência inédita sobre desenvolvimento de software que acontecerá no próximo dia 14 de setembro no Centro de Convenções SulAmérica, no Rio de Janeiro!

O evento está sendo organizado por mim (Guilherme Chapiewski) em parceria com o meu amigo Henrique Bastos e a realização está sendo coordenada pelas nossas experientes amigas da Arteccom (e tê-las ao nosso lado já garante que este será um evento para marcar o circuito carioca).

Nossa programação conta com três palestrantes nacionais e três internacionais falando sobre Open Source, Java, Ruby on Rails, Django e desenvolvimento ágil de software:

“O molho secreto”: como as comunidades do Joomla! e Open Source estão melhorando o cenário de tecnologia… e mudando o mundo!

Ryan OzimekRyan Ozimek é atual membro do Steering Committee da Open Source Initiative, membro da diretoria da Open Source Matters e co-fundador e CEO da PICnet Inc. Com enfoque em tecnologias open source, Ozimek está constantemente a procura de formas em que a Internet possa servir melhor o “bem maior” e, mais especificamente, as entidades sem fins lucrativos.

O Java está morto?

Guilherme SilveiraGuilherme Silveira é especialista em Java para a web e graduando em matemática computacional na USP, ministrou diversas palestras relacionadas ao tema em eventos e empresas pelo Brasil. Atualmente é commiter do CodeHaus pelos projetos XStream e Waffle, além de um dos responsáveis pelo desenvolvimento do VRaptor.
Nico SteppatNico Steppat é Engenheiro da Computação Aplicada na Fachhochschule Brandenburg na Alemanha, é instrutor, consultor e desenvolve há cinco anos com Java no Brasil e Alemanha, atuando agora na Caelum com enfoque especial em EJB. É o responsável técnico no Rio de janeiro. Escreve para a revista MundoJava e possui as certificações SCJP, SCWCD, SCBCD e SCEA.

Ecossistema Ruby on Rails

Fabio AkitaFabio Akita é Gerente de Produtos de Hospedagem na Locaweb e ajudou a implantar Ruby on Rails pela primeira vez num grande hosting no Brazil. Ano passado também organizou o Rails Summit Latin America, o primeiro grande evento de Rails na América do Sul. Trabalhou na consultoria americana Surgeworks LLC, prestando serviços relacionados a projetos Ruby on Rails, com o cargo de Brazil Rails Practice Manager.

Django: o framework web para perfeccionistas com prazos

Jacob Kaplan-MossJacob Kaplan-Moss é um dos líderes de desenvolvimento e co-criador do Django. Jacob é um desenvolvedor de software experiente com foco em desenvolvimento de aplicações web e arquitetura de gerenciadores de conteúdo. Em 2005, Jacob ingressou no Lawrence Journal-World, um jornal local em Lawrence, Kansas, e ajudou a desenvolver e tornar open source o projeto Django. É também co-autor do livro “The Definitive Guide to Django” (Apress, 2007).

Desenvolvimento ágil e iterativo de produtos

Jeff PattonJeff Patton cria e desenvolve software nos últimos 15 anos desde sistemas de pedidos de peças de aeronaves até fichas médicas eletrônicas. Jeff se focou em metodologias ágeis desde que trabalhou com um time de Extreme Programming em 2000. Em particular, Jeff se especializou na aplicação de práticas de user experience design (UX) para melhorar requisitos ágeis, planejamentos e produtos. Desde 2007, Jeff tem aplicado Lean thinking e práticas de desenvolvimento com Kanban e Scrum para ajudar times a focarem na entrega de valor.

Vinicius TelesPara fechar com chave de ouro, no encerramento do evento faremos um bate-papo com os palestrantes, alguns membros das comunidades de desenvolvimento e a participação especial do meu amigo Vinicius Teles!

Como se isso tudo já não fosse suficiente, enquanto todas essas apresentações estão acontecendo teremos sessões de Coding Dojo rolando do lado de fora com participação especial dos nossos palestrantes (caso eles consigam ficar por lá)! Estamos planejando fazer um Dojo de Python, um de Ruby e um de Java!

Será simplesmente incrível, ninguém pode ficar de fora dessa!

As inscrições podem ser feitas no site do evento (http://www.devinrio.com.br) e custam apenas R$ 65,00. Todos os inscritos terão direito a participar de todas as sessões, incluindo o Dojo.

Nosso encontro será numa segunda-feira, ou seja, se você não for do Rio de Janeiro já tem uma ótima desculpa para passar o fim de semana aqui, assistir uma ótima conferência na segunda-feira e voltar para o trabalho cheio de idéias na terça!!! Ainda estamos tentando fechar uma parceria com algum hotel para oferecer desconto para participantes do evento. Fiquem ligados nas novidades por aqui ou pelo Twitter!

Gostaria de deixar registrados meus sinceros agradecimentos para os nossos patrocinadores Locaweb e Caelum, além de outras organizações que nos apoiaram de alguma forma: Associação Python Brasil, Fábrica Livre, Open Source Matters e Myfreecomm. E por último, meu mais sincero agradecimento para a Globo.com pois ela é a principal responsável por viabilizar essa idéia! Obrigado por mais uma vez acreditarem nesse louco aqui tarado por desenvolvimento de software! Não tenho palavras pra dizer o quanto é gratificante fazer parte dessa equipe!

Então nos vemos no Dev in Rio 2009! Faça agora sua inscrição no nosso site! Fique ligado também no Twitter do @devinrio para concorrer a inscrições gratuitas!

Ah, e uma última coisa. Por favor, nos ajudem a divulgar o evento! Falem com seus amigos, postem nos seus blogs, Twitters, coloquem nossos banners nos sites de vocês, enfim, por favor nos ajudem a divulgar esse evento! Vamos fazer barulho no Rio de Janeiro!

Categories
Python

Apresentando: simple-db-migrate

Desde o fim do ano passado tenho me divertido um bocado desenvolvendo em Python e Django.

Apesar de ter alguns detalhes esquisitos (especialmente na implementação de OO), Python é uma linguagem sensacional e muito produtiva! O Django também é ótimo e não deixa nada a desejar para o Rails, porém, as comparações são inevitáveis. Uma das coisas que mais senti falta desenvolvendo com Python/Django foram as migrations do Rails. Na verdade, pra quem está acostumado as migrations também fazem falta em Java, PHP e basicamente em qualquer projeto que os bancos de dados são constantemente modificados e complicados demais para serem gerenciados manualmente, independente da linguagem.

Foi por isso que decidi começar o projeto simple-db-migrate. Inicialmente o objetivo era criar algo parecido com as migrations do Rails para o Django, mas agora o objetivo é (além disso) criar migrations para o que quer que seja.

Para isso ser possível as migrations usam DDL ao invés de uma DSL em Python:

Arquivo: 20090215224601_criar_tabela_pessoas.migration

SQL_UP = """
create table pessoas (
    id int(11) not null auto_increment,
    ... etc. ...
);
"""
SQL_DOWN = """
drop table pessoas;
"""

Na verdade, como as migrations são nada mais do que duas Strings Python (SQL_UP e SQL_DOWN), é possível executar qualquer código Python nas migrations que gerem SQL. No futuro isso irá me ajudar a implementar alguma coisa que use os models do Django para criar a DDL automaticamente.

O fato das migrations serem em DDL faz com que eu possa escrever migrations para qualquer tipo de projeto, independente da linguagem e mesmo que no futuro as migrations também possam ser feitas usando uma DSL Python.

Para ver o simple-db-migrate funcionando, depois de instalá-lo (instruções no site), basta ir para o diretório onde estão as migrations e executar:

db-migrate

Se você não quer ter o trabalho de escrever as suas migrations, no diretório “example” tem uma porção delas prontas. Além das migrations é necessário criar um arquivo “simple-db-migrate.conf” com as configurações do banco de dados:

HOST = "localhost"
USERNAME = "root"
PASSWORD = ""
DATABASE = "migration_example"

O arquivo pode ter outros nomes e não necessariamente você precisa estar no diretório das migrations, basta passar essas configurações para o db-migrate pela linha de comando:

db-migrate --dir=migrations_dir --config=path/to/file.conf

Ou output é algo assim:

$ db-migrate --dir=example --config=example/sdbm.conf
 
Starting DB migration...
- Current version is: 20090211120000
- Destination version is: 20090212120000
 
Starting migration up!
 
===== executing 20090211120001_add_user_age.migration (up) =====
===== executing 20090211120002_add_user_mother_age.migration (up) =====
===== executing 20090211120003_create_table_chimps.migration (up) =====
===== executing 20090212120000_create_table_aleatory.migration (up) =====
 
Done.

E por último, já que eu ainda não tenho muita documentação disponível ainda, para ver todas as opções possíveis da linha de comando basta digitar:

db-migrate --help

O simple-db-migrate ainda está em fase embrionária (na verdade comecei na semana passada), mas já está entrando em uso essa semana em dois projetos na Globo.com, ou seja, possivelmente ele vai evoluir bem rápido. Apesar de ainda ser bem simples, tudo que eu mostrei aqui já funciona.

Agora há pouco criei uma versão inicial da página do projeto no Github pages com algumas instruções para instalação e uso (bem simples mesmo, ainda pretendo melhorar bastante). O código fonte está disponível no meu Github e os tickets podem ser acompanhados no Lighthouse.

Categories
Engenharia de software

Java é ruim?

Em tempos de Ruby on Rails parece que está na moda falar mal de Java. Na Rails Summit então meus ouvidos chegaram a doer de tanto ouvir falar que Java é ruim, Java é burocrático, bla bla bla e que Ruby on Rails é fantástico, produtivo e sexy. Calma, essa não é mais uma daquelas comparações ridículas de Java versus Ruby on Rails.

Mas ainda ficou a pergunta que não quer calar: Java é ruim mesmo? A resposta, como sempre, é que depende do caso…

Em um projeto de desenvolvimento de software, mesmo antes de começar o desenvolvimento você já tem algumas restrições para escolher tecnologias. A finalidade do software por si só pode já restrigir muito a tecnologia que terá que ser usada.

Por exemplo, se você estiver fazendo um website, provavelmente você não escapará de fazer uma interface em HTML, Flash ou qualquer outra coisa específica para desenvolver uma camada de apresentação web. Provavelmente você não vai querer usar Assembly para fazer a parte server-side, já que não seria muito produtivo (apesar de não ser impossível). Eventualmente esse site pode ser um portal como a Globo.com que têm milhões de acessos por dia e você terá que escolher uma plataforma/linguagem/arquitetura que priorizem performance e favoreçam escalabilidade. Ou então pode ser um site com pouquíssimos acessos e você nem precisará se preocupar com isso…

Ou então você pode precisar fazer um pequeno script para fazer backup automatizado de um banco de dados MySQL. Seria totalmente incoerente usar Delphi, Fortran ou Piet. Provavelmente você vai querer usar algo como Shell script e resolver o problema em meia dúzia de linhas. Alguns bancos como o SQL Server têm mecanismos de agendamento de backup automático que são super fáceis de configurar e usar, portanto nesse caso usar Shell script seria trabalho desnecessário.

Meu ponto aqui é que não dá para dizer que Java (ou qualquer outra coisa) é ruim por sí só. Java pode ser ruim ou bom dentro de um contexto. Por exemplo, em 2005 eu trabalhei num projeto de Call Center à distância via Internet onde precisei desenvolver um softphone e a melhor opção foi usar Java Applets. Além de existirem bibliotecas Java para trabalhar com IAX (que é um protocolo como o SIP, só que proprietário do Asterisk), o usuário não precisava instalar nenhum programa para falar com o Call Center, bastava acessar o site. Eu odeio Applets com todas as minhas forças, mas foi ótimo para esse projeto (eu diria até que foi relativamente fácil). Seria correto então dizer que Ruby on Rails é ruim só porque seria impossível de fazer esse projeto com tanta facilidade? É óbvio que não!!!

Jamais existirá uma única linguagem ou plataforma para resolver todos os problemas. O desenvolvedor de software precisa conhecer vários tipos de ferramenta e saber escolher a melhor delas para resolver cada problema. Que fique claro que eu não sou defensor de Java, Ruby ou de qualquer outra coisa. O caso é que é incoerente dizer que X ou Y é bom ou ruim por sí só; é preciso analisar as opções dentro de um contexto.

Categories
Eventos Java Notícias

Falando em Java 2008, aí vou eu!

Falando em Java 2008Na próxima semana estarei em São Paulo para o Falando em Java 2008, um ótimo evento realizado anualmente pelos amigos da Caelum, a melhor empresa de treinamentos em desenvolvimento de software do Brasil na atualidade.

Esse ano haverá a ilustre presença do Emmanuel Bernard (um dos líderes do projeto Hibernate na JBoss) que fará duas apresentações, uma sobre JPA 2.0 e outra sobre Hibernate Search. Por uma grande ironia do destino, a palestra de Hibernate Search foi uma das que eu não consegui assistir na JBoss World 2008 e agora vou ter minha segunda chance! Além disso esse ano não se falará só em Java mas também em arquitetura de software, Domain-Driven Design, JRuby on Rails, Scrum e AJAX.

Nos vemos por lá! 🙂

Categories
Engenharia de software Eventos

[JBoss World 2008] Emmanuel Bernard: Hibernate

JBoss World 2008 - Emmanuel Bernard - HibernateA apresentação do Emmanuel Bernard sobre Hibernate foi muito boa. Inicialmente o Gavin King também iria participar, mas ele acabou não chegando a tempo. Fiquei com medo achando que eles fossem falar sobre coisas muito básicas que todo mundo já conhece, mas ao invés disso o Emmanuel se preocupou justamente em falar sobre coisas que as pessoas não estão muito acostumadas a ver por aí, como estratégias de replicação e ResultTransformers, por exemplo.

Roadmap do Hibernate 3.x

O Emmanuel deu uma visão muito ampla do que eles planejam para o futuro. O roadmap do Hibernate para as próximas versões (3.x), que serão lançadas durante os próximos meses, incluem dentre outras coisas o seguinte:

Second-level Cache

  • Re-design das estratégias de replicação em cluster usando JBoss Cache (aliás, muito necessário, porque isso definitivamente não funciona bem, já tive experiências não muito boas de aplicações que simplemente se afogam com isso).
  • Re-design da clusterização de um modo geral.

JDBC Work API

Quando o Hibernate se torna um impecilho para o desenvolvimento porque não te dá a flexibilidade que você precisa, use um “proxy” para JDBC provido pelo Hibernate.

Stateless API

Usada para operações em batch, esta API permitirá a inserção de milhões de objetos sem erros de “out of memory”, facilitará o desenvolvimento de tarefas para rodar em intervalos de tempo determinados (tipo cron jobs) e coisas do tipo.

Hibernate 4.0

Já o Hibernate 4.0, que não tem data marcada para sair e parece que não vai ser tão cedo, tem uma lista de features muito mais extensa e “agressiva”. Basicamente essa nova versão do Hibernate será focada nos seguintes objetivos:

Facilidade de desenvolvimento

Configuração mais simples

  • Cada vez menos baseada em texto/String e xml e mais baseada em convenções e annotations.
  • Mutável em runtime, ou seja, alterar determinadas configurações não irá requerer que o contexto seja reiniciado.

Mais flexibilidade de mapeamento

  • Mais opções para mapeamento de componentes polimórficos.
  • Mais opções para mapeamento de coleções.

Otimizações

  • Melhorias no startup, que hoje é muito lento, especialmente quando se tem centenas ou milhares de entities.
  • Novas estratégias de fetching e melhorias no fetch automático.

Queries

Funcionalidades de alto nível

Versionamento automático e transparente de dados “out of the box”.

Entity Manager

Uma das idéias é que não seja mais necessário registrar as entities em um arquivo de configuração, só a annotation @Entity será necessária.

Hibernate Tools

  • Criação de Ant tasks para que toda a DDL (tabelas, constraints, sequences, etc) necessária para a aplicação funcionar seja gerada automaticamente.
  • Leitura das informações para geração de DDL diretamente das entities, suportando tanto os mapeamentos feitos com Hibernate como com JPA.
  • Integração com JBoss Developer Studio.

Ampliação da plataforma

Outros projetos mais novos como Hibernate Search, Hibernate Validator e Hibernate Shards ganharão mais foco.

E a JPA?

Tudo isso automaticamente nos remete ao assunto Java Persistence API. A JPA foi lançada com um conjunto de featues muito pequeno que simplesmente não atende qualquer caso que não seja feijão-com-arroz. O que normalmente acaba acontecendo é que você sempre tem que recorrer a features específicas do Hibernate para resolver casos mais complexos. Isso simplesmente elimina o papel da JPA, que seria manter a aplicação desacoplada de um “vendor” específico. Então, o Emmanuel também falou um pouco do que podemos esperar para a JPA para resolver esses problemas:

  • Objetivo principal: padronização de um mecanismo de mapeamento objeto-relacional “lightweight”.
  • Focada em Domain Model.
  • Uso massivo de annotations: o objetivo é fazer tudo funcionar por annotations sem a necessidade de nenhum arquivo de configuração.
  • Incorporação das annotations avançadas específicas do Hibernate.
  • Fará parte do Java EE 6 padrão.
  • Terá uma Criteria API.
Categories
Engenharia de software Eventos

[QCon 2007] Neal Ford: Building DSLs in Static and Dynamic Languages

QCon 2007 - Neal FordNeal Ford da ThoughtWorks fez mais uma apresentação sobre Domain Specific Languages, desta vez mostrando alguns aspectos do desenvolvimento de DSLs em linguagens com tipagem estática e dinâmica.

Ele evoluiu sobre a idéia de que uma DSL é um estilo declarativo de programação ao invés de imperativo. Um exemplo é a linguagem SQL. Em SQL você não diz como você quer alocar memória ou como organizar ponteiros e listas, você só diz o que quer e o banco de dados “descobre” como atender seu pedido.

DSLs podem ser usadas como uma camada de abstração sobre APIs, assim como Java poderia ser considerado uma camada de abstração sobre C, por exemplo. Veja os dois códigos a seguir que exemplificam esta diferença. O primeiro código é um código típico de API e o segundo código seria uma DSL wrapper para esta API:

// API
Car car = new CarImpl();
MarketingDescription desc = new MarketingDescriptionImpl();
desc.setType("Box");
desc.setSubType("Insulated");
desc.setAttribute("length", "50.5");
desc.setAttribute("ladder", "yes");
desc.setAttribute("lining type", "cork");
car.setDescription(desc);
 
// Fluent Interface
Car car = new Car.describedAs()
		.box()
		.length(12)
		.includes(Equipment.LADDER)
		.has(Lining.CORK);

A partir daí o Neal mostrou algumas técnicas para construir DSLs como aninhamento e encadeamento de métodos, finalizar/salvar “transações” e outras coisas mais. Também falou sobre as vantagens de se utilizar linguagens dinâmicas como Groovy e Ruby para tirar proveitos de features como closures, classes abertas, tipagem dinâmica e sintaxe menos rigorosa que a do Java.

Mais uma vez a questao dos testes foi enfatizada. Muito provavelmente as DSLs vão evoluir ao longo da vida do sistema e é necessário ter uma suite de testes verificando cada pequena parte e garantindo que os incrementos nela não trarão efeitos colaterais. Trabalhar com DSLs sem testes é um pesadelo!

Algumas coisas que você precisa ter em mente ao criar DSLs:

  • Pense sempre na DSL perfeita. Mesmo que você não consiga chegar na perfeição, pensar no melhor caso possível vai te ajudar a te guiar pelo melhor caminho. Neste caso utilizar uma técnica como TDD pode ajudar bastante pois você irá determinar onde quer chegar antes mesmo de começar a codificar.
  • Utilize um contexto pequeno. Não tente criar uma DSL super genérica, escreva um domínio especializado.

Download