domingo, 18 de março de 2012

7 meses sem post

É impressionante como o tempo passa rápido. Do nada, já são quase 7 meses sem um único post sequer. Nem eu acredito. Tudo bem que não sou o cara das postagens diárias nem semanais. Mas 7 meses é muito tempo.

O caso é que, o blog acaba sendo muito útil ao dono por conter informações já compiladas e aprovadas. E como tem este tempo todo sem postar nada, o prejuízo é ter que sair buscando coisas que poderiam estar aqui. Além deste, tem ainda o não colaborar com uma comunidade que muito me ajuda. Cada post que deixei de fazer sobre Linux, Rails ou qualquer ou tema, certamente deixou muitas pessoas sem respostas para questões que eu domino fácil. Não que meu conhecimento seja indispensável, mas tem teu seu valor.

De agora em diante vou escrever mais, Eu próprio acabo sentido falta disto. É ruim por não compartilhar, é ruim por não forçar a criatividade, não gera desafios e é mais do que muito ruim para a auto-promoção. Imagine você acessando o blog de um cara como eu é que o último post tem quase 1 ano. Isto queima o filme.

Pelo menos eu consegui durante este tempo juntar algum material que, depois de editado e revisado dará um bom conteúdo aqui. Dentre eles, tenho dois mini tutoriais que pretendo enriquecer sobre como instalar Ruby on Rails em produção com o Fusion Passenger e/ou Nginx, com o Ruby instalado no sistema com um pack bom de gems e permitindo a instalação de gems na pasta do usuário. Isto pode não parecer nada, mas vai procurar informações de como fazer o Rails rodar em um servidor de hospedagem compartilhada cedendo acesso SSH. Nem em Japonês tem um bom, completo e rico.

Estes serão os próximos posts:  Criando um host de com hospedagem compartilhada Ruby on Rails. Um com Apache e outro com Nginx. Só não sei ainda se faço apenas um longo ou se divido em partes.

Esta semana ainda estará aqui.

;-)

segunda-feira, 15 de agosto de 2011

Como foi o Rally on Rails

Começamos bem, muito bem. Tínhamos tudo para ter uma boa participação na competição, até que vieram os problemas:


Tudo começo na sexta, dia 12, quando tive que passar o dia com minha esposa e família, no Hospital Universitário Gaffrée e Guinle, da Unirio, por questões relacionadas à gravidez e ao bebê. No final do dia, voltei para casa. Neste mesmo dia, o Vagner, que passa por problemas de saúde, alergias e outras ingrisias, também faltou. O Igor, ficou na empresa normalmente, até a noite, quando a Viviane foi encontrar-se com ele. O plano era eles levarem para a casa do Vagner os 2 notebooks da empresa, e tocarem de lá o projeto, junto comigo, que chegaria depois. Foi quando tudo foi se complicando.

A Antonieta não estava bem, passava mal e, temendo por sua integridade e do bebê, não pude ir encontrar com a equipe baseada na residência do Vagner, que estava bem. Fiquei trabalhando remotamente com eles enquanto prestava assistência em casa. Algumas horas depois que a competição já havia se iniciado, tive que sair do computador de vez, deixando-os tocando o projeto. A coisa se complicou mais ainda quando descobrimos que estávamos com metade do apartamento sem energia elétrica. Achava eu que o disjuntor havia torrado por causa do chuveiro. Agora tínhamos que aquecer a água no fogão para a Antonieta tomar banho de balde. :-(

No sábado pela manhã, já tínhamos o servidor cedido pela Speedy Rails, pronto, a aplicação base fuuncional e o layout quase pronto. Em casa, eu estava agora envolvido com várias tarefas de preparação para o parto, que nos parecia iminente. De arrumação da casa até passar as roupas do bebê, entre outras, enquanto tentava resolver o problema elétrico que, logo descobri que havia sido causado por técnicos da Light. Segundo o porteiro, eles haviam estado no prédio para efetuar o desligamento do fornecimento de energia de um vizinho do segundo andar. Nos testes que fiz, constatei que uma das duas fases que abastecem o apartamento estava desligada. Liguei então para a Light, ainda cedo, na esperança de que tudo pudesse ser resolvido logo. O atendimento gerou o protocolo número 43767616.

No início da tarde me liga o Vagner, dizendo que estava indo ao hospital com seu primo, pois, segundo ele, havia piorado bastante. A competição agora estava nas mãos do Igor e da Viviane. Eu não podia aplicar quase nada de tempo, mesmo remotamente, e o Vagner só voltaria no início da noite. Chegamos a falar em cancelar a competição, mas os Jedis restantes, bravamente, assumiram a missão e continuaram firmes. Confesso que isto tudo junto, mais a falta de energia elétrica, mil e uma tarefas por fazer para a chegada do Tales (o bebê) e um grande cansaço, me desanimaram um pouco. Mas não havia como desistir, não havia como deixar para outro dia. Era fazer ou fazer. Ainda consegui fazer algo no sábado, mas foi bem pouco mesmo. O Igor e a Vivi levaram tudo praticamente sozinhos noite a dentro.

No domingo, o Vagner estava melhor e voltou para a competição. Em casa, as coisas agora estavam melhores. A Antonieta sentia-se mais segura por ter ido encontrar com os médicos numa consulta e uma pequena bateria de exames. Infelizmente, como persistia ainda o problema elétrico, não pude ir com ela, que teve que ir sozinha com nossa filha Elisa de 6 anos. O interessante, foram duas ligações, uma no sábado a noite, outra no domingo logo cedo, da Central de Relacionamento com o Cliente da Light, querendo saber se o problema estava solucionado. Fiquei pensado que eles imaginaram que o problema fosse interno, que eu não soubesse o que estava falando quando fiz a reclamação e pedido de reparo de emergência. Na segunda ligação, tive que falar com a pessoa que me ligou que, por um passe de mágica, o problema não seria resolvido sem a presença de técnicos. Umas duas horas depois, os técnicos da Light chegaram ao local. O problema sabem qual era? O "fio estava solto" quadro geral de força, que fica lacrado e fortemente protegido. Em 5 minutos resolveram o caso. Coisa que eu faria se tivesse acesso à dita caixa de força. Praticamente 2 dias de problemas e transtornos diversos em casa, com a esposa grávida, sem poder tomar banho gelado, porque os técnicos da Light não sabem efetuar um desligamento sem que interfira nos demais apartamentos e, por total descaso da centra de atendimento, que me passou a impressão de esperarem o problema se resolver, como se fosse por minha culpa.

É foda ser tratado como se o tempo todo você seja um imbecil que não sabe o que é barra de título no navegador web, que não sabe a diferença entre uma chave de fendas e um martelo, ou que não sabe usar uma chave de testes e identificar se o problema é interno ou externo. Mas bem, foi resolvido e, decidirei depois se processo esta empresa, que nos últimos anos, tinha como boa e séria.

A solução do problema elétrico foi a boa para eu retornar ao Rally, mas agora restavam apenas 5 horas de competição. Até pensei em ir para a casa do Vagner, mas todos concordaram que o melhor era eu ficar mesmo remoto. Os três Jedis lá estava exaustos e toda equipe com uma carga de stress bem grande, mas conseguimos fazer, digamos que 60% do que pretendíamos em tempo de fechar bonito a competição. A aplicação, contudo, não chegou a ficar exatamente funcional, com problemas de interface, traduções por fazer e outras coisas mais. Mas todos ficamos com a sensação de missão cumprida.

Independente de qualquer coisa, nós participamos da competição, cada um de nós deu o máximo de si e, quando outros desistiriam, nós continuamos. Diversas equipes nem chegaram a cadastrar seus aplicativos, mas nós estávamos lá.

No final do dia, a Viviane e o Igor ainda foram lá em casa, para trazer meu notebook e para a ela poder ainda trabalhar em um projeto seu. Um site em Wordpress que deveria entregar hoje.

O mérito final é do Igor, da Viviane e do Vagner. 
Estes 3 são realmente Jedis.
Ninja é fraco!
Ele usa bombinhas de fumaça para fugir.
A Equipe Cidadelas Jedis, até morrendo, se mantém firme.

E o Dumuzzi não ficou mal não, ficou um tanto incompleto, mas não está feio e ainda será concluído. Vamos seguir com nossos planos e, em breve teremos nosso serviço de monitoramento operacional.

Meus agradecimentos à todos da Equipe Cidadelas Jedis.

E vem ai o Rails Rumble, estaremos lá.

sexta-feira, 12 de agosto de 2011

Começou o Rally on Rails

A Equipe Cidadelas Jedis ja está na corrida. Nosso App, como dito no post anterior é o Dumuzzi, um serviço de monitoramento de hosts e serviços, que logo estará acessível no VPS cedido pela Speed Rails para a competição, nos endereços http://65.39.226.150/ e http://rally.dumuzzi.com/.

Devido a problemas relacionados a gravidez de minha esposa, tive que ficar de casa, trabalhando remotamente com o resto da Equipe, que está baseada na casa do Vagner.

Até agora está indo tudo bem, nosso treinamento para trabalho remoto está dando resultados. :-D

Torçam por nós, que somos guiados pela força.

quinta-feira, 11 de agosto de 2011

Dumuzzi Hosts Monitor e o Rally on Rails

Nos dias 13 e 15 de agosto acontece o Rally on Rails, evento ao estilo Rails Rumble no qual os participantes tem 48 horas para desenvolver uma aplicação Ruby on Rails completa. A diferença, é que o Rally é somente para desenvolvedores naturais da zona a qual chamam de América Latina, ou sub-américa da América do Norte.

Questões politico-sócio-geográficas à parte, o evento é patrocinado por empresas como Github, Crowd Interactive e O'Reilly, além de comunidades como Rails México e Coders Venezuela, entre outras. A lista completa de patrocinadores pode ser vista na página específica no site da competição.

A Equipe Cidadelas está cadastrada como a número 57, com o nome Cidadelas Jedis e planejamos desenvolver o Dumuzzi, um sistema de monitoramento de hosts e serviços, que atuará de forma distribuída, rodando em pelo menos 3 continentes, inicialmente contando com 5 máquinas no Array.

O Dumuzzi é a evolução de um antigo protótipo que, inicialmente, era chamado de rCluster Monitor, já citado nos posts rCluster Monitor - ./startO que fazer quando a única opção é mudar e cliente opta pela não-mudança. O projeto original, apesar de funcionar bem com testes de Ping e HTTP, nunca saiu do protótipo "toscogildo", mas desta vez se tornará um produto funcional, desenvolvido com Ruby 1.9.2 e Rails 3.1.0.rc5, rodará no domínio dumuzzi.com, será gratuito e de código aberto.

Dumuzzi  é o Filho fiel, deus sumério, consorte de Inanna, irmão de Geshtin-anna, rei-pastor de Uruk, guardião do portal dos céus de Anu, junto com Gishzida, e pescador de Ku'ara.

Um serviço de monitoramento eficiente é, de fato, o Guardião do Portal dos Céus de um SysAdmin, já que, tendo certeza de que seus servidores estão online, ele pode dormir tranquilo, ir ao horaextra, dojo e demais eventos e atividades de gente normal, motivo que nos levou à selecionar o nome. :-D

A equipe é formada por Vagner Zampieri, Igor Lanes, Viviane Nonato e Fernando Kosh, eu.

Na Cidadelas somos guiados pela força, que nos mantém firmes e seguros em todas as nossas missões. Que venha o evento, vamos desenvolver nosso aplicativo confiantes de uma boa colocação.

Que a força esteja com todos nós!

sexta-feira, 8 de julho de 2011

rake db:migrate - couldn't parse YAML

Colocando um projeto em Rails 3.1 em produção, tive um problema novo, que me custou uma meia hora para resolver:

 $ rake db:migrate RAILS_ENV=production
 rake aborted!
 couldn't parse YAML at line 20 column 16

 Tasks: TOP => db:migrate => environment
 (See full trace by running task with --trace)

Doideira! Nunca tinha visto isso. Numa busca mais ou menos rápida, encontrei este tópico no StackOverFlow, no qual a resposta do vicvega resolveu meu problema. Ele diz para adicionar duas linhas ao config/boot.rb:


 require 'yaml'
 YAML::ENGINE.yamler= 'syck'

Em desenvolvimento não percebi o problema. Então, fiz assim:


if ENV['RAILS_ENV'] == 'production'
  require 'yaml'
  YAML::ENGINE.yamler= 'syck'
end

E ficou perfeito. Mas há outras causas prováveis para o problema. 

As versões em uso:

 ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]
 Rails 3.1.0.rc4
 Rake 0.9.2

quinta-feira, 7 de julho de 2011

Cadastro: Usar ou não campos para DDD e DDI?

Desde que iniciei na area de desenvolvimento, sempre implementei campos para DDD e DDI nos formulários de cadastro. De lá para cá, observei algumas mudanças que, até causaram certos problemas no aplicativos:

  1. Primeiro vi problemas com o tamanho dos campos: Nesta época, aqui no Rio os telefones eram compostos por 7 dígitos. Logo logo mudou para 8
  2. As pessoas só possuíam um único telefone, quando possuíam.
  3. Era comum o campo Fax, também com os campo DDD e DDI (este último só em casos especiais.)
  4. Usava-se somente um campo DDD e/ou DDI, considerando que os demais telefones e números de Fax fossem do mesmo código de area 
 Hoje, é comum uma pessoa ter vários números de telefone. Tenho amigos que tem telefones do Rio e de Petrópolis, empresas tem números em vários estados, quase não se usa mais Fax, existe SIP/Skype e, mesmo em casa, já se tem mais de um número fixo.

Fica inviável ter campos para DDD/I ao lado de cada número de telefone.

Como se resolve isso?

Somente utilizando um único campo sem limitação para os números de telefone e, prevendo que a pessoa possa ter N números. Assim, cria-se modelos/tabelas especificas para as formas de contato, que agora devem incluir e-mail, Gtalk, MSN, Twitter, entre outros, relacionando-as com o cadastro da pessoa, que agora vai digitar tudo neste campo.

Para quem achar que o usuário não vai saber usar, fica a velha dica do exemplo, onde irá informar ao usuário como preencher o campo. Ex.: + 55 21 1234-5678

Isso já elimina vários problemas. E tem mais: Já tem operadoras de telefone falando em números com 9 dígitos. Não é uma maravilha? Logo, logo os números de telefone vão ser como IPs, precisando de um serviço de tradução de nomes, como DNS. Será o PNS de Phone Name Server . ;-)

O que me dizem? Mantém ou remove os campos DDD e/ou DDI?

quarta-feira, 6 de julho de 2011

familiakosh.org

No ar desde 27 de Junho de 2011, o nosso blog da Família foi feito compartilhar nossas aventuras e tudo que for possível postar. Já tínhamos a ideia de fazer um site, mas sabe como é, sempre ficava para depois. Foi assim até que a Antonieta, passou a postar umas notas que ela apelidou de "Proezas da Elisa", o que fez muita gente gostar e sempre acompanhá-las. Estas mesmas pessoas, acabavam sempre  sugerindo e sugerindo que fizéssemos um blog ou um site. Não podíamos mais adiar.

Pois é. Ficamos em xeque: Única saída, fazer o site.

Considerei utilizar algo pronto, um CMS, Wordpress, mas vi uma boa oportunidade para efetuar testes e tudo mais. Muitas novas tecnologias à explorar dentro de minha própria área de atuação, nas ferramentas que desenvolvo. Assim, usando o Engine da Cidadelas e feito em Rails 3.1.0-RC4, usando MySQL como banco de dados e rodando no Ruby 1.9.2, implementei em umas horas o site da Família, que pode ser acessado no endereço http://familiakosh.org. Família Kosh.

No servidor, roda com Unicorn + Ngnix no Linux. Uma das melhores combinações que já experimentei.