I’ve started to write a kind of documentation about Cameron, in the spirit of a presentation, really brief and direct. It’s still a work in progress, like Cameron as well, but I think it’s already able to give you an idea on what Cameron aim to be.

Stay tuned…

A briefly introduction to Cameron

It has been built as an Erlang/OTP system with an REST-like API, powered by Misultin, through which one can POST a JSON request to run a given process workflows, that will be executed in background [parallely with other running ones], and then GET its JSON results as soon as them become available. And obviously, it uses Redis for the win.

What about Process Workflows?

Process workflows are defined in terms of REST-like web services, written in virtually any language, which basically must talk a simple JSON contract.

These web services are the activities that define a process workflow; these web services are the tasks to achieve a given target. And as you can imagine, yes, an activity can cascade many others; it is pipeline-based, as well.

So if you have any background job that must cascade many tasks to achieve a goal, maybe it fits to your needs.

Does it work?

Although it still experimental, a work in progress, it works reasonably well – at least under my tests.

So if you have time, take a look at the documentation.

…and in The .NET World

A melhor prática para aqueles que trabalham com .NET é escrever log com o Event Log. Os melhores sysadmins de Windows que conheço estão sempre ligados (Nagios? Zabbix?) no Event Viewer.

Então, apesar deste post se destinar a Ruby/POSIX, fica a dica do Renato Lucindo – no final desse post – para a galera de .NET/Windows também.

Bem, como a biblioteca padrão do Ruby para escrever no Syslog não é lá muito amigável, resolvi facilitar um pouco as coisas e criei a gem slogger.

Dois exemplos rápidos

Antes de mais nada, installe a gem:

$ gem install slogger

Log simples:

slogger = Slogger::Logger.new "sample_app", :debug, :local0
slogger.info "A good info"
slogger.debug "A deep info"

Log com tempo de execução:

slogger = Slogger::Logger.new "sample_app", :debug, :local0
slogger.info "A really good info preceded by spent time" do
    # do something
end

Depois, claro, dê uma olhada no seu Syslog, para ver as mensagens “logadas”.

A lambuja

Se você estiver usando Sinatra, por exemplo, pode usar o middleware Slogger::Rack::RequestLogger em vez do famoso Rack::CommonLogger, que usa Logger (não que o Logger seja ruim).

configure do
  slogger = Slogger::Logger.new "sample_app", :debug, :local0
  use Slogger::Rack::RequestLogger, slogger
end

E a dica final

Ecoando a dica do Renato Lucindo: não seja ingênuo, log everything!!!

Tá esperando o que para começar a fazer a coisa direito?

É aqui que entra o tema deste post.

Essa semana andei fazendo algumas contribuições em um projeto open source bem simples, mas igualmente interessante, que é o jetty-rackup.

O objetivo do jetty-rackup é rodar aplicações Rack no Jetty WebServer, sem ter que empacotá-las em arquivos WAR, o que é definitivamente excelente em ambiente de desenvolvimento ou quanto você quer fazer deploy orientado a git pull.

Tutorial de 1 minuto

Bem, para que o jabá seja completo, nada melhor do que um tutorial. Vamos escrever então uma aplicação Sinatra básica – ótima pedida para Web API.

1. Com Sinatra já instalado, crie uma aplicação – app.rb

require 'sinatra'

configure :development do
  Sinatra::Application.reset! # recarrega as rotas
  use Rack::Reloader          # recarrega arquivos
end

get '/?' do
  "hello"
end

get '/:message/?' do |message|
  "hello #{message}"
end

2. Com a aplicação criada, crie o arquivo rackup – config.ru

require 'rubygems'
require 'app'

set :run, false
set :environment, :development

run Sinatra::Application

3. Com o arquivo rackup criado, installe a gem jetty-rackup

$ gem install jetty-rackup

4. Com a gem jetty-rackup instalada, no diretório da aplicação criada, inicie a aplicação

$ jetty-rackup config.ru

5. Finalmente, com tudo pronto, teste com cURL e Apache Benchmark

$ curl http://localhost:9292/

$ ab -n 10000 -c 25 http://localhost:9292/

Voilà!

Agora, rode o último comando algumas vezes e observe a variação crescente de “Requests per second”. JIT Compiler for the win!

Um pouco mais

Se quiser saber como usar bibliotecas Java, no repositório do projeto tem também um exemplo usando classes Java, tanto contidas no diretório WEB-INF/classes quanto em arquivo JAR no WEB-INF/lib.

Divirta-se!

Se você tem experiência em Ruby, Python, Java, .NET, PHP, Perl, bancos de dados relacionais e não-relacionais, arquiteturas distribuídas, sistemas de agendamento de tarefas, filas assíncronas, desenvolvimento web, e umas coisinhas mais, pode ser que tenhamos um lugar aqui para você. Que tal?

O perfil completo pode ser visto na integra aqui, no OndeTrabalhar.com.

Bem, o resultado dessa brincandeira pode ser visto aqui, no projeto ReactiveJ.

Ainda é um projeto de brincandeira, uma coisa didática, sem qualquer otimização extra de performance. Portanto, não é production ready. Quem sabe algum dia, caso eu leve a brincadeira a sério.

Se gostarem da brincadeira e quiserem continuar explorando o assunto, tenho mais uns links pra vocês:

• Niosted, uma implementação de Reactor baseada em Twisted e Java NIO – por Alexandre Fiori
• Exemplo de uso da Niosted com JRuby – por Gleicon Moraes
• Implementação de non-blocking server com a API de Servlet 3 – por Paulo Silveira

Divirtam-se!

“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”

E sua resposta foi:

“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”

Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.

O mesmo vale para Ruby e Python, como ele mesmo cita.

Mundos diferentes

Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.

Comparação entre mundos diferentes

Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.

Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.

Super CRUD com Erlang? Não, acho que não.

Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?

Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.

Mundos diferentes se complementam

Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.

Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.

Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.

Essa é a ideia de tirar o melhor de cada linguagem!

Mesmo porque, dificilmente, você constroi um sistema de verdade – que não seja um super CRUD – com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.

Esse é o mundo real dos sistemas de verdade.

Moral da história

Isso me faz pensar que brigas de fanboys de linguagens – em frenéticas buscas por prosélitos – são uma verdadeira piada.

Demorei um pouco, mas cá está, subi minha apresentação pro SlideShare.

O que achei do evento?

Achei o evento muito arretado, como de fato era sua proposta. (háh!)

Bem, mas sendo um pouco mais especifico, deixo um destaque especial para a organização do evento, que foi impecável; muito acima da média mesmo; o pessoal da comunidade lá de Natal está de parabéns. Annaysa Melo, Paulo Fagiani, Maximiliano Guerra e todos os demais, muito obrigado pela receptividade!

Presença da Locaweb

Esse ano, um coisa peculiar que rolou foi que, além de mim, outros quatro locawebers também palestraram: Fábio Kung, Nando Vieira, Rafael Rosa e Daniel Cukier. Me senti em casa!

Palestras

A maioria das palestras que assisti foram muito boas, em especial a do Tapajós que, como já era de se esperar, mandou super bem falando de CouchDB. Queria muito ter visto também a do CV, mas infelizmente não pude, porque palestramos no mesmo horário. Fica pra próxima.

A palestra do Geoffrey – com aquela voz de peepcoder – foi no mínimo divertida; mas a do José Valim acho que ficou devendo um pouco – talvez porque, IMHO, soou um tanto quanto marketing da Plataforma. Já a do Akita me surpreendeu. Nem tanto pelo conteúdo – apesar de indiscutivelmente relevante –, mas mais pelo formato e desenvoltura. Bem legal mesmo.

Não gostei da palestra do Carlos Brando, achei muito auto-ajuda; mas deixo um ponto positivo pro trecho de Assembly e C que ele codou ao vivo. Aliás, falando em codar ao vivo, a palestra do Nando foi muito boa, com seus slides super descolados e coloridos, mas ele não codou ao vivo. Tadinho do Murphy e sua lei, não paparam essa.

Dessa fez o Kung também não codou ao vivo, como de costume, mas sua palestra foi legal, bem contextualizada, dinâmica e totalmente #devops. Aliás, ela fez tanto sucesso que, depois de terminá-la, ele ficou um tempão trocando idéia e codando com a galera no open space.

Não pude ver a palestra do Rafael Rosa, meu colega de Locaweb, porque estava na do Hugo Baraúna sobre Project Rescue. Não gostei muito, pra ser sincero, então acabei ficando meio frustrado.

O Henrique Bastos deu um show de humildade, numa palestra que, sinceramente, eu não esperava muito do tema. Foi excelente. Já a palestra do Daniel Lopes, não gostei não. Gostei do Steak, que eu ainda não conhecia, mas achei a palestra dele meio bala de prata no que diz respeito a testes de aceitação.

A palestra do Vinícius Teles foi legal, mas como eu já tinha visto ele palestrar nos dois últimos anos, na Rails Summit, não foi muito novidade pra mim. Mesmo assim, uma boa palestra.

Nessa linha de empreendedorismo – também seguida pelo Rafael Lima –, o Alê Gomes, cara muito gente fina, fez uma apresentação meio reworkeana, mas mega divertida. Casquei o bico com ele.

Vi também a palestra da Thaís, falando sobre seu dia-a-dia no trabalho, comprometimento e respeito aos colegas. Foi legal.

E por fim, rolou um Q&A com todos os palestrantes, quando foi revelado que somente eu, Akita, CV e Juan Bernabó não terminamos a faculdade. Aliás, falando nesse Q&A, rapaz, como tem gente que gosta de falar, hein? Teve palestrante que pegou o microfone e não quis mais largar. Fiquei impressionado.

Balanço final

Valeu bastante a pena ter participado dessa conferência, em especial pelas discussões e bate-papos informais.

Ano que vem, quem sabe, nos vemos por lá outra vez!

Se você estiver por lá e quiser ver uma palestra nada técnica, logo depois do coffe-break, às 16:00, na sala B, vou falar sobre “gerenciamento de times auto-gerenciáveis”.

Uma introdução ao assunto da minha palestra são os posts:

• Tchau, tchau gerente, agora sou Scrum!
• Rápidos conselhos para gerentes humanos
• Você ainda acha que programação em par é desperdício?

Bem, aos poucos temos escrito sobre o evento (review, palestras, etc) no blog da Locaweb e também coloquei uma porção de fotos no meu Flickr.

Divirtam-se!