Ruby fora dos trilhos

Às vezes parece que minha empresa é a única empresa no mundo usando Ruby, mas não Ruby on Rails, a ponto de Rails quase se tornar sinônimo de Ruby.

Tenho certeza que isso não é verdade, mas seria divertido ouvir algumas histórias sobre o uso de Ruby não-Rails por aí.

Um dos grandes benefícios do Ruby é a capacidade de criar DSLs com muita facilidade. Ruby permite que você crie "regras de negócios" em uma linguagem natural que geralmente é fácil de usar para um analista de negócios. Muitos aplicativos Ruby fora do desenvolvimento web existem para este propósito.

Eu recomendo fortemente Googling "ruby dsl" para uma leitura excelente, mas eu gostaria de deixar você com um post em particular. Russ Olsen escreveu um blog em duas partes sobre DSLs . Eu o vi fazer uma apresentação sobre DSLs e foi muito bom. Eu recomendo fortemente a leitura dessas postagens.

Também achei esta excelente apresentação sobre Ruby DSLs de Obie Fernandez . Leitura altamente recomendada!

Eu uso Ruby extensivamente em meu trabalho, e nada dele é baseado em Rails (ou mesmo na web).

Meu domínio é geralmente de aplicativos Windows do lado do cliente (wxRuby GUI) e scripts, automatizando o Excel, Internet Explorer, consultas do SQL Server e geração de relatórios (automação COM win32ole). Eu também uso o sqlite, pdf-writer e bibliotecas gruff para várias tarefas de munging de dados e geração de gráficos.

O sucesso de Rails tem sido ótimo para Ruby, mas concordo que Rails tem recebido tanta atenção que o valor de Ruby além da web é frequentemente esquecido.

Somos principalmente uma loja de C ++, mas encontramos várias áreas em que Ruby tem se mostrado bastante útil. Aqui estão alguns:

• Geração de código - construiu várias DSLs para gerar código C ++ / Java / C # a partir de arquivos de entrada única
• Suporte de construção
  • scripts para gerar Makefiles para unix a partir de arquivos de projeto do Visual Studio
  • scripts para construir projetos e formatar a saída para Cruise Control
  • scripts para executar nossos testes de unidade e formatar a saída para Cruise Control
  • scripts para manipular projetos e soluções do Visual Studio a partir da linha de comando
• Testes de integração - podemos realizar testes muito mais rápidos e limpos usando Ruby do que C ++
• Todo o pacote de testes do QA é escrito em Ruby

Ruby é basicamente minha ferramenta ideal para onde faz sentido. E faz sentido em muitos lugares.

O Google Sketchup usa Ruby como uma linguagem de script incorporada. Você pode usá-lo para realizar todos os tipos de modelagem 3D e tarefas de importação / exportação. O script funciona com a versão gratuita e há até documentação decente .

Ruby com uma extensão homebrew escrita em C ++ faz todo o esforço de pixel para o meu processamento fotográfico. Eu estava usando Python + numpy, mas quando faço coisas artísticas , Ruby é apenas mais divertido. Além disso, a relativa falta ou menor maturidade de boas bibliotecas de processamento de imagens me faz sentir menos como se estivesse reinventando rodas. Eu não tenho a menor ideia sobre Rails, exceto que já ouvi falar dele, tenho uma ideia vaga do que é, e na verdade tenho um livro sobre ele (fechado)

Usamos Watir (biblioteca Ruby) para testar nosso aplicativo da web .net.

Confira Shoes , uma API simples para construir GUIs em Ruby voltada para programadores novatos.

Ou você pode usar Ruby para fazer música à la Giles Bowkett's Archaeopteryx. Esta apresentação de Giles sobre o Archaeopteryx é uma das melhores apresentações de todos os tempos. Eu recomendo.

RubyCocoa e MacRuby. Possível fazer aplicativos GUI completos baseados em Cocoa sem Rails. E então você pode usar o Interface Builder também.

Trabalhei em um projeto de museu no ano passado que usava muito Ruby. ( http: // http: //ourspace.tepapa.com/home )

A parte em que passei a maior parte do tempo foi um mapa interativo. O mapa no chão tem sensores para que, quando as pessoas andam sobre ele, as luzes sejam acionadas e as exibições na parede mostrem imagens ou vídeos e faixas de áudio sejam reproduzidas.

Todo o código de controle para esta parte da exibição é rubi. Eu escrevi interfaces C com invólucros de rubi para se comunicar com os sensores de piso e os controladores de iluminação. O sistema consulta um banco de dados MYSQL para os arquivos de mídia a serem exibidos e, em seguida, diz aos computadores nas paredes para reproduzir a mídia via UDP.

É a parte mais confiável de toda a exposição.

Ruby foi usado para a outra parte principal da exposição, o Muro, embora eu não tenha muito a ver com isso. A maioria dos gráficos foram prototipados em ruby ​​usando interfaces para OpenGL, um pouco de Cocoa e uma biblioteca de física antes de serem portados para Obj-C puro.

Fantoche e Chef: DevOps

Não vi nenhuma menção a Puppet ou Chef nas 30 respostas que antecederam a minha chegada. Ruby parece dominar o trabalho atual em automação em nuvem e é a base, extensão e linguagem de modelos desses dois grandes jogadores. Eles são usados ​​principalmente para distribuir informações de configuração de sistema e aplicativo para matrizes de servidores e para gerenciamento geral de estações de trabalho de TI.

O campo DevOps é bastante compatível com Ruby. Hoje, Perl tem um concorrente. Embora um script realmente simples possa freqüentemente ainda ser escrito diretamente para sh(1),uma tarefa complexa, agora pode ser feito em Ruby em vez de Perl.

O único site que fiz com Ruby no trabalho é usando Rails, mas gostaria de experimentar o Merb .

Fora isso, eu faço vários pequenos programas utilitários em Ruby - por exemplo, um aplicativo que lê RSS feeds e importa novos posts para um dabase.

É divertido, então também escrevo algumas coisas idiotas só porque é muito rápido. Ontem eu escrevi um aplicativo para reproduzir o problema Monty Hall 100.000 vezes para ajudar uma amiga a convencer seu professor de que mudar é a estratégia correta.

Quase me ofende que rubi seja coisa de trilhos. É como quando CGI era a última tendência e todos imaginavam que, se você conhecesse perl, deveria fazê-lo apenas porque programou aplicativos CGI. Ruby é apenas uma linguagem de script para mim, embora não tão madura quanto python, então eu me arrependo de ter que passar por alguns de seus obstáculos e mudanças recentes, eu ainda gosto e uso. Embora eu trabalhe em uma loja de java e, portanto, groovy seja a escolha ideal para uma linguagem de script, ainda uso ruby ​​em casa e para jogar fora scripts que não precisam ser compartilhados no trabalho.

Eu estava pensando em entrar no RoR por causa de todo o burburinho e quão rápido / simples ele é, mas depois de olhar os trilhos, não vi nada que fosse incrível ou pelo menos um pouco inovador ou rápido em seu desenvolvimento em comparação com qualquer outro estrutura. O único benefício que vi foi que podia codificar em ruby, o que seria bom, mas a configuração inicial, a manutenção do servidor e o escalonamento são mais difíceis, compensando assim o prazer de codificar em ruby.

Eu criei uma apresentação - coincidentemente chamada Off The Rails - para discutir os aplicativos da web baseados em Rack:

https://github.com/alexch/Off-The-Rails

O repo git inclui slides no formato Markdown e código de amostra (na forma de aplicativos em execução e middleware). Aqui está o resumo:

Ruby on Rails é a estrutura de aplicativo da web mais popular para Ruby. Mas não é o único! Se você acha que Rails é muito grande, ou muito opinativo, ou muito qualquer coisa, você pode ficar feliz em aprender sobre a nova geração dos chamados microframeworks construídos no Rack. E como o Rails 3 é um aplicativo Rack, você não precisa desistir do Rails para obter o benefício das rotas Sinatra ou APIs Grape.

E aqui estão algumas referências:

• Esta palestra está disponível em https://github.com/alexch/off-the-rails
• 10ª coisa favorita de Yehuda sobre Ruby
• Prateleira
  • teste de rack
  • cliente de rack
• Sinatra
• Uva
• Vegas
• Siesta
• Repetir

Espero que seja útil!

Sou principalmente um desenvolvedor Web e aprendi Ruby a usar Rails, mas gosto tanto da linguagem que comecei a desenvolver um aplicativo Swing de desktop em Ruby, usando JRuby e Monkeybars. Sou competente em Java, mas não gosto muito de usá-lo, e a API Swing é horrível, então colocar Ruby no topo foi uma grande vitória.

Usamos principalmente rails, mas temos muitas outras coisas ruby ​​não-rails - por exemplo, um daemon de autenticação autônomo para autenticação centralizada de usuários e um 'servidor de processamento de imagem' que executa um número arbitrário de processos ruby ​​para processar imagens em paralelo.

Ah, e não se esqueça do bom e velho Rake :-)

Ruby também é usado para aplicativos de desktop. Especialmente o uso de JRuby para desenvolver aplicativos de desktop Swing.

Eu usei Ruby no trabalho para

• Um extrator de dados, gerando arquivos csv de saída binária.
• Um gerador de arquivo .ini, transformando uma sintaxe simples em um formato .ini repetitivo.
• Um servidor TCP / IP simples, atuando como substituto do sistema do cliente durante o teste.

Usamos Ruby para implementar nosso software de automação de teste. Isso inclui a estrutura de teste e o código do driver para Selenium RC, WATIR e AutoIT.

Ruby é poderoso o suficiente para criar aplicativos abrangentes que podem interagir com ferramentas de teste como Selenium ou WATIR, enquanto ao mesmo tempo lê arquivos de dados, interage com uma IU remota do Windows e executa comunicação de rede quase transparente. Tudo isso rodando em Windows ou Linux.

A sintaxe organizada torna-o ideal para a leitura de programadores novos e inexperientes. Embora sua natureza totalmente OO facilite para esses mesmos programadores aplicarem boas técnicas OO (aprendidas recentemente), desde o início.

A natureza flexível da sintaxe do Ruby também torna o uso e a criação de DSLs muito mais fácil. Isso permite que pessoas menos técnicas se envolvam, leiam e possivelmente criem seus próprios testes.

Usei Ruby para geração de código de procedimentos armazenados C # e T-SQL em um projeto com requisitos instáveis. O modelo de dados foi codificado em um arquivo YAML e modelos .erb foram usados ​​para as classes e procedimentos armazenados. Também permitia uma solução muito mais DRY do que seria possível com C # puro, já que o código repetitivo poderia ser fatorado em um único método no gerador de código.

Onde eu trabalho, usamos Ruby para fazer vários tipos de trabalhos em lote únicos. Um exemplo disso é um trabalho que interage com o serviço S3 da Amazon. Na época, a biblioteca Ruby S3 era provavelmente a mais fácil de se colocar em funcionamento em um curto espaço de tempo.

Eu escrevi um sistema especialista em processamento de pedidos (veja a resposta DSL também), converti 100 mil linhas de perl específico do cliente em cerca de 10 mil linhas de rubi lidando com dezenas de clientes. Sem componentes web, sem Rails.

Eu sou um usuário do webdriver. ruby é usado pelo webdriver para automatizar o processo de construção graças ao rake. consulte http://code.google.com/p/webdriver/ para obter detalhes

Heh, ótima pergunta.

Usei Ruby para converter dados de instalações de aeroportos em planilhas do Excel em sqlite3 para a plataforma de telefone Android ao fazer um aplicativo para pilotos.

Eu uso Ruby com Sinatra que é muito mais simples que Rails. Eu usei Rails, mas acabei de descobrir que ele se transformou em um monstro, embora Rails ainda seja incrível em comparação com frameworks web disponíveis para Java.

A principal característica do Ruby que eu adoro, entretanto, é "eval" e "method_missing", que Rails realmente usa por exemplo no ActiveRecord para que você possa usar as incríveis consultas "find_by-field-name-".

Eu usei Ruby para muitos códigos de back-end simplesmente porque eu era a única pessoa encarregada de fazer isso e precisava de uma linguagem limpa e agradável que me permitisse ser muito produtivo e escrever códigos fáceis de manter. Acho que Ruby me permite fazer isso mais facilmente do que Perl e Python. A quilometragem de outras pessoas pode variar nisso, mas funciona bem para mim.

Além disso, gosto de como o Sequel e o Nokogiri funcionam. Eu também usei ActiveRecord por um tempo separadamente do Rails.

Nós usamos um pouco de Ruby para manipulação de arquivos, mas ainda não conseguimos incorporar trilhos.

Usei Ruby muito profissionalmente para scripts rápidos para coisas como embaralhar arquivos. Eu sou da mesma forma que estava usando Ruby antes de tocar em Rails.

Em Boulder havia um excelente grupo de usuários de Ruby que se encontrava mensalmente. Este ponto foi feito - que Ruby tem uma existência além de seu uso em Rails. Os usuários simples de Ruby existem, estão implorando por atenção, têm coisas legais para mostrar e podem se encontrar em reuniões de grupos de usuários.

Eles também comeram pizza melhor do que o grupo Python, que também se reunia no mesmo dia do mês. Só posso escolher um ...

Embora tenhamos vários aplicativos Rails trabalhando, também usamos Ruby para algumas coisas não web bastante intensivas.

Temos um daemon de entrega de SMS, que puxa mensagens de uma fila e as entrega, e um daemon de processamento de cartão de crédito para o qual outros aplicativos podem chamar, o que garante que haja uma trilha de auditoria central.