Sábado agora começa o curso de Deploy. A idéia deste curso surgiu conversando com o Carlos Eduardo (sócio da eGenial) e nós percebemos que não existia em lugar algum uma forma centralizada de aprender o que realmente acontece em um um servidor. Rapidamente o Carlos veio com uma estrutura de grade do que poderia ser o curso e eu achei a idéia muito legal.

Faltava encontrar um instrutor, já que alguém com perfil de desenvolvedor (pois é um curso para desenvolvedores) e com profundo conhecimento de sysadmin não é fácil de encontrar. E para esta tarefa ninguém melhor que o Silvestre Mergulhão (Rede Parede, Portal do Voluntário, Improve-it, e etc).

Por que o curso é importante?

Para 2010 a eGenial veio com um planejamento um pouco diferente. Atuando forte na comunidade Ruby, o Carlos e o restante do pessoal criou 4 cursos de Ruby. Todos cursos são complementares e com conteúdo que você não consegue encontrar facilmente (e centralizado) por aí. Ao final dos 4 cursos nós, instrutores, e a eGenial estaremos contribuindo para criar uma comunidade Ruby com mais qualidade.

Os cursos são:

1. Rails do Básico ao Avançado (que eu ministro)
2. Ruby e Rails Imersão (que eu também vou ministrar)
3. BDD on Rails (com o Lucas Húngaro)
4. Sysdeploy (com o Mergulhão)

Com o primeiro curso você será capaz de criar aplicações Rails já com qualidade e bem elaboradas. Com o imersão Ruby você vai entender como as “mágicas” funcionam e como criar a sua própria magia da forma correta. O curso de BDD é uma obrigação para qualquer desenvolvedor Ruby e é a única forma de garantir manutenção a longo prazo e qualidade em seu sistema (mais para frente faço um post sobre este curso).

E para finalizar, o curso de Sysdeploy é a resposta para todas as pessoas que perguntam sobre performance do Rails mas que na verdade mal sabem o que é uma VPS. Todas as dúvidas sobre performance que aparecem são porque as pessoas não sabem o que é VPS, cluster, escalar vertical ou horizontalmente, proxy balancer, cache, memcache, diferença entre servidor de banco, web e aplicação e etc.

Desenvolver aplicações para internet não é apenas escrever código, UI e testes. É também garantir que estas coisas vão rodar da forma correta, com performance, automatizadas e que não serão invadidas por qualquer script kid que fique “chutando” senhas via ssh.

Vejo muita gente dizendo que hoje é fácil fazer deploy de aplicações Rails pois a forma básica é igual a PHP. Sinceramente que fala uma coisa dessas não tem a menor idéia do que é deploy de aplicações em nenhuma linguagem. Colocar uma aplicação rodando em um shared host é fácil mas você nunca poderá fazer deploy de uma aplicação séria (isso em qualquer linguagem) em um shared host.

Já que cedo ou tarde você não vai poder recorrer mais aos shared hosts você terá que contratar uma VPS (se não sabe o que é isso então é mais um motivo para fazer o curso). E com uma VPS você está sozinho, nada de suporte, ninguém para configurar as coisas para você e ninguém para você colocar a culpa quando sair uma nova versão do Rails e sua app não funcionar.

Temas como configuração de servidores e automatização de deploy são tão difíceis de aprender que o suporte das empresas de hospedagem estão sempre atolados. Os desenvolvedores web de hoje pensam como desenvolvedores desktop, compilei, instalei e pronto. O que na prática a coisa deveria ser totalmente diferente.

Mas eu não vou ser sysadmin

Nem eu quero arrumar emprego de sysadmin, mas a pouco tempo escutei um podcast com um entrevista do Chad Fowler onde ele fala que todos os bons desenvolvedores que ele conhece sabem fazer tudo. Quando ele diz tudo é desenvolver o código, testar, noções de UI, configurar um servidor, escalar este servidor e etc.

Mesmo que você não trabalhe com isto diariamente vai precisar saber onde a sua aplicação deve se comportar de certa forma para se adequar a estrutura dos seus servidores e você não vai poder abrir um ticket ou contratar um sysadmin cada vez que fizer deploy e aplicação não iniciar.

Mas eu já uso Linux e sei instalar uma VPS do zero

Quem bom, mas mais uma vez você está errado. Nenhum sistema respeitável vai depender de ajustes manuais para fazer deploy ou configurar servidores.

Você vai precisar conhecer ferramentas como Capistrano, Chef, Puppet, Moonshine e etc. Ferramentas responsáveis por automatizar o processo de deploy da sua aplicação e criação dos servidores ou você vai querer gastar dois dia para cada deploy? Ou pior, você não tem um servidor de Staging pois demora para deixar tudo sincronizado ( O.O )

E para estas ferramentas funcionarem é preciso ter conhecimento da aplicação, conhecer quais gems são necessárias, como compilar libs binárias e etc. Este tipo de coisa não será um sysadmin de um host contratado o responsável por fazer.

Mas ainda posso aprender sózinho…

O servidor de produção não é um bom local para cometer erros. É bom que tudo funcione de primeira, sem falhas de segurança e principalmente com backups. Este é o tipo de coisa que eu gostaria de ter tido um curso para minimizar os meus erros.

Um exemplo comum: Backups. Raramente quando comento sobre Backups eu escuto uma boa estratégia. Normalmente é dump do banco e um tar.gz da pasta da aplicação, (que as vezes é agendado no cron) e a pessoa baixa isto para um disco local. Esta é a pior estratégia de backup possível.

Seu backup deveria ser feito automaticamente, no mínimo uma vez ao dia e enviado para um outro servidor seguro ou disco remoto em um data center, sem nunca passar pela sua máquina. Existem outras diversas formas de ter um Backup de qualidade, mas a mais comum (do parágrafo anterior) é a mais errado de todas.

E Backup é só um assunto que eu pagaria facilmente para nunca ter problemas, existem vários outros. E para evitar estes problemas que tal pagar pelo curso e aprender com alguém já sabe tudo isto na prática?

Faça já sua matrícula

Veja a grade no site e faça já sua matrícula para subir um nível na sua carrera de desenvolvedor. E melhor ainda, preparar a base para que você possa criar suas próprias aplicações. Ou você vai querer cometer os erros acima em seu próprio produto?

PS: Eu não ganho comissão por curso ein

Se você é estudante de ensino médio ou de graduação, não perca a chance de aumentar / ou reciclar seus conhecimentos em .NET gratuitamente!

As inscrições para o Microsoft Students to Business (S2B) em Curitiba vão até o dia 19 de abril de 2010.

O Programa tem por objetivo aproximar estudantes de oportunidades de trabalho nas carreiras de Tecnologia de Informação.

Para isso inclui diversas ações, sendo as principais capacitações gratuitas nas plataformas Microsoft e aproximação com empresas que buscam mão-de-obra com esse perfil.

O programa tem um total de 84 horas/aula para capacitação de jovens, com um conteúdo que abrange palestras sobre o mercado de trabalho e aulas teóricas e práticas ligadas às carreiras de TI.

As capacitações são voltadas a estudantes do ensino médio e superior e visam preparar as próximas gerações de profissionais nas tecnologias Microsoft.

Ao longo de 3 fases os estudantes adquirem formação técnica para tornarem-se profissionais júnior desenvolvimento. Na primeira fase o curso traz informações sobre as carreiras de TI, na segunda, aulas teóricas e na terceira, aulas práticas, com o desenvolvimento de um projeto de formatura.

No encerramento são entregues certificados, em um evento que inclui uma feira de empregos, uma excelente oportunidade para você que ainda não trabalha ou está querendo trocar de empregador.

Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Qual foi o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Tenho dedicado os últimos anos a ministrar treinamentos, sejam pela eGenial ou para equipes em empresas. No ano passado participei de treinamentos com mais de 100 pessoas e só no começo deste ano foram mais quase 100.

Treinar tanta gente é uma experiência fantástica pois em nenhum emprego eu poderia ver o fonte de tantas pessoas, conhecer tantos problemas diferentes e aprender com os erros dos outros e propor soluções antes mesmo de aconteçam comigo.

Mas uma coisa tem me assustado muito: NOMES. Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Qual foi o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Então, o primeiro fator que considero para desenvolver OO corretamente é como você deve nomear e simular o mundo real através do seu código.

Mas como nomear corretamente as coisas?

A funcionalidade do Rails que acho mais fantástica é a preocupação de manter a característica do Ruby de ser legível. Temos métodos como validates_presence_of ou has_and_belongs_to_many ao invés de apenas vpo ou has_blg. Esta preocupação fica mais clara ainda se pensarmos nas tabelas, models e controllers.

Tabelas no Rails praticamente só servem para persistir objetos (reparem: objetos no plural) por isso elas são nomeadas no plural (customers, transactions, teachers, etc) enquanto a classe (class é um esqueleto para um objeto) e como ela criará um objeto por vez ela é nomeada no singular (Customer, Transaction, Teacher).

Métodos são operações que o objeto pode realizar, logo devem ser ações como calculate, find, sum enquanto propriedades/atributos são características do objeto que consequentemente devem ser nomeadas como tal. Seus accessors devem ter nomes de propriedades como name, age, value e etc. Se existe uma variável que é um verbo/ação então simplesmente seu código está errado e não tem significado como um objeto.

Já sabemos como nomear tabelas, classes e como a prática do Rails é muito boa para manter o código legível. Mas o que são controllers?

Um controller é uma forma de expor ao mundo os seus objetos do sistema e ao pensar como organizar seu controllers você deve ter isto em mente (por isto o Rails é REST e não apenas para expor uma API qualquer). Suas actions do controller devem ser ações mesmo, ações que vão ser executadas em seus objetos para poder mostrá-los ao mundo.

Se você tem uma action chamada “calculos” o nome simplesmente está errado, isto não é uma ação. Se você pensar em um controller como expositor de seus models com views então o método “calculos” está até no local errado, ele deveria estar dentro do model de BankAccount por exemplo e o controller apenas obtém o valor retornado pela ação calculate de um objeto da classe BankAccount. Neste exemplo a preocupação com nomes nos ajuda a colocar os métodos nos locais corretos criando uma boa arquitetura.

Código deve ser legível mesmo quando o sistema se tornar legado.

Qualquer sistema se torna legado, mesmo ele sendo escrito em Rails 3.0beta hoje, daqui a uma semana ele é legado e você não se lembrará de boa parte do que foi escrito lá.

Um desenvolvedor é um escritor e seu código (principalmente em Ruby) são frases que dizem o que deve acontecer. Se você não nomear seus métodos, objetos e variáveis da forma correta mais cedo ou mais tarde nem mesmo você entenderá um código que escreveu (experiência própria) quanto mais outro desenvolvedor.

Outro fator que destrói a legibilidade são os resumos. Um helper como options_for_select que cria options para um select do html poderia ser resumido para opt_select ou has_many poderia ser h_many. Mas estes resumos são extremamente prejudiciais e tornam o fonte impossível de ler futuramente.

Então sempre escreva o fonte como um manual e pensando em outra pessoa que venha a le-lo ao invés de pensar em você mesmo. Isto evitará o problema acima e mesmo daqui a 1 ano você voltará no código e entenderá tudo na primeira leitura.

Por que escrever fonte em Português é péssimo?

Nos treinamentos percebo que muita gente tenta escrever código Ruby em Português. O grande problema disto é que você terá algo assim: Pessoa.find_all_by_nome. Se você pensar em seu código como um simulador do mundo real que apenas contem instruções de como as coisas devem acontecer está óbvio que o seu simulador está “manco”.

Pessoa.find_all_by_nome não diz nada nem em Português e nem em Inglês. Logo é uma falha de arquitetura, e principalmente em Ruby, seu código acabou de perder a legibilidade da linguagem, que o Rails mantém e você acabou de destruir.

Como é impossível escrever tudo em Português então evite escrever qualquer coisa em Português. Desta forma você não terá um simulador “manco” que não descreve nada em linguagem nenhuma. Claro, termo técnico ou da regra de negócio como CPF, CNPJ e outros devem ser mantidos em Português ou na linguagem que for mas outras coisas como enturmação em uma rede social de alunos deveria ser representado como membership. Caso contrário você terá uma bizarrice como está:

class Estudante < ActiveRecord::Base
  has_and_belongs_to_many :enturmacoes
end

ao invés de

class Student < ActiveRecord::Base
  has_and_belongs_to_many :memberships
end

Evitando este tipo de arquitetura ruim: Estudante.first.enturmacoes.all(:conditions=>…). Ao ler esta frase (isto deveria ser uma frase) não existe nenhum significado em Português e nem em idioma algum, logo você tem um erro de nomenclatura e seu simulador do mundo real está manco, não representa a realidade e mais cedo ou mais tarde você estará dando manutenção em um sistema que apenas você entende.

Por favor não me venha dizer que é patriota e que o idioma do seu país é Português. Se você pensa assim deveria escrever class em japonês ao invés de Inglês já que o Ruby é uma linguagem Japonesa. Seu código é escrito para os outros e a única garantia que qualquer pessoa entenderá é escrevendo-o semanticamente correto e como a linguagem de programação já é em Inglês escreva-o em Inglês.

Também não existe problema algum se seu Inglês não é fluente. Tenha um dicionário a mão e tudo estará resolvido.

Conclusão

Não tenho vergonha em dizer que escrevi vários sistemas de 4 ou 5 anos atrás que por não ter seguido uma boa arquitetura o código é terrível e de difícil leitura. E pensando em arquitetura que me apaixonei por Ruby e consequentemente Rails, com eles é simples escrever um código que será fácil de ler mesmo daqui a 3 anos.

É sua obrigação fazer o código funcionar mas também é sua obrigação subdividir seus arquivos em pastas que fazem sentido, criar classes, templates e escrever código semanticamente correto, como um livro. Isto tudo é arquitetura do projeto e não apenas frescura, é preocupação com manutenção futura.

Esta regra o ajudará a identificar o que são método, o que são variáveis, objetos e onde colocar estas coisas.

Então pense 2 ou 3 vezes antes de escrever um método ou classe e não tenha vergonha em gastar mais horas do seu dia pensando em como organizar seus models e controllers do que escrevendo dezenas de linhas de código.

Recentemente houve um debate na FB sobre qual seria um valor justo a se pagar a um programador Flex. A pessoa que começou a thread por até não ter se dado conta, mas mexeu num vespeiro. Muitas pessoas deram suas opiniões (eu também, lógico!) e parece que o saldo do debate ficou assim:

1. Programadores ganham pouco porque a profissão não é regulamentada.
2. Programadores em Flex ganham pouco porque há muitos newbies.

Eu, pessoalmente, não estou competindo com nenhum newbie… Não há um projeto onde eu tenha trabalhado que pudesse ser tocado por eles (menos quando eu era newbie, haha).

Mas eu não estou escrevendo para quem está fazendo a vida em cima do Flex, que ganha bem e entende o framework. Eu queria escrever para aqueles que estão aprendendo Flex e estão entrando num emprego ou aceitando um free-lance.

Eu até ia fazer uma compilação das perguntas absurdamente sem noção que aparecem na FB e na FD, de pessoas que estão trabalhando (e provavelmente desenvolvendo uma gastrite, coitados…), mas isso seria antiético. Então, pegue um lápis e um papel e faça o checklist:

1. Sei exportar um projeto de forma correta.
2. Sei a diferença entre Flex e AIR.
3. Entendo os prós e contras de trabalhar com módulos e RSLs.
4. Sei disparar e capturar eventos. Entendo as propriedades .currentTarget, o parâmetro bubbles e os métodos da classe EventDispatcher.
5. Sei o que é deferred instantiation.
6. Sei escolher os containers de forma a otimizar aplicações.
7. Sei popular os data controls com coleções do Flex.
8. Sei recuperar e modificar itens dentro das coleções do Flex.
9. Sei usar os métodos das coleções do Flex.
10. Sei recuperar dados de RadioButtons, ComboBox e Repeaters.
11. Sei construir um ItemRenderer.
12. Passo objetos entre views (por exemplo, módulos ou seus custom components).
13. Sei usar um swc de terceiros.
14. Sei usar o HTTPService, RemoteObjects, WebServices ou a tecnologia que você está usando.
15. Entendo o que significa assincronismo e aceitar que isso não é ruim; é uma característica do framework.
16. Sei quando o que procuro é uma propriedade, um estilo, um método ou um evento.
17. Sei ler a documentação.
18. Sei pesquisar meus problemas na internet (google, flex forums,etc)
19. Sei elaborar uma questão para alguns dos forums Flex e não espero uma solução pronta com código pra só copiar/colar.

Se você aceitou um freela ou não é estagiário e não passou em TODOS estes itens, saiba que as chances de você ter dificuldades muito grandes durante o seu projeto são enormes. E que você vai ter que depender da boa vontade / paciência / disponibilidade de outras pessoas te ajudarem.

Se você está aprendendo ou é estagiário: você está estudando – PARABÉNS PELO SEU BOM SENSO!

E aos que deram risada desse checklist: aceito sugestões!

É isso mesmo. Se você é um programador Flex e está desempregado atualmente, saiba como ganhar o Flex Builder 3 da Adobe e também como conseguir 60 dias de acesso a coleção online de livros Adobe Flex e técnicas de desenvolviment RIA na Safari Books Online.