equipe-scrum

O que são equipes auto-organizadas e como funcionam?

equipe-scrumUma das características interessantes a respeito do Scrum é que ele é focado em equipes auto-organizadas e auto-gerenciáveis. Mas o que significa isto?

Scrum Guide diz:

Ninguém – nem mesmo o ScrumMaster – diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis. O Time descobre por si só. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo.

São equipes que tem autonomia para decidir a melhor maneira de fazer seu trabalho sem necessitar de direção externa. Dizer que são auto-organizáveis significa que são independentes para se organizar em torno de um problema a ser resolvido. Nestas equipes, todos tem as mesmas responsabilidades, de modo que elas se tornam também auto-gerenciáveis. O trabalho que seria feito por um gerente de projetos cabe a toda a equipe, visto que a figura do Scrum Master está mais para um facilitador, um líder que tem apenas a função de garantir que não haja impedimentos para que a equipe possa realizar seu trabalho.

Assim, durante as reuniões diárias, outra característica do Scrum, todos os eventuais impedimentos podem ser identificados para que se possa buscar a melhor solução para que o prazo possa ser respeitado e os requisitos listados no backlog atendidos.

Como em quase tudo na área de T.I., não há leis que definam com as coisas devem ser feitas. Há princípios e padrões que indicam boas práticas a serem seguidas. O próprio Scrum não é considerado uma metodologia, mas um framework que deve ser adaptado de acordo com a necessidade do momento. Neste sentido, ele também indica um número de membros que deve compor a equipe, que varia entre 5 e 9 pessoas. Mais uma vez, isto depende da necessidade do projeto, do cliente, do contexto, enfim, de cada caso. Importa muito mais que o processo de desenvolvimento permita à equipe trabalhar de forma ágil, independente de seu tamanho.

Não é difícil encontrar na web comparações entre os papéis de um gerente de projetos e de um Scrum Master, o que já está além do assunto deste texto. O certo é que o desenvolvimento ágil exige das pessoas um comprometimento (lembram-se da história do porco e da galinha?) para que as coisas funcionem como esperado.

 

Ruby Lessons #1 – Introdução

Algumas coisas importantes sobre o Ruby:

#1.1 Origem

Surgiu em 1995, criada pelo japonês Yukihiro Matsumoto. O intuito era criar uma linguagem natural, que facilitasse a leitura e manutenção do código. Para isto, juntou boas características de outras linguagens de programação e criou uma nova que acabou se tornando um grande sucesso. Além disso, é totalmente gratuita para usar, copiar, modificar e distribuir.

#1.2 É uma linguagem interpretada

Necessita da instalação de um interpretador que pode ser encontrado no site oficial. Pulando os detalhes da instalação em cada plataforma, para executar um código Ruby, pode-se utilizar:

  • O shell interativo (IRB) que acompanha a instalação padrão
irb(main):001:0> 'Hello World'
=> "Hello World"
  • Ou salvar os scripts em arquivos .rb e executá-los através do interpretador “ruby” ou “ruby.exe”
$ ruby hello.rb
Hello World
  • Uma outra opção para executar scripts interativamente, com muito mais recursos: Pry

#1.3 É uma linguagem orientada a objetos

Como não poderia deixar de ser. Aliás, tudo em Ruby é um objeto. Isto significa que, além de podermos utilizar todos os recursos da orientação a objetos, podemos chamar métodos ou acessar atributos sobre qualquer coisa, até mesmo constantes literais, como 1 ou ‘foo':

irb(main):001:0> 1.equal? 2
=> false
irb(main):002:0> 'foo'.upcase
=> "FOO"

Mas o Ruby é flexível o suficiente para permitir diferentes estilos de codificação, se assemelhando à programação funcional ou procedural quando necessário. Para scripts pequenos, por exemplo, é possível escrever algo semelhante a isto:

print 'Digite seu nome: '
nome = gets
puts nome

Onde print, gets e puts são métodos da classe Kernel, embutida no interpretador. Isto fica completamente transparente para o desenvolvedor.

#1.4 É uma linguagem simples e expressiva

Como dito anteriormente, o objetivo era criar uma linguagem natural, fácil de entender. Por consequência, a linguagem é extremamente simples de ler e escrever mas também extremamente poderosa.

#1.5 É uma linguagem dinâmica, fortemente e implicitamente tipada

Não é necessário declarar tipos. Eles são inferidos pelo interpretador. Nem é necessário declarar uma variável para utilizá-la. A simples inicialização é suficiente para que o interpretador saiba qual é o escopo e o tipo do objeto.

irb(main):003:0> numeros = [1, 2, 3]
=> [1, 2, 3]
irb(main):004:0> numeros.class
=> Array

O dinamismo da linguagem também permite adicionar métodos a classes existentes em tempo de execução (metaprogramação). Isto também vale para as classes das bibliotecas padrão:

  class Numeric
    def inverso
      1.0 / self
    end
  end

  # inverso agora é um metodo válido para qualquer número
  print 2.inverso
  0.5

Fortemente tipada porque, apesar de sua tipagem dinâmica, os tipos importam para o interpretador. O que é número, é número. O que é string, é string e assim por diante. Conversões entre tipos não são feitas implicitamente.

#1.6 Gems

Numa linguagem chamada Ruby, é bem sugestivo o nome “gem” (jóia, pedra preciosa) para um pacote de código. Aqui, quando falamos de pacotes, estamos nos referindo quase sempre a uma biblioteca de classes. Também pode ser um aplicativo. Numa gem, todo o código está empacotado para facilitar a distribuição, instalação e manipulação de versões.

O gerenciador de pacotes oficial do Ruby é o RubyGems. Ele é um framework para gerenciamento das gems com um repositório online onde elas são publicadas para serem reutilizadas em qualquer projeto. Depois de instalado o Ruby, é recomendável atualizar o RubyGems para a ultima versão. A maneira mais fácil de fazer isto é pelo comando:

$ gem update --system

Para instalar ou atualizar uma gem, usamos estes comandos:

$ gem install gem_name
$ gem update gem_name

Onde gem_name é o nome da gem, conforme informado pelo desenvolvedor.

Por exemplo, para instalar uma gem para comunicação com o Twitter, o comando seria este:

$ gem install twitter

Lembrando que a gem ‘twitter’ é apenas uma entre as várias existentes.

Para usar o código desta gem num aplicativo, usamos o método require no início do código fonte:

require 'twitter'

Twitter.configure do |config|
  config.consumer_key = YOUR_CONSUMER_KEY
  config.consumer_secret = YOUR_CONSUMER_SECRET
  config.oauth_token = YOUR_OAUTH_TOKEN
  config.oauth_token_secret = YOUR_OAUTH_TOKEN_SECRET
end

Twitter.update("Twittando com #ruby!")

Mais informações sobre como usar o RubyGems, inclusive para criar e publicar novas gems, podem ser encontradas nos guias do RubyGems.

#1.7 Bundler

Para não ter que incluir dentro de cada projeto todas as gems utilizadas e ter sempre as versões corretas das gems, existe o Bundler, um gerenciador de dependências que ajuda a manter um ambiente consistente para a execução dos aplicativos.

Instalando o Bundler (repare queo Bundler também é uma gem!):

$ gem install bundler

As dependências são especificadas no arquivo Gemfile que deve ficar na raiz do projeto. O Gemfile deve conter o endereço da fonte onde buscar as gems, seguido da especificações de cada gem. Exemplo:

source 'https://rubygems.org'
gem 'nokogiri'
gem 'rack', '~>1.1'
gem 'rspec', :require => 'spec'

Para instalar ou atualizar todas as gems necessárias ao projeto, usamos o comando:

$ bundle install

Esta foi a primeira lição. Até a próxima!

Ruby Lessons

Official Ruby logo
Official Ruby logo (Photo credit: Wikipedia)

Esta é uma série de posts sobre a linguagem de programação Ruby. A ideia é registrar, em pequenas textos, os meus estudos sobre a linguagem. Incentivado pela iniciativa da Tecsystem em promover o RubyLab – treinamento em Ruby/Rails – entre a equipe de desenvolvimento, resolvi conhecer mais a fundo o Ruby. Depois vamos estudar, é claro, o framework Rails mas por enquanto é preciso criar bases sólidas nesta linguagem que é nova para todos da equipe, inclusive eu. Por isso, o conteúdo postado aqui será de um iniciante em Ruby. Dicas e sugestões são sempre bem vindas. Talvez possa servir para consulta futura mas o principal objetivo é estudar e compartilhar, fixando os conceitos através de exemplos práticos.

O que possibilita toda essa simplicidade do Rails são os recursos poderosos que Ruby oferece e que deram toda a simplicidade ao Rails. Esses recursos proporcionados pela linguagem Ruby são fundamentais de serem compreendidos por todos que desejam se tornar bons desenvolvedores Rails[…] – Caelum

Formato

Livros e tutoriais ensinando a programar em Ruby existem aos montes. Minha intenção não é criar mais um e sim reunir os pontos que acho mais importantes para se chegar mais rápido ao domínio da linguagem e compartilhar. Então resolvi organizar o conteúdo em pequenas lições. Cada lição vai ter alguns tópicos curtos sobre algum aspecto da linguagem ou das suas bibliotecas. Cada tópico vai ter um trecho de código demonstrando como funciona na prática, usando testes. Acredito que ficará mais intuitivo aprender desta maneira. Todo o código produzido vai estar disponível no GitHub.

Veja as lições já publicadas:

mobile

Estratégias de desenvolvimento de aplicativos móveis em várias plataformas

Este é o título do meu Trabalho de Conclusão de Curso aprovado no dia 27 de novembro de 2012 na UNES em Cachoeiro de Itapemirim – ES.
Foi uma pesquisa bem interessante porque aumentou ainda mais o meu interesse sobre desenvolvimento para dispositivos móveis. Não foi um trabalho muito extenso, até por conta do tempo que eu levei para começá-lo. Encontrar material adequado para servir de referência também não foi tarefa fácil, o que também atrasou o início. Há bons livros em português mas a abordagem que eu queria dar ao tema exigia algo um pouco mais aprofundado, conceitualmente falando. Me parece que pouco se tem escrito sobre isto academicamente. Até encontrei alguns artigos científicos mas tinham outras linhas de pensamento. Por isso, todas as referências utilizadas são livros em inglês. Gostaria de ter desenvolvido um aplicativo para multi-plataforma para complementar o trabalho mas, devido ao curto espaço de tempo, isto não foi possível. Então a abordagem se concentrou mais na análise conceitual dos problemas encontrados no desenvolvimento de aplicativos para dispositivos móveis e das estratégias comuns para resolvê-los.

A escolha do tema

Antes de decicir escrever sobre dispositivos móveis, outros temas nos quais tenho muito interesse também estavam na lista: bancos de dados não-relacionais (NoSQL) e arquitetura de sistemas orientada a serviço, sobretudo APIs baseadas em REST. Acredito que as três coisas estão intimamente relacionadas: a expansão do mercado de dispositivos móveis leva a uma demanda por aplicativos para estas plataformas. Além do mais, a “dependência” da web para quase tudo e o papel das APIs online neste cenário, juntamente com novas soluções de armazenamento de dados, que todo sistema deve tratar como um dos componentes principais. Todos estes temas poderiam ser considerados difíceis em termos de bibliografia, mas numa pesquisa rápida pude perceber que há livros muito bons sobre dispositivos móveis e esta acabou sendo a escolha, também pela atualidade do assunto. O objetivo do TCC era identificar as dificuldades encontradas no desenvolvimento de aplicativos para múltiplas plataformas móveis e analisar estratégias que possam minimizar estas dificuldades. Especificamente, apontar os problemas que podem comprometer o processo de desenvolvimento, bem como as vantagens e desvantagens de diferentes estratégias para contornar estes problemas. Quis ainda analisar algumas ferramentas que podem auxiliar no desenvolvimento.

Principais pontos

Aqui vai um pequeno resumo das 40 páginas do trabalho:

  1. Boa parte das principais dificuldades estão relacionadas às próprias plataformas móveis: como não há uniformidade no mundo mobile, um aplicativo está sujeito a ser executado em dispositivos e sistemas operacionais bem diferentes uns dos outros. Outras dificuldades podem surgir, por exemplo, quando se decide desenvolver para várias plataformas simultaneamente. Nem toda equipe é fluente em várias linguagens e tecnologias;
  2. É necessário criar uma experiência para o usuário que torne agradável o uso do aplicativo. Fornecer uma boa experiência para o usuário significa utilizar os recursos de uma plataforma ou dispositivo para entregar ao usuário a informação da maneira mais eficiente e intuitiva possível. Isto porque cada plataforma tem seus recursos específicos, principalmente em relação às interfaces gráficas, e interfaces aparentemente idênticas em duas plataformas podem ter comportamentos diferentes por terem formas diferentes de interagir com o usuário;
  3. Basicamente, pode-se escolher entre focar numa experiência imersiva numa única plataforma ou abranger o maior número possível de usuários em várias plataformas. Ao longo do tempo, as duas abordagens tendem a evoluir para o desenvolvimento multi-plataforma mantendo o objetivo de criar uma experiência excelente em cada uma delas;
  4. Entre as soluções possíveis, temos: aplicativos nativos, aplicativos web móveis e aplicativos híbridos (nativos mas desenvolvidos com tecnologias típicas da web como HTML, CSS e JavaScript);
  5. Como sempre, não há uma solução ideal para todos os casos.

Conclusão

Apesar de o mercado mobile ser bastante fragmentado, isto não inviabiliza o desenvolvimento de aplicativos. Pelo contrário, abre grandes oportunidades e mostra que, assim como no desenvolvimento de qualquer tipo de software em quaisquer outras plataformas, todas as opções devem ser analisadas com muito cuidado, pois há muitos fatores envolvidos no desenvolvimento de um software.
As soluções que foram apresentadas já foram postas em prática no mercado e tem auxiliado muitas empresas e desenvolvedores a criar suas estratégias para o desenvolvimento móvel.
Das tecnologias discutidas, uma das mais promissoras é sem dúvidas o HTML5, pelos recursos que apresenta para a construção de sites bem como aplicativos web e híbridos, e pelo seu potencial que, por estar ainda em evolução, não foi totalmente explorado, seja nas plataformas móveis ou desktop. Para as plataformas móveis, alguns dos recursos do HTML5 que podem despertar mais interesse são o armazenamento off-line, o suporte a áudio e vídeo, a geolocalização e seus recursos gráficos, que já tem sido bastante utilizados para a produção de jogos.

Enfim, independente da tecnologia utilizada, quando se fala em dispositivos móveis o foco deve estar sempre na
experiência que o aplicativo possibilita ao usuário. Sem isto, outros requisitos importantes podem não ser suficientes para garantir o sucesso de um aplicativo.

Dev in Cachu 2012

Dev in Cachu 2012
Dev in Cachu 2012

Falta pouco para o Dev in Cachu 2012, a segunda edição do evento de TI que movimenta o sul do Espírito Santo. Voltado principalmente para o desenvolvimento de software, o evento deste ano vai trazer temas bem interessantes e palestrantes de peso. Não pude participar do primeiro e, também por isso, não posso deixar de estar no próximo que vai acontecer no dia 5 de maio e 2012, no Centro Universitário São Camilo, em Cachoeiro de Itapemirim.

Destaco o workshop do Klaus Wuestefeld sobre computação soberana. Acho que vamos sair de lá com muitas boas ideias. E também a palestra do Ronaldo Ferraz, que vai falar sobre entrega contínua. Mesmo assim, todos os temas são de grande interesse para qualquer desenvolvedor.

A empresa em que trabalho – Tecsystem Tecnologia em Software – também patrocina o evento. As inscrições já se encerraram mas ainda podem sobrar vagas para quem não garantiu a sua. Nos vemos lá?

Codingo Dojo na Tecsystem

Ontem foi realizado mais um coding dojo na Tecsystem, empresa onde trabalho. Foi o segundo em uma semana e a intenção é que continuem acontecendo todas as quartas-feiras.
A ideia inicial era fazer um fork, um grupo de estudos sobre qualquer assunto relacionado a desenvolvimento de sistemas, mas o que acabou se concretizando mesmo foram os dojos.
No primeiro, que aconteceu no dia 11 de janeiro, eu fiz uma breve introdução ao TDD para aqueles que não estavam bem familiarizados com a técnica e com o funcionamento de um dojo: programação em par, o revezamento, o ciclo de testes, etc., e partimos direto para os testes.

O mais interessante, porém, não são os problemas propostos, mas a possibilidade de adquirir conhecimento, como novas linguagens, ferramentas e técnicas, e a interação que acontece quando todos pensam juntos para desenvolver uma solução. Além disto, desenvolver software num novo ambiente, mesmo que seja um problema simples, não deixa de ser uma ótima experiência. Acredito que seja isto que está despertando o interesse da equipe. Para mim, por exemplo, vai ser uma boa oportunidade de aprender algo sobre Python, Java e muito mais.
Se tudo der certo, na próxima quarta tem mais.
Em breve, mais novidades.

Veja mais no blog do Martinusso.

cloud2

Computação nas nuvens cada vez mais acessível – parte 2

No post anterior, escrevi um pouco sobre as vantagens da computação nas nuvens e fiz um pequeno comparativo entre alguns serviços que estão disponíveis na internet para desenvolvimento e publicação de aplicativos.

Agora vamos mostrar na prática como fazer isto usando um dos serviços citados, o AppHarbor, sem qualquer custo. A única limitação é que somente será alocada uma instância do aplicativo, ou seja, um único servidor para atender a todas as requisições. Para este aplicativo de exemplo, uma instância é mais que suficiente.

O AppHarbor foi escolhido pela familiaridade e pela facilidade de publicação com controle de versão. A implementação será feita em .Net.

Pré-requisitos:

  • Uma conta no AppHarbor
  • Sistema de controle de versão (Git ou Mercurial) – neste caso, usaremos o Mercurial
  • Visual Studio 2010 ou Visual Web Developer 2010 Express
  • Qualquer editor de HTML e CSS
  • Uma conta no Bitbucket – opcional, caso você queira compartilhar o código ou mantê-lo independente da hospedagem escolhida. Usarei o Bitbucket para disponibilizar o código fonte (link no fim do post).

Ao final, teremos:

  • O código fonte da aplicação armazenado em um repositório na web
  • A aplicação hospedada nas nuvens sem restrição de acesso

A aplicação fará conversão de moedas usando um web service. Não irei entrar em detalhes sobre a implementação e sobre o uso de sistemas de controle de versão. Vamos aos passos.

Criar uma conta no AppHarbor
Se você ainda não possui uma conta, vá até o site e clique em Sign up. Depois de entrar na conta, você será redirecionado à sua página de aplicativos.

Criar um novo aplicativo
No campo abaixo de Create new application, informe o nome do seu aplicativo e clique em Create New.

Integração com o Bitbucket
Esta etapa pode ser ignorada caso você não queira fazer a integração com um serviço externo. Eu recomendo que faça porque além de poder compartilhar o código mais facilmente, os fontes serão mantidos mesmo se o aplicativo for excluído do servidor.
Depois de criado o aplicativo, vamos então integrá-lo com o Bitbucket. Cada atualização no repositório será refletida no AppHarbor. Na verdade, quando um aplicativo é criado, um repositório vazio também é criado para ele no AppHarbor. Esta integração permite atualizar automaticamente os dois repositórios.

Criar uma conta no Bitbucket
Da mesma maneira, se você ainda não se cadastrou, faça-o neste momento (O GitHub também pode ser usado).

Criar o repositório
Entre em sua conta e clique em Repositories -> Create repository. Defina o nome do aplicativo (o mesmo). Há duas opções de sistemas de controles de versão: Git e Mercurial. Usaremos o segundo. Agora basta confirmar a criação clicando no botão ao fim do formulário.

Configurar o repositório
Clique na guia Admin para ir à pagina de configuração.

No menu à esquerda, clique em Access management para dar ao AppHarbor permissão de leitura do seu repositório. Informe o usuário apphb e clique em Read para confirmar. O resultado deve ser parecido com a tela abaixo.

O último passo da integração é inserir a URL que irá notificar o AppHarbor de cada atualização feita no repositório. Isto dispara todo o processo de publicação do aplicativo.
No mesmo menu mostrado acima, clique em Services. No campo Select a service, selecione POST e depois clique em Add service.

A URL a ser inserida aqui é gerada pelo AppHarbor e está na página do aplicativo.

Trata-se da build URL, que tem exatamente este propósito: permitir que outros aplicativos notifiquem que um novo build deve ser feito e uma nova versão deve ser publicada. Clique no botão build URL, cole o endereço no campo URL no Bitbucket e salve as configurações. A partir de agora, qualquer alteração no repositório fará com que a última revisão seja transferida para o AppHarbor. A compilação e a publicação no servidor são automáticas.

Clonar o repositório e sincronizar com o servidor
Todas as configurações na web já foram feitas. Agora resta clonar o repositório na máquina local (hg clone), adicionar o código fonte do projeto – que neste caso já está pronto – (hg add) e enviar as alterações (hg commit e hg push). Vejamos o resultado do push:

Das duas atualizações feitas até o momento, a mais recente ainda estava sendo publicada no servidor. Depois disto, se não houver nenhum erro, ela se torna a versão ativa e o app está online.
O endereço de acesso ao aplicativo pode ser visto na página Hostnames.

Conclusão
Há outros recursos a serem explorados mas pudemos perceber que é simples usar esta tecnologia. Mesmo num serviço gratuito como o que foi usado aqui, é possível, com um pouco mais de esforço, criar um aplicativo ou site com muito mais funcionalidades.

Tanto para desenvolvedores que trabalham sozinhos quanto para pequenas e médias empresas, existem muitas outras ferramentas prontas para serem usadas.

Links
Código fonte do conversor de moedas: https://bitbucket.org/evandroamparo/conversor-de-moedas/src
Endereço do aplicativo: http://conversordemoedas.apphb.com/

Computação nas nuvens

Computação nas nuvens cada vez mais acessível – parte 1

A computação nas nuvens está disponível e acessível para qualquer desenvolvedor a um custo muito baixo e com muita facilidade de implantação. 

Chamada por alguns de “a nova onda em tecnologia”, a computação nas nuvens ou cloud computing não é apenas um assunto da moda, mas um modelo de computação que surgiu para atender às demandas de TI da atualidade. Mas não é uma novidade: grandes empresas como a Microsoft já vem há muitos anos investindo nesta área e mantendo uma boa parte de sua força de trabalho dedicada a criar tecnologia para as nuvens. Nem tão pouco é uma exclusividade para os grandes. Hoje é possível usar toda esta tecnologia de maneira fácil e rápida. Vamos mostrar algumas vantagens para as empresas e usuários mas o nosso foco é o uso da computação nas nuvens do ponto de vista de um desenvolvedor.

Vantagens

Podemos citar muitas mas creio que todas elas vêm do fato de que a computação nas nuvens está fortemente ligada ao conceito de virtualização, que também já deixou de ser uma coisa só para grandes corporações. Eu mesmo tenho três sistemas operacionais em meu computador, com a ajuda do VMWare. Em escalas diferentes, seja nos data centers da Google ou num desktop, o princípio é o mesmo: usar os recursos computacionais de forma inteligente.

Escalabilidade

Não importa o tamanho da aplicação, os recursos sempre podem ser estendidos de acordo com a demanda dos negócios.  A facilidade de monitoramento e gerenciamento permite a alocação de mais recursos como memória, processamento e armazenamento em banco de dados sob demanda. Isto possibilita uma elasticidade virtual e não física do data center.

Redução de custos

Encarando a TI com um serviço, não é mais necessário investir em instalações físicas, servidores e pessoal para administrar toda a infraestrutura envolvida nisso. Também pode-se dispensar a preocupação com o sistema operacional e a implantação do software, que geralmente é feita de forma transparente.

Alta disponibilidade

A virtualização, quando bem utilizada, permite que o sistema fique online com uma probabilidade muito pequena de “queda”, já que vários servidores podem atuar em conjunto para servir às requisições dos usuários. A carga de rede é balanceada, assim como a capacidade de processamento, minimizando os riscos de uma sobrecarga no sistema.

Tecnologia acessível

Não faltam ofertas de serviços nas nuvens. Webmails, sistemas financeiros, colaboração em equipe e qualquer coisa que se possa imaginar e desenvolver. O fato é que hoje a computação nas nuvens está disponível e acessível para qualquer desenvolvedor a um custo muito baixo e com muita facilidade de implantação. Segundo o especialista em TI, Edivaldo de Araujo Filho, empresas de todos os portes podem tirar proveito deste modelo:

“O conceito de Cloud está há algum tempo em destaque no mercado e já é uma realidade para muitas empresas, principalmente de pequeno e médio porte, as quais já migraram toda ou parte de sua infraestrutura de TI para a nuvem, contratando como serviço a solução tecnológica de suporte aos seus negócios. Nas grandes corporações os CIOs também vêm buscando fortemente virtualizar suas infraestruturas, investindo, na maioria das vezes, em nuvens privadas dentro de seus próprios ambientes de TI (Private Cloud)”.

English: Cloud computing stack showing infrast...

O foco no aplicativo e não na infraestrutura é um dos principais motivos para se desenvolver para a nuvem. Vamos falar de alguns serviços, focando naqueles que oferecem planos gratuitos.

Este é um breve comparativo dos serviços disponíveis no mercado. Muitas destas empresas são startups que têm recebido muitos investimentos e prometem aumentar ainda mais a concorrência.

Serviço

Pontos fortes

Plano gratuito?

Arquitetura cheia de recursos avançados mas fáceis de usar

Até 750 horas de processamento por mês

Grande variedade de linguagens e frameworks

Sim

Utilizar a tecnologia da Google para executar seus próprios aplicativos; ambiente de desenvolvimento local, simulando a execução mesmo off-line

Sim: até 10 aplicativos com cotas de armazenamento de 500 MB cada

Facilidade de implantação com uso de controle de versão

Sim

Possui ambientes distintos para desenvolvimento (incluindo integração contínua) e execução do aplicativo

Sim

Algo em comum entre todos estes é a possibilidade de usar add-ons ou services – tecnologias que podem ser agregadas ao software, além do próprio ambiente de execução. Isto inclui banco de dados, envio de e-mail, monitoramento de erros, geração de logs e muito mais.

Alguns ainda facilitam o processo de deployment com uso de sistemas de controle de versão. Uma atualização no repositório é suficiente para que o aplicativo esteja online em segundos.

Existem também o Windows Azure da Microsoft, uma plataforma sofisticada para desenvolvimento em .Net e com avaliação gratuita por 90 dias, e o Amazon Web Services, que está investindo muito no mercado da América Latina, além de contar com uma plataforma robusta e confiável, utilizada por grandes companhias e outras empresas que terceirizam os serviços de cloud. É possível testar alguns serviços básicos por um ano.

Na próxima parte vamos mostrar como publicar uma aplicação nas nuvens em alguns passos.

Até a próxima.

Prova do Google Developer Day 2011

A exemplo do Erick Sasse, resolvi fazer também a prova do Google Developer Day 2011. A prova faz parte do processo de inscrição no evento e serve para selecionar os inscritos, caso haja mais inscrições que vagas disponíveis. Ela é opcional, mas os que a fizerem terão preferência se não houver vagas suficientes. Mesmo não pretendendo participar do evento, a prova me pareceu um desafio interessante. A prova é composta basicamente de cinco questões que envolvem manipulação de strings. Nela, são apresentados dois textos escritos num idioma fictício, o Googlon. Cada usuário recebe um conjunto de palavras diferentes. Portanto, as respostas são únicas para cada inscrição.

TDD

Com base nos dados fornecidos na própria prova, foi possível ter uma base para certificar-se das respostas. E o TDD se encaixou perfeitamente neste problema em especial, pois permitiu implementar os cálculos e conferir os resultados com os exemplos do texto antes de elaborar as respostas específicas. Por exemplo:

  • Contar o número de preposições no texto B: “existem 69 preposições no texto A” (1º teste);
  • Contar o número de verbos no texto B: “no texto A existem 82 verbos, dos quais 62 estão em primeira pessoa” (2º e 3º testes);
  • Obter a lista de vocabulário do texto B: foi dada a lista de vocabulário do texto A (4º teste);
  • Obter a quantidade de “números bonitos” no texto B: “No texto A existem 115 números bonitos distintos” (5º teste).

Para entender melhor, veja a prova aqui.
O código fonte da solução pode ser acessado neste repositório.

Em resumo, para cada questão, foi criado um teste específico para responder somente o que foi pedido. Aliás, não faz sentido utilizar TDD se não for assim: não codificar mais do que o necessário para fazer os testes passarem. Depois disto, vem as refatorações. Poderiam ter sido feitos muitos outros testes mas, como o foco era responder às questões, tudo foi feito pensando nisso.

Apesar de ter usado TDD, a experiência ensina que nem tudo é o melhor sempre. Pode-se até fazer testes unitários sem necessariamente desenvolver a solução com TDD. Uma coisa é mais que certa: testes são necessários e nunca são suficientes. Lembro-me de um professor que dizia: “Não existem sistemas corretos. Existem sistemas mal testados”. Em outra oportunidade, vou aprofundar a discussão sobre o assunto.

Até a próxima!

[Atualização: 22 de agosto de 2011]

Muitas pessoas tem chegado a este post através de pesquisas como “respostas da provinha google developer day” ou “resposta google developer day brasil 2011″. Como disse acima, as respostas não são as mesmas para todo mundo, mas o código fonte pode ser facilmente adaptado para responder qualquer variação do teste. Vale a pena tentar fazer mas o código está aí para quem quiser consultar.

071811_1519_PorquenoDel1.png

Por que não Delphi?

Antes de qualquer coisa, quero esclarecer que pretendo escrever aqui mais sobre conceitos, metodologias, padrões e coisas afins e menos sobre tecnologias. Estas vão e vem num espaço de tempo relativamente curto e não podemos ficar presos a elas. Os conceitos independem delas e nos ajudam a utilizar melhor todas as tecnologias disponíveis. Contudo, tenho observado como algumas pessoas se demonstram avessas a determinadas linguagens ou frameworks, favorecendo outros. E é exatamente isto que eu não quero fazer. O objetivo aqui não é defender o Delphi, mas lançar a ideia de que todos os recursos que estejam ao nosso alcance podem ser muito bem utilizados em qualquer projeto, desde que a solução atenda aos requisitos. Falo do Delphi por ser a ferramenta com a qual trabalho há muitos anos, embora conheça outras linguagens.

A ideia deste post surgiu justamente por causa da reação de algumas pessoas ao ouvirem falar da ferramenta criada pela Borland. O projeto que desenvolvo hoje é único no segmento no Estado por ter funcionalidades que ainda não foram implementadas em nenhum outro sistema similar. O mesmo poderia ser feito em Java, C#, Python ou qualquer outra linguagem. Isto não é o mais importante.

Depois que surgiram algumas linguagens de programação mais recentes, muitos tendem a dizer que o Delphi está ultrapassado. Eu afirmo que não, por alguns motivos:

Cada desenvolvedor ou empresa pode escolher o que julgar mais adequado para desenvolver seus projetos. A escolha pode ser feita pela afinidade da equipe com determinada linguagem, por querer usar algo mais inovador ou por outros motivos. É uma questão de viabilidade.

Lembro-me que há aproximadamente dois anos, numa palestra na UNES, o então presidente da SOFTES – associação que reúne as empresas de desenvolvimento de software do sul do Espírito Santo – apresentou uma visão geral sobre o mercado de trabalho na região. Ao afirmar que grande parte das empresas associadas ainda utilizava o Delphi em seus projetos, ele enfatizou que os sistemas atendiam muito bem a demanda dos clientes e iriam continuar atendendo por um bom tempo. Isso continua sendo verdade.

Não faz muito tempo, li um artigo que questionava: “O Delphi está morto?”. O autor (cujo nome não me lembro) respondeu que não e que ainda há espaço para ele. Acrescento dizendo que ainda há espaço para todos!

Também vi pessoas que se especializaram em .Net o defenderem como a oitava maravilha do mundo. Eu mesmo tenho estudado muito sobre ASP.Net. É realmente muito confortável desenvolver utilizando as ferramentas da Microsoft, mas há muitas outras opções. Neste momento estou testando o Delphi XE para avaliar os novos recursos. Mesmo que ele não seja adotado como a ferramenta de desenvolvimento no meu trabalho, valeu a pena conhecer a nova versão.

Em resumo, o título lá em cima é a pergunta que eu gostaria de fazer a alguns desenvolvedores. Uma tecnologia pode ser considerada a mais indicada para qualquer tipo de projeto? É justo deixar uma linguagem de lado apenas porque ela não está entre as mais “modernas”? Sou a favor da evolução, mas não sou radical.

Comentem!