Esses dias vi esse anúncio no adsense de um site. Depois sou eu quem faz piadas das coisas na hora errada e da maneira errada … agora, “visão” de negócio mesmo seria se fosse uma empresa que só atendesse online :P
Com as férias chegando, nada melhor que um planejamento básico para não se perder. Não tenho intenção de fazer nenhuma viagem longa, então é melhor ter o que fazer em casa nas próximas 3 semanas. Obviamente esta lista não está em ordem de importância e/ou prioridade, é só a sequencia que lembrei ao digitar aqui :)
Quando as férias acabarem eu vejo o que eu cumpri deste planejamento.
Estava fazendo uma transferência de alguns grandes arquivos utilizando o WinSCP quando, sem querer, esbarrei no teclado e o foco estava no botão “Cancel”. A ferramenta, como era de se esperar, me mostrou uma janela perguntando se eu realmente queria cancelar, conforme imagem:
Eu NÃO quero cancelar, clico em “OK” ou “Cancel”???
Ok, é óbvio que seria em “Cancel” pois iria cancelar o cancelamento, mas se estivesse um pouco distraído (e estava, já havia clicado antes no botão pra aparecer este diálogo) ou se fosse um pouco leigo no assunto, teria continuado com a ação e cancelado a transferência…
Só pra mostrar como um pouco de facilidade para o usuário final, mesmo que não leigo, ajuda :)
Quando se usa uma distribuição Red Hat like tem-se uma vantagem de usar o yum para instalar pacotes e suas dependências de maneira fácil. Basta executar yum install pacote para que o pacote seja baixado da Internet e instalado juntamente com suas dependências.
O “problema” é que muitas vezes se deseja utilizar os pacotes que estão no DVD de instalação do Red Hat e não os da Internet (nem todos tem uma assinatura da RHN) e o yum não está configurado para utilizar o DVD como repositório.
Não é algo muito difícil de se fazer, basta criar um repositório e adicionar o caminho correto para o DVD.
Então crie o arquivo /etc/yum.repos.d/dvd.repo (não é necessário que o nome seja dvd.repo, pode-se escolher qualquer nome desde que a extensão seja mantida) e adicione o seguinte conteúdo:
[dvd]
mediaid=1250663123.136977*
name=DVD do RHEL5
baseurl=file:///media/RHEL_5.4%20i386%20DVD/Server
enabled=1
gpgcheck=0
Feito isto, o yum irá reconhecer o DVD como repositório de pacotes de instalação. As únicas observações são que valor para o mediaid está contido no arquivo .discinfo que está na raiz do DVD de instalação e que a baseurl eventualmente precisará ser ajustada, dependendo da versão do Red Hat que se tem disponível.
Sim, filmes !!! Não, não vou ser cineasta, ainda acho que me viro razoavelmente bem em informática, mas quem me conhece sabe que depois dos jogos, minha diversão favorita é ver filmes. Confesso que ultimamente reduzi muito a minha ida a cinemas devido a misto de falta de tempo com falta de ânimo, mas pretendo melhorar nisso dentro do possível.
Recentemente vi no Facebook um aplicativo que listava os 100 melhores filmes de acordo com votação pública no IMDb (na verdade, a lista do IMDb tem 250 filmes mas o aplicativo selecionou “somente” 100) e pedia para que você selecionasse quais deles já assistiu. Tenho cadastro no IMDb desde 1997 onde adicionei na minha lista praticamente todo filme que vi desde então, seja no cinema ou na TV, além de filmes que eu já tinha visto antes de conhecer o IMDb e que eu me recordava bem. Minha lista no IMDb tem ótimos filmes como também tem filmes péssimos, mas eu não imaginava que dos 100 melhores eu tinha assistido somente trinta e poucos.
Analisando os outros quase 70 filmes não vistos, percebi que a maioria são filmes antigos ou pelo menos não tão recentes assim (como anos 70 ou 80). Realmente nunca fui atrás de ver filmes muito antigos e nos anos 80 eu assistia mais Os Trapalhões do que qualquer outro tipo de filme (e eles não estão no top 250) mas, se tanta gente votou e escolheu esses antigos para estar entre os 100, devem ser bons, não?
Então, do que se trata o projeto? Basicamente é assistir a TODOS os filmes listados ali entre os 100.
Por motivos óbvios, não vou dar um prazo final para conclusão. Acho óbvio pois filmes muito antigos são bem difíceis de encontrar em DVD (e não tenho vídeo cassete faz muuuuitos anos) ou mesmo para baixar na Internet.
A ideia também é acompanhar a lista mais de perto e, sempre que um filme que estiver em cartaz entrar entre os 100, ir assistir no cinema. Para me ajudar, o próprio IMDb tem uma ferramenta que mostra todos os filmes daquela lista que eu não marquei como vistos (ufa, menos trampo assim!!!).
Com o tempo, pretendo ir atualizando aqui como está o status deste projeto, quais filmes assisti e etc.
Algum tempo atrás tive um problema e precisei reinstalar o Windows XP (não pretendo atualizar para o Vista ou Seven com o hardware que tenho). Tenho 3 HDs conectados na máquina, 1 particionado somente para Linux, 1 com uma partição NTFS, para Windows, e outro com 4 partições, sendo 2 NTFS e 2 FAT32 (também não pretendo explicar meus motivos para este particionamento).
A instalação do Windows XP ocorreu normalmente, atualizei o SO, instalei os drivers e etc, tudo funcionando corretamente mas (sempre tem um mas), meus drives apareceram com letras diferentes das que o Windows identificava anteriormente.
Tecnicamente não há problema algum nisso, exceto me acostumar a procurar minhas músicas em E: ao invés de D:, salvar meus documentos em F: ao invés de E:, ter meus backups e instalações em G: ao invés de F: e por aí vai. O trabalho começou a ficar chato quando restaurei algumas configurações que tinha no backup e vi que estava apontando para os drives “antigos”. Poderia reconfigurar tudo para a nomenclatura nova? Poderia mas, além de dar trabalho, não teria graça :)
Basicamente precisa-se editar o registro do Windows e mudar alguns apontamentos. Para isso, abra o regedit e vá em HKLM\SYSTEM\MountedDevices. A primeira coisa a se fazer é salvar um backup deste trecho do registro. Para isso, clique com o botão direito do mouse sobre MountedDevices e selecione Exportar, escolha um nome qualquer para o arquivo e pronto.
Feito o backup, é hora de mudar a letra que um drive aparece. Nesta mesma tela do regedit, procure o drive que deseja “remapear” (estará algo como \DosDevices\D:), clique com o botão direito sobre o nome da chave e selecione renomear. Se desejar remapear o D: para E:, bastaria trocar o “\DosDevices\D:” por “\DosDevices\E:“.
Feito isso, basta reiniciar o Windows e os drives irão aparecer mapeados com outras letras.
Outros usos possíveis são: colocar o drive de CD/DVD em outra letra. Assim, se instalar outro HD, não correrá o risco de perder algum atalho criado para a letra anterior correspondente ao drive de CD/DVD.
Só uns lembretes, não testei remapear o C:, não sei como o Windows se comportaria neste caso. Não tentei colocar dois drives distintos com a mesma letra e também não me responsabilizo por eventuais problemas caso alterar algo errado no registro do Windows.
Era primeiro de abril de 2004 quando o Google anunciou seu email gratuito com espantosos 1 GByte de espaço de armazenamento. Pode parecer normal, ou mesmo pouco, espaço nos dias de hoje, mas numa época onde a maioria dos webmails gratuitos não disponibilizava mais que 20 ou 25 Mbytes e mesmo boa parte dos serviços pagos não permitia tanto espaço de armazenamento, era espantoso mesmo. Tanto que muitos pensaram ser uma pegadinha de primeiro de abril…
Foi um dos primeiros serviços a utilizar ajax intensivamente para evitar ter que recarregar a página toda a cada clique do mouse, tornando a navegação muito mais rápida e “parecendo” mais uma aplicação do que uma página na web. Após o lançamento, o Google continuou aumentando o espaço do Gmail, um pouco por dia, e hoje o espaço das contas já ultrapassa os 7,5 GBytes no total. Além de aumentar espaço, diversos “extras” foram surgindo para incluir novas funcionalidades ao serviço.
Foi aí que começaram os problemas. Muitos extras significam mais códigos para serem executados, o que por si só faria a página ficar mais lenta. Muito espaço também significa que normalmente não precisa deletar emails não importantes e, para mostrar na tela, mais tempo para carregar e mostrar as mensagens. Isso acabou tornando o gmail mais lento e, em alguns casos, excessivamente lento.
Pensando nisso, fiz alguns testes e verifiquei que com algumas configurações no próprio gmail podemos deixá-lo mais rápido. Algumas vezes sem prejuízo para a usabilidade.
Segue a pequena lista que montei:
Parece óbvio (e é), se o gmail tem menos itens para mostrar, ele demora menos para carregar a tela.
Vá em Settings / General / Maximum page size. Minha sugestão é:
Show “25” conversations per page
Show “50” contacts per page
Os snippets são o começo do texto dos emails. Se eles estiverem ativos, o gmail irá mostrar o começo do texto de cada email ao lado do subject. Com eles desabilitados, somente o subject será mostrado.
Em Settings / Snippets Selecione “No snippets”
Web clips são os textos com resumo de notícias que aparece sobre a lista de emails.
Em Settings / Web Clips
Desmarcar “Show my web clips above the Inbox”
Existem diversos itens no labs do gmail, alguns muito interessantes mas nem sempre necessários. Aconselho a usar somente os que realmente são úteis para você. As configurações estão em Settings / labs
A ideia do Buzz até era interessante, mas pouca gente acabou aderindo efetivamente ao serviço e ele acabou sendo um “replicador” de twittes. Se não utiliza, vá em Settings / Buzz / Disable Google Buzz
Como configurar o yum para utilizar somente um repositório?
Primeiro, o que gerou esta motivação?
Acompanho a lista fedora-users-br e vi este email do Ricardo Vendramini: http://lists.fedoraproject.org/pipermail/br-users/2010-November/013615.html
Para reduzir o uso de banda, surgiu a ideia de se configurar um proxy squid. Quando uma máquina for se atualizar, ela baixa os pacotes e o squid os armazena em cache. Quando uma segunda máquina buscar esta mesma atualização, o squid irá entregar o arquivo do cache ao invés de baixar novamente, economizando tempo (rede interna provavelmente é mais rápida que Internet) e banda.
O problema: o yum tem uma lista de mirrors possíveis e, a cada vez, ele pode utilizar um mirror diferente da última. Com isso, o squid terá diversas cópias de um mesmo arquivo mas vindo de domínios diferentes. Assim, além de não reduzir o uso da banda (ideia inicial) ainda se ocupa espaço de disco do cache que poderia ser melhor utilizado com outros arquivos.
Solução? “Forçar” o yum a baixar sempre de um mesmo mirror.
Para isso, deve-se configurar os repositórios “updates” e “fedora” (assim tanto os updates como eventuais instalações de pacotes serão armazenados no cache do squid). Então, edite o arquivo “/etc/yum.repos.d/fedora-updates.repo“, comente a linha “mirrorlist” e descomente “baseurl“. Em “baseurl“, coloque o endereço de um dos mirrors. Como sugestão, estou utilizando o mirror da Universidade Federal do Paraná que normalmente é bem rápido para usuários no Brasil.
[updates]
name=Fedora $releasever – $basearch – Updates
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/updates//$releasever/$basearch/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
Também deve-se editar o “/etc/yum.repos.d/fedora.repo“:
[fedora]
name=Fedora $releasever – $basearch
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/releases/$releasever/Everything/$basearch/os/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
Repita o procedimento em todas as máquinas com Fedora na rede. Feito isto, basta utilizar novamente o comando “yum update” para que todas as instalações e atualizações venham sempre do mesmo mirror.
Outra ideia para melhorar o desempenho, desabilitar o uso do plugin “yum-presto”. O presto utiliza o conceito de deltarpm para reduzir o tamanho dos pacotes de atualização. O deltarpm é um diff binário entre duas versões de rpm. Basicamente você baixa somente a diferença entre duas versões de um mesmo pacote e não mais o pacote todo. Ex: é liberada uma atualização do OpenOffice onde apenas um arquivo foi modificado. Este arquivo tem 1 Mbyte enquanto o pacote todo tem 50. O deltarpm teria aproximadamente 1 Mbyte e se teria uma economia de 49 Mbytes de download. Veja um outro artigo que escrevi sobre o yum presto aqui.
Mas como desabilitar o yum-presto melhora o desempenho? Como você terá todos os pacotes (ou pelo menos os mais utilizados) no cache do squid, você não estará fazendo o download de um pacote grande, você estará utilizando uma cópia localizada no cache na rede interna. Assim, o download será rápido e não precisará de tempo para reconstruir os pacotes de atualização, o que normalmente leva alguns minutos. Só para reforçar, yum-presto economiza muito download, mas aumenta o tempo de atualização devido a reconstrução do pacote. Se o tempo de download é muito baixo (rede interna), provavelmente não compensa o tempo de reconstrução, por isso a sugestão de desabilitar o yum-presto.
E como fazer isso? Basta editar o arquivo “/etc/yum/pluginconf.d/presto.conf” e configurar “enabled=0“. Pronto, da próxima vez que utilizar o yum, o plugin presto não será carregado.
Sem ter o que fazer esta noite (maldita insônia) resolvi fazer algo que já estava adiando há algum tempo: atualizar o WordPress do meu site.
Basicamente, tinha instalado a versão 2.9.2 e iria migrar para a 3.0.
Primeiro de tudo, backup!!!
Fiz backup do banco de dados do site (alias, sugiro que tenha backups sempre, evita dores de cabeça). Se não sabe como fazer o backup do seu banco de dados, existe este tutorial no site do WordPress que deverá te ajudar: Backing Up Your Database
Fiz backup de todo o site (copiei recursivamente o diretório onde o site está no servidor).
Após o backup feito e validado, parti para a remoção de dados que o novo wordpress irá criar. Então apaguei os diretórios wp-admin e wp-includes (esta informação consta em Upgrading WordPress Extended, não é obrigatório fazer isso, mas terá que confirmar a sobrescrita de alguns arquivos durante o upgrade se não fizer este passo).
Baixei o arquivo da nova versão diretamente do site do wordpress.
Descompactei sobre os dados do site antigo.
Loguei como admin no site e respondi que quero que ele atualize as informações do banco de dados.
Fiz diversos testes para ver se nada havia quebrado e pronto, upgrade concluído.