Encontrei, há alguns meses, uma forma bacana de gerenciar documentos MongoDB, trata-se do Genghisapp. Ele serve uma pequena web app de admin, rodando local ou integrando com Rails, e pode acessar bancos remotos.
Minha aplicação dele, além de administrar meu banco mongo local, é acessar um banco de uma aplicação hospedada no Heroku com o addon MongoLab. Realmente fácil.
Tenho dedicado um tempo, nas minhas horas vagas, em tentar aprender NodeJS, e desse estudo surgiu o Foster, outra aplicação simples que compartilha links com um tipo de curadoria voltado para área de desenvolvimento. A ideia foi totalmente inspirada no Hacker News, mas com um porém, a saber, não necessitar obrigatoriamente de autenticação.
Ainda que simples, implementar o Foster me permitiu estudar e aplicar, além do Node e Express, outros vários recursos, como por exemplo, Backbone, Mongo com Mongoose, Socket.IO, SSE do HTML5, SugarJS, Heroku Scheduler, e outras coisas que acabaram não entrando, como o GruntJS. Agora o plano é fazer um redesign, mas também sem muita pressa e começar a estudar Titanium seguindo a mesma ideia.
É isso, tem um outro post sobre o Foster no Blog do Sorta. Try Foster! Sigam o @FosterTrends no Twitter ou assine o RSS.
Duas ferramentas que eu conheci durante os estudos:
Genghis: Um view de admin para MongoDB.
Nodefly: Monitora aplicações Node.
Té mais!
Uma coletânea de links com posts sobre o Ruby 2.0:
[Tradução] Ruby 2.0 Por Exemplos
Inspecting Rails 4 Using Ruby 2.0
O desenvolvedor geralmente é um cara preguiçoso, mas isso nem sempre é algo ruim. Costumamos automatizar soluções para os nosso próprios problemas criando ferramentas verdadeiramente fantásticas.
Pelo mesmo motivo (preguiça), e claro, sabiamente tentando não reinventar a roda, nos valemos de 'plugins' que oferecem recursos poderosos prontos. Genial. O problema: frequentemente acontece que precisamos de uma funcionalidade específica e para isso utilizamos alguma ferramenta que vai muito além do que, de fato, precisamos, cheios de bruxarias e malabarismos.
Meu foco a partir daqui são aplicações Rails.
O Rails sozinho oferece vários recursos que nem sempre precisamos ou que sequer sabemos que existem. Aliado a isso, nosso Gemfile está cheia daquelas gems com +100 features, mas que na real, você só precisa e usa uma ou duas. Estes recursos não utilizados dentro da aplicação, não passam de lixo ou gordura.
Muitas vezes abusar das gems adiciona uma camada de complexidade que não queremos. No final do seu projeto você vai se sentir como se estivesse em um jogo de Jenga.
Além de trazer uma camada de complexidade, ainda causa uma dependência indesejável. Pense assim: um projeto fica orfão cada vez que uma gem fica depreciada. Cada vez que um projeto fica orfão, morre um koala na Austrália.
Desenvolvedores, além de preguiçosos, conseguem ser extremamente vaidosos com seu código. Exitem gems com finalidade meramente estética. Esse senso de estética do programador também pode comprometer a performace da aplicação. Bonitinho, mas gagueja na resposta.
Não sabemos mais escrever métodos?
Parece exagerado, mas é para gerar reflexão. O que estamos tentando ganhar em tempo, podemos está perdendo em desempenho. Considere se você consegue algum ganho de performance escrevendo suas próprias bibliotecas, em alguns casos. Adicionar uma linha ao Gemfile para resolver um problema de simples resolução, ainda que rico em calorias, é tentador. Sem dúvida, rápido, objetivo ou não.
Aqui vale ponderar sobre a necessidade de plugar uma gem a mais na sua aplicação. Quando é meramente estética, ou quando decidimos com a pressão do prazo estourando, ou estamos com pura e violenta preguiça? Acrescente o fato de que você pode estar perdendo uma puta oportunidade de conhecer e praticar mais sobre vários conceitos bacanas. O quão é relevante manter um regime on rails?
Code Climate é uma ferramenta de análise de código ruby que ajuda a melhorar a qualidade do nosso código. Ele identifica métodos longos e complexos, classes com alto nível de complexidade e blocos duplicados e chama isso de 'Smells'.
Cada projeto no Code Climate recebe uma pontuação média ponderada (GPA) que vai de 0 a 4.0 e aplica uma pontuação e classificação a sua classe que vai de A a F.
O Code Climate utiliza a gema de métricas Flog, uma variante da métrica ABC. A métrica ABC (Atribuições, Branchs e Condições) calcula o número de atribuições, ramificações sem escopo e condições de um trecho de código, ou seja, apenas diz - 'Escreva métodos menores, essa condicional pode ser melhorada? Tente ser mais preciso, e menos verboso no seu código'.
Além de medir complexidade, o Code Climate procura por duplicações e trechos de códigos semelhantes, se baseando no Flay. E medidas de churn e gráficos. Just DRY!
Todos esses trechos de códigos complexos indicam que talvez seu código precise ser refatorado. Mas, claro, aqui vale o julgamento do desenvolvedor. Eu tenho uma disputa bem bacana com o Code Climate para melhorar meu código a cada commit. Somos desenvolvedores tentando fazer um bom código, certo? Podemos nos valer dessas ferramentas na tentativa de fazê-lo bem. Além de tudo, Code Climate é bonitão e ajuda na integração contínua. Uma ferramenta para ser ouvida.
O Code Climate apenas aceita projetos do Github e é free para open source. Plug and Play.
pluck :column_name
Do Active Record, pluck cria uma query direta para uma coluna específica e retorna um array com o resultado. Beauty, han!?
Person.pluck(:id) # SELECT people.id FROM people
Person.uniq.pluck(:role) # SELECT DISTINCT role FROM people
Person.where(:confirmed => true).limit(5).pluck(:id)
Um amigo designer não-web me perguntou sobre o trabalho de um web designer. Eu não sou uma pessoa didática mas tentei explicar de forma simples e objetiva. O que segue é uma transcrição adaptada do email que mandei para ele.
Eu já havia explicado as diferenças entre um web designer e um desenvolvedor, mas novamente:
constrói a estrutura, layout e designer de uma aplicação web ou mobile. O web designer comporta...
UI Designer (User Interface Designer): o cara que cria o desenho de elementos de web designer, como um botão, uma barra de menu, uma caixa de texto, etc, usando ferramentas como o photoshop e o illustrator. O UI Designer tem um trabalho meramente estético.
UX Designer (User Experience Designer): o maluco que sabe montar tudo que o UI fez de forma a ficar intuitivo para o usuário. A gente chama isso de usabilidade.
De fato, um complementa o trabalho do outro, então geralmente é trabalho de um só cara.
escreve o código por trás que fazem a aplicação de fato funcionar.
O Front-End: a gente chama de front (ou interface) o que o usuário vê na tela. Esse cara transforma o trabalho do web designer em código HTML, CSS e manja muito de Javascript.
Algumas definições de web designer entende que você precisa saber algo de front-end, mas eu acredito que as duas não necessariamente se misturam, apenas se confundem.
O Back-end: o código que o usuário não sabe que existe mas que faz tudo funcionar magicamente.
Não sou web designer de fato, mas adoro o tema. Selecionei dos meus feeds alguns poucos e bons conteúdo que eu acompanho sobre o tema: Smashing Magazine, Dribbble, UI Parade, Abduzeedo, Codrops, WDL, PixelsDaily, UltraUI, Inspiredology, UIDetails
Um bom web designer deve estar por dentro de novas tendências de designer para web, conhecer vários elementos que permitam ao usuário uma boa experiência e navegação por toda a aplicação. Isso é o básico. O design de Interfaces Mobile é um plus mais que desejável.
serialize(attr_name, class_name = Object)
"Se você tem um atributo que precisa ser salvo no banco como um objeto, especifique o nome do atributo usando o método serialize para fazê-lo automaticamente. A serialização é feita através de YAML"
class User < ActiveRecord::Base
serialize :preferences
end
class_name é opcional.
Turbolinks é um nome sugestivo, novidade que será integrado ao Rails 4, não vou explicar a p* toda.
Ele faz a requisição de forma assíncrona e carrega o conteúdo apenas do corpo (body), ao invés da página inteira, e isso tudo sem jQuery ou nada além que poucas linhas de js.
Uma vez na sua aplicação todos os links irão seguir o comportamento do Turbolinks por padrão. Para 'desabilitá-lo' do link basta adicionar um atributo chamado de data-no-turbolink setado para true à sua âncora.
Ele usa um recurso chamado pushState para alterar a URL e simular um click normal e tem outros recursos interessantes como eventos de página.
Isso me lembrou o velho PrototypeHelper do rails 2.3, o update_html, remote_function, aqueles page.call, page.insert_html, uma seboseira, mas escutei muito choro de dev.
Pro do Turbolinks: carregar conteúdo duas a três vezes mais rápido. Contra: o navegador precisa dar suporte ao recurso.
Métodos obscuros...
record.toggle :boolean_attribute
troca chave true/false de um campo booleano api
record.clone
cria um novo registro de com os mesmos valores do objeto clonado #damn! api
record.touch
atualiza o campo update_at/on com a data/hora atual api
record.reload
atualiza os campos de acordo com o banco api