You are currently browsing the archives for the java category


Página nova e contratações

Virei a página outra vez….

Ontem assumi como diretor de tecnologia da Urban Summer, uma agência digital bem bacana, que tem feito trabalhos incríveis para uma porção de clientes legais. E como de costume, cá estou eu procurando por gente boa para trabalhar no meu time.

Tenho algumas vagas em aberto, que ainda vou postar aqui com mais detalhes, mas de cara, urgente, urgentíssimo, estou procurando por dois desenvolvedores client-side, como uns dois anos de experiência mais ou menos, com bastante habilidade em:

  • Recortar imagem – você pega um PSD e faz a mágica para transformar em página web
  • HTML
  • CSS
  • JavaScript

Se souber programar “razoavelmente bem” em Python, PHP, C#.NET, Objective-C, Java ou Ruby, que beleza, isso conta ponto a seu favor. Mas se não souber, tudo bem, não tem problema; esse não é um requisito obrigatório.

Se você não tiver interesse, mas souber de um camarada que tem, indique! Eu ficarei grato. Ele, certamente, também ficará – talvez ele até lhe pague um café.

Aguardo contato em leandro@urbansummer.com.br.

Valeu!

klogd2: My second try to route Syslog messages to Kafka

It was really cool to play around with klogd but I have to confess that I’d like to have more fun. So this is my aim with klogd2.

Klogd2 is essentially a new implementation of klogd but in Java, relying on Syslog4j, as I said on klogd2’s README:

I’d want to try Syslog4j on the server side, because I know it’s a rock solid stuff and all those cool kids are using it, e.g. Graylog2.

Take a couple of minutes to get a look there, when you can. As usual, I’d really appreciate your feedback and possibly a pull request.

jetty-rackup: rodando aplicações Rack no Jetty

Por conta de um projeto que está pintando no trabalho, que requer o uso de um conector escrito em Java, há umas duas semanas mais ou menos comecei a fazer novos testes com Jython, considerando fortemente uma solução baseada Python. Até publiquei uma aplicação boba usando Flask, só de exemplo, porque googlando não achei nada que não fosse com Pylons ou Django. Mas no final, Jython não pode preencher alguns requisitos e voltamos então para JRuby.

É 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!

A Locaweb está contratando!

A Locaweb está procurando por desenvolvedores experiêntes e talentosos para integrar nossos times de SaaS, Cloud Computing, Hospedagem, Q&A e Sistemas Centrais.

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.

ReactiveJ: uma brincadeirinha com Evented I/O

Estive estudando e brincando um pouco com evented I/O nas últimas duas semanas e resolvi então fazer uma implementação disso em Java, usando a Java NIO, que biblioteca de I/O não-blocante da plataforma Java, e seguindo o pattern Reactor.

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:

Divirtam-se!

O quanto realmente importa a escolha de uma linguagem?

Há alguns meses perguntaram ao Rich Hickey:

“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.

Quer saber onde será seu próximo trabalho?

Então não deixe de visitar…

O site é recém-nascido, mas já tem uns recursos bem legais, como sistema de pesquisa por palavras-chave, núvem de tags e entre outros. Vale a pena conferir e acompanhar sua evolução – e oportunidades de bons trabalhos.

Mais uma iniciativa bem interessante da Caelum. :)

Então, falando em Java…

Ontem aconteceu a terceira edição do já tradicional e indispensável evento Falando em Java, organizado pela Caelum em São Paulo.

O evento, como tudo que a Caelum faz, foi muito bem organizado, num excelente espaço, com ótimos coffebreaks (eu perdi o do almoço, porque fui comer comida chinesa no Hong He. #fail) e boas pessoas. Afinal de contas, como disse o Sério Lopes e o Fábio Kung na abertura do evento, a Caelum são as pessoas.

O que achei das apresentações?

As duas apresentações do Jim Webber foram fantásticas, mostrando uma visão bem realista de SOA, ESB e outras buzzworlds do momento, e dando uma boa luz no caminho dos serviços baseados na Web, REST e microformatos. Com certeza foram palestras que me fizeram reafirmar uma antiga crença: Você aprende muito com seus erros; e mudar de opinião porque aprendeu um pouco mais sobre algo, não é demerido nenhum, muito pelo contrário, é sinal de amadurecimento. O Jim é um exemplo disso.

Só tenho uma coisa a acrescentar, Jim: Quem mata gatinhos pequeninos quando alguém usa URL em lugar de URI, ou faz de um ESB um grande espaguete digno de festa do Bexiga, é o diabo, não Deus. Anote isso ai pra sua próxima aprensentação. :)

A palestra do Guilherme Silveira junto com o Felipe Sabella teve uma ótima dinâmica, muito bem entrosada e com conteúdo homeopaticamente dosado. Nota 10. Mas infelizmente, nem todas as duplas tiveram o mesmo entrosamento, o que em alguns momentos acabou prejudicando bastante a mensagem das apresentações. Uma pela.

Destaque para o Paulo Silveira que, como sempre, não deixou a peteca cair e salvou a palestra; para o Ricardo Nakamura, que cativou a galera de primeira com sua revelação de que dorme com o pijama do Jaspion; e para o Kung que sempre tira uma carta ou duas sinistraças da manga.

O Sérgio e o Guilherme Moreira, no entanto, a pesar de dominarem o assunto que apresentaram, me deixaram um tanto decepcionado, porque a palestra não me pareceu muito condizente com o tema proposto. Por outro lado, devem ter feito vibrar os hibernate buys.

E claro, hehehe, eu não podia deixar de citar o mico o imprevisto do cluster com JBoss não funcionar na apresentação deles. Não por culpa do JBoss, é lógico, porque todos sabemos que há várias empresas mundo afora que rodam JBoss em cluster.

Eu mesmo fui um dos que entrou na zueira, mesmo não tendo nada contra o JBoss. Muito pelo contrário, é um dos meus preferidos – talvez por ainda não ter tentado colocá-lo em cluster. rsrs

Fica aqui minha remissão. I’m sorry!

Ponto positivo também pras Caelets, muito discretas e distintas, bem distantes da vulgaridade que vemos em muitos eventos por ai. Gostei do bom senso.

Ah! Tem também uma novidade que vale a pena citar: Logo mais teremos o livro da Caelum de Arquitetura e Design de Software à luz da Plataforma Java, com prefácio do gujeiro velho de guerra, Phillip Calçado. Se não me engano, o lançamento será em novembro.

Bem, no mais, é isso. Se você quiser uma cobertura mais completa sobre o evento, dê uma lida nas minhas tuitadas. Eu ralei pra caramba pra tuitar o evento interinho, não vou digitar tudo outra vez. Dá uma forcinha, vai. Dá uma olhada lida lá. :)

Até a próxima!

Entrevista com Ola Bini: Ioke, JVM, .NET e mais!

Quem me conhece há algum tempo ou acompanha este meu blog, sabe que eu sou totalmente meio fissurado por linguagens de programação. Sempre estou dando uma olhada em uma aqui e outra ali. Lendo, fuçando…

Mas tem um cara que com certeza é ainda muito mais fissurado em linguagens de programação do que eu - e diferente de mim, manja pra caramba. Esse cara é o Ola Bini, membro do core team do JRuby, consultor da ThoughtWorks, escritor do livro JRuby on Rails, membro do expert group da JSR-292 e criador da linguagem Ioke.

Bem, como não podia deixar de ser, eu resolvi fazer uma pequena entrevista com ele sobre Ioke, linguagens para a JVM e a Microsoft CLR, e uma coisinha ou duas mais. Confira!

Ola Bini e nosso compatriota Fábio Akita

Ola Bini e o nosso patrício Fábio Akita (QCon 2008)

Fale-nos um pouco sobre sua paixão por linguagens de programação. Quando isto começou? O que mais te motivou?

Oh wow. Boa pergunta. Eu não sei quando isto começou. Em algum momento obscuro do passado – muito longe para me lembrar. =)

Eu comecei bem cedo, com Basic no Apple IIc. Fiz muito C e assembler na minha adolecencia, e então, aprendi C++, Java e Lisp.

Penso que minha atual facinação por linguagens começou quanto eu percebi como diferentes linguagens são e como muitas coisas ruins são usadas. Esta percepção levou algum tempo, mas ficou cada vez maior.

Eu comecei com a implementação de outra linguagem há 5-6 anos atrás.

Além de contribuir com o projeto JRuby, você também criou a linguagem Ioke do zero. O que você tem a dizer sobre a JVM com plataforma para outras linguagens (além da linguagem Java)?

Sim. Então, a JVM é uma excelente plataforma para linguagens. Você tem um JIT muito maduro no Hotspot. Você tem garbage collectors fantásticos; e você tem um monte de bibliotecas e ferramentas disponíveis. A parte ruim é que a JVM atualmente está muito amarrada a linguagens que se parecem com Java, no nível do bytecode. É possível contornar isto, e nós estamos trabalhando na JSR292 para dar suporte a invocações dinâmicas na JVM.

Mas atualmente a JVM ainda está um bocado ligada a linguagens como Java. Isto não é necessário a tudo (muitas das tecnologias Java começaram em Smalltalk e Strongtalk).

Você acredita que a linguagem Java está caminhando para se tornar em uma linguagem de infra-estrutura? (Uma linguagem para escrever linguagens e outros componentes críticos de infra-estrutura.)

Espero que sim. Java não é uma boa linguagem para escrever aplicações – ela é realmente muito baixo nível.

Sobre Ioke. O que levou você a começar o projeto desta linguagem? Onde você pensa chegar com ela? O que você planeja para o futuro de Ioke?

Basicamente, a ideia com Ioke é ver o quão expressiva você pode fazer uma linguagem; e isto é o que tenho feito. Isto tem dado características linguísticas bastante avançadas; você pode fazer coisas nela que muitas pessoas inicialmente tem problemas para entender – mas ela permite você escrever código bastante sucinto e legível, que capture suas intenções.

O que acontecerá exatamente no futuro está no ar. Tenho muitas idéias, mas nada concreto no momento.

Recentemente, você também portou a linguagem Ioke para a Microsoft CLR. O que te motivou a fazer isto? O que você pensa sobre a plataform Microsft .NET como plataforma host para novas linguagens?

Sim! Eu fiz isto porque não queria que Ioke fosse somente uma linguagem da JVM. Queria ver como a CLR funcionaria para implementa-la e queria amplicar um pouco a base de usuário. A plataforma .NET é mais ou menos tão boa quanto a JVM. Algumas coisas são piores, outras são melhores.

O que você recomenda a aqueles que gostariam de, como você, serem designers de linguagens para a JVM? Esta recomendação seria mais ou menos a mesma para a plataforma .NET?

Há duas coisas que você precisa fazer. A primeira é ter uma boa idéia de como diferentes linguagens funcionam. Você precisa aprender linguagens de diferentes paradigmas e tentar entender como elas podem ser implementadas. Então, você precisa começar a fazer. Esta é a parte mais importante.

Comece realmente a implementar e ver o que acontece.

Finalmente, sinta-se à vontade para dizer o que quiser sobre Ioke.

Ela é muito “louca”. Ela é expressiva. Ela é muito lenta.

Penso que esta coisa de expressividade vai ser importante no futuro – já que nós estamos fazendo coisas mais e mais avançadas. Texto não escala se não podemos ter uma abstração estrutural (1). Ioke permite isto.

(1) N.T.: O que o Ola Bini quis dizer é que “texto, por si só, não pode ir a um nível superior, não pode evoluir, crescer, se não pudermos ter uma abstração estrutural sobre ele”. :)

Sparrow, um cliente JMS baseado em JRuby

Mês passado comecei a tocar um projeto na CVC Turismo que, entre outras coisas, envolve troca mensagens assíncronas usando JMS. Esse trabalho foi está sendo tão divertido que me inspirou a escrever um post sobre Message-Driven Beans e Transações; e mais recentemente, a começar um novo projeto pessoal.

Sparrow é um cliente JMS implementado sobre JRuby e distribuido como uma Rubygem – hospedada no Github,  é claro. Ele é uma boa opção para quem precisa integrar sistemas Ruby com servidores de aplicações Java EE, provedores de mensageria JMS.

É pá, pum! Quer ver?

require 'rubygems'
require 'sparrow'

# Configuração que tem que ser feita uma única vez
jms_client = Sparrow::JMS::Connection::Client.new do |props|
  props.client_jar_file         = '/oc4j_extended_101330/j2ee/home/oc4jclient.jar'
  props.initial_context_factory = 'oracle.j2ee.naming.ApplicationClientInitialContextFactory'
  props.provider_url            = 'ormi://localhost:23791'
  props.security_principal      = 'oc4jadmin'
  props.security_credentials    = 'welcome'
end

jms_client.enable_connection_factories(
    :queue_connection_factory => 'jms/MyQueueCF'
  )

jms_client.enable_queues(
    :my_queue => 'jms/MyQueue'
  )

# Envio
jms_client.queue_sender(:my_queue).send_text_message('sparrow rocks!') do |msg|
  msg.set_string_property('recipient', 'sparrow-example')
end

# Recebimento
jms_client.queue_receiver(:my_queue).receive_message(
    :timeout  => 5000,
    :selector => "recipient = 'sparrow-example'"
  ) do |msg|

  puts msg.is_text_message?    # true
  puts msg.text                # sparrow rocks!
end

Fácil, não? :)

Se você quiser saber mais sobre o projeto, testá-lo, critica-lo, ou algo assim, por favor, não fique acanhado fique à vontade. E se não for pedir demais, deixe um comentário nesse post, como um feedback, para eu saber o quanto ainda preciso melhorá-lo e evoluí-lo.

Valeu!