Posts Tagged ‘ programação

Adobe AIR no Linux

O Adobe Integrated Runtime, ou AIR, é uma plataforma para desenvolvimento de aplicativos multiplataforma com o Flash, Flex, HTML e AJAX, de modo que podem ser executados também no desktop.

Atualmente há uma versão alpha para o Linux, e um public beta para o Windows e Mac. Essas duas versões já estão bem estáveis, e há muitos aplicativos para o AIR por causa delas. Já do lado do Linux, não se ouve falar muito do AIR.

Depois que eu vi um artigo no Lifehacker sobre aplicativos interessantes para o AIR, resolvi me aventurar e instalar o dito no meu Ubuntu Hardy. Antes que me apedrejem, o procedimento deve funcionar em qualquer distribuição do Linux, mas eu não faço idéia quanto a dependências, por isso não garanto nada.

AIR

O processo é extremamente simples. Primeiro, baixe o AIR para alguma pasta do seu PC.

Num terminal, agora dê um chmod +x adobeair_linux_a1_xxxxxx.bin, substituindo, obviamente, pelo nome do seu arquivo. Por estar em alpha, espere atualizações freqüentes (eu sei que eu espero).

Depois é só rodá-lo com permissões de root (um sudo ./adobeair_etc.bin deve resolver) e esperar ele instalar.

Ele é instalado no /opt, prática louvável, porque vários .bins que eu instalei ultimamente tentavam se instalar em outros lugares, tornando-se um inferno para removê-los.

Depois disso, basta baixar qualquer .air e dar dois clickes que o instalador dá conta do resto. Ele pede a tua senha e instala em /opt também, para facilitar a remoção.

Apesar de tudo, minha experiência não foi muito feliz. O AIR está muito instável no Linux ainda, e dos 10 programas do artigo do Lifehacker, somente o do google analytics funcionou, e ainda assim, eu tinha que criar um perfil novo a cada vez que rodava.

O instalador foi a parte mais surpreendente de tudo. Mostra que é possível distribuir binários unificados para o Linux, fazendo uma instalação independente de distribuição sem muita dificuldade, e sem a possibilidade de quebrar o sistema. A Sun já nos mostrava isso há tempo, mas com a Adobe agora, a mente dos desenvolvedores deve se abrir para a idéia.

Só espero que a Adobe continue investindo no AIR para o Linux, e não faça como está fazendo com o Flash, onde nos deixa com versões antigas e não corrige bugs simples.

A Importância do Backup

Eu era um cara negligente com backups, como a grande maioria. Confiava cegamente nos meus HDs, e mais ainda na minha falta de capacidade de estragar tudo. Até a terceira ou quarta vez que eu perdi dados por falha de hardware ou puta bocabertice mesmo. Aí eu comecei a levar a sério esse negócio de becápi.

Hoje, por exemplo, eu fui fazer a atualização de um maravilhoso plugin que eu uso, o XHTML Video Embed, que gera código XHMTL strict para vídeos do youtube, bastando usar tags e o endereço do clipe. Eu dependo um monte desse plugin, todos os posts com vídeos daqui estão com ele. O problema é que, por algum motivo, a versão nova que saiu hoje não funciona. Dá caca total, nem ativa o plugin. E agora, José? Simples: restaurar o backup. Dois minutinhos depois eu estava com a versão velha (e estável) do plugin rodando.

Agora você me diz que fazer backup é chato, tedioso, para pessoas com muito tempo livre. E eu digo que sim, pode até ser, mas como eu sou um cara legal, vou te ensinar a automatizar isso tudo.

Vamos começar do começo, e vamos por partes, como diria Jack.

Você vai precisar, indispensavelmente, de um servidor com suporte a cronjobs. Se o seu servidor não suporta, corra e assine outro, porque é um servidor muito furreco esse que você tem. Eu recomendo o Dreamhost.

A seguir, você precisa criar uma pasta para armazenar os backups no seu servidor. Por favor, faça um serviço de gente normal, e deixe essa pasta fora da webroot, que é aquela pasta acessível pelo navegador, senão qualquer jaguara pode acabar por descobrir onde está teus backups e te pegar a DB, dados confidenciais, etc, etc.

Dentro desta pasta você precisa de pelo menos três outras pastas: uma para os backups diários, outra para os semanais, e outra para os mensais. Já deu para ver aqui que você fará 3 scripts, certo? Vamos detalhá-los.

O primeiro script toma conta dos backups diários e de remover os que já têm mais de uma semana. O seguinte código deve ser salvo num arquivo de texto, e você deve dar permissão de execução (vulgo chmod +x) nele. No cron, que provavelmente fica no painel do seu servidor, adicione este script para ser rodado diariamente. O código é esse:

#!/bin/bash
suffix=$(date +%y%m%d)
nice -19 tar -czf caminho_do_backup_diário/backup-$suffix.tar.gz pasta_a_ser_salva
mysqldump –opt -uuser_do_mysql -psenha_do_mysql -h host_do_mysql database | gzip -c > caminho_do_backup_diário/database-$suffix.sql.gz
find caminho_do_backup_diário -type f -mtime +7 | xargs rm

Substitua o que está marcado pelo que deve ser substituído.

Explicando: a primeira linha somente informa o sistema de que isto se trata de um shell script. A segunda linha gera um sufixo baseado na data, de modo a que cada arquivo seja gerado com um nome diferente. A terceira linha compacta com o tar.gz a pasta que você quiser. Ela pode ser repetida para compactar em arquivos separados pastas separada, só trocar o nome do arquivo (no caso, backup-*). A terceira linha fará um dump da DB e a compactará. Finalmente, a última linha procura por arquivos com mais de uma semana e os exclui.

Para o backup semanal, o script é o mesmo, somente trocando o caminho_do_backup_diário pelo caminho_do_backup_semanal. Além disso, a última linha deve ser:

find caminho_do_backup_semanal -type f -mtime +30 | xargs rm

De modo a deletar todos os arquivos com mais de um mês. Este script deve ser posto no cron para rodar semanalmente.

Finalmente, o script do backup mensal também deve ser igual aos anteriores, mas removendo a última linha, ou substituindo o -mtime +x pelo valor em dias a guardar o backup. Eu prefiro guardar para sempre, já que eles não são muito grandes, mas 365 deve ser um bom valor para isso. Lembre-se também de alterar o caminho do backup para a pasta de backups mensais, para que um script não interfira no outro. Novamente, mande o cron rodar este script mensalmente.

Agora você deve estar com um bom sistema de backup criado. Você terá sempre um backup de cada um dos últimos 7 dias, um de cada semana do último mês, e um de cada mês, podendo assim reverter para o que for mais conveniente. Vale lembrar que, se der uma zica geral no teu servidor, isso não vai te salvar. Em tese, a empresa de hospedagem deve se responsabilizar pelos dados, mas, se não der… Bem, ferrou. Isso deve aumentar as tuas chances, mas vale a pena baixar estes backups de vez em quando também para o PC.

Outra possibilidade seria enviar estes backups para o email, usando o comando mail. Mas isto não é exatamente seguro, então pode-se criptografar estes backups com o pgp. Mas isso é só para os extremamente paranóicos.

Estou indo implementar isso agora.

Cuidado! A Vivo está roubando os seus dados.

Eu tenho um nojo de telemarketing que só vendo. Raiva, ódio.

Acabei de desligar o telefone de uma ligação muito instrutiva, porém.

Estava eu muito concentrado tentando implementar um algoritmo de ordenação de vetores, porque sou um bom menino nerd e faço os exercícios de programação com duas aulas de antecedência, e meu cebolar tocou.

O número era (11)71006327, um número de São Paulo, sendo que eu moro na grande Porto Alegre. Isso já é estranho o suficiente. Quando eu atendo, é uma representante da vivo, querendo me oferecer uma promoção. Imediatamente perguntei como ela conseguiu o meu número, já que meu celular é da Claro.

E esta foi exatamente a parte instrutiva da ligação. Ela me disse:

O Senhor deve ter ligado para algum número da vivo, algum celular de alguém, e o seu número ficou registrado no nosso sistema.

Então essa é a moral da história: quando você liga para um número da Vivo, eles armazenam o seu número no sistema deles, para poder te atormentar a vida posteriormente. Já não foi a primeira vez que me ligaram de lá, e não foi a primeira vez que eu recusei, mas dessa vez consegui que me dissessem, com todas as letras, como conseguiram o meu número.

Morto

Quando ela me perguntou porque eu estava recusando a oferta (que eu nem quis ouvir), eu disse o óbvio: não faria negócios com uma empresa que consegue os meus dados de maneira ilícita.

Por sinal, ela disse que isso é “procedimento padrão. Todas as empresas de telefonia fazem isso“. Engraçado que eu nunca recebi ligação da Tim, da Oi, da Brasil Telecom, etc. Alguém já?

Barcos de Programação

Se as linguagens de programação fossem barcos…

Java
Java

Java seria um cargueiro. Voltado para grandes empresas, parrudo e estável. Mas não é divertido dirigir.

PERL
Perl

Perl é um rebocador. Poderoso o suficiente para encarar quase tudo o que o java faz, em menos de 80 caracteres.

Ruby
Ruby

Divertido de dirigir, sexy e rápido, Ruby é um speedboat.

PHP
PHP

Um monte de pedaços de pau agrupados, mantidos juntos por meios rudimentarem. Seria uma jangada. Faz o serviço, e só.

C
C

Submarino nuclear. O manual deve estar em alguma língua estrangeira obscura, mas todo o hardware está optimizado para permormance extrema.

HTML
HTML

HTML não é um barco uma linguagem de programação.

[Fonte]

 
SEO Powered by Platinum SEO from Techblissonline