Hoje ao migrar para o Delayed_job 2.0.2 me dei conta que os erros que viessem a acontecer no nos jobs em background não seriam enviados para o Hoptoad.

O Hoptoad por padrão só captas as exceptions que ocorrerem no controller. Logo seus rake tasks e background_jobs ficam de fora.

Para resolver este problema a melhor forma que encontrei foi fazer um hack leve no delayed_job. Sempre que faço algum hack acho imprescindível que este seja feito na aplicação e não no fonte da gem e criar uma versão própria. Ter uma versão própria de uma gem com hacks eu acho a pior alternativa possível.

Hoje ao migrar para o Delayed_job 2.0.2 me dei conta que os erros que viessem a acontecer no nos jobs em background não seriam enviados para o Hoptoad.

O Hoptoad por padrão só captas as exceptions que ocorrerem no controller. Logo seus rake tasks e background_jobs ficam de fora.

Para resolver este problema a melhor forma que encontrei foi fazer um hack leve no delayed_job. Sempre que faço algum hack acho imprescindível que este seja feito na aplicação e não no fonte da gem e criar uma versão própria. Ter uma versão própria de uma gem com hacks eu acho a pior alternativa possível.

Depois de abrir um ticket no Hoptoad eles me disseram que não tinham nada pronto em relação a isto. A minha solução foi primeiro escrever um Job que falhe e os specs que comprovem isto:

Em seguida o que fiz foi dentro do initializer que configuro o Delayed_job aplicar o hack. Como o Delayed_job já tem um método que trata as falhas dos jobs o que eu queria fazer é apenas também chamar o notify do Hoptoad e rodar o processo comun do DJ.

Para não duplicar o método, o que seria uma péssima idéia e nada DRY, eu usei uma técnica conhecida como Alias Chain para armazenar o método original e sobreescreve-lo com o meu novo método que faz a inclusão do Hoptoad e depois chamar o original armazenado.

Esta é uma técnica simples mas que ajuda muito em situações como esta. Veremos esta e muitas outras formas de solucionar problemas diversos no novo curso da eGenial: Imersão Ruby on Rails , espero ver todos lá

No mês passado concluímos mais um projeto. O tempo anda um pouco corrido por aqui, então acabamos divulgando hoje aqui no blog. Desta vez o projeto foi o blog Ameixa Japonesa (ameixajaponesa.com.br), onde o cliente queria melhorar radicalmente o blog antigo, que já fazia bastante sucesso.

Foi um projeto bem interessante e com um tema muito agradável. Uma das principais exigências foi a capacidade de suportar imagens grandes, além de ser possível o cliente administrar tudo com conhecimento técnico zero.

Nosso papel foi migrar do Blogger para algo mais profissional, com um layout renovado e moderno mas “clean”. O resultado foi a transformação do blog abaixo:

Para este novo:

Como foi desenvolvido

Como o blog original estava hospedado no Blogger, nem cogitamos a idéia de mante-lo lá devido às dificuldades de customização da plataforma, o painel administrativo fraco, além de não termos muito controle sobre o servidor.

Codificar um sistema de blog inteiro não estava dentro dos planos, então muitos poderiam argumentar o uso de algum CMS em Ruby. O grande problema é que Ruby possui bons CMS’s, mas nada ideal para blogs quando o objetivo do cliente é algo profissional com vários posts ao dia.

O projetos minimalistas com Enky estavam totalmente fora de cogitação já que o cliente não é técnico e seria preciso algo mais robusto. Mephisto (o que usamos para o nosso próprio blog) é interessante mas está muito abaixo das funcionalidades do WordPress. O Typo parece ter voltado a ser uma plataforma interessante e em constante desenvolvimento, inclusive atualizado para o Rails 2.3.5 e Ruby Enterprise Edition. Porém não chegamos a testá-lo novamente pois já tivemos problemas com ele anos atrás (mas assim que sobrar um tempo vamos voltar a experimentá-lo).

Nós honestamente gostaríamos muito que tivéssemos algo tão robusto em funcionalidades e simples de se usar como WordPress, porém escrito em Ruby. Mas como esta não é a realidade, nos restará apenas o WP.

Antes que comecem a argumentar que o WP é muito bom, nós dizemos que, de fato ele é muito bom se você vai apenas pegar um template pronto e colocar um blog default online. O grande problema do WordPress é a confusão que é o código fonte do projeto, além de ser quase impossível encontrar plugins de qualidade. Então, se você precisa criar um template próprio ou acrescentar funcionalidades na administração, você está por sua conta e de pouco adiantará os milhares de plugins.

Como o serviço é muito bom e a forma como o cliente administra o blog é sem dúvida uma das melhores do mercado, não sobra outra alternativa. O grande problema é que como desenvolvedor Ruby, estamos acostumados com dezenas de boas práticas do mundo Rails como: divisão de ambientes, deploy automatizado, testes automatizados, organização em arquitetura MVC e etc. Este tipo de organização e prática passa bem longe do WordPress.

De qualquer forma, é possível contornar esta situação e criar algo razoavelmente simples de manter. O que fazemos é evitar ao máximo os plugins e criando métodos para ignorar práticas ruins (incentivadas pelo WP) como pegar posts por ID da categoria.

Colocando online

Mais uma coisa que consideramos inaceitável é atualização de plugins e do próprio WordPress direto pelo site. Por isso sempre trabalhamos com atualizações e qualquer alteração localmente. É uma pena não existir esta cultura e o WP não ter sido feito pensando assim. Para remediar o caos que pode ser o deploy, adaptamos uma receita do Capistrano, transformando o deploy tão trivial quanto em Ruby.

Criamos a receita abaixo e versionamos o projeto com Git:

O que ocorre acima é nada mais do que configurar algumas coisas como domínio, repositório git e caminha do projeto no servidor (nada diferente de Rails). A diferença está nas pastas compartilhadas entre cada deploy. Mantemos avatares, uploads, cache e ads em uma pasta compartilhada.

Nós não versionamos o wp-config.php que contém as senhas do DB, então criamos uma tarefa para fazer o upload deste arquivo.

Com tudo configurado agora colocamos as alterações online rodando apenas o famoso comando: cap deploy

Resultado final

O apanhado final do projeto foi um template customizado, feito a partir do zero (sem os lixos como posts por ID da categoria). Quase não usamos plugins, e os existentes foram bem analisados e/ou fizemos vários ajustes. Utilizamos uma forma própria de deploy automatizado via Capistrano com Git. E para terminar, um arquivo de funções gigante que reproduz coisa muita que estamos acostumados no Rails (métodos link_to, image_tag, etc).

Desta forma temos um projeto simples de manter e bem organizado além de atender às expectativas do cliente.

Internet Explorer

Não é novidade que a maior pérola da internet é o Internet Explorer. É incontestável a inferioridade do navegador. E para este projeto seguimos a tendência atual da internet de evitar as versões mais antigas do IE.

No Ameixa seguimos o que já explicamos neste post . O site é compatível com IE6 e IE7 e contém todos os hacks para o layout ficar perfeito nestes e nos demais navegadores. Ao acessar o site com os IE6 e IE7, o usuário é avisado que existe uma nova versão do navegador e que ele deveria atualizá-lo.

O mais interessante é que IE6 não representa nem 5% do usuários do site. O IE representa no geral apenas 30% do tráfego total (mas ficando em 2º lugar). O primeiro colocado é o Firefox, o terceiro o Chrome e o Safari também possui uma boa fatia de acessos.

(Antes de tudo deixem-me dizer que sou fã de vários produtos Apple. Tenho um MacBook Pro, um iPhone e muitos periféricos e por isso a minha visão tentará ser o mais imparcial possível!)

Para quem tem estado atento ao Twitter e aos blogs de tecnologia e web, esta imagem tem estado em todo o lado. Foi na Terça-Feira, que a Apple mostrou o seu mais recente gadget, o iPad.

O iPad é a tentativa da Apple de tentar preencher um nicho de mercado / nicho de tecnologia que fica ali um pouco entre os smartphones e os portáteis / desktops. É aquele instrumento que pode ser utilizado para coisas mais “light” como surfar na web e ver uns filmes.

Assim como o iPhone, o iPad tenta ser um produto revolucionário e que, como o próprio Steve Jobs o diz “A melhor experiência para surfar a web“.

Será?

Como pode um produto tentar ser a melhor forma de surfar na web se não possui um plug-in que está instalado em 95% dos dispositivos que se ligam à Internet (Flash)? Sem ter um plug-in em que estão a ser investidos milhares de euros neste momento (Silverlight)? Aliás, sem ter nenhum plug-in a não ser os criados pela própria Apple e que a Apple acha que são os mais apropriados para nós?

Desde o iPhone que a Apple já nos tinha mostrado que vai deixar o Flash de fora dos seus produtos. Mas, se bem que no iPhone a desculpa era a bateria e o processador, neste momento, no iPad não há nada que desculpe o facto da Apple tentar manter todos os plug-ins de fora dos seus browsers obrigando os utilizadores a navegar na web da forma como a Apple acha que é o mais interessante.

Porquê que é que Apple faz isto então?

Simples! Porque a Apple quer fazer dinheiro vendendo aplicações na sua galinha dos ovos de ouro, a App Store e assim não deixar “passear” as aplicações e os modelos de distribuição por onde não os pode controlar.

Se este é um bom modelo? Claro que é! Se pensarmos em termos de negócio para a Apple é um sistema perfeito! Obrigamos os nossos utilizadores a utilizar a nossa ferramenta para terem acesso a jogos, aplicações e outros modelos que geram retorno imediato para a Apple.

O problema é que, pela primeira vez, parece que há muita gente que não está de acordo com as explicações da Apple. Ninguém acredita que o iPad não aguenta com o Flash Player.

O que é que isto tem a ver com o HTML5? Tudo! A Apple está a tentar gerar todo o buzz em volta desta tecnologia que, sinceramente, antes de ser inovadora já não o é.

Confusos?! Fácil!

1- Será muito difícil para o html5 gerar, com tanta facilidade, aplicações ricas para os clientes e que funcionem perfeitamente em todo o lado (mobile, desktop, browser);

2 – Que a experiência seja independente de sistema, independente de browser, etc.;

3 – Que tenham servidores dedicados para dar ao utilizador a melhor experiência em vídeo;

4 – Que o Player de vídeo possa ser tão “estendido” ao ponto de se conseguir coisas como o Youtube.

5 – Que faça ISTO!

Enquanto o HTML5, o supracitado canvas e a tag <video> andam a tentar fazer coisas que o Flash já faz, o Flash já anda a tentar chegar a outros voos. Se formos ver o caso das RIA, com a nova versão do ActionScript 3.0 e principalmente com o Flex, a Adobe deu passos importantes para ser tornar um sério concorrente para aplicações em desktop e web. Basta ver casos como o Aviary que é uma ferramenta extremamente rica e que está na web para qualquer um aceder.

Ok, podem-me falar do Google Docs, Gmail, Google Wave e etc. Mas qual é aqui o denominador comum? o Google! Que é tão só uma das maiores empresas do Mundo a produzir conteúdo Web e que tem os recursos que quase nenhuma empresa no Mundo tem…

Mais. Até o HTML5 ser oficialmente um standard ainda vai demorar muito tempo. Para já temos de andar com hacks and tricks para podermos fazer com que tudo fique igual em todos os browsers (à lá Internet Explorer) o que faz com que o tempo despendido para criar aplicações demore muito mais tempo tanto a criar como na fase do debug.

Em resumo…

Se bem que a Apple está claramente a tentar divergir a web para um sistema mais de serviços onde, para cada conteúdo temos um software e uma aplicação dedicada para o efeito (ouvia ontem uma pessoa a dizer que a intenção da Apple é simplesmente acabar com os browsers), cabe a cada pessoa / empresa decidir qual o melhor veículo para dar a conhecer ou demonstrar um seu produto.

Anda por aí uma discussão enorme com dezenas de posts em blogs onde há sempre quem puxe para o lado do Flash, quem puxe para o lado do HTML e para quem discuta estes valores de uma forma basta acalorada e que demonstra a paixão que temos pelas tecnologias em que criamos e sentimos necessidade de as defender.

No fim de contas, o que interessa aqui é que para cada projecto. Devemos utilizar HTML5, JavaScript, Ajax e amigos? Claro que sim! Devemos sempre utilizar a ferramenta correcta para fazer o trabalho da melhor forma!

Se o melhor caminho é seguir empresas que nos tentam cortar o acesso à forma como nós queremos ver a web? NÃO! Por mais banners, mais consumos de recursos e mais crashes que um plug-in dê (Uma observação. Programo em Flash no meu MacBookPro há mais de dois anos e ele nunca crashou por culpa do Flash. Tive sorte? Talvez ) devemos sempre optar por uma web livre e só assim se consegue a inovação!

Ah! E não, o Flash não vai acabar

Olá,

É muito comum no Flex o programador criar componentes para facilitar sua vida, porém, nem sempre você tem a necessidade de criar uma Library para isso, ou seja, você acaba customizando componentes dentro da sua própria aplicação. Porém, em algumas situações, você pode criar um componente “pai” e alguns “filhos”, usando a herança. Geralmente nesses casos você só usa na sua aplicação os componentes “filhos”, o componente “pai” é a base para eles e ele não deve ser utilizado em sua aplicação. Agora, como remover ele de sua aba “Custom” no FlexBuilder?

Existe uma forma simples de fazer isso, você fará o uso da metadata ExcludeClass.

Para exemplificar essa situação, iremos criar a seguinte situação. Um componente base que eu devo usar para os botões da minha aplicação, e depois, iremos criar um botão para o uso na aplicação. Vale lembrar que essa situação é apenas para ilustrar o uso da metadata e não é um padrão para criação de botões, até porque o componente pai irá herdar suas propriedades de um Canvas.

Segue abaixo, o código fonte do componente principal: Botao

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package br.com.horochovec
{
	import mx.containers.Canvas;
 
	public class Botao extends Canvas
	{
 
		public function Botao()
		{
			super();
		}
 
	}
 
}

Feito isso, iremos criar um novo componentes, que iremos chamar de BotaoOK:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package br.com.horochovec
{
	import br.com.horochovec.Botao;
 
	public class BotaoOK extends Botao
	{
		public function BotaoOK()
		{
			super();
 
		}
 
	}
}

Dessa forma, teremos o componente BotaoOK pronto para o uso, porém, no grupo “Custom” de meus componentes no FlexBuilder, eu tenho também disponivel para o uso o componente Botao, que é o componente pai, e eu não quero utilizá-lo em meu projeto. Quero removê-lo da lista, para que nenhum desenvolvedor utilize o mesmo. Como devo proceder?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package br.com.horochovec
{
	import mx.containers.Canvas;
 
	[ExcludeClass]
	public class Botao extends Canvas
	{
 
		public function Botao()
		{
			super();
		}
 
	}
 
}

Pronto. Adicionando a Metadata [ExcludeClass] dentro do seu componente, ele não estará mais disponivel para o uso em minha aplicação, mas poderei continuar usando o componente pai para ser base de outros componentes.

Espero ter contribuido,

Abraços, dúvidas? Comentem!