O Rails 3 vem aí
Entendendo o Ruby on Rails
Juan Maiz   maiz@softa.com.br - @joaomilho
Rails   não escala?
Perl   my $language
C   not for kids
not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print q...
Ruby   a programmer’s best friend
Ruby   not in english
Pickaxe   updated
Design Patterns   revolução em OO
Agile   manifesto
<project name="MyProject" default="dist" basedir=".">
    <description>
        simple example build file
    </descriptio...
Ricardo Semler   Maverick!
37signals   Getting Real & Rework
Ruby   elegância
Rails3   Lotsa stuff
Ruby   evolved
Sites   github
RS   on rails
Obrigado   perguntas?
Upcoming SlideShare
Loading in...5
×

Rails3

2,647

Published on

O Rails 3 vem aí.

(X) Muito provavelmente você já ouviu falar do Ruby on Rails. “É um framework para desenvolver aplicações web, em uma linguagem pouco usada, chamada Ruby. É open source, e o pessoal que usa diz que é muito produtivo. Mas vá saber, o pessoal que usa Java ou PHP diz a mesma coisa. E, ao menos, nestas linguagens há muitos empregos. Dizem também que Ruby é lento e não escala. Além disso, seria mais uma linguagem para aprender...”

Se é essa a história que você ouviu, você perdeu a parte importante. E é essa a parte que eu vou contar aqui. Para entendermos da onde veio o Ruby on Rails, teremos de quebrar isto em três partes. A primeira será a parte tecnológica. A segunda será, na falta de um nome melhor, a parte metodológica. E a terceira e última, chamarei, para continuar rimando, a parte mercadológica. Após entendermos o que é de fato Ruby on Rails, vou resumir a história dele entre a versão 1.0 e a 3.0, que está no título desta palestra.

(X) A história tecnológica do Ruby on Rails começa na década de 80, quando foi criada a linguagem Perl. Assim como hoje há uma certa competição entre Java e Ruby, havia nos anos 90 entre Visual Basic e Fox Pro e entre Smalltalk e C++, naquela época Perl rivalizava com C.

(X) C era, e ainda é, o protótipo da linguagem para “homens de verdade”. C servia para trabalho pesado. Protocolos, drives, sistemas operacionais, servidores web... Mas quando você tinha que abrir um arquivo e modificar algo, ou copiar algo de lá pra cá, era como dar um tiro de bazooka em um mosquito. Mas era justamente este tipo de tarefa que ocorriam no dia a dia dos administradores de redes e servidores. Foi para estes que Perl foi criado. Tanto é que Perl significa “practical extraction and reporting language”, traduzindo mais ou menos como “linguagem prática de extração e relatórios”. Perl cresceu e se tornou muito mais do que isso. Mas a palavra que acho importante aqui é o “prática”. Isso sigficava que C, e as outras linguagens da época não eram praticas o suficiente para resolver um certo conjunto de problemas. E Larry Wall, ao se deparar com estes resolveu criar sua própria linguagem. Mas como estes problemas eram comuns há muitas outras pessoas, estas também adotaram Perl. Não seria exageiro dizer que Perl foi a principal linguagem na criação e no início da internet.

(X) Ao contrário de C, que era uma linguagem compilada, Perl tinha uma filosofia mais próxima do Lisp, e era interpretada. Bastava escrever uma linha, ou algumas poucas linhas e “jogar” para dentro do interpretador e resolver o seu problema. Conseguir resolver um problema apenas com uma linha de código se tornou um quase um objetivo, um ideal estético e um desafio lógico.

A diversão da comunidade Perl era escrever “just another perl hacker” ou desenhar o camelo das formas mais criativas possíveis. Criaram concursos de código ofuscado, onde se programava apenas pelo prazer de se programar. Diversão começou a ser um fator importante.

(X) Agora voltamos ao início dos anos 90. Perl já era gente grande, e Python estava redefinindo a simplicidade e legibilidade das linguagens de script. Ao contrário da comunidade Perl, o “zen” da comunidade Python era escrever algumas linhas a mais, mas fazer o código fácil e compreensível. Dizem por aí que entender o próprio código, 6 meses após escrevê-lo, é algo muito difícil. A comunidade Python queria acabar com isso, mantendo as facilidades do Perl. Foi neste cenário que Matz (Yukihiro Matsumoto) criou Ruby. Ele não estava satisfeito com Perl, que tinha se tornado complexo demais e que não tinha uma boa orientação a objetos. Nem com Python, que era simples demais, removendo do jogo coisas boas do Perl e de outras linguagens mais “quick and dirty”.

Matz viu que faltava uma linguagem que incorporasse o melhor do Perl, sua flexibil

Published in: Technology
2 Comments
3 Likes
Statistics
Notes
  • Abaixo está o texto completo da apresentação. Para acompanhar troque o slide a cada (X).
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • O Rails 3 vem aí.

    (X) Muito provavelmente você já ouviu falar do Ruby on Rails. “É um framework para desenvolver aplicações web, em uma linguagem pouco usada, chamada Ruby. É open source, e o pessoal que usa diz que é muito produtivo. Mas vá saber, o pessoal que usa Java ou PHP diz a mesma coisa. E, ao menos, nestas linguagens há muitos empregos. Dizem também que Ruby é lento e não escala. Além disso, seria mais uma linguagem para aprender...”

    Se é essa a história que você ouviu, você perdeu a parte importante. E é essa a parte que eu vou contar aqui. Para entendermos da onde veio o Ruby on Rails, teremos de quebrar isto em três partes. A primeira será a parte tecnológica. A segunda será, na falta de um nome melhor, a parte metodológica. E a terceira e última, chamarei, para continuar rimando, a parte mercadológica. Após entendermos o que é de fato Ruby on Rails, vou resumir a história dele entre a versão 1.0 e a 3.0, que está no título desta palestra.

    (X) A história tecnológica do Ruby on Rails começa na década de 80, quando foi criada a linguagem Perl. Assim como hoje há uma certa competição entre Java e Ruby, havia nos anos 90 entre Visual Basic e Fox Pro e entre Smalltalk e C++, naquela época Perl rivalizava com C.

    (X) C era, e ainda é, o protótipo da linguagem para “homens de verdade”. C servia para trabalho pesado. Protocolos, drives, sistemas operacionais, servidores web... Mas quando você tinha que abrir um arquivo e modificar algo, ou copiar algo de lá pra cá, era como dar um tiro de bazooka em um mosquito. Mas era justamente este tipo de tarefa que ocorriam no dia a dia dos administradores de redes e servidores. Foi para estes que Perl foi criado. Tanto é que Perl significa “practical extraction and reporting language”, traduzindo mais ou menos como “linguagem prática de extração e relatórios”. Perl cresceu e se tornou muito mais do que isso. Mas a palavra que acho importante aqui é o “prática”. Isso sigficava que C, e as outras linguagens da época não eram praticas o suficiente para resolver um certo conjunto de problemas. E Larry Wall, ao se deparar com estes resolveu criar sua própria linguagem. Mas como estes problemas eram comuns há muitas outras pessoas, estas também adotaram Perl. Não seria exageiro dizer que Perl foi a principal linguagem na criação e no início da internet.

    (X) Ao contrário de C, que era uma linguagem compilada, Perl tinha uma filosofia mais próxima do Lisp, e era interpretada. Bastava escrever uma linha, ou algumas poucas linhas e “jogar” para dentro do interpretador e resolver o seu problema. Conseguir resolver um problema apenas com uma linha de código se tornou um quase um objetivo, um ideal estético e um desafio lógico.

    A diversão da comunidade Perl era escrever “just another perl hacker” ou desenhar o camelo das formas mais criativas possíveis. Criaram concursos de código ofuscado, onde se programava apenas pelo prazer de se programar. Diversão começou a ser um fator importante.

    (X) Agora voltamos ao início dos anos 90. Perl já era gente grande, e Python estava redefinindo a simplicidade e legibilidade das linguagens de script. Ao contrário da comunidade Perl, o “zen” da comunidade Python era escrever algumas linhas a mais, mas fazer o código fácil e compreensível. Dizem por aí que entender o próprio código, 6 meses após escrevê-lo, é algo muito difícil. A comunidade Python queria acabar com isso, mantendo as facilidades do Perl. Foi neste cenário que Matz (Yukihiro Matsumoto) criou Ruby. Ele não estava satisfeito com Perl, que tinha se tornado complexo demais e que não tinha uma boa orientação a objetos. Nem com Python, que era simples demais, removendo do jogo coisas boas do Perl e de outras linguagens mais “quick and dirty”.

    Matz viu que faltava uma linguagem que incorporasse o melhor do Perl, sua flexibilidade e do Python, sua organização e simplicidade. Também, é claro, deveria ser orientada a objetos e possuir uma arquitetura simples e elegante como Smalltalk. E Matz fez Ruby. Originalmente, ele o fez para resolver seus problemas. Mas, é claro, ele fez a coisa que faltava, na hora certa, assim como ocorrera com Python e Perl, muitas pessoas se identificaram e começaram a usar Ruby.

    (X) No final dos anos 90 surgiram os principais concorrentes atuais em linguagens para aplicações web: PHP, Java, ASP e depois .NET. Durante este período, Ruby esteve adormecido, pois ainda faltava a ele superar um abismo para se tornar uma linguagem conhecida: o abismo entre oriente e ocidente. Até o início desta década não haviam livros de Ruby em inglês. A documentação era feita na lingua original, japonês e a tradução para inglês era lenta ou mesmo incompleta. (X) Foi com o livro Programming Ruby, mais conhecido como “pickaxe”, ou “picareta” em bom português que Ruby de fato chegou ao Ocidente. E assim o cenário técnico estava completo, faltando apenas que Ruby tivesse alguma aplicação prática em algum nicho em que superasse as opções das outras linguagens. E foi neste nicho que veio o Ruby on Rails.

    (X) Agora precisamos conhecer a parte que chamei de “metodológica” da história. Durante os anos 90, as aplicações “empresarias” prosperaram. Todas as grandes empresas investiram em sistemas de gestão, os bancos se tornaram muito mais ágeis e começaram a surgir também as primeiras aplicações web. As aplicações também se tornaram muito mais complexas, pois precisavam integrar muitas necessidades destas empresas. Escrever sistemas como se fazia antes não era mais uma opção. Era necessário encontrar padrões nestas aplicações e tornar os sistemas mais modulares.

    Foi neste ambiente que surgiu o conceito de “design patterns”, comumente traduzido como “padrões de projeto”. Autores como Kent Beck, Ward Cunningham, Erich Gamma (e o “gang of four”) e Martin Fowler começaram a desmembrar as aplicações e separar as partes “atômicas” que encontravam para facilitar o desenvolvimento futuro. Os primeiros livros sobre estes tópicos foram escritos, geralmente com foco em linguagens orientadas a objeto, como Smalltalk.

    (X) Com estes padrões em mãos começou a ser possível diminuir o custo de se modificar o software a medida em que este ia sendo desenvolvido. Até então se considerava algo muito custoso fazer modificações após a aplicação estar “pronta”. Por isso, era comum se utilizar métodos inspirados na engenharia para se fazer software. No “waterfall”, se dividia o desenvolvimento em etapas rígidas, justamente para previnir modificações tardias. Mas como eu dizia, os padrões de projeto começaram a mudar este cenário. Desenvolver software não era mais empilhar tijolos, pois passamos a ter andares inteiros prontos.

    Outras técnicas e práticas também começaram a ser adotadas e contribuiram para tornar o desenvolvimento de software algo mais iterativo e preparado para mudanças: programação em pares, propriedade coletiva de código, sistemas de controle de versão, refatoração, testes automatizados, integração contínua, etc. Estas foram organizadas em metodologias completas, como extreme programming, scrum, crystal clear, etc.

    Estas metodologias, além das práticas citadas, trouxeram uma verdadeira revolução ao ambiente de trabalho. Os métodos ágeis, como ficaram conhecidos após o “agile manifesto”, buscavam valorizar as pessoas em detrimento dos processos ou ferramentas, a colaboração, em detrimento à burocracia e uma verdadeira geração de valor ao negócio. Outro ponto importante foi o foco em uma qualidade impecável no desenvolvimento de software. É irônico notar aqui, que muitas destas técnicas e filosofias de trabalho, assim como Ruby, vieram do oriente, e.g. as técnicas até hoje estudadas que foram criadas na Toyota.

    (X) Muitas destas metologias iniciaram em projetos em Smalltalk, outras iniciaram na própria Microsoft ou outras empresas. No final dos anos 90, quando de fato começaram a ser utilizadas, as empresas já estavam migrando para a dobradinha Java/.NET. As empresas brasileiras que começaram a dar atenção a estas mudanças também estavam indo por este caminho. Java e .NET criaram dezenas de ferramentas para se desenvolver software utilizando estas práticas, devemos reconhecer, com muito sucesso. Ainda assim, não parecia que as filosofias destas linguagens, que haviam sido criadas por comitês, para resolver problemas genéricos e serem vendidas para grandes empresas, onde, via de regra, vale mais a padronização e a previsibilidade do que a adaptação e a possibilidade da criatividade. Além disso, estas linguagens e suas ferramentas foram adaptadas à estes métodos, e não pensadas desde o início para isso. Também as suas comunidades, apesar de grandes esforços, em sua maior parte, pareciam não ter os métodos ágeis no DNA. Quando saiu a primeira versão do Rails, ainda antes da 1.0, as práticas de extreme programming pareciam estar embutidas na filosofia do framework. Mas voltaremos à isto depois.

    (X) A terceira parte da nossa história inicial do Rails, a que chamei de mercadológica, pode começar, talvez, em São Paulo, nos anos 80. Foi lá que Ricardo Semler, ainda jovem, assumiu a Semco, empresa familiar que era gerenciada de forma “tradicional” por seu pai. Semler implantou um sistema que ainda parece afrontar o senso comum. Antes, seus funcionários eram revistados na entrada e na saída, o horário era rígido e a hierarquia respeitada. Com Semler, os horários, os cargos e mesmo os locais de trabalhos se tornaram flexíveis, os funcionários trocavam de função regularmente, as equipes escolhiam seus próprios líderes e, ao contrário das revistas, os funcionários passaram a viajar com cartões de crédito da empresa, sem perguntas quanto aos gastos. Mais do que isso, os próprios funcionários começaram a ditar seus salários de acordo com os ganhos da empresa. O que fazia este sistema funcionar? Seria o fato de ser um modelo socialista, como muitos pensam? Muito pelo contrário, o sistema de Semler abandonou o paternalismo das empresas anteriores, e criou um ambiente de respeito pelos indivíduos onde a cooperação pelo bem é perfeitamente compatível com a competição natural ao capitalismo. Aliás, a saudável competição deste sistema contrasta com o sistema arcaico ainda adotado em muitas empresas e órgãos públicos, onde salários e promoções são ou ditadas por leis, por “qi” ou por “puxa-saquismo” mesmo, raramente pelo real merecimento. Já no sistema da Semco, os líderes eram escolhidos e avaliados pelos próprios liderados, e todos os salários eram abertos. Desta forma, é evidente que, aqueles que tem altos salários, mas cujo trabalho não agrega valor, não parecem ter neste sistema uma carreira promissora.

    (X) E o que isto tem a ver com o Rails? Pois bem, o Ruby on Rails foi criado por David Heinemeier Hansson. David, já trabalhava na 37Signals, junto com seu sócio, Jason Fried. Semler foi uma grande inspiração para eles, e também para uma geração inteira de empreendedores. Foi na 37 que David criou um software chamado Basecamp, e dele extraiu a primeira versão do Rails em 2004. O fato do Rails ter saído de uma aplicação comercial, que hoje conta com milhões de usuários também explica muita coisa.
    Com as três histórias concluídas, podemos entender agora como surgiu o Rails. David pensava originalmente em fazer o Rails em PHP, ou talvez Java. Mas ele estava descontente com ambas as linguagens. PHP era muito “quick and dirty” e Java, apesar de ter uma ótima organização, não era produtiva nem expressiva o suficiente. (X) Quando David conheceu a então nascente comunidade Ruby, ficou fascinado não apenas com a linguagem, mas pelo fato de que aquele grupo usava os termos “estética” e “elegância” em frases sobre programação. Mas não era a estética ainda embrionária do Perl, nem o cubismo do Python. Era algo simples, mas também pragmático. Era o que David precisava.

    A primeira versão do Rails, como já mencionei acima, também já vinha com métodos ágeis no DNA. Testes automatizados já eram gerados ao se criar um modelo ou um controle. (X) A filosofia de “convenção sobre configuração” tornava a produtividade incomparável com o que havia na época, mas mantendo a flexibilidade. E Ruby permitia a criação de DSLs (linguagens específicas de domínio), o que tornava o código de uma aplicação Rails diferente do que se via, como exemplo dos já famosos “has many” e “belongs to”.

    A versão 1.0 saiu em 200, ano em que David esteve falando sobre ele no FISL em Porto Alegre, com menos de 20 presentes. Em contrapartida, naquele mesmo ano, ele ganhou o prêmio de hacker do ano, da OSCON. O interesse pelo framework cresceu rapidamente, e em um ou dois anos ele se tornou a ferramenta padrão da maioria das startups do vale do silício.

    Com a versão 2.0 e as seguintes, vieram novas funcionalidades como internacionalização, interfaces REST e melhorias de segurança. Enquanto isso, surgiram dezenas de outros frameworks inspirados no Rails em PHP, Java, Python, Perl e .NET. Mas também surgiram competidores dentro da própria comunidade Ruby, como o Merb que prometia mais flexibilidade e performance. Foi aí que, em vez se fechar, a comunidade Rails mostrou que é capaz de se adaptar e é da cooperação com a comunidade do Merb que surge o Rails 3.

    (X) No Rails 3, além de todas as vantagens do Rails, os componentes foram isolados. Existem, por exemplo, diversas ferramentas para ORM (abstração com o banco de dados). Você pode escolher entre ActiveRecord, SEQUEL ou DataMapper.

    A comunidade criou também uma infinidade de plugins e ferramentas de altíssima qualidade que podem ser conferidas no site ruby-toolbox.com. Hoje, com Ruby e Rails, é possível fazer TDD & BDD, integração contínua, deploy de aplicações de forma automatizada, realizar autenticações de forma totalmente segura, fazer aplicações com javascript e ajax, criar bots, fazer jogos, enviar e receber e-mails, trabalhar com dados geográficos, gerar relatórios, processar imagens, mexer com música, criar aplicações altamente escaláveis com queues e bancos distribuídos, fazer upload de arquivos grandes, processar vídeos, criar APIs, executar operações em background e existem até mesmo servidores web escritos em Ruby.

    (X) Neste meio tempo também surgiu o Ruby 1.9, com melhorias de perfomance e concorrência. Ruby entrou na JVM e no .NET com o JRuby e o IronRuby. E também teve implementações inovadoras como MagLev e Rubinious.

    (X) Além das ferramentas, repare nos sites da comunidade Ruby. Eles são diferentes da maioria dos outros projetos de código aberto. Talvez isto tenha alguma relação com a precupação estética da comunidade. Veja também a quantidade de aplicações comerciais criadas pela comunidade. Os próprios projetos Ruby giram em torno do GitHub, uma aplicação comercial para projetos fechados, mas que hospeda aplicações abertas sem custos.

    A orientação para o mercado da comunidade, cujo produto já nasceu de um produto é clara. Mas Ruby ainda é mais utilizado por pequenas, mas lucrativas empresas, que buscam novos modelos de negócios e de trabalho. Competindo no mercado e ao mesmo tempo colaborando, pois como já vimos, as duas atitudes não são incompatíveis. Muito pelo contrário, a economia não é um jogo de soma zero.

    No Brasil, grande empresas adotaram Rails, como UOL, Locaweb, Globo.com e agora a ThoughtWorks. Também muitas startups estão surgindo e utilizando Rails para ter vantagens competitivas e criar aplicações com qualidade e produtividade. Em Porto Alegre, já estamos organizando um grupo de startups ágeis para cooperar em negócios e trocar know how. (X) No dia 21, realizamos o RS on Rails, que contou com quase 200 participantes e foi um grande sucesso. Em Outubro, em SP, ocorre a Rails Conf LA. Como você pode ver, Rails está maduro e pronto para ser utilizado. As empresas que usam Rails são, via de regra, ótimos lugares para se trabalhar. Levando tudo isto em consideração... não está na hora de você começar a estudar Rails?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,647
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
37
Comments
2
Likes
3
Embeds 0
No embeds

No notes for slide




















  • Transcript of "Rails3"

    1. 1. O Rails 3 vem aí Entendendo o Ruby on Rails
    2. 2. Juan Maiz maiz@softa.com.br - @joaomilho
    3. 3. Rails não escala?
    4. 4. Perl my $language
    5. 5. C not for kids
    6. 6. not exp log srand xor s qq qx xor s x x length uc ord and print chr ord for qw q join use sub tied qx xor eval xor print qq q q xor int eval lc q m cos and print chr ord for qw y abs ne open tied hex exp ref y m xor scalar srand print qq q q xor int eval lc qq y sqrt cos and print chr ord for qw x printf each return local x y or print qq s s and eval q s undef or oct xor time xor ref print chr int ord lc foreach qw y hex alarm chdir kill exec return y s gt sin sort split Just Another perl hacker
    7. 7. Ruby a programmer’s best friend
    8. 8. Ruby not in english
    9. 9. Pickaxe updated
    10. 10. Design Patterns revolução em OO
    11. 11. Agile manifesto
    12. 12. <project name="MyProject" default="dist" basedir="."> <description> simple example build file </description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <property name="dist" location="dist"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" description="generate the distribution" > <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean" description="clean up" > <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target> </project> Java simple...?
    13. 13. Ricardo Semler Maverick!
    14. 14. 37signals Getting Real & Rework
    15. 15. Ruby elegância
    16. 16. Rails3 Lotsa stuff
    17. 17. Ruby evolved
    18. 18. Sites github
    19. 19. RS on rails
    20. 20. Obrigado perguntas?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×