Primeiras impressões 2 - vindo do php

Dessa vez deve ser curtinho... Continuando a relatar minha experiência com Ruby on Rails, e novamente companando com Php, não para desmerecer a linguagem, mas porque é foi o parâmetro que eu tive para comparar, quem vai de outra linguagem certamente comparará com a que usava anteriormente. Uma diferença muito grande é que no Php toda manipulação de dados primitivo é feita de maneira procedural, ou seja, por funções globais, e não por métodos encapsulados. Eu me senti mais confortável trabalhando com métodos, e principalmente com as convençôes do ruby que indicam se o método é destrutivo (possui !(bang) no final do nome) ou não, ou então pode possuir ? no final, o que significa que o método faz uma checagem e retorna true ou false. Estes caracteres serem aceitos nos nomes de funções já é uma surpresa...Alguma outra linguagem tem isso ? Nunca vi. checando se a array users está em vazia

users = ["Zamba","Bicudo", "Igonium","Zamba"]
users.empty?

# false

Uso de bang: No primeiro exemplo se trata de um método destrutivo, no caso ele remove as duplicidades na array, ele não apenas retornou uma cópia da array sem duplicidades, mas a alterou

users.uniq!

#["Zamba","Bicudo", "Igonium"]

users

#["Zamba","Bicudo", "Igonium"]

Já aqui, re retornada uma cópia da array sem duplicidades, porem o objeto original, continua inalterado

new_users = users.uniq

#["Zamba","Bicudo", "Igonium"]

users

["Zamba","Bicudo", "Igonium", "Zamba"]

Bom,só de você, caro desenvolvedor não ter que catar no documentação para saber se a função é destrutiva ou não, ou então ter as 2 opções a disposição, o que em certas linguagens não se tem, obrigando a fazer como no exemplo 3 já é uma grande mão na roda. Além de tudo os métodos destrutivos são mais rápidos e consomem menos recursos, então é legal ter esta opção. Os métodos de checagem por outro lado deixam o código mais humano, legível até para quem não entende: Exemplo básico, chegando se uma array está vazia o que é mais legível?

users.length == 0

# false

ou

users.empty?

# false

Me parece claro que a segunda opção é mais clara. Agora imagine que existe um método na array chamado "empty!" (ATENÇÃO: este método não existe na array do ruby ! É só um exemplo) Por dedução , o que imagina que ele faz ? Se você disse que ele esvaziou a array, você está certo !

users.empty!

# []

Esse tipo de convenção é muito legal, uma idéia muito simples mas que facilita bastante as coisas. Uma pena que a classe array não tenha este método não acham ? Mas será que dá para alterar isso ? Sim você pode, e sem ter que criar uma outra class de array estendinda: em php teria que ser assim:

class SuperArray extends ArrayObject {
public function is_empty(){

//código aqui

}
}

no Ruby basta redeclarar a classe apenas adicionando o

class Array{
def empty!

//código aqui

end
}

Note que no exemplo em Php, alterei o nome do método desejado para expressar um questionamento "é vazia ?", enquanto que no Ruby foi criada mais um membro de uma famínia de métodos semelhantes, cujo escopo é o mesmo, temos empty? e empty! agora, e poderíamos ter empty também Chamamos isso de classes abertas, uma maneira de estender as funcionalidades sem o uso de heranças. Deixando claro aqui que isso é uma possibilidade, não uma regra. Neste caso específico eu acho que usar herança é como usar um canhão para matar um mosquito, alguns pensam se outra forma, mais rígida ao meu ver e acham que a extensão da classe deixa claro que aquela não é mais uma array "nativa". Ao meu ver o uso de Herança se é mais interessante quando múltiplas classes irão herdar, não apenas uma. E vocês o que acham sobre isso ?

Primeiras impressões 1 - vindo do php

Uma coisa bem diferente para quem vem de Php para outras linguagens em geral, e talvez essa experiência seja única para quem vem Php,  é que o indivíduo de depara com uma linguagem que não funciona na web. Opa! Como assim ?
É, pois é Php nasceu para construção de sites, isso na minha opinião é sua maior força e sua maior fraqueza, dependendo da necessidade.
Deixa eu explicar para quem não veio de Php. A grosso modo, um site em Php pode (pode) ser simplesmente um arquivo html, com códigos php entre tags "<?php ?>" (ele só funciona entre estas tags) mas a com extensão alterada para .php para assim o servidor devidamente configurado encaminhar para o interpretador rodar este arquivo e devolver a resposta que costuma ser um html. Para o pessoal do Rails, imaginem-se fazendo um site com os arquivos .erb e colocar toda a lógica alí.
Os erros do php são formatados para web, com tags html, isso é um indício da finalidade para qual a linguagem foi criada, uma vez rodando em linha de comando vi que quando os erros estouravam mostram tags html.
Outro ponto é que nem todo erro é "fatal" , interrompendo o restante do script , eu não sei se tem alguma configuração de erros que trate tudo como "fatal", as configurações de erro que eu usava era "ativada" e "desativada".
É uma linguagem ótima para web designers (designers que atuam na web), tem coisas muito legais fora uma imensidão de pacotes pré-configurados com apache +php +mysql como Xampp e EasePhp. Onde é só instalar e começar a brincar. Fora vários sistemas opensSources com possibilidade de costumização de templates, destaco o fodastico Wordpress.

Falei pra caramba de Php para explicar o que é diferente no ruby.
Com ruby "puro", um simples arquivo .rb não se faz um site...não de uma maneira legível, vendo o html bonitinho, isso é uma desvantagem se por exemplo você quiser fazer uma hotsite de uma ou 2 páginas com um simples formulário (pra complicar um pouquinho), um concurso cultural ! Com php se faz isso muito rápido, sem uso de extensões (gems , serivores de aplicação etc), pois como disse, ele nasceu para isso. Basta 2 arquivos com extensão .php
O costume é usar Ruby com frameworks que o "portam" para web, Rails, Sinatra etc. E esses frameworks são estruturados, grandes estruturas. ..muitos arquivos.

"Porra, mas então eu só vai valer a pena usar isso em grandes projetos !"  

Não! por causa dos scaffolds e generators ! Comandos no terminal que criam as estruturas básicas do seu site. Isso foi uma coisa que eu demorei a pegar, uma dificuldade. Nunca havia trabalhado com terminal e é obvio que leva um tempo para se acostumar, tem gente que não se acostuma...rs mas não foi o meu caso.
No caso do site descrito acima , em Rails(Ruby) bastaria escrever no terminal:

rails g scaffold Participation name:string email:string response:string

Com este comando você, definiu uma tabela com 3 campos e todos os links e páginas usadas para sua manipulação , o famoso CRUD. Mas essa tabela ainda não existe no banco de dados...você vai ter que ir lá criar os campos, definir os tamanhos, os tipos certo ? Errado, dessa forma não. Basta executar:

rake db:migrate

Estes comandos é claro não vão gerar o seu site pronto como você imagina, mas o funcionamento dele e num layoutzinho padrão dele meia boca. É gerado todas as páginas necessárias para o CRUDi (create, retrieve, update, delete) + list (index)...
Bem, isso foi um pouco a mais do que se previa, onde era esperado apenas um formulário + resposta. Não tem importância, você pode editar retirando o que não deseja, ou pode deixar ali mesmo, mas inacessíveis (tirando as rotas).
Mas vamos lá, depois que este concurso acabar você ou alguém vai precisar ver as respostas, e não seria legal exportar isso num excel quando se pode ver alí mesmo na página as respostas., ainda moderar. A intenção era algo simples, mas se com o mesmo trabalho, ou menos se conseguiu mais, porque não deixar como está ?
Na terminologia usada pelo rails "new" e "create" , seriam as páginas públicas. Enquanto, index(listagem) , "edit","update" e "destroy" seriam as páginas dos administradores.
Esta restrição pode ser feita com uma autenticação bunda com o password no próprio código do ruby, lixão mesmo, para não ter que criar outra tabelas neste exemplo...vamos simplificar agora.

Obs.: A solução acima não é a melhor prática no que se refere a segurança e tal blá blá blá, o ministério https adverte, não digam que eu dei esse exemplo.
Enfim, talvez seja difícil entender como algo mais complexo pode te dar menos trabalho, esse paradoxo é resolvido pelas ferramentas que o rails traz consigo. Se tem mais arquivos, mais estruturado e certamente eu não optaria em fazer o projeto do exemplo que é bem simples em rails sem estas ferramentas , que eu pretendo me aprofundar nas próximas publicações.  Quero deixar claro que estou me referindo nesto ponto ao RAILS, rails é o framework, ruby a linguagem.
Em php o que mais o framework que vi mais se aproximar CakePHP, e mesmo assim ainda falta um bocado, parece que ele usa um scaffold sem linha de comando é esquisito,  parei de procurar também.

E vocês, o que você acham ?

Rails e Eu

Há muito tempo já havia conhecido o conceito de MVC mas sem experiência não entendia muito o porquê de ter que se criar por exemplo 3 arquivos em pastas convencionalmente separadas para um fazer uma webpage.
Meu primeiro contato foi no PHP com um Cake ou algum outro framework MCV dos mais completos em PHP. Tive dificuldade para entender o ORM devido ao nível de conhecimento que tinha e também em usar o scaffold deste framework, talvez por ser no dos do windows ou talvez por ser na linha de comando do PHP, que diferente do Ruby, não é uma linguagem muito independente da web, eu não me adaptei de início e voltei a fazer sites sem ajuda de frameworks, usando minha própria organização, certa fez tentei fazer um MVC, mimetizando o comportamento que vi  nos que tentava usar mas deu tanto trabalho que putz...Bom, achei melhor voltar a fazer sem, hoje trabalhando com Rails eu vejo porque não deu certo, um dos motivos que vejo é que sem um scaffold (incluo aí os generators) e sem o ORM o MVC se torna muuuito trabalhoso . Não que eu fosse fazer um MVC fodão, mas que minimamente funcionasse (e até funcionou ) e por convenções encontrasse seus caminhos internos.

Continuei com PHP , principalmente com Wordpress, que na minha opinião é o melhor openSource para blog que existe, sempre se atualizando com comunidade ativa é um sistema do caralho onde se pode customizar e estender para praticamente tudo e roda em praticamente qualquer ambiente, bastando ter php e mysql (o que qualquer servidor bunda tem, até gratuíto).

Minha primeira formação é de Desenho Industrial, e é uma formação onde não é muito espaço para teorias bonitas que não funcionam na prática, ou a coisa funciona ou não funciona, ou agrada ou desagrada, de nada adiante uma incrível teoria se na prática ela não satisfaz e minha segunda incompleta e trancada é Eng. Mecânica, que eu espero continuar...


Comecei como web designer no meu atual trabalho (ia falar emprego, mas não gosto desta palavra), justamente com Wordpress, que é usado para diversos blogs da empresa, inclusive parte da intranet. Onde fiz algumas coisas interessantes (eu acho) como migração de dados do antigo sistema de conteúdo prórprio para o Wordpress e a criação de tipos de conteúdos personalizados integrados ao sistema, como "ramal".
Surgiu a oportunidade de desenvolver aplicativos para concursos culturais no Facebook (antes da lei brasileira querer se meter nisso), e eu assumi o desafio, foi muita dor de cabeça entender a API mal documentada do SDK deles, muita informação desencontrada, constantes mudanças (uma vez aconteceu de eu publicar o app e no dia seguinte expirar o certificado da SDK, shit! , e até entender que o erro não foi seu), bugs relatados sem resposta, era difícil encontrar a informação correta...e com outras questões que antes de entrar na empresa não me preocupavam como retrocompatibilidade para navagadores muito antigos (IE6 etc). E aí eu fui fazendo...
Neste período, em um dos últimos projetos acho que cheguei a usar codeIgniter, um MVC bem simplificado em PHP, e estava até gostando, até conhecer o Rails.
Quando surgiu uma oportunidade na equipe de desenvolvimento, perguntaram se eu tinha interesse, eu é claro que eu falei que sim.
E foi assim que eu conheci o Rails.

No próximo post falarei das minhas primeiras impressões, a maioria positivas, algumas dificuldades etc.
Até lá !