Posts Tagged 'desenvolvimento'

Classes abstratas em Ruby?

Post movido para: http://blog.guilhermegarnier.com/2009/12/04/classes-abstratas-em-ruby/

Como eu estava há algum tempo sem mexer com Ruby, resolvi fazer o ótimo curso online gratuito Core Ruby, do Satish Talim (também conhecido como Indian Guru) para relembrar algumas coisas. Ao chegar no tópico Ruby Overriding Methods, há um item sobre classes abstratas, que diz o seguinte:

Abstract class

In Ruby, we can define an abstract class that invokes certain undefined “abstract” methods, which are left for subclasses to define. For example:

# This class is abstract; it doesn't define hello or name
# No special syntax is required: any class that invokes methods
# that are intended for a subclass to implement is abstract
class AbstractKlass
  def welcome
    puts "#{hello} #{name}"
  end
end

# A concrete class
class ConcreteKlass < AbstractKlass
  def hello; "Hello"; end
  def name; "Ruby students"; end
end

ConcreteKlass.new.welcome # Displays "Hello Ruby students"

Assim que li esse código, fiquei com uma pulga atrás da orelha. Ele mostra como um exemplo de classe abstrata uma classe que faz referência a métodos não definidos, explicando que seria necessário criar uma classe concreta estendendo esta classe e implementando os métodos necessários.

Eu sempre pensei que classes abstratas fossem classes que não poderiam ser instanciadas, o que não é o caso do exemplo. É perfeitamente possível criar objetos da classe AbstractKlass. Só ocorrerá uma exceção se o método welcome do objeto criado for executado:

irb(main):006:0> obj = AbstractKlass.new
=> #<AbstractKlass:0x37d490>
irb(main):007:0> obj.class
=> AbstractKlass
irb(main):008:0> obj.welcome
NameError: undefined local variable or method `hello' for #<AbstractKlass:0x37d490>
        from (irb):9

Resolvi levantar esta questão no forum do curso, e recebi uma resposta de um dos participantes dizendo que em Ruby o conceito de classes abstratas seria diferente daquele que apresentei acima. De acordo com a definição da Wikipedia: “An abstract class, or abstract base class (ABC), is a class that cannot be instantiated”.

Pesquisando sobre o assunto, encontrei referências apresentando algumas sugestões de como implementar classes abstratas em Ruby de diferentes maneiras (herança, módulos e até um gem):

Uma das possibilidades mostradas nos links acima seria desta forma:

class AbstractClass
  class AbstractClassInstiationError < RuntimeError
  end

  def initialize
    raise AbstractClassInstiationError, "Cannot instantiate this class directly"
  end
end

class ConcreteClass < AbstractClass
  def initialize
  end
end

Isso teoricamente resolveria o problema:

irb(main):043:0> obj1 = AbstractClass.new
AbstractClass::AbstractClassInstiationError: Cannot instantiate this class directly
        from (irb):36:in `initialize'
        from (irb):44
irb(main):044:0> obj1.class
=> NilClass
irb(main):045:0> obj2 = ConcreteClass.new
=> #<ConcreteClass:0x309f9f>
irb(main):046:0> obj2.class
=> ConcreteClass

Porém, há um detalhe importantíssimo: em Ruby todas as classes são abertas, ou seja, sempre será possível reimplementar métodos ou adicionar módulos que alteram o comportamento da classe, tornando impossível proibir completamente a instanciação e, consequentemente, a implementação de classes abstratas (pelo menos de acordo com o conceito apresentado aqui).

A linguagem Ruby possui alguns conceitos diferentes dos utilizados em outras linguagens, em função de algumas de suas características, como classes abertas e meta programação. Isso nos força a pensar em maneiras diferentes de implementar soluções para os mesmos problemas, o que é muito bom.

Para concluir, segue um trecho do livro “Programming Ruby” que foi apresentado na discussão sobre este assunto no forum do curso:

The issue of types is actually somewhat deeper than an ongoing debate between strong typing advocates and the hippie-freak dynamic typing crowd. The real issue is the question, what is a type in the first place?

If you’ve been coding in conventional typed languages, you’ve probably been taught that the type of an object is its class—all objects are instances of some class, and that class is the object’s type. The class defines the operations (methods) that the object can support, along with the state (instance variables) on which those methods operate.

In Ruby, the class is never (OK, almost never) the type. Instead, the type of an object is defined more by what that object can do. In Ruby, we call this duck typing. If an object walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it were a duck.

Resumo do Dev in Rio

Post movido para: http://blog.guilhermegarnier.com/2009/09/29/resumo-do-dev-in-rio/

No último dia 14 aconteceu o Dev in Rio (veja vídeos e fotos do evento). Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento foi um grande sucesso.

Na abertura do evento, Guilherme e Henrique informaram que o evento seria totalmente voltado para os desenvolvedores, destacando a importância de se integrar e reunir as pessoas para troca de experiências. Eles também ressaltaram a importância de se integrar comunidades de diferentes tecnologias, reforçando também a tendência dos desenvolvedores poliglotas.

A primeira palestra foi de Ryan Ozimek, sobre o CMS Joomla. Ryan, que não é desenvolvedor, falou sobre a história deste projeto, destacando a importância da participação da comunidade para o crescimento do Joomla.

Na palestra seguinte, Nico Steppat e Guilherme Silveira, da Caelum, falaram sobre Java como plataforma, e não como linguagem, destacando o suporte a várias linguagens, permitindo que possamos escolher a linguagem mais adequada a cada situação sem perder as vantagens oferecidas pela plataforma.

Após o almoço, Fábio Akita trouxe uma geral sobre o ecossistema Ruby on Rails. Na minha opinião, esta foi a melhor palestra do evento, pois ele soube resumir em pouco tempo uma quantidade enorme de conteúdo. Primeiramente, ele trouxe um histórico da linguagem Ruby, e, através de uma “meta-apresentação”, mostrou um pouco da linguagem e suas principais características, como meta-programação, por exemplo. Depois, falou sobre Rails, destacando algumas de suas principais características e os mais famosos mitos, como “Rails não escala” (link para a apresentação).

Em seguida, Jacob Kaplan-Moss, um dos criadores do Django, falou sobre este framework Python, sua história, evolução e principais características (link para a apresentação).

Na última palestra, Jeff Patton falou sobre metodologias ágeis, mas focando na criação de produtos e interação com o cliente, e não no desenvolvimento em si. Ele trouxe como exemplo o desenvolvimento de um produto real, as dificuldades encontradas e as soluções utilizadas.

Finalmente, foi feita uma espécie de mesa redonda com a maioria dos palestrantes e alguns convidados, como Marcos Tapajós, Sylvestre Mergulhão e Daniel Cukier, entre outros. Vinicius Teles fez o papel de mediador entre os participantes e o público.

Em paralelo às palestras, ocorreram coding dojos de Ruby, Python e Java. Destaque também para a tradução simultânea das palestras (tanto inglês-português quanto português-inglês), serviço que foi bastante elogiado por aqueles que o utilizaram. Também foram sorteados vários brindes no final, como ingressos para o Rails Summit.

No final, o balanço do evento foi extremamente positivo, pois conseguiu reunir muita gente, incluindo figuras bastante importantes e conhecidas no desenvolvimento de software. Os organizadores estão de parabéns, pois tudo correu sem qualquer problema aparente, todas as palestras foram muito pontuais e de excelente qualidade. Agora, só resta esperar pelo Dev in Rio 2010! Vale a pena conferir também os posts do Guilherme e do Henrique sobre o evento.

Desenvolvedores e plataformas poliglotas

Post movido para: http://blog.guilhermegarnier.com/2009/09/11/desenvolvedores-e-plataformas-poliglotas/

Há alguns anos atrás, era muito comum encontrarmos desenvolvedores que conheciam somente uma linguagem, e por isso intitulavam-se “desenvolvedor Java”, “desenvolvedor Delphi”, “desenvolvedor ASP”, ou qualquer outra linguagem. Eram pessoas que conheciam uma, e somente uma, linguagem de programação, e a defendiam com unhas e dentes em qualquer discussão nos fóruns, frequentemente gerando flame wars.

Esse tipo de desenvolvedor ainda existe, mas é cada vez menos comum, e isto é muito positivo. O livro The Pragmatic Programmer recomenda que aprendamos uma linguagem nova por ano, e, com isso, muitos daqueles desenvolvedores Java ou C# estão aprendendo Ruby, Python ou Erlang. Mesmo que não tenhamos pretensão de trabalhar com estas linguagens, pelo menos a curto ou médio prazo, cada linguagem tem suas particularidades, ajudando a quebrar paradigmas. Quando conhecemos somente uma linguagem, temos uma grande tendência a resolver os problemas sempre da mesma forma, conforme aprendemos e como é feito tradicionalmente com aquela linguagem. Desta forma, a tendência é a estagnação, pois não procuramos outras maneiras de resolver os problemas. A partir do momento em que começamos a estudar outras linguagens, abrimos nossa cabeça e começamos a “pensar fora da caixa”, e percebemos que existem muitas outras maneiras de resolver aquele mesmo problema, muitas delas mais simples e adequadas à situação. Surgem os desenvolvedores poliglotas.

Na época dos desenvolvedores monoglotas (sim, essa palavra existe!) era muito comum vermos discussões do tipo: “que linguagem é melhor, X ou Y?”. A melhor resposta é: depende! Depende da situação, do projeto, da experiência da equipe… Para cada situação, uma linguagem pode ser mais adequada que outra, o que traz uma grande vantagem para os poliglotas, pois, para se tomar esta decisão, é necessário conhecer as linguagens disponíveis. Ao mesmo tempo, se ninguém na equipe tiver experiência com determinada linguagem, seria um grande risco utilizá-la no projeto. É como uma caixa de ferramentas: se eu tiver somente um martelo na minha caixa, como farei para apertar um parafuso? É importante termos o maior número possível de ferramentas disponíveis, e conhecimento sobre cada uma delas, para que possamos escolher a mais adequada em cada situação.

Acompanhando esse comportamento, há atualmente uma forte tendência a plataformas poliglotas, o que também é muito positivo. As plataformas existentes já estão bastante maduras, têm algoritmos eficientes para gerenciamento de memória e Garbage Collection, por exemplo, e são bem conhecidas. Encontram-se nesta categoria as plataformas Java e .NET, que estão continuamente aumentando o número de linguagens suportadas – veja a lista de linguagens suportadas pela JVM e pelo .NET. Com isso, a escolha da linguagem para cada projeto fica muito mais fácil, permitindo, inclusive, projetos poliglotas. Se você trabalha com Java e decide utilizar Ruby no seu projeto, por exemplo, basta adicionar o jar do JRuby.

A conclusão que podemos tirar disso é que um desenvolvedor nunca deve estagnar. Procure sempre estudar e aprender novas coisas, mesmo que não seja nada relacionado com o que você está trabalhando atualmente, pois, mesmo que não venha a trabalhar, isso ajuda a quebrar paradigmas e permite que você se torne um melhor desenvolvedor.

Dev in Rio – eu vou!

Post movido para: http://blog.guilhermegarnier.com/2009/08/27/dev-in-rio-eu-vou/

Muitos já devem estar sabendo, mas acho que não custa nada ajudar a divulgar: no dia 14 de setembro ocorrerá aqui no Rio de Janeiro um evento imperdível: o Dev in Rio. Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento terá palestras sobre Rails, Django, Java, Open Source e metodologias ágeis, contando, inclusive, com palestrantes internacionais. A inscrição custa apenas R$ 65,00, e, pelo sucesso que está fazendo, acho que as vagas vão acabar logo!

Para quem estiver sem grana, vale a pena tentar ganhar ingressos pelo RubyInside ou pela revista TI digital.

Mais informações sobre o Dev in Rio no site e no twitter. Parabéns aos organizadores pela iniciativa!

Instant Rails, o ambiente Rails de bolso

Post movido para: http://blog.guilhermegarnier.com/2009/06/18/instant-rails-o-ambiente-rails-de-bolso/

Com a proliferação dos pen drives com alguns GB de capacidade e a preços acessíveis, aplicativos que rodam sem necessitar de instalação tornaram-se igualmente populares. Estes aplicativos “portáteis”, mais conhecidos como Portable Apps, podem ser executados diretamente do pen drive, geralmente com todas as funções dos equivalentes instaláveis. Eles são mais comuns em ambiente Windows (o site mais conhecido é o PortableApps, mas existem outros, como o The Portable Freeware Collection), porém também existem Portable Apps para Mac OS X. Até onde eu sei, não existem Portable Apps para Linux, porém, é possível executar os Portable Apps de Windows via Wine.

Como não poderia deixar de ser, existem também muitos ambientes de desenvolvimento portáteis. Talvez o mais conhecido seja o XAMPP, que inclui um servidor Apache com MySQL, PHP e Perl, entre outras ferramentas. Basta descompactar e executar.

Para Ruby on Rails, também existe um ambiente portátil. É o Instant Rails, infelizmente disponível somente para Windows. A exemplo do XAMPP, basta descompactar um arquivo zip para se ter um ambiente Rails totalmente funcional, com Mongrel, Apache e MySQL. É possível, inclusive, instalar RubyGems e plugins Rails normalmente, como num ambiente Rails comum. O pacote inclui ainda o SQLite, PHP, phpMyAdmin, o editor SciTE e o typo, sobre o qual já escrevi aqui no blog.

A principal desvantagem do Instant Rails é que ele está bastante desatualizado – a versão atual, 2.0, é de dezembro de 2007, e inclui as seguintes versões:

  • Ruby 1.8.6
  • Rails 2.0.2
  • Mongrel 1.1.2
  • RubyGems 1.0.1
  • Rake 0.8.1
  • Apache 1.3.33
  • MySQL 5.0.27
  • SQLite 3.5.4
  • PHP 4.3.10
  • SciTE 1.72
  • phpMyAdmin 2.10.0.2

Segundo o wiki do projeto, há uma petição solicitando o upgrade para a versão 1.9.1 do Ruby.

UPDATE: Só agora vi que o Urubatan escreveu sobre o mesmo assunto no blog dele. Só que ele citou o Ruby on Rails Portable, um projeto muito semelhante ao InstantRails, porém um pouco mais atualizado: a versão do Rails atualmente é 2.1.0 (a do Ruby é 1.8.6).

Outro projeto semelhante que encontrei, mas ainda não testei, é o Flash Rails.

Scrum e comprometimento

Post movido para: http://blog.guilhermegarnier.com/2009/04/29/scrum-e-comprometimento/

No ano passado trabalhei na Globo.com, e lá tive algumas oportunidades de trabalhar com Scrum (aliás, para quem ainda não leu, recomendo o post do Guilherme Chapiewski sobre a adoção de Scrum na Globo.com). Eu pretendia escrever sobre isso há algum tempo, mas a procrastinação me impedia de transformar um rascunho antigo neste post.

Quando cheguei na empresa, eu não sabia nada sobre Scrum, e fiquei muito curioso ao ver que, em determinado horário, todos os dias, todos os membros de algumas equipes levantavam-se, reuniam-se (em pé!) em torno de um cartaz na parede com vários post-its, e, após 15 minutos, todos retornavam às suas atividades normais. Comecei a observar e estudar o assunto, e aos poucos fui percebendo a simplicidade desta metodologia: tudo o que não for realmente necessário não deve ser feito. Acredito que isto seja um dos principais elementos do Scrum, pois ajuda a manter o foco naquilo que é realmente importante.

Outro ponto importantíssimo, e que é o assunto principal deste post, é o comprometimento. Para que o Scrum realmente funcione, é necessário que o time esteja comprometido com o projeto.

Num dos projetos em que trabalhei com Scrum, o Scrum Master era o Guilherme Chapiewski e o Product Owner, inicialmente, era o Antônio Carlos Silveira. Porém, por falta de tempo disponível para dedicar-se ao projeto, o Antônio saiu do time, repassando o papel de PO para outra pessoa. De todo o time, incluindo o SM e o PO, eu era o único que não estava envolvido em outro projeto. O GC, por exemplo, trabalhava em um outro projeto que era muito maior e mais importante que este, que, consequentemente, tinha baixa prioridade. Desta forma, começamos a passar pelos seguintes problemas:

  • nos Daily Meetings geralmente eu tinha concluído a minha tarefa, e muitas vezes até adiantado alguma outra, enquanto os demais membros do time não tinham nem iniciado as suas, pois estavam muito ocupados com seus outros projetos, e já sabiam que não poderiam iniciá-las nos próximos 2 ou 3 dias;
  • após algumas semanas, começamos a não conseguir mais realizar o Daily Meeting todos os dias, pois não conseguíamos 15 minutos livres de todos os membros do time simultaneamente.

Quando isso começou a acontecer com mais frequencia, começamos, na prática, a parar de usar Scrum, pois já não havia mais comprometimento. Como o Bruno Carvalho já escreveu, Daily Meeting é comprometimento. Não estou dizendo que o time estava desestimulado ou não queria se dedicar ao projeto. Pelo contrário, todos achavam o projeto bem interessante, porém não conseguiam se comprometer a ele, exatamente por estarem comprometidos com outro.

A solução encontrada pelo GC foi pararmos de usar Scrum neste projeto, pois tornou-se impossível praticar Scrum sem que todos os membros estivessem comprometidos. Continuamos a utilizar algumas das práticas do Scrum, como o Planning e o Review, mas na verdade não era Scrum.

A lição que tirei daí foi que é importantíssimo ter um time comprometido com um projeto para que o Scrum realmente aconteça, e que, sem isso, fica muito difícil utilizá-lo na prática. Até acredito que seja possível trabalhar em dois projetos simultâneos com Scrum, mas com certeza exigiria uma grande disciplina para conseguir dividir igualmente o tempo entre os dois, sem deixar de comprometer-se com um ou outro.

Extensões do Firefox recomendadas para desenvolvedores web

Post movido para: http://blog.guilhermegarnier.com/2009/01/06/extensoes-do-firefox-recomendadas-para-desenvolvedores-web/

Quase todo usuário de Firefox que tem um blog já postou uma lista de extensões recomendadas. Chegou a minha vez! Sei que muitas aqui já são velhas conhecidas da maioria, mas acho interessante ressaltar a importância. Hoje em dia é difícil imaginar o desenvolvimento web sem o auxílio do Firefox. Segue abaixo a lista de extensões que eu recomendo:

  • Firebug
    Como não poderia deixar de ser, o primeiro da lista, e totalmente indispensável, é o Firebug. Seria até exagero chamá-lo de extensão, pois o Firebug é uma verdadeira plataforma para debug de aplicações web. Com ele é possível, além de inspecionar visualmente o código HTML, seja diretamente pelo código, seja selecionando o componente visual associado a ele, é possível modificar o código, alterando, excluindo ou incluindo tags, e o resultado aparece em tempo real. O mesmo pode ser feito com os códigos Javascript e CSS da página. Há também um console para debug; é possível utilizar o comando console.log(“texto”) no seu código Javascript, e durante a execução, o texto será exibido no console do Firebug. Também é possível visualizar o resultado de todas as requisições, incluindo arquivos carregados (imagens, arquivos CSS, Javascript e Flash) e chamadas assíncronas (Ajax), exibindo o cabeçalho da requisição, o resultado, o tamanho do arquivo e o tempo de resposta. Esta extensão é tão poderosa que há extensões para ela, como o YSlow, do Yahoo, que exibe estatísticas de desempenho da página.

    Como o Firebug é só para Firefox, foi lançada uma versão Lite que também funciona com IE, Opera e Safari. Nunca testei esta versão, porém acredito que seja uma boa alternativa para debugar problemas que aconteçam num destes browsers mas não no Firefox. Nesse mesmo link é disponibilizada uma versão do Firebug Lite como bookmarklet. Basta arrastar o link para a barra de bookmarks do Firefox para poder utilizá-lo sem precisar instalar o Firebug.

  • Web Developer
    Esta extensão é uma das mais úteis no desenvolvimento web. Entre as opções disponíveis, ela permite visualizar o CSS da página, cookies, bloquear imagens e muitas outras funções.
  • Poster
    O Poster é uma extensão simples, porém muito útil para testar Web Services. Ele exibe uma janela com opções para digitar a URL de destino, o tipo de requisição (GET, POST, PUT ou DELETE), o body e os parâmetros. Feita a requisição, é possível visualizar a resposta recebida.
  • JavaScript Debugger
    Extensão muito poderosa, que exibe uma janela listando todos os arquivos Javascript da página atual. Pode-se definir breakpoints no código e executá-lo passo a passo, verificar e alterar valores de variáveis e tudo o que se espera de uma ferramenta de debug.

    Javascript Debugger

    Javascript Debugger

  • Greasemonkey
    Uma das extensões mais conhecidas, permite criar scripts usando Javascript para modificar o comportamento de sites específicos. O site Userscripts.org possui centenas de scripts pré-definidos para vários sites conhecidos. Com o Greasemonkey, você pode até mesmo ajudar a Vivo a adicionar suporte a HTML no Firefox.
  • Greasefire
    Extensão que adiciona ao Greasemonkey uma funcionalidade de busca automática de scripts para o domínio atual no Userscripts.org. Ao clicar no ícone do Greasemonkey, aparece uma nova opção no menu, que, ao ser selecionada, exibe em uma nova janela a lista de scripts encontrados.
  • CSSViewer
    O CSSViewer exibe todas as propriedades CSS dos elementos da página atual num div flutuante, conforme o cursor do mouse é movido pela tela.
  • X-Ray
    Mais uma extensão simples e útil. O X-Ray permite visualizar o código fonte de uma página sobre a própria. Desta forma, as tags HTML se misturam aos elementos da página, permitindo visualizar exatamente onde se localiza cada elemento do fonte, apesar de a visualização ficar um pouco confusa.
  • Live HTTP Headers
    Exibe numa janela os cabeçalhos HTTP de cada requisição, auxiliando na verificação de erros de rede. As informações dos cabeçalhos também podem ser exibidas numa barra lateral, e as URLs das requisições que serão analisadas podem ser definidas como expressões regulares.

    Live HTTP Headers

    Live HTTP Headers

  • Aardvark
    Esta extensão permite excluir elementos da página com um clique. É muito útil para acessar sites muito poluídos, com excesso de elementos na tela, ou quando há algum elemento sobrepondo outro, no caso de erros de visualização de sites que não foram testados no Firefox. Também pode ser utilizado para remover elementos desnecessários antes de imprimir uma página.
  • MeasureIt
    Exibe uma régua para contagem de pixels de um elemento. Útil para ajustes finos no design.
  • JSView
    Exibe um ícone no rodapé do Firefox. Ao clicar nele, é possível visualizar automaticamente todos os arquivos CSS e Javascript da página atual. Pouco útil caso você já utilize o Firebug.
  • ErrorZilla Mod
    Quando uma página estiver inacessível, esta extensão exibirá uma tela alternativa de erro, com opções para consultar esta página no Google Cache, tentar ping e trace, entre outras opções.

    ErrorZilla Mod

    ErrorZilla Mod

  • CheckBoxMate
    Permite marcar vários checkboxes de uma vez, através de drag & drop. Esta extensão não tem qualquer relação com desenvolvimento web, mas resolvi incluir na lista pois acredito que pode ser útil, por exemplo, quando se deseja selecionar vários emails no seu webmail.
  • Stylish
    Praticamente um Greasemonkey para CSS. Permite criar folhas de estilo para URLs específicas e pesquisar no Userstyles.org por estilos pré-definidos para o domínio atual.
  • ColorZilla
    Permite descobrir o código RGB da cor do elemento atual, fazer zoom de até 1000% na página (para facilitar a seleção de um elemento específico) e selecionar cores numa paleta, entre outras opções.
  • PDF Download
    Converte páginas Web para PDF, além de permitir selecionar a ação desejada ao clicar em um arquivo PDF (download, abrir com o programa padrão, abrir no browser).

Além de muitas extensões úteis, existem outras nem tanto. A extensão mais inútil para Firefox, na minha opinião, é o Fast Close Tabs: você acha irritante ter que clicar no X à direita de uma aba para fechá-la? Com esta extensão, você pode fechá-la clicando no X da própria janela do Firefox!

Finalizando, um site que acho muito interessante é o Firefox Facts, que traz muitas dicas sobre o Firefox, principalmente sugestões de novas extensões e temas.


@guilhermgarnier

Erro: o Twitter não respondeu. Por favor, aguarde alguns minutos e atualize esta página.

Estatísticas

  • 58,340 hits
Linux Counter