Um dos pontos fortes do Ruby on Rails é que abstrai o acesso de dados de distância para que você não precisa se preocupar com SQL ao escrever o seu pedido. Infelizmente, este banco de dados de acessos esconde desenvolvedores, o que pode levar a sérios problemas de performance. A solução para este problema não é mais distante, então o Rails log.

Considere esta simples aplicação Mixx-ish, que exibe uma lista de histórias:

O controlador:
@stories = Story.find(:all, :conditions => "some condition")

O ponto de vista:
<ul>
<% @stories.each do |s| %>
<li>"<%= s.title %>" by <%= s.submitter.display_name %>
with <%= s.comments.count %> comments
</li>
<% end %>
</ul>
(Eu deveria notar que Jason e Doug criar marcação muito melhor do que isso. Isto é o que você começa quando um cara me backend como escreve o código para o propósito de demonstrar alguma coisa - que não usaria nada deste feio em Mixx código de produção).

Parece bastante razoável, certo? Mas como o número de histórias sobre a lista cresce, rapidamente se torna mau desempenho. Vamos descobrir o porquê.

Primeiro exemplo de saída de uma execução deste código:

• "Obama vence!" Por joe com 3 comentários
• "Tempestades de raiva em todos os lugares", de Julie com 0 comentários
• "Mixx lança" de Chris com 3 comentários
• "A criação de Berinjela", de Chris com 1 comentários

Em seguida, dê uma olhada no log do Rails quando esta lista é gerada. Isto pode ser encontrado no diretório do aplicativo em logs / development.log:
Story Load (0.000911) SELECT stories.* FROM stories
Rendering stories/show
User Load (0.000601) SELECT * FROM `users` WHERE (`users`.`id` = 176)
Comment Load (0.000391) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 545)
User Load (0.000441) SELECT * FROM `users` WHERE (`users`.`id` = 188)
Comment Load (0.000364) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 99)
User Load (0.000424) SELECT * FROM `users` WHERE (`users`.id' = 6)
Comment Load (0.000358) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 85)
User Load (0.000408) SELECT * FROM `users` WHERE (`users`.`id` = 6)
Comment Load (0.000269) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 18)
A primeira linha é razoável - que está apenas começando a lista de histórias. Mas veja o que acontece quando tornar a ver: para cada história exibida, há duas consultas enviadas ao banco de dados. Não é de admirar que gerar uma longa lista de histórias leva um longo tempo quando você está emitindo duas consultas para cada história.

Um rápido olhar para o código diz-nos o que está acontecendo: a expressão s.submitter.display_name "recebe o apresentador da história (que é o modelo de história como um atributo belongs_to) e extrai o display_name dele. Mas isso requer uma recuperação de banco de dados (consulta em relação a tabela de usuários). E a expressão "s.comments.count" requer a consulta na tabela de comentários.

Felizmente, há uma série de técnicas que podem ser usados para eliminar essas consultas extra. Estas incluem:

1. O uso do include ":" directiva ao buscar os dados. Por exemplo, alterar o código de controle acima, como segue:
@stories = Story.find(:all, :conditions => "some condition", :include => [:submitter])
e todas as consultas dos usuários da tabela acima são substituídas por uma única consulta com a tabela de usuários.

(Nota: era uma vez, o Rails pode ser ineficiente na sua aplicação dos: include directiva. Felizmente, este é fixado em Rails 2.0, então não há mais nenhuma razão para evitar: include).

2. Armazenar dados freqüentemente usados na tabela pai. Evidentemente, esta é uma violação dos princípios de normalização banco de dados. Com base nestes princípios, nunca queremos duplicar os dados no banco de dados. Mas em alguns casos, os ganhos de desempenho que começa a partir de desnormalização valem os potenciais problemas com com dados saem de sincronia. Especialmente quando os dados em questão não é crucial.

Neste caso, nós adicionamos um campo para a mesa comment_count histórias. Usamos ações after_create e before_destroy sobre o modelo de comentário para manter o campo comment_count atualizado - quando criamos um novo comentário, o incremento que o valor comment_count para seu pai história. (Nós fizemos uma decisão consciente que, embora pudesse ser espertos e conseguem manter comment_count precisa, nós podemos viver, se ele estiver incorreto de algumas histórias.) Depois disso, podemos usar o campo comment_count na história em vez de comments.count, assim evitando a consulta necessária para obter a contagem de comentários para uma história. A visualização resultante é a seguinte:
<ul>
<% @stories.each do |s| %>
<li><%= s.title %> by <%= s.submitter.display_name %>
with <%= s.comment_count %> comments
</li>
<% end %>
</ul>
Em conjunto com o controlador observar a mudança em # 1, o log de consulta agora parecido com este:
Story Load (0.006564) SELECT * FROM `stories` WHERE ( some condition )
User Load (0.000943) SELECT * FROM `users` WHERE (`users`.id IN ('127','193','6','249','216','239','91','240','196','37','93','176', '188','244','235','136'))
Rendering stories/show
O que costumava levar nove consultas (e poderia facilmente crescer mais que o número de histórias de aumento), agora leva dois.

3. Em alguns casos, você pode encontrar os dados que você precisa nos atributos do modelo. Se você pode evitar, assim, recuperar através de um relacionamento belongs_to ou has_X, em seguida, fazê-lo

Não é um exemplo disso no código de exemplo. Mas suponha que não queria mostrar o apresentador real de uma história no exemplo acima, mas nós queremos mostrar a história de forma diferente se for apresentado pela pessoa que vê a página. (No nosso caso, o modelo de utilização do visualizador da página é sempre contida pela variável de usuário @.) Podemos usar qualquer um dos métodos a seguir para fazer este teste:

if @user == story.submitter # bad! Requires database retrieval of submitter
if @user.id == story.submitter.id # bad! Also requires retrieval.
if @user.id == story.submitter_id # good! No retrieval required.
Mesmo se você usar o include: directiva para obter o apresentador, os dois primeiros métodos exigem, pelo menos, uma recuperação de dados para a página.

Outro caso comum envolve um teste para a existência de dados relacionados a um modelo por meio de um belongs_to. Por exemplo, suponha que queremos testar se uma história tem um apresentador a todos. Aqui estão duas maneiras de fazê-lo:

if story.submitter # bad - retrieves submitter if present
if story.submitter_id # good - no retrieval required
Em resumo, embora Rails permite que você acessa banco de dados abstrair, se você quiser que seu aplicativo para executar, você precisa estar ciente de como ele está usando o banco de dados. Um excelente método para ser consciente é rever o Rails log enquanto você estiver desenvolvendo o aplicativo, dando especial atenção aos casos de repetição de uma mesma consulta (como no exemplo acima, onde as consultas contra os usuários e repita comentários tabelas). Na verdade, você deve rever frequentemente os trilhos log sempre que você está construindo uma aplicação que tem um bom desempenho.

Através da história da internet, existem pontos de inflexão, onde uma tecnologia nova hits "as massas" e realmente decola. Quase universalmente, a linha comum em uma rápida expansão e adoção de uma tecnologia é um grande avanço, não de pura tecnologia, mas um avanço em design. Especificamente, um grande avanço na facilidade de uso.

Antes de o Google criou uma interface simples busca mortos, a maioria das pessoas navegando usado como método primário de navegação na web. Antes de mosaico feito visual simples navegação, a navegação feita através de Archie e Veronica eram a norma. A Apple fez consumir música online facilmente com o iTunes eo iPod. AOL fez "ficando on-line" fácil para a mamãe e papai. Mais recentemente, o YouTube tornou mais fácil a partilha de vídeo da Internet para cada escolar elevado no mundo.

A história da Internet está cheia de tecnologias que foram fabulosos, mas nunca se tornou mainstream. Na Mixx, nós estamos tão apaixonados com a idéia de OpenID que queremos fazer a nossa parte para fazer OpenID certeza não é relegada aos livros de história do "pode ter sido o capítulo".

Para aqueles novos ao OpenID, a idéia é simples. Depois de criar uma conta com um provedor de OpenID, você recebe um identificador único (uma URL personalizada) que você usa por sua vez, para login e cadastro em sites que suportam OpenID ("consumidores", como eles chamam). O objetivo do OpenID é duplo. Primeiro, você, caro usuário, pode criar o seu OpenID conta com um provedor de confiança e, por sua vez, alargar essa confiança para sites e serviços da sua escolha. Não mais que você precisa entregar um endereço de e-mail e uma senha para cada novo (potencialmente fly-by-noite) aplicação web que vem. Em segundo lugar, uma vez que normalmente têm um único OpenID, você não terá que tentar lembrar qual nome de usuário e senha que você usou no site ou site. Basta lembrar que você usou OpenID!

OpenID, desde a sua criação, tem feito grandes avanços em toda a web. Alguns dos maiores provedores de serviço lá fora (AOL, Yahoo, etc) tornaram-se provedores de OpenID, dando OpenIDs para milhões e milhões de pessoas. Todas as semanas, pelo menos uma lança site com OpenID apoio ou um site existente OpenID adiciona funcionalidade para o seu login ou processo de registro. O problema, como temos observado, é que enquanto o OpenID login e registo está a ser rapidamente adicionados aos sites, a sua apresentação não tem o projeto necessário para a mãe eo pai de agarrar o poder do OpenID.

Hoje, estamos orgulhosos de lançar nossos assumir OpenID registo e login. Se você balançar pela Login ou Registro páginas e você verá algo novo. Para Mixxers existentes, a tela de login será contextual para o seu actual método de login (ou nome de usuário e senha ou OpenID).

Para Mixxers novo, você pode se cadastrar com um AOL, Yahoo, Facebook ou conta. Standard registo OpenID também ainda está disponível. Se por algum golpe de sorte, você não tem uma conta com qualquer um dos serviços de terceiros atualmente suportadas, você ainda pode registrar seu endereço de e-mail. Enquanto o Facebook não é OpenID per-se, a AOL ea Yahoo! Registo e login utiliza OpenID debaixo das cobertas, sem pedir para seus usuários OpenID URL. No caso da AOL, pedimos o seu nome ou conta AOL AIM e baralhar-te para a página de login apropriado. Yahoo! Login e de registo é ainda mais simples clique no honkin grande "Registe-se com o seu ID Yahoo! Botão e nós cuidamos do resto.

Nós fomos um pouco mais longe e acrescentou um ótimo recurso para login: nós acompanhar o último método de login que você usa e redesign da página com base nisso. Então, se você usar Facebook para login, você será presenteado com um ícone Facebook grande e botão. Não há necessidade de caçar e clique com nossas opções de login!

A última peça do quebra-cabeça está a gerir as suas contas. Navegue até Configurações de Conta e clique no novo "Contas" guia. De lá, você pode adicionar ou remover o seu terceiro contas à vontade. Ao vincular suas contas diversas em toda a web à sua conta Mixx, você pode usar qualquer um desses métodos se logar para Mixx. Este é um grande primeiro passo em direção à meta da interoperabilidade entre Mixx e seus sites favoritos e aplicações.

Nós colocamos uma boa dose de trabalho para o novo registo e login experiência e esperamos que encontre as melhorias útil e, acima de tudo, fácil. Como sempre, nós apreciamos o seu feedback e estamos ansiosos para ouvir o que você tem a dizer!

~ Jason (eo resto da equipe Mixx)

Desde que entrei para a equipe Mixx (um ano e alguns trocos atrás) e começou a pôr em marcha o HTML, CSS e JavaScript que você vê e usa todos os dias, fiz questão de construir com recursos de acessibilidade em mente. Mixx tem uma grande variedade de usuários abrange todas as raças, cores, credos e capacidades. Foi (e permanece até hoje) muito importante para nós que nós fornecemos uma grande experiência para nossos usuários enquanto não deixar ninguém de fora no frio.

Como a maioria de vocês sabem, há uma tonelada de interatividade no Mixx voto, relatório, apresentação, interagindo com YourMixx-lista continua. Cada um desses elementos envolve uma interação diferente com a aplicação e cada um deles envolve a manipulação de conteúdo na tela usando uma combinação de JavaScript e CSS.

Em um esforço para acomodar os usuários (ou, mais diretamente, seu browser de escolha), que possui o JavaScript desativado, tomamos a abordagem de exibir todo o conteúdo por padrão e, em seguida, usando JavaScript para esconder os elementos adequados. A forma mais fácil de observar exemplo disto é nas páginas permalink. Com redux recente do permalinks , nós adicionamos alguns novos "guias" (por falta de um melhor descritor) abaixo as informações sobre a entrada e comentários de atividades, sobre este site, e afins.

Ao navegar para uma página permalink, dependendo de como sua conexão com a Internet zippy é, você pode notar que as três guias são expandidos e empilhados um sobre o outro no início. Após uma breve pausa, agarram vou embora e eles podem então ser acessadas clicando em seu respectivo botão. Esta é, na maioria de base, a situação acima descrita. carrega o conteúdo da página. JavaScript faz o seu trabalho e esconde as peças adequadas.

Em um mundo perfeito, isso iria acontecer instantaneamente, e ninguém notaria. No mundo real, as conexões de Internet são variáveis, soluço servidores web, e recursos externos (como o Google Analytics) tem o efeito colateral de perda de queima de scripts local. O último ponto não é o único motivo de preocupação para a nossa discussão. Steve Souders, em seu excelente livro High Performance Web Sites , entra em grandes detalhes sobre o porquê deste adiamento acontece. Confira o Capítulo 6 sobre "Problemas com Scripts."

Então o que fazemos? Vamos primeiro dar uma olhada em como Mixx trabalha atualmente.

Como temos observado, o nosso HTML e CSS tudo estilo na página e elementos de visualização por omissão. Depois que tudo estiver carregado, o JavaScript Mixx (usando jQuery , um assunto para outro post) usa $ (). ready () ao fogo fora de nossos eventos onload. Os bits adequado esconder e estamos a fazer. Isso é ótimo, tanto quanto as "melhores práticas" e todos os que estão em causa, mas menos do que excelente do ponto de vista perceptual.

Robert Nyman , em seu post Como esconder e mostrar o conteúdo inicial, dependendo do suporte a JavaScript está disponível , descreve uma técnica onde você adiciona um elemento <script> ao <head> do documento que chama uma função anônima que, por sua vez , adiciona um arquivo CSS para sua página. O ficheiro CSS contém uma linha única, com um selector (no seu caso, um seletor ID-based) que conta um elemento a não mostrar.

É uma solução brilhante, que supera o problema onload introduzido por activos remoto. A única alteração que eu faria com o seu exemplo é a utilização de uma classe-base ao invés de seletor ID-based. Dessa forma, você pode configurar uma única classe ("." Alt, por exemplo) e aplicá-la a todos os elementos que você deseja esconder.

Simples como isso, realmente. Robert nos oferece uma solução extensível a um problema que vem incomodando os desenvolvedores mais e mais. Então, por que, então, você pergunta, tem Mixx não implementado isso? "Time", em sua maioria. Nós somos uma pequena equipe aqui com uma lista enorme de coisas para fazer! Eu prometo-lhe, porém, que esta medida será aplicada enquanto temos tempo.

Você já encontrou outras soluções eficazes para este problema? Se assim for, deixe-nos uma nota nos comentários!

5 teclas para fazer o salto de designer visual para Web Designer

Então, primeiro vamos definir, (minhas definições quando se fala sobre a web)

Um designer visual: Alguém que desenha os gráficos que fazem o seu caminho para a web.

Um web designer: alguém que tem as habilidades de design visual, mas também sabe como escrever limpo, semântico, baseado em padrões de HTML / XHTML e CSS.

Este último compreende a tela que a tinta está acontecendo. O primeiro sabe como misturar a tinta.

1. Que tipo de aluno é você?
Meu maior erro da minha carreira, não estava respondendo a esta pergunta antes que eu tentei aprender o "outro lado" pela primeira vez. Eu teria sido escrito anos antes de marcação, se eu tivesse acabado de pegar o tipo certo de materiais. Black tipo em papel branco com um gráfico ocasional gráfico / foi o primeiro método de auto treinamento. tempo Big falhar. Se há alguma coisa que me assustou de novo em meu photoshop-buraco só.

Cinco anos depois eu peguei um livro de Jeffery Zeldman. Se você está lendo este blog, é provável que você já ouviu falar dela: " Designing with web standards ". Este livro salvou a minha carreira. O livro contou com o que poderia-online e, historicamente, deve ser feito. Ele abriu as portas que antes estavam fechados - Parreira, mortos e aparafusados Master fechado. A área-chave em que o livro me afetou mais é que levou o fator de "assustador" para fora da palavra "desenvolvimento". Em vez de começar o desenvolvimento na forma de projeto, design e semântica baseada em padrões se tornou a norma. O contexto histórico também desempenhou um papel fundamental. Ele me ajudou a entender o que era certo eo que era errado, e explicou como as limitações da tecnologia causou um monte de que o errado.

Olhando para trás, esse foi o jogador chave na obtenção de mim para a próxima etapa. Cada livro ou outro assessor de formação adquirido após este ter isso em mente. Que livro Zeldman trouxe-me que os outros não eram gráficos e cores. Ele falou a minha língua e transmitiu as respostas às perguntas que eu tinha.

2. Você tem certeza essa é a vida que você quer?
Algumas pessoas só se fixa não são capazes de fazer a troca. Eu nunca vou ser um programador back-end e estou bem com isso. Meu cérebro simplesmente não funciona desta maneira. Neste caso, não há nada de errado com só fazendo design visual. Para mim, foi o próximo passo lógico na direção que eu queria ir.

3. Quem você conhece? Porque vai ajudar.
Se a maioria dos livros não me, e as classes nunca chegou perto de entrega, foram as ligações que eu fiz na indústria que realmente me ajudou a superar o rebolado. Participar de conferências, sendo uma parte da cena local ou apenas enviar um e-mail aleatório para uma weblebrity "sempre trouxe mais retorno do que ler o livro ou qualquer classe atendida. Portanto, não tenha medo de chegar.

4. Você vai estragar tudo, é bom, mas certifique-se que as ferramentas certas quando você o faz.
Você vai cometer alguns erros, todos nós fazemos. Algo tão parvo como o fechamento de uma tag de parágrafo fará com que você deseja extrair o seu cabelo para fora. Acalme-se, certifique-se de ter as ferramentas necessárias para a tarefa e continuar a manter por diante.

Ferramentas recomendadas

1. Firefox - Obtenha a última versão
   * extensão Firebug para o Firefox
   * Web Developer Toolbar para o Firefox
2. Parallels - Obtenha a última versão
   * Gostemos ou não, o IE6 ainda é um dos navegadores mais utilizados por aí. Você utilizadores Mac terá que este teste.
3. Opera - Obtenha a última versão
   * Dragonfly - Semelhante ao Firebug, mas para o Opera (rumor é que eles chamaram porque tais libélulas comer incendiários)
4. html e CSS referência - HTML Dog
5. Um grande site de referência trazidos a nós por Dan Cedarholm

5. Verifique se você está se divertindo.

Faça o que você ama e você ama o que faz. Esses caras concordam:

"Escolha um trabalho que você ama, e você nunca terá que trabalhar um dia em sua vida." - Confúcio

"Eu nunca fiz um dia de trabalho na minha vida. Foi tudo divertido. "- Thomas A. Edison

A grande vantagem de ter gasto muito tempo em uma indústria é que você vê certos padrões se repetem ao longo do tempo. Um destes modelos teve um impacto importante sobre a nossa decisão de usar Ruby on Rails para Mixx.

Um dos meus primeiros empregos foi em uma empresa de defesa chamado Logicon. Logicon tinha uma série de contratos com várias agências de inteligência, muitos dos quais envolvidos notícias tratamento recebido via newswire, categorizando as histórias, e entregá-los para os analistas que tinham registado um interesse em um tópico específico. Assim, por exemplo, um analista especializado na Rússia poderia se inscrever para todas as histórias que mencionou Vladamir Putin, a Rússia ea Geórgia (mas não mencionou Atlanta).

Este software foi escrito para mainframes IBM na linguagem assembly IBM. Ela só poderia ser utilizado nesse ambiente, e não era adaptável a outros sistemas. Meu trabalho era levar a tecnologia, transformá-lo em um produto de prateleira, e pacote de ajuda para o uso por terceiros. A esperança era de que poderíamos vendê-lo para uma ampla gama de clientes, tanto dentro como fora do governo.

Um dos nossos grandes desafios foi antecipada para obter permissão para gravar o novo produto na linguagem de programação C. Nosso vice-presidente local Logicon, o cara que controlava a luz verde, havia sido um programador de linguagem de montagem, tendo trabalhado no sistema que nós éramos adaptação. Estava desconfiado de que poderíamos obter o desempenho necessário de C. (de alto desempenho foi o grande ponto de venda desse produto, que foi concebido para processar milhares de consultas em diversas histórias recebidas por segundo, um grande problema com o hardware de tempo.) Tinha pouca experiência com C mesmo, e assim ele precisava convencer.

Nós construímos um protótipo que revelou que, embora a implementação da linguagem C não foi tão rápido quanto a versão original montadora, era mais do que rápido o suficiente para o nosso mercado-alvo. Isso, combinado com as outras vantagens de C (maior portabilidade e produtividade do programador) , foi suficiente para convencê-lo a projetar o bem. E assim eu passei os próximos anos da vida do meu prédio e manutenção do Logicon Mensagem Dissemination System (LMDS), que acabou sendo usado por um número de agências do governo. E o que levou diretamente para mim ser contratado na AOL, que comprou dois LMDS e, eventualmente, me Logicon.

(Eu não tenho certeza se LMDS ainda está em uso na AOL. Mas foi a partir de um par de anos atrás, sendo usado como parte do sistema que classifica as notícias para a Fábrica de Alimentos AOL. Nada mau, para um pedaço de software que foi originalmente escrito há vinte anos.)

Esta foi a minha primeira vez enfrentando o debate entre uma linguagem antiga e estabelecida uma nova linguagem que, embora não tão eficiente em termos de velocidade do processador, foi muito mais eficiente em matéria de tempo de um programador.

Avancemos dez anos. C foi firmemente enraizada na AOL, como I. Mas uma nova linguagem foi ganhando destaque - Java. E o argumento surgiu: AOL deve tornar o Java a linguagem de escolha para as novas aplicações?

Java tinha um monte de vantagens em relação a C. É uma linguagem muito fácil de usar, e não é vulnerável a alguns bugs realmente dolorosa que você pode criar em C. (uma vez eu vi um projeto C de uma dúzia de pessoas adiada por um semana devido a uma equivocada ponto-evírgula.) Tudo isto se traduz em maior produtividade do programador.

Mas Java nunca vai ser tão eficiente quanto o C em termos de recursos da máquina. Algumas das características que fazem Java seguro também custa ciclos de processador. Isso é independente dos compiladores envolvidos: mesmo com o melhor compilador no mundo, um programa Java não vai realizar-se de um programa C equivalente.

Tomemos um exemplo: checagem de limites. No C, você pode criar um conjunto de dez itens, e depois feliz pedir para acessar o item XI. C permite isso - o princípio norteador do C é que o programador sabe o que está fazendo, assim mesmo que pareça estúpido, basta fazer o que o programador diz que, caramba! Isso pode causar todos os tipos de efeitos desagradáveis em C. (O atraso de uma semana que eu mencionei acima apenas como resultado de um erro).

Mas sempre que você acessar um elemento da matriz em Java, Java verifica que não está saindo dos limites. Uma tentativa de acessar o décimo primeiro item de um conjunto de dez itens, resultará em um erro de Java que aponta exatamente onde você errou. O bug será encontrada numa questão de minutos, não dias.

Isso economiza muito tempo do programador. Mas fazer essas verificações matriz limites de tempo do processador despesas - cada vez que você acessar um elemento da matriz em Java, tem que verificar que o acesso está na quadra. Tempo de processamento, foi sacrificado por tempo de um programador.

AOL correu alguns benchmarks e descobriu que um programa Java levaria cerca de duas vezes por muito tempo da CPU para executar como o programa C equivalente. Mas, sobretudo tendo em conta que o fator limitante no desempenho geral foi de I / O e não do CPU, e tendo em conta que o tempo do programador tinha ficado mais caro, enquanto o tempo de CPU foi constantemente ficando mais barato, esse foi um bom trade-off. E assim AOL adotou a política que o empreendimento, a menos que houvesse uma boa razão para fazer o contrário, deve ser feito em Java.

Agora chegamos ao presente, o momento inevitável quando há um novo garoto sobre o bloco, uma nova linguagem que é um desafio Java. É mais fácil desenvolver uma aplicação web em Ruby on Rails do que em Java. Sim, Ruby não é tão tempo eficiente em termos de tempo de processamento, mas é muito mais eficiente em termos de tempo de um programador. E a transformação não é o fator limitante na maioria dos aplicativos de qualquer maneira.

Em outras palavras, é exatamente o mesmo argumento que tínhamos dez anos atrás, quando decidir ficar com C ou passar para Java. Que por sua vez, era exatamente o mesmo argumento que tínhamos dez anos antes que, para decidir se quer permanecer com assembler ou passar a C. É um argumento que se resume à questão do que o fator limitante no desenvolvimento é: CPU tempo ou tempo de um programador. E na maioria das aplicações, a resposta vai ser tempo de um programador.

(Falando como programador, posso apenas dizer que estou muito feliz que os programadores são mais caros do CPU's. Espero que isso continue no futuro distante, com CPU's ficando mais baratos, enquanto os programadores ficar mais caro!)

Claramente, há outros fatores envolvidos. Não devemos mergulhar na nova tecnologia só porque é novo. E pode provar que Ruby on Rails não é a onda do futuro, da mesma forma que C e Java era uma vez.

Mas é interessante ver que os mesmos argumentos antigos detidos mais e mais, e é instrutivo, quando conta estes argumentos, para lembrar como acabou a última vez.

Eu aprendi uma lição valiosa nesta manhã, e eu pensei que eu iria partilhá-la com você. Para lidar com situações de erro, Ruby inclui, como fazem outras línguas, a manipulação de exceção. Isso permite que você coloque todo o seu código que pode gerar um ou mais erros em um bloco, e lidar com quaisquer erros que ocorrem em outro bloco. De longe preferível aos dias de idade, quando nós tivemos que verificar o valor de retorno de qualquer chamada que pode gerar um erro, e lidar com ele no local, cada um na forma original. A manipulação de exceção é muito mais limpo e mais gerenciáveis:

begin
# Do stuff that may fail here
rescue
# Deal with those failures here
end

A maioria dos artigos que tratam de manipulação de exceção Ruby irá dizer-lhe que o caminho para capturar exceções é com o "resgate" de linha. Mas ao que parece, isso é apenas parte da verdade. Um exemplo feito em Ruby IRB console:

irb(main):001:0> begin
irb(main):002:1* raise "Haha, you missed me!"
irb(main):003:1> rescue
irb(main):004:1> puts "No I didn't!"
irb(main):005:1> end
No I didn't!

Até aí tudo bem. Mas agora preste atenção a este:

irb(main):006:0> begin
irb(main):007:1* raise Exception.new("Haha, you missed me!")
irb(main):008:1> rescue
irb(main):009:1> puts "No I didn't!"
irb(main):010:1> end
(irb):7:in `irb_binding': Haha, you missed me! (Exception)

Woops! Nesse caso, o resgate realmente falta. Mas por quê? Não "resgatar" tudo salvamento significa? Fiquei surpreso ao descobrir que ele não faz. Mais um exemplo deve esclarecer as coisas:

irb(main):016:0> begin
irb(main):017:1* raise "Better luck next time!"
irb(main):018:1> rescue => e
irb(main):019:1> puts("I caught a " + e.class.to_s)
irb(main):020:1> end
I caught a RuntimeError
=> nil
irb(main):021:0> begin
irb(main):022:1* raise StandardError.new("Better luck next time!")
irb(main):023:1> rescue => e
irb(main):024:1> puts("I caught a " + e.class.to_s)
irb(main):025:1> end
I caught a StandardError
=> nil
irb(main):026:0> begin
irb(main):027:1* raise Exception.new("Better luck next time!")
irb(main):028:1> rescue => e
irb(main):029:1> puts("I caught a " + e.class.to_s)
irb(main):030:1> end
(irb):27:in `irb_binding': Better luck next time! (Exception)

Ah-ha! Assim, enquanto parece que "resgate" seria a forma mais genérica de lidar com as exceções de qualquer tipo, ele realmente não é. Ele vai pegar StandardError (dos quais RuntimeError é uma subclasse), mas perde Exception. O manipulador de exceção mais genérica se transforma em "Exceção de emergência":

begin
# Do stuff here
rescue Exception
# I will catch everything, even stuff that "rescue" misses
end

Lição aprendida: se você não sabe a única coisa que você pode ter que enfrentar é StandardError ou uma de suas subclasses, é melhor usar "Exceção de emergência" que apenas "resgate". Nevermind documentos que sugerem que o "resgate" das capturas excepções, isto é verdade, mas enganosa - é realmente apenas capturas determinados tipos delas.

Mixx é construído usando o Ruby on Rails quadro. (Trilhos é o quadro. Ruby é a linguagem.) Se você prestar muita atenção ao mundo da Internet tecnologia, esta é susceptível de levantar uma grande questão: não significa que os problemas de escala?

Infelizmente, o Twitter está com vários problemas de escala e confiabilidade ter jogado um monte de FUD em torno de Rails. Afinal, o Twitter é a mais conhecida em grande escala aplicação Rails na web, e tem inegavelmente teve problemas com ambas escala e estabilidade. (Apesar de ter trabalhado com os engenheiros excelente que o Twitter acaba de adquirir com a compra do Summize , sinto-me confiante de que seus problemas serão em breve uma coisa do passado.) Um meme comum é que os problemas do Twitter são devidos a Rails, e que, portanto, É impossível construir um aplicativo estável e escalável usando Rails.

Desde que eu sou o cara que escolheu usar Rails para Mixx, eu obviamente discordo. Deixe-me dizer-lhe porquê.

(Nas notas que se seguem, vou falar sobre o desempenho ea escalabilidade. Percebo que estes não são os mesmos. No entanto, eles estão intimamente relacionados, e não há FUD relacionados tanto ao redor dos trilhos, por isso acho que vale a pena cobri-los tanto nesta discussão).

1. 80-90% do tempo de resposta do usuário final não tem nada a ver com alguma coisa no servidor - está no desenho e implementação da página.

   Este é o resultado de um estudo feito pelo Yahoo!, Como relatado em excelente Steve Souders High Performance Web Sites (que eu recomendo - deve haver uma cópia deste livro em qualquer loja de desenvolvimento web). A maior parte do desempenho está ligada a questões como a definição de cabeçalhos de cache corretas sobre as imagens, reduzindo o número de objetos na página, design e bom de marcação, CSS e JavaScript. Se você quiser suas páginas para carregamento rápido, olhe para a sua marcação. (Esta é uma das muitas razões que a primeira pessoa que contratou quando cheguei a bordo foi Jason Garber, arquiteto Mixx da interface do usuário. E por que eu comprei-lhe um exemplar do livro Souders, logo que foi publicado.)

2. Performance no servidor é principalmente uma questão de design das lojas de dados, não do código do aplicativo.

   Uma aplicação web típica envolve recuperar dados de um ou mais armazenamentos de dados, manipulá-lo de alguma maneira, e tornar a página para conter os dados. Dessas etapas, o que é mais provável a causar problemas de desempenho é a recuperação dos armazenamentos de dados . Um banco de dados mal posicionado pode provocar problemas graves, e os maiores ganhos de desempenho em um aplicativo bem escrito vai envolver lojas de dados mais rápida e uma estratégia de cache inteligente. Mas estas questões não são exclusivas do Rails - são problemas comuns a todas as aplicações web, não importa qual língua está sendo usada.

   (Enquanto eu sei quase nada sobre a arquitetura do Twitter, eu estou disposto a apostar que os seus problemas de dimensionamento tem que fazer com os dados de design da loja, e não o código do aplicativo. Se Twitter foi traduzido para outra língua sem redesenhar as lojas, eu espero que teria os mesmos problemas. A construção de sistemas que necessitam de reunir dados de várias coleções, com cada usuário que exige um conjunto diferente de dados, é um problema complicado design de dados, não importa o idioma.)

3. Rails suporta escala através da duplicação de servidores de aplicação.

   É fácil ao fogo até quantas instâncias de aplicação e servidores de web que você precisa em Rails. Escala Hardware - jogando em outra caixa de mistura para partição de carga - é tão fácil com o Rails como é com qualquer framework de aplicações modernas da web.

   O fator limitante para este tipo de escala é o tamanho do seu host de banco de dados - mas isso vai ser o fator limitante não importa o framework que você tem. E os mesmos truques utilizados em outras línguas para superar os limites de trabalho em Rails.

4. Rails suporta dimensionamento através do particionamento do pedido.

   Outra abordagem escala típica envolve o particionamento da aplicação em sub-aplicações, cada uma das quais é executado em um conjunto separado de servidores. Isso pode ser feito em Rails tão facilmente como em qualquer outra língua.

5. Rails otimiza o tempo do programador, e não o tempo do processador - e essa é a escolha certa.

   Eu não estou dizendo que Rails vai realizar, bem como linguagens como Java. Rails Mas é otimizada para facilitar a vida dos programadores, não computadores. Este é um tema comum na história das linguagens de programação - uma nova linguagem vem que é mais fácil para os programadores, mas menos eficiente em termos de tempo do processador. Há um blog inteiro em que - e eu prometo escrever em breve.

6. É fácil escrever código Rails ingênuo que executa mal. É por isso que você não deve escrever o código Rails ingênuo.

   Clearly, any language can be used to write bad, inefficient programs.  But Rails, which abstracts out the database to make database access transparent to the programmer, probably makes it easier to write inefficient code.  It is easy to slap together a quick Rails application without worrying too much about the database - that's the great strength of Rails.  But to get performance, you need to pay attention to the details.  That isn't too difficult, and I'll blog sometime about how we've done it at Mixx.  But it is necessary.

   (I suspect that this is another cause of the bad reputation for performance that Rails has.  People throw together a quick Rails application, taking advantage of its ease in programming, and are then surprised when it doesn't perform.  But while building an application can be easy, we aren't yet at the point where building a complex and highly performant web application is easy.)

E aí está. At Mixx, we feel that Rails will serve us quite well as our application platform.  In fact, we have effectively bet the company's future on this belief.  I do not expect to be proven wrong on this - while Rails is not a perfect platform in terms of performance, and there are a number of improvements that could help (another fertile ground for a blog post), for our application it performs just fine.

Welcome to the Mixx Engine Room, the blog of the Mixx engineering team. Over time, we'll be writing posts describing various aspects of Mixx technology - how things are built, challenges that we've encountered in scaling, the reasons behind some of our technical decisions, and other details about our systems that we feel we can share with the world.

At Mixx, we're strong believers in community. We've read The Cluetrain , and we believe in it. This blog will be the engineering team's car on the Mixx Cluetrain.

But this blog is not like the movies. Here we roll the credits first. And so, without further ado, I give you the Mixx engineering team, listed by Mixx longevity:

- Raghu Somaraju is a backend developer here at Mixx, building the server code for several of our subsystems. When you first registered for Mixx, and the last time you logged in, you used Raghu's code. In his pre-Mixx days, Raghu worked at Yahoo! in the News and Information group for three years, where he met Mixx CEO Chris McGill. After Yahoo!, Raghu worked at Juno Online in India and at an online ad agency start-up that, alas, did not make it.

- Joe Dzikiewicz (hey, that's me!) wears many hats at Mixx, so it's a good thing he has such a big head. As CTO, he manages the development and operations teams. As backend architect, he does overall architectural design of the backend systems. As a backend developer, he codes much of that design, including the initial work on the voting, submission, and categorization systems. Before Mixx, Joe was a systems architect at AOL for ten years, most of it spent in the Search and Community development teams. If you ever searched for something on AOL, chances are you used some of Joe's code. When not writing Mixx blog, Joe blogs at www.drdzoe.com .

- Like most of the crew at Mixx, Jason Garber wears many hats, all of them stylish. His job as User Interface Architect implies that he has some sort of working knowledge of blueprints, AutoCAD, and spackle. This couldn't be farther from the truth. Unless, of course, you think of HTML as a blueprint, CSS as spackling paste, and JavaScript as AutoCAD, but that's a rather weak analogy. Poor analogies notwithstanding, Jason spends a good deal of time working with the rest of the Mixx team to ensure that everything that goes out the door is functional, attractive, and easy to use.

Prior to joining up with Mixx, Jason worked at a small design and marketing firm in Bethesda, MD, and did some time at AOL, most notably working on Ficlets, which won an award for Best CSS at this year's South by Southwest conference. Between breaths, he is also involved in the local DC tech scene, organizing events, shooting photography, and playing in a rock and roll band.

- Nathaniel Collinsworth is Director of Operations for Mixx. His responsibility is the smooth running of all the technical infrastructure that the company needs. This umbrella covers a large number of disciplines; database, web server, mail, security, monitoring and alarming, business continuity, etc. It also includes the less challenging, but just as critical, needs of the office personnel. Nathaniel spends much of his days ensuring that Mixx can continue to scale to the needs of it's growing user base. The first half of his career Nathaniel managed technology operations groups for non-technology companies, including non-profits, mining companies and the US Federal Government. The second half he has focused on the scalability and distribution of community applications on the web for AOL and for Mixx. He enjoys working at Mixx because he gets to use his broad range of talents to serve both the Mixx employees and our users.

- Bill Kocik also joins us from AOL, where he spent several years working in both Systems Operations and Software Engineering disciplines. At Mixx, Bill spends most of his time writing code that runs on the servers. Of note, he designed and implemented the Mixx API, and is largely responsible for the Site Mail feature, as well as once-per-day email notifications and the Google AdSense revenue sharing functionality.

- Doug March is a Senior Web Developer at Mixx. He spends much of his time bringing product designs and ideas to life. On the side, he helps dream up new features and dabbles in Search Engine Optimization. Doug started his career in the world of government consulting. Later, he found his niche and honed his skills at Revolution Health. In his free time he is usually on the links trying to collect that elusive 5th hole-in-one. When not enlightening you via the engine room, Doug blogs at http://doug-march.com .

So that's us. Follow this space to learn more about the way we think, and the way we do technology.