AkitaOnRails.com

Ruby 1.9.3-p0 e gem MySQL2 0.3.7

Fabio Akita — Wed, 01 Feb 2012 17:53:31 PST

Hoje bati com um probleminha ao tentar iniciar um aplicativo Rails 3.1.x sobre Ruby 1.9.3-p0 com a gem MySQL2 no meu Mac OS X Lion.

Resumindo, é possível que você esbarre com o seguinte erro:

dyld: lazy symbol binding failed: Symbol not found: _mysql2_set_field_string_encoding
  Referenced from: /Users/akitaonrails/.rvm/gems/ruby-1.9.3-p0/gems/mysql2-0.3.7/lib/mysql2/mysql2.bundle
  Expected in: flat namespace

dyld: Symbol not found: _mysql2_set_field_string_encoding
  Referenced from: /Users/akitaonrails/.rvm/gems/ruby-1.9.3-p0/gems/mysql2-0.3.7/lib/mysql2/mysql2.bundle
  Expected in: flat namespace

Trace/BPT trap: 5

Esse problema foi reportado como bug no projeto do MySQL2 com o número #216. O criador e mantenedor da gem, Brian Mario já fez um commit com a correção, basicamente a mudança é esta:

1
2
3

-inline VALUE mysql2_set_field_string_encoding(VALUE val, MYSQL_FIELD field, rb_encoding *default_internal_enc, rb_encoding *conn_enc) {
          142        
+static VALUE mysql2_set_field_string_encoding(VALUE val, MYSQL_FIELD field, rb_encoding *default_internal_enc, rb_encoding *conn_enc) {

Se quiser usar esta correção, modifique seu Gemfile declarando a gem mysql2 da seguinte maneira:

1	gem "mysql2", "~> 0.3.7", :git => "git://github.com/brianmario/mysql2.git", :ref => "d3a96b8"

O Brian ainda não lançou uma nova versão da gem com a correção por isso podemos baixar diretamente do repositório no Github.

Para atualizar execute bundle update mysql2. Isso deve resolver esse problema.

Lembrete: Bug de Rack Antigo (1.3.0)

Fabio Akita — Wed, 01 Feb 2012 06:08:05 PST

Ano passado minha equipe colocou um grande projeto em produção. Por conta do NDA assinado com o cliente, não podemos divulgar, posso dizer que era internacional e com grande tráfego. Porém quero descrever uma situação que passamos que talvez possa ajudar outros projetos mesmo sendo um bug antigo.

Pesquisando esses dias esbarrei com este Gist do John Nunemaker. Não afirmo que é exatamente o mesmo bug mas a descrição é idêntica. Em nosso caso, os servidores de produção estavam todos funcionando bem, mas aleatoriamente quando monitoramos víamos algumas das CPUs em 100%, se deixássemos mais algum tempo em breve todas as CPUs estavam no máximo e parando de responder.

Não havia uma situação especial, parecia bem aleatório. A única forma de recobrar o servidor era um bem não amigável kill -9 nos processsos que estavam a 100% já que o próprio monitor do Passenger também não conseguia reciclar os processos travados. Tentamos reproduzir em ambiente de desenvolvimento ou outro ambiente controlado mas essa situação não acontecia, era apenas em produção.

Inicialmente achávamos que poderia ser algum bug no Passenger (chute). Procuramos a respeito em fóruns e listas de discussão. Encontramos relatos como este# que nunca foram confirmados como “bug”. Pensamos em substituir pelo Unicorn mas como não tínhamos certeza que o bug era no Passenger e nem tínhamos muito tempo, a solução – nada elegante – foi fazer um script no cron para matar os processos que ficavam presos em 100% por muito tempo. Não era a solução mas “resolveu” o problema.

Só agora, meses depois, finalmente vi essa descrição do Nunemaker que bate muito com o que passamos e finalmente com um diagnóstico mais preciso. Como ele tentou eu também fiz dumps dos processos com gdb mas me falta conhecimento de gdb, strace e outras ferramentas de debug para encontrar o ponto exato do erro.

A forma de reproduzir é abrir o IRB e executar:

12	str = "http%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26source%3Dweb%26cd%3D1%26sqi%3D2%26ved%3D0CCkQFjAA%26url%3Dhttp%253A%252F%252Fnd.edu%252F%26rct%3Dj%"str =~ /\A(?:%[0-9a-fA-F]{2}\|[^%]+)*\z/

Se sua versão de Ruby ainda tiver o bug de regex, ele vai travar e a CPU vai pra 100%. Ctrl-C no terminal deve matar o processo. Essa situação acontece num aplicativo Web que usa Rack porque especificamente na versão 1.3.0 existe esse código na linha 61. Dependendo de quem estiver acessando seu site (crawlers do Google por exemplo) ele pode desencadear o bug travando seu processo (literalmente um Denial of Service).

Esse erro acontece nos Ruby REE 1.8.7, nos 1.9.2. O teste exato acima não acontece no 1.9.3 porém ele acontece no próximo teste que tentei. Resolvi fazer um micro teste importando exatamente a versão com o bug do Rack:

Estranho que isso passa no meu Ruby 1.9.3-p0 embora essa mesma versão de Ruby falhe com o teste direto no IRB anterior. Ambos executam a mesma Regex na mesma string, só que um trava e a outra retorna (com exceção mas retorna). Ainda não entendi por que, provavelmente estou fazendo algo errado muito simples mas que não estou vendo (alguém tem idéias?)

A versão 1.3.0 foi lançada no dia 23 de maio, aproximadamente a época em que colocamos a aplicação em produção. Me parece que as versões anteriores não tinham essa regex (e por outro lado não validavam a URI acima como errada). Porém não tenho certeza que não estávamos usando o Rack 1.2.5 ou anterior e nesse caso o bug não seria este. Infelizmente não temos mais acesso aos servidores de produção do cliente para ter certeza, mas se não for isso seria uma grande coincidência.

A versão 1.3.1 – lançada no dia 13 de julho – já tem uma correção que modifica a regex para que ela não trave. Portanto a janela onde esse bug ficou no ar foi de 23 de maio a 13 de julho, se alguém rodou um bundle nessa época e travou o Rack para a versão 1.3.0 (cheque no seu Gemfile.lock) esse pode ser um problema ainda ativo no seu servidor e precisa ser verificado.

Para facilitar, a versão do Rails nessa época era 3.0.7, mas chequem projetos mais antigos também. Especialmente se você já viu, aleatoriamente, algum processo se prendendo a 100% de CPU sem nenhuma explicação aparente.

Escrevi este artigo mais como um post-mortem porque passamos por esse problema nessa época de maio a julho no ano passado e ele ficou sem solução, e eu detesto problemas sem solução.

[Off-Topic] Mensagem de Ano Novo - Filosofia

Fabio Akita — Sat, 31 Dec 2011 15:29:16 PST

Este foi um longo ano, pessoalmente foi um dos piores e um dos melhores tudo ao mesmo tempo. Uma consequência foi que bloguei muito pouco, mas 2012 deve ser o ano do retorno. Para fechar o ano bem, acho que este ano com tantas novas startups e tantos novos interessados em explorar as oportunidades de serem empreendedores devem levar a sério e entender a verdadeira filosofia por trás de qualquer empreendimento capitalista (verdadeiramente capitalista e não este capitalismo-misto medíocre que a maioria pratica). Sem uma filosofia adequada, o mundo dos negócios não vai muito longe.

Obviamente, busco minha fonte nos artigos de Ayn Rand e Leonard Peikoff, como uma entrada light vamos ver o artigo Uma Resposta para Empresários, publicado em 15 de maio de 1962, em uma revista de notícias não identificada encontrada entre os documentos de Ayn Rand. Terminando esta introdução, veja o principal, Por que Empresários Precisam de Filosofia, escrito por Leonard Peikoff, e é um trecho do livro de mesmo nome que todo interessado em empreender deveria ler.

Uma Resposta para Empresários

Se você quer salvar o capitalismo só existe um tipo de argumento que você deve adotar, o único que sempre ganhou em qualquer disputa moral: o argumento da auto-estima. Cheque suas premissas, se convença de que sua causa é correta, então lute pelo capitalismo com completa e certeira moral.

A crise mundial de hoje é uma crise moral – e nada menos do que uma revolução moral pode resolvê-la: uma revolução moral para sancionar e completar a conquista política da revolução Americana. Devemos lutar pelo capitalismo, não como uma disputa prática, não como uma disputa econômica, mas, com o maior orgulho de justiça, como uma disputa moral. É isso que o capitalismo merece, e nada menos irá salvá-la.

Gostaria de dizer que você deve começar aplicando ao mundo das idéias o mesmo critério objetivo, lógico, racional de julgamento que você aplica ao mundo dos negócios. Você não julga disputas de negócios usando padrões emocionais – não faça isso em disputas ideológicas. Você não constrói fábricas guiado pelas suas emoções – não deixe suas emoções guiarem suas convicções políticas.

Não tente enganar as pessoas nos negócios

Você não conta com a estupidez dos homens em negócios, você não lança produtos de qualidade inferior “porque as pessoas são idiotas demais para apreciar o melhor”, não faça isso em filosofia política; não endorse ou propague idéias que você sabe serem falsas, na esperança de conquistar o medo, preconceitos ou ignorância das pessoas. Você não engana as pessoas em negócios – não tente fazer isso na filosofia: os chamados homens comuns são perceptivos de forma incomum.

Você não duvida de seu próprio julgamento nos negócios – não duvide no mundo da ideologia; não deixe a bobagem inintelegível dos intelectuais “liberais” o intimidar ou desencorajá-lo; não conclua: “deve ser profundo, porque eu não entendo isso” ou “se é assim que as coisas de intelectuais se parecem, então todas as idéias são impraticáveis e não fazem sentido”. Idéias são o maior e mais crucial poder da Terra.

Você não contrata homens como cabeças dos seus departamentos de negócios, sem conhecimento prévio da natureza dos seus trabalhos e como julgar suas performances – não faça isso em relação ao seu departamento de relações públicas; aprenda a julgar se o que estão lhe vendendo é veneno ou não. Você não contrata doutores-bruxos como mecânicos ou engenheiros – não os contrate como relações públicas.

Conheça seus amigos e seus inimigos

Aprenda a diferenciar seus amigos de seus inimigos. Saiba quem dar suporte em disputas ideológicas e políticas. Se você não consegue dizer livremente, se estiver preso e engasgado pela desgraçada injustiça de tais maus como leis antitruste – no mínimo, não elogie, espalhe ou suporte a filosofia de seus próprios destruidores; não lhes dê a sanção das vítimas. Pense um pouco na possibilidade de estabelecer um sindicato de liberdades civis – para empresários.

E se tem o desejo de ter uma missão ou propósito “social” – não existe serviço maior à humanidade do que lutar pelos seus próprios direitos e propriedades.

[Journey to Japan #3] Exclusive Video Interviews

Fabio Akita — Sun, 27 Nov 2011 20:40:20 PST

It’s been a while since I’ve written about my Ruby Kaigi 2011 trip. Since then I’ve been really busy and I left out lots of great material shamelessly accumulating dust in my hard drive, but no more. Today I was finally able to edit some of that and upload the interviews I have recorded with some of the most well known Japanese Ruby contributors. Wonderful people that I was lucky to meet and that were very friendly to me and eager to tell their stories.

These are the first versions of the edited videos, I still didn’t have time to add English subtitles, but I wanted to upload them as soon as possible so the Japanese community could check them out first. I will try to add the subtitles in the following days (help would be appreciated). The Matz interview in particular has the worst audio as we were in the middle of an after-party in a small bar with very bad acoustics, so I apologize for its quality, I hope you can get most out of it.

Alencar Koga helped me out a lot during the interviews. Coincidentally he is a Brazilian just like me, but he’s been living in Japan for a long time and was able to build a great career, being now the CTO of MTI Japan, one of the largest mobile app developers in the country. Akira Matsuda also helped me a lot, and he is also a very well known Rubyist in Japan. Both were edited out of the videos to make them shorter to watch. I appreciate their help a lot as they will be very useful when I do the English subtitles.

The first three videos were recorded at the after-party in the first day of Ruby Kaigi. I have to admit that I was not in my best shape after having a few drinks and after a full day of event :-) By the way, the second and third video interviews were introduced by me in Brazilian Portuguese instead of English, so forgive me for my confusion. All of them have myself making questions in English and the guests replying back in Japanese. Only the Matz interview is all in English.

Shintaro Kakutani-san was the first one I’ve interviewed, being one of the main organizers of the event and a long time Ruby evangelist in Japan. He is a very active community leader, helping maintain the Japanese Ruby ecosystem.

The second one was Gotou Yuzou-san, he is one of the oldest Ruby Core Committers being the author of both Webrick and OpenSSL. He wrote a few books about Ruby in Japan and he works for the Tokyo branch of Nacl, the company from Matsue that has been contributing to Ruby since the beginning, hiring Matz as a fellow researcher.

The third one was recorded when the party was over. I was able to reach the couple Yasuko and Koichiro Ohba. Yasuko-san is well known being the president of the consulting company EveryLeaf. She employs several Ruby developers and does Ruby related projects and now mobile development as well. She is an example of entrepreneurship in the community. Koichiro-san works for a Heroku-like company in Japan, managing Cloud based infrastructure using JRuby technology. He contributes and evangelizes JRuby, specially in terms of documentation, localization (internationalization, etc).

On the second day of the event I was able to catch up with Nobuyoshi Nakada-san. He is “the” oldest Ruby Core Contributor, and he probably touched every single part of Ruby. He is also known as “the patch monster” as he seems to be a coding machine, being more active through out the last 15 years than Matz himself. He deserved to be the first one Matz chose to follow him at SalesForce.com.

Finally, at the Heroku Drink up in the last day of the event, I was finally able to grab Matz himself for an interview. Having been continuously and consistently on this road for that last few years, you can imagine how thrilled I was for having being able to interview Matz himself in person, at my home land in Japan. But as I’ve warned before, the audio is not good because of all the noise. At least Matz can speak English so everybody will be able to get most of this one.

Enjoy them all. This is for all of my friends in Japan! Thanks again for the hospitality.

Páginas Estáticas no Rails

Fabio Akita — Thu, 10 Nov 2011 19:38:10 PST

Faz tempo que não posto uma dica técnica, vou retornando aos poucos. Hoje uma dica bem simples mas que muitos ainda desconhecem.

Muitos aplicativos Rails tem seções com páginas estáticas, páginas de conteúdo como institucional, instruções, etc. Digamos que para organizar isso você tenha criado um controller chamado “Page”, assim:

1	bundle exec rails g controller Page

O problema é que eu sempre vejo algo parecido com isto no config/routes.rb

123	match "page/hello" => "page#hello" match "page/help" => "page#help" ...

Daí no app/controllers/page_controller.rb encontro:

  def hello
  end

  def help
  end
  ...

Actions vazias de placeholder somente para renderizar páginas estáticas como app/views/page/hello.html.erb. E este exemplo tem apenas duas páginas, agora escale isso para algumas dezenas e você verá logo o code smell de um clássico efeito shotgun: múltiplos match redundantes no routes.rb e múltiplos métodos vazios no controller.

Em vez disso, uma das muitas formas de resolver esse problema é fazer simplesmente isto no arquivo config/routes.rb:

1	get "page/:id" => "page#index", :as => :page

E no controller “Page” ter uma única action:

123	def index render params[:id] end

Agora você pode colocar quantas views quiser em app/views/page e quando chamar http://localhost:3000/page/hello ele irá automaticamente mapear para app/views/page/hello.html.erb.

Eu disse “páginas estáticas” mas na verdade seriam “semi-estáticas” já que normalmente faríamos desta forma porque queremos que a página herde o layout principal e tudo mais. Se for para ser uma página realmente estática, fora do layout padrão do site, etc, você pode simplesmente colocar um html no diretório public.

Dá para melhorar mais isso, fazendo algumas checagens óbvias como validar se o template da página existe:

  def index
    if params[:id] && template_exists?(params[:id], ["page"])
      render params[:id]
    else
      redirect_to '/404.html', :status => 404
    end
  end

A dica é a mesma de sempre: se está parecendo um amontoado de copy & paste em todas as camadas, alguma coisa está definitivamente errada. Como eu disse antes, existem múltiplas maneiras para resolver essa funcionalidade, se tiverem outras melhores, não deixem de comentar.