Quem usa twitter sabe da dificuldade de encontrar um cliente desktop que se encaixe em todos seus anseios, afinal, cada ser humano tem suas preferências e besteiras, os meus eram:

- Ser de código aberto/livre

- Leve

- Descomplicado e bonito

Depois de uma longa saga atrás do software perfeito, eu encontrei o Hotot, contruído sob Python+GTK, porém com a maior parte do código feito em Javascript…bem diferente =). O Hotot por ser um software bem novo (Outubro de 2010) ainda precisa melhorar bastante para alcançar as funcionalidades dos principais players do mundo Twitter, mais uma me fazia falta: a impossibilidade de mudar o seu encurtador de urls padrão, o Bit.ly. Nada contra o Bit.ly, mas eu queria usar o Jazu.in, pois além de ser desenvolvido por um conterrâneo meu, o Gleydson Costa, é uma ferramenta com várias “features”(olha lá o site e veja todas) que muitos dos grandes encurtadores não possui. Com a impossibilidade de mudar via painel de configuração, resolvi ir ao código, afinal, é de código aberto!

Esse é o hotot...bonitinho né ? =)

Aqui começa uma história interessante: Encontrei o trecho de código que iria ser mudado:

short_url_base: ‘http://api.bit.ly/v3/shorten?login=shellex&apiKey=R_81c9ac2c7aa64b6d311ff19d48030d6c&format=json&longUrl=’,

Bem…fácil né ? Só mudar a URL e apontar para a API do Jazu.in, correto ? Não, pequeno karatê kid…o trabalho seria mais árduo. A API do Bit.ly me retornava isso se eu fosse encurtar o endereõ da Veezor:

Entrada: http://api.bit.ly/v3/shorten?login=shellex&apiKey=R_81c9ac2c7aa64b6d311ff19d48030d6c&format=json&longUrl=http://www.veezor.com
Saída: { “status_code”: 200, “status_txt”: “OK”, “data”: { “long_url”: “http:\/\/www.veezor.com”, “url”: “http:\/\/bit.ly\/9m5ZyL”, “hash”: “9m5ZyL”, “global_hash”: “9fnqq3″, “new_hash”: 0 } }

Ou seja, um retorno no formato JSON. Enquanto a API disponível no Jazu.in funcionava assim:

Entrada: http://jazu.in/api.php?url=http://www.veezor.com
Saída: http://jazu.in/bgC

Humm…a URL já encurtada em texto puro. Legal, mas não era o que o Hotot esperava nesse trecho de código:

$(‘#btn_shorturl’).click(
function (event) {
var procs = [];
var urls = [];
var _requset = function (i) {
var req_url = ui.StatusBox.short_url_base + urls[i];
procs.push(function () {
lib.network.do_request(‘GET’,
req_url,
{},
{},
[],
function (results) {
var text = $(‘#tbox_status’).val();
text = text.replace(results.data.long_url, results.data.url);
$(‘#tbox_status’).val(text);
$(window).dequeue(‘_short_url’);

Eu tinha 2 alternativas: Mudar o código de tratamento de retorno da API do Jazu.in ou mudar o Jazu.in para me retornar em JSON =) ! Cheguei a cogitar fazer uma mudança radical no código, alterando para o formato texto puro do Jazu.in, mas resolvi recorrer ao “dono da bola”, o Gleydson Costa, mais conhecido como @costalince no Twitter, o dono do Jazu.in. Eis o trecho do meu bate-papo com o mesmo:

às 17:33

costalince: fala Gustavo

eu: Fala Gleydson blz ? Rpz…tava aqui eu querendo usar o jazu no meu client de twitter…ai resolvi revirar o codigo é um otimo cliente pra Linux, pouco conhecido, o Hotot o ruim/bom é q eh todo javascript com algumas coisas em python o padrão dele é o bit.ly e ele faz um tratamento pro retorno do bit.ly q eh bem diferente da tua api….ele json

costalince: hummm

eu: deixa eu abrir aqui oq eu tava mexendo

costalince: se vc me passar o formato JSon que ele precisa, posso providenciar pra vc

eu: mas ai vc vai disponibizar outra caminho da api pra isso ? acho mais fácil eu “patchear” pra o teu formato…q eh url pronta …bem…

costalince: faço sim, sem problemas

às 18:03

eu: Gleydson…vou ter q sair agora…quiser deixar pra amanhã ou depois viu ?! Tem pressa não rsrsrsrs =)

costalince: já está feito

eu: ah eh ? vije….então passa o link preu testar =)

costalince: http://jazu.in/api2.php?url=http://meiobit.com/76953/eike-batista-apple-brasil-montadora/&type=json

eu: ok….testar agora aqui

costalince: essa api2 será a API mesmo, criei a 2 só pra testar
http://jazu.in/api.php?url=http://meiobit.com/76953/eike-batista-apple-brasil-montadora/&type=json já pode usar assim

eu: ah blz!

costalince: deu certo aí o retorno?

eu: o retorno sim..to vendo na aplicação

costalince: massa

eu: Funcionando!=)

costalince: olhae que bacana

eu: Perfeito…só mudar o parametro…nem prescisa de um patch =)

Resultado: API nova pro Jazu.in retornando JSON e um usuário do Hotot feliz em 30 minutos =) . Seguem as modificações:

Jazu.in

Entrada: http://jazu.in/api.php?type=json&url=http://www.veezor.com

Saída: {“status_code”:200,”status_txt”:”OK”,”data”:{“long_url”:”http:\/\/www.veezor.com”,”url”:”http:\/\/jazu.in\/bgC”,”hash”:”bgC”}}

Hotot (Ubuntu, home do usuário/hotot/data/ui/js/ui.status_box.js , linha 40)

Antes: short_url_base: ‘http://api.bit.ly/v3/shorten?login=shellex&apiKey=R_81c9ac2c7aa64b6d311ff19d48030d6c&format=json&longUrl=’,

Depois: short_url_base: ‘http://jazu.in/api.php?type=json&url=’,

Prá facilitar a vida dos que querem modificar eu disponibilizei um “mini-patch” e um tutorial para Ubuntu (é a distro que uso, testem em outras e me mandem feedback) para fazer a modificação. Use por sua conta e risco =) :

Baixe o patch aqui e salve na pasta hotot, que se encontra home do seu usuário. Ex. /home/gustavonfr/hotot/

Na shell/console, dentro da pasta hotot faça: patch -p1 -i hotot_jazuin_gustavonfr.patch

Após aplicado o patch, no Ubuntu, execute o script install.ubuntu, que se encontra dentro da pasta hotot: ./install.ubuntu

Pronto…você já tem o Hotot com o Jazu.in como encurtador de URL! 

Sugestões, perguntas e etc nos comentários. OBS.: Não costumo ser desenvolvedor ou contribuidor de código, então me desculpem qualquer gafe nesse processo de disponibilização o patch, é meramente falta de costume =)

No sábado passado, dia 02/10/2010, realizei a palestra Desvendando as Redes Virtuais Privadas, no IT SYSOP DAY, evento promovido pela IT Cursos, na qual eu tentei passar a essência das tecnologias de VPNs utilizadas no mercado. O tempo foi curto e corrido, mas deu para passar um pouco das possibilidades de se trabalhar com esse tipo de tecnologia. Disponibilizo em PDF e ODP(BROffice/LibreOffice) a palestra que inclui a parte de configuração de serviços de OpenVPN e PPTP nos últimos slides:

Download versão em PDF

Download versão em ODP

Nesse mundo de twitters, facebooks, foursquares e outras redes, ter uma aplicação de uso público rodando em um servidor dedicado, dentro da empresa, soa como amador. Hoje, rodar na “nuvem”, é tão obrigatório quanto ter um perfil nessas redes citadas. Vários motivos são citados como o auge do mundo da computação: redução de custos, computação verde, escalabilidade, poder de processamento, armazenamento que beira o infinito – tudo isso pode ser sim associado a cloud computing, mas nem tudo são flores. Já é citado em revistas da área, que empresas que estão colocando toda TI nas nuvens, e isso pode ser preocupante quando “toda TI” é levada ao pé da letra.

Sou um grande fã de serviços nas nuvens e das APIs que permitem integrar esses serviços as nossas aplicações ou até outros serviços, mas uma coisa tem que se revelada para aqueles que não são usuários tão ativos da nuvem e simplesmente assistem a ela como a nova maravilha da computação: a nuvem falha !

Um dos principais serviços de cloud computing é o Amazon Web Services, ou simplesmente, AWS. O AWS, como dá para perceber pelo nome, é gerenciado pela Amazon, grande player do mundo do comercio eletrônico, que viu a possibilidade de oferecer o poder de sua infraestrutura computacional, construída para suportar o seu portal, para o público em geral. O AWS mantém um site com o estado da sua nuvem, o Service Health Dashboard, trazendo assim transparência para seus usuários de possíveis problemas que possam acontecer. O problema é que sempre existe um relatório de problema ocorrido na página ! E por incrível que pareça isso já virou cotidiano do serviço.

Um dos problemas que mais percebo, pelo fato de usar mais o serviço de armazenamento, é no S3 (Simple Storage Service), que tem apresentado erros nas API e no armazenamento, podendo até ocorrer perda de dados ! Olhando o a página de estado dos serviços, no dia 04 de agosto, vi que outros serviços também estavam passando por problemas. Puxando o histórico de dias anteriores, percebe-se que o mês de julho foi turbulento no AWS.

A questão aqui não é desqualificar o serviço da Amazon, que continuo fã mesmo assim, mas alertar os calouros do mundo das nuvens. A Amazon se mostra rápida e eficaz para resolver as instabilidades na nuvem, mas mesmo assim não se pode apostar todas “fichas” num único ponto de falha. Já se fala por ai em soluções multi ponto nas nuvens utilizando serviços de empresas diferentes, ou ainda a “velha” infraestrutura local como ponto de apoio da nuvem

Domingo, dia 15/08/2010, estarei palestrando no evento Infofertas 2010 promovido pela Miranda Computação, no Natal Shopping, Natal-RN. O tema será negócios no mundo aberto e livre da computação em que vivemos hoje, abordando desde de como surgiu essa história de software livre, decisões estratégicas de empresas que mudaram os rumos da informática, chegando até aos empreendimentos de tecnologia aberta.

Hoje, negócios baseados em tecnologias abertas dominam o mercado e se mostram uma forma eficaz de “ser pequeno e enfrentar os grandes”. As famosas startups , em sua grande maioria, utilizam software livre atrelado a ótimas idéias e incomodam os grandes players do mercado, acontecendo até desses mesmos grandes adquiriem esses pequenos e trazer os recurso humano e idéias para dentro de seus grandes escritórios. Um exemploe nem tão recente de um grande que compra um pequeno é da Oracle, famosa pelo seus banco de dados, que adquiriu a Sun(tá a Sun não é pequena) visando principalmente o MySQL(esse sim é um “pequeno” que incomodava a Oracle), que havia sido adquirido anteriormente pela Sun.

Convido a todos a irem a bater um papo comigo sobre software livre e negócios em Ti na atualidade.

Update: Já podem baixar a apresentação no formato ODP (OpenOffice/BrOffice): download

Pessoas menos familiarizadas com sistemas de backup relacionam o tema a simplesmente fazer cópia de segurança em pendrive, HD externo, CD ou DVD, mas quando é trazido o tema para dentro de um ambiente corporativo de uma média ou grande empresa(ou por que não, numa pequena e organizada empresa) outras soluções podem ser citados. Fazer backups em disco ou em fita pode surgir como dúvida em alguns departamentos de TI, muitas vezes por desconhecimento ou falta de orientação.

O que aparenta a todos é que backup em disco será sempre a melhor opção, uma vez que a fita parece uma solução muito ultrapassada, lembrando tempos onde esse formato de mídia era a evolução dos cartões perfurados. A resistência ao longo dos anos como opção para armazenamento reflete a sua principal característica, a durabilidade . Uma fita pode durar até 30 anos se armazenada de acordo com as recomendações, sendo uma ótima opção para armazenamento de longo prazo, superando qualquer expectativa em relação aos HDs – ou você imagina utilizar um mesmo HD por mais de 10 anos? Por exemplo, um cenário onde o sistema de saúde precisa manter informações clínicas de um paciente, a necessidade de armazenamento de longo prazo é prioridade, permitindo um médico avaliar um adulto pelo seu histórico de doenças da infância até hoje.

A facilidade de transportar uma fita é outro ponto a ser pesado, principalmente quando pretende-se armazenar as mesmas num local fora da empresa, garantindo que os seus dados estejam protegidos mesmo que ocorra um incêndio na infraestrutura de TI. Já o preço, que era uma das vantagens da fita, hoje já não é algo a ser considerado, pois com o aumento da capacidade dos hds o preço vem caindo progressivamente, empatando na categoria custo as duas soluções.

A favor dos discos, a taxa de leitura/gravação superam dos equipamentos de fita, o que pode ser decisivo na escolha da solução. Imagine um cenário onde a quantidade de dados gravados para fita é tão grande que um dia só não baste, fazendo o backup ocorrer até a manhã do dia seguinte. Nesse caso teria que ser adotada uma solução de gravação mais rápida (gravação para discos) ou utilizar uma técnica de cache antes de gravar nas fitas(cache em disco). Outro cenário seria na recuperação desses mesmos dados, onde teríamos um problema parecido da gravação ou até maior quando não se utiliza equipamentos de fita de gerenciamento automático, como autoloaders ou bibliotecas de fita.

Podemos ter duas conclusões ao final do artigo: usar uma das soluções vai depender do cenário onde queremos implantar o backup, ou ainda, usar uma solução híbrida, o que recomendo. Numa solução híbrida – Disk-to-Disk-to-Tape ou simplesmente D2D2T – os dados poderiam ser armazenados, num primeiro momento, em storages de disco e sendo migrados ao longo do tempo para fitas, garantindo assim durabilidade e fácil acesso aos backups.

A Veezor® com o Nimbus Backup além de atingir todos esses cenários de forma simplificada ainda permite fazer backups offsite em ambientes de cloud computing, levando o backup a níveis infinitos de armazenamento.