Editores e mais editores - além do highlighting

Fala, pessoal.

Vira e mexe vejo disucussões sobre os editores e IDEs preferidos do pessoal. Muitos são incompreendidos, muitos são desconhecidos...

Bom aqui vão meus pitacos e dicas do que vale a pena dar uma olhada.

Começando pelos pesos-leve, os que vale a pena citar são:
Notepad++ (para windows, pode ser emulado via wine no Linux)
Facilidade para mudar o encoding do arquivo, suporte a várias linguagens, split (divisão) da tela, comparação de arquivos.

Kate (para KDE)
Suporte a muitas linguagens (muitas mesmo).

Bluefish
Vários recursos built-in (como por exemplo montar elementos HTML - tabelas e selectbox - em PHP baseado numa query, a partir de um click).

Agora os pesos-médio, mas graficamente espartanos... estou falando do VIM (gVIM) e do Emacs.

Ambos contam com muitos recursos, modos de edição diferentes, e permitem um tipo de integração com outros aplicativos e recursos tão grande que podem chegar a assustar à primeira vista - na verdade à primeira vista você não lhes dá um tostão, mas depois de usar por algum tempo você vê a genialidade e o poder trás dos mesmos.

E por fim, os editores parrudões.
Eclipse
Criado em Java, e visando a possibilidade de extensão ad infinitum, este é um dos editores mais usados hoje me dia. Atende a praticamente qualquer finalidade, e tem recursos excelentes - geralmente providos nas suas extensões específicas - como mapeamento de objetos, dicionário de função e previews em tempo real (compila e executa, ou conecta e executa...). O ponto fraco é o peso do mesmo, que facilmente enche 1 GB com seus recursos.

Quanta Plus
Suíte genial feita pra KDE. Em primeiro lugar é leve. Muito leve. E isso se deve por ele ser uma plataforma onde podem se agragar vários plugins (parecido com o Eclipse). Mas os plugins são componentes e aplicações do próprio KDE, e essa é a chave para a sua leveza. Em segundo lugar, ele tem recursos de editor para bater de frente com o Eclipse (ou quase, mas a diferença peso x funcionalidade compensa).

Não falarei sobre IDEs específicas como JavaBeans justamente por serem específicas demais.

Bom, é isso. Experimentem e opinem. Té mais.
-----------
keepReading

Monitor novo, vida nova

Fala pessoal.

Sei que prometi um novo formato e tals, mas o fato é que fiquei praticamente um mês sem meu PC. O monitor LG 500, um CRT de 15 polegadas velho de guerra, enfim bateu as botas.

Comprei nada mais nada menos que um Samsung 2232BW Plus para substituí-lo. Sim, um LCD TFT de 22 polegadas. Ignorância desmedida à parte, o fato é que foi a melhor relação custo/benefício que encontrei.

Nada difícil de configurar. Resolução máxima de 1680x1050, a 60Hz.

No Windows XP ele foi que foi... velho procedimento, colocar CD, instalar drivers e depois gozar da resolução máxima - aliás minha esposa joga Spore na resolução máxima, sem dar lag nem nada.

No Ubuntu, foi necessário um pouquinho de trabalho para configurar o xorg.conf, mas nada de outro planeta - mesmo assim acho válido falar sobre como foi, pois vai que tem alguém na mesma situação...

Assim que coloquei ele aqui, liguei primeiramente no Ubuntu, usando o cabo analógico (ele vem com um cabo analógico-RGB e um DVI-D).

Iniciou normalmente com resolução 1024x768. Tenho uma placa Nvidia GeForce XFX 6200, AGP, devidamente configurada e usando os drivers fornecidos pelos repositórios do Ubuntu (Ubuntu 7.10).

Enfim, a primeira coisa foi configurar o xorg.conf. Criei um backup do mesmo - isso é um passo mandatório, porque vai que dá algum problema você tem como voltar a uma configuração válida - e depois fiz a seguinte alteração (seções Monitor e Screen).

Section "Monitor"
Identifier "SyncMaster"
Vendorname "Samsung"
Modelname "2232BW"
Horizsync 31-81
Vertrefresh 56.0 - 75.0
modeline "1680x1050@56" 140.76 1680 1712 2240 2272 1050 1071 1081 1103 -hsync +vsync
Gamma 1.0
#Option "DPMS"
EndSection

Section "Screen"
Identifier "Default Screen"
Device "nVidia Corporation NV44A [GeForce 6200]"
Monitor "SyncMaster"
Defaultdepth 24
SubSection "Display"
Depth 24
Virtual 1680 1050
Modes "1680x1050@56" # "1024x768" "800x600" "720x400" "640x480"
EndSubSection
EndSection

Depois disso limpei as configurações que o GNOME salva nas seções - se você não fizer isso, ele vai reiniciar com a última resolução válida usada, que seria 1024x768 no meu caso.

Para fazer isso, basta editar o arquivo /home/yourUser/.gconf/desktop/gnome/screen/default/0/%gconf.xml

Crie, um backup por precaução. E edite como a seguir:

<?xml version="1.0"?>
<gconf>
<entry name="rate" mtime="1214273641" type="int" value="56">
</entry>
<entry name="resolution" mtime="1204383760" type="string">
<stringvalue>1680x1050</stringvalue>
</entry>
</gconf>

Pronto. Configurações feitas. Reiniciei. A resolução não foi aceita bem logo de primeira. Deu uma mensagem no próprio monitor. Apertei o botão de auto ajuste e pronto, me livrei da mensagem de erro, mas...

A resolução estava como 1680x1050, como previsto. o que é bem legal. Só que a tela estava deslocada para a direita e ficou uma faixa preta gigantesca na esquerda - tentei fazer um ajuste com o alinhamento de tela e tals, auto-ajuste, mas nada funcionou. Larguei mão e liguei fui instalar no Windows.

Tentei mais tarde, mas continuou com a faixa preta até que resolvi trocar o cabo RGB pelo DVI. Foi batata. Alinhou sozinho.

É interessante notar que esse monitor foi feito para trabalhar nativamente com a entrada DVI e operar a 1680x1050@60. Qualquer parâmetro que fuja disso, requer algum layer de adaptação. E quanto menos disso tivermos, melhor porque a chance de acopntecer alguma incompatibilidade ou erro é reduzida.

Por último quero falar sobre um monitor desses ser uma escolha razoável para compra. Como disse acima, sua resolução é 1680x1050. O Full HD que se fala hoje em dia é, grosseiramente falando, uma referência à resolução com 1080 linhas e scan progressivo - 1080p.

Em termos de resolução, estou apenas a 30 linhas disso. Os monitores que apresentam essa resolução são os de 24 polegadas e o mais barato deles é pelo menos mil reais mais caro.

O progressive scan faz diferença para gamers, o que não é meu caso. Assim, essa escolha se mostrou a mais vantajosa dentre as que eu poderia fazer.

See yo.
-----------
keepReading

Recuperando o grub

Eu uso muito pouco os produtos da M$ em casa. E tempos atrás o Windows deu pau pra variar. Fosse outra época, eu gastaria dias recuperando o sistema, os documentos, etc... Mas já faz muito tempo que não tenho saco pra ele.

Existem uns pouquíssimos motivos para eu continuar com ele na minha máquina, mas ele ainda é necessário sim. Pois bem, depois de muito postergar resolvi meter a mão na massa e fazer o odioso ritual do formata-e-instala.

Qual minha surpresa quando vou procurar no meio dos CDs e lembro que joguei fora o CD de instalação do Windows. Solução: deixar a madrugada inteira baixando um torrent. Terminado o download, vejo que o arquivo de imagem não era uma iso e sim um nrg, que é um formato de imagem proprietária do Nero, e não dava pra gravar direto pelo meu querido K3B. Nada de mais, uma googlada e pronto, eis uma linha de comando para fazer a conversão. Isso mesmo. Com uma linha deu pra fazer a conversão de nrg para iso, e enfim gravar a imagem num CD.

Ah sim a linha em questão é:
$dd bs=1k if=imagem.nrg of=imagem.iso skip=300

Enfim, comecei a via sacra... formata, instala, instala drivers, aplicativos básicos, aplicativos de segurança, configura uma coisa, configura outra, restaura os backups...

Hora de restaurar o grub, o bootloader do Linux, para que eu pudesse deixar a máquina novamente com dual boot.

Vou dar o boot com o CD do Linux e trava. Tento de novo e de novo e nada. O CD foi pro espaço tbm. Solução: baixar o Linux, gravar num CD e daí sim recuperar o meu mojo.

Depois de iniciar o boot com o CD do Linux, abri um terminal e fiz:

$sudo grub
>find /boot/grub/stage1

daí usei a saída do comando acima no comando abaixo

>root (hd0,0)
>setup (hd0)
>quit

Reiniciei e pronto. Tudo funcionando como deveria ser, nos trilhos.

E agora consegui passar as fotos do meu aniversário para o PC (sim, a minha câmera é um dos motivos para eu ainda manter o Rwindows aqui).

Hasta la vista.
-----------
keepReading

IFS - Internal Field Separator

No post anterior, eu disse que o script reconhecia nomes de arquivos que incluiam espaços e outros caracteres especiais, mas não escrevi sobre como fiz isso. Aliás, este foi um dos passos que mais me deu dor de cabeça durante o desenvolvimento do script.

Voltando um pouco na causa... minha esposa e eu temos o costume de renomear em massa os arquivos e as cópias que ela faz, usando espaços nos nomes, tanto dos arquivos quanto dos diretórios. Porém quando fui criar o script me deparei com o problema. A saída do comando find. Sempre que havia um espaço em branco nos nomes de diretórios e arquivos, era como se fosse um valor diferente para o loop for.

Após muita pesquisa, vi que o problema era uma variável especial do shell, o IFS. Ela é uma variável criada pelo shell (builtin) e é extensivamente usada para reconhecimento e expansão de strings. Seu valor padrão é "", e ela afeta o comportamento de vários outros comandos, como grep, cut, ls... Assim, "o pulo do gato" foi definir o valor dessa variável para "".

Bem, além de mais elegante e eficiente, esse tipo de tranformação ajuda a diminuir o tempo de execução, o que pode tornar o uso racional desse recurso muito interessante quando temos de lidar com grandes quantidades de dados, por exemplo importação/exportação de valores em bancos de dados.

Agora cabe algumas observações sobre o uso do IFS.
- É recomendável que você guarde o valor antigo e retorne ele ao normal no final do script.
- Definir o novo valor de forma direta funciona apenas para a atual instância do shell onde se trabalha. Se você cria subshells, você deve usar o comando (também builtin) export.
- Essa é uma variável existente para vários sabores de shell (sh, dash, bash, ksh, zsh).

E para fechar, dois links para aprofundar a leitura:
- http://www.dicas-l.com.br/cantinhodoshell/cantinhodoshell_20070103.php
- http://nixshell.wordpress.com/2007/09/26/ifs-internal-field-separator/

See ya.
-----------
keepReading

Script para remover arquivos duplicados

Fala pessoal, tudo certo?

Venho postar aqui pela primeira vez um presente meu para vocês: um scriptzinho (em shell script) para remover arquivos duplicados. O link é esse aqui. Tá no 4shared, então não tem complicação para fazer o download.

O uso do mesmo é bem simples.

$./check_dups.sh /dir/to/scan/ /another/dir/to/scan/ /and/one/more/

O script lê todos os arquivos dentro dos diretórios passados, inclusive nos seus subdiretórios. Reconhece arquivos que contenham caracteres especiais no nome como espaço e parênteses. Remove os duplicados (com base no hash MD5 deles), deixando apenas um, e gera um log no formato HTML, com o arquivo que ficou, e quais que tinham o mesmo conteúdo que foram removidos. Tudo organizadinho.

Esse script me custou umas boas horas e eu realmente tinha a necessidade dele. Como não achei nada que fizesse isso, criei e agora espero que seja útil para alguém.

Críticas e sugestões são bem-vindas.

Abraços.
-----------
keepReading

Um pouquinho de velocidade

Fala pessoal.

Como sempre venho trazer alguma coisa para vocês, baseada em erros comuns que vejo. E hoje trago algumas dicas de como melhorar o desempenho em bancos de dados.

Tempos atrás eu já tinha publicado algo sobre isso em relação ao Postgre aqui.

Bem, negócio seguinte, quando tratamos com uma quantidade grande de dados (1GB ou mais), algumas mudanças podem e devem ser feitas para acelerar o andamento das atividades (importar, exportar, selecionar, filtrar, pesquisar, etc...).

Primeiro em relaçãoà modelagem de dados. Veja se a estrutura não precisa de modificações, como por exemplo partições nas tabelas, índices, etc...

Depois, veja se a tabela está em dia. Um ANALYZE TABLE faz milagres. Agendar ele no CRON para rodar todo dia num horário de pouco uso, nem se fala.

Se tem uma opção mais eficiente que essa, é o OPTIMIZE TABLE do MySQL.

Para importar/exportar quantidades muito grandes de informação, evite usar alguma linguagem de programação. Faça pela linha de comando, usando recursos do próprio banco de dados. Prepare scripts para automatizar estas tarefas. Se for necessária alguma verificação, faça com stored procedures. Isso aumenta absurdamente a performance.

Outra coisa, em caso de queries complexas, use o EXPLAIN. Aprenda a otimizar suas queries com ele (a ordem dos joins importa, assim como a sua quantidade e o método usado).

Por último, nos casos mais críticos, verifique a condição física da máquina. Se a operação que está sendo executada começa a usar espaço em disco (swap/arquivo de paginação) é hora de rever alguns parâmetros do banco de dados, do sistema operacional ou mesmo instalar mais memória.

[]'s

-----------
keepReading

Dica rápida (1) - baixar sites

Fala pessoal. Enquanto arrumo os preparativos para o primeiro artigo no novo formato, vai aí uma dica retirada do VOL (mais especifamente, daqui) e que me quebrou um galhão.

O problema: queria baixar todo o conteúdo de um site. (nada de pirataria, era para abaixar apostilas e tudo o mais de uma vez só, porque enche o saco ficar clicando e salvando um por um).

A solução: depois de experimentar vários plugins do Firefox, e coisa e coisa e tal, sem obter um resultado satisfatório, finalmente encontrei a solução. Supondo que você queira baixar todo o conteúdo do site http://www.algumsite.bar/, vá na linha de comando e digite:

$wget -cpr http://www.algumsite.bar/ -o logfile.log

Este comando irá baixar TUDO (conteúdo, folhas de estilo CSS, scripts, imagens, e vai seguir os links dentro do domínio, baixando tudo também). O parâmetro -o logfile.log irá gerar um arquivo chamado logfile.log, com toda a saída do comando, ou seja, uma lista com todas as páginas baixadas e o que eventualmente não deu certo. Para dar uma conferida geral nisso, recomendo que se rode na mesma linha de comando, logo após o download, você faça:

$grep 404 logfile.log

Para vc ter uma idéia de quantos arquivos não foram encontrados. Se houver algum erro, aí é melhor abrir o log com o gedit ou similar e usar o ctrl-f para localizar as ocorrências.

Enjoy.
-----------
keepReading

Depois do novo visual, novos bagulhos

Fala pessoal. Tudo certo?

Depois de mudar o layout dos meus blogs, foi hora de implementar algumas melhorias. Primeiro foi no meu outro blog, e agora trago as mudanças à este.

Ainda estou organizando muita coisa aqui no meu PC depois de um baita upgrade, mas fica a promessa de que em breve um novo formato, modéstia à parte, bem mais interessante, será implementado aqui. Inclusive já há uma fornada fresquinha de artigos e tutoriais só esperando para serem publicados.

See ya.
-----------
keepReading

Rootkits - checando a sua máquina

Fala pessoal.

Aqui vai uma dica rápida de dois programas que podem ser uma mão na roda na hora de checar a sua máquina quando algo suspeito acontece, no ambiente GNU/Linux.

chkrootkit
Você pode baixá-lo em http://www.chkrootkit.org/. Após descomprimir o tarball, basta entrar no diretório criado e compilar com:
# make sense

Para ver os testes disponíveis, use:

#./chkrootkit -l

Para fazer o checkout completo oferecido por ele:

#./chkrootkit

Rootkit Hunter
O site oficial do rkhunter é http://www.rootkit.nl/projects/rootkit_hunter.html.

Após descompactar o tarball, é recomendável atualizar as referências de rootkits. Para isso, entre no diretório criado na descompactação. Uma vez lá, entre no diretório files, e então execute:

#./rkhunter --propupd
#./rkhunter --update

E partir daí para fazer uma varredura do sistema, basta usar:

#./rkhunter --check

Acima está o basicão, e recomendo a leitura dos manuais e do material disponível nos sites, bem como as instruções já disponíveis com os pacotes - o chkrootkit tem um README, e o rkhunter tem a opção --help.

So, have fun!
-----------
keepReading

Uma conversa sobre boas práticas de desenvolvimento

Quando começamos a desenvolver, a principal meta é obter uma aplicação que funcione. E com o tempo vamos melhorando nossas práticas, facilitando e polindo nosso código - claro que estou me referindo aos verdadeiros profissionais.

Mas mesmo assim, na enorme maioria das vezes os desenvolvedores não vão tão a fundo sobre o funcionamento da aplicação, sendo que isto muitas vezes pode ser muito útil. Seja por falta de informação, ou na dificuldade de encontrar e entender a mesma.

Por exemplo, quantos de vocês já pararam para pensar sobre o processo de requisição de uma simples página de internet? Vamos fazer uma pequena viagem neste processo (acredite, isso é a forma simplificada!).

Ao clicar num link para uma página, o seu navegador pede ao sistema operacional que envie um pacote de requisição pela interface de rede. Este pacote contém os request headers, ou seja informações sobre o destino solicitado (o SO é que acrescenta o endereço de origem), informações sobre o navegador, quais linguagens e encodings ele aceita, etc.. Essa solicitação é resolvida num servidor DNS, que converte o nome para um endereço IP, e a saga do pacote continua de roteador em roteador até que o IP da página requisitada seja encontrado. Chegando lá, o SO do servidor, vai direcioná-lo para o servidor HTTP (geralmente o Apache), onde será enfim processado.

O servidor é responsável por localizar qual arquivo está sendo solicitado, checar regras e políticas de segurança junto ao SO, formatá-lo, codíficá-lo se for o caso, e por fim, enviar de volta o arquivo em pacotes, fazendo o caminho inverso. Se o seu navegador, ao reconstruir os pacotes, identificar que existem outros arquivo sendo solicitados na própria página, como folhas de estilo externas (CSS), arquivos javascript, imagens, arquivos flash, ou mesmo frames, ele irá enviar novas solicitações ao servidor para que este envie os arquivos necessários.

Com tudo recebido, o seu navegador monta a página, rederiza o CSS sobre os elementos, e carrega os javascripts para execução.

Bastante coisa não? Vamos deixar um pouco de lado a parte do seu navegador e vamos focar em duas coisas: o processamento do lado do servidor, e o tráfego de rede.

O servidor tem que alocar memória para cada requisição feita. Este processo também demanda processamento, tanto do servidor HTTP, quanto do SO. Ele tem que gerenciar muitas coisas, ainda mais quando se tem várias requisições chegando ao mesmo tempo.

Agora quando uma página dinâmica é solicitada, o trabalho do lado do servidor acaba aumentando bastante. Ao identificar que se trata de uma página PHP ou Python, por exemplo, o servidor HTTP precisa ler o arquivo e passá-lo ao engine responsável pelo processamento. Isso faz com que o SO reserve mais memória e consuma mais processamento, pois há mais um aplicativo participando da bricadeira. Pelo amor de Deus, eu não estou falando para criar apenas páginas estáticas, mas estou dando uma visão geral para que vocês entendam a importância de uma polida no código no sentido de otimização quando forem fazer um sistema.

Bem, vamos lá... temos um SO gerenciando vários processos e alocando memória para o Apache e para o engine do PHP. Até aí nenhum problema, os softwares são bem escritos e as máquinas de hoje dão conta do recado sem precisar fazer muita força. Mas o mundo não é feito só de hello world's, e de scripts para mostrar que horas são em Estocolmo.

Então, não raro o seu script PHP vai precisar acessar um banco de dados ou arquivos. E aí é onde a coisa pode começar a complicar. Quando acessa um banco de dados, o PHP carrega um módulo, com uma API para o banco de dados, e então ele abre uma conexão para o banco de dados. O processo é muito parecido com a requisição de uma página (exceto, geralmente, o que diz respeito a ficar passando de roteador em roteador para encontrar o banco de dados). E o servidor de banco de dados trabalha de forma muito parecida (guardando-se as devidas proporções) com o servidor HTTP. Ele válida a sessão, reserva memória e começa a processar prioridades de acesso - em outras palavras, mais memória alocada, mais processamento consumido.

Aí voltamos ao seu script. Ele se conectou no banco de dados. Hora de enviar as queries. Para cada query enviada, uma nova requisição é enviada ao banco de dados, através da conexão que você abriu (sim, isto é tráfego de rede). Ao receber a requisição, o engine do banco de dados realiza primeiro o que é chamado de execution plan. Ele estima algumas formas de como pode executar sua requisição, e executa aquela que ele julga ser a mais apropriada (com menor custo ao sistema). Isso é assunto pra tese de doutorado, então não vou me ater a explicações profundas sobre isso. Mas só para constar, triggers, rules, reconstrução de índices, validação de constraints e outros recursos também entram nas contas das estimativas do execution plan, daí você imagina o trabalho do servidor de banco de dados ao decodificar cada query ANTES de executá-la.

Executar a query, envolve além de consumo de processamento e memória, acesso a discos, e possivelmente gravação neles (o que nos trás de volta ao SO, que é o responsável por essa parte de acesso e gravação em discos).

Terminada a maratona da execução, o banco de dados retorna o resultado disso para o PHP (através daquela conexão que ele tem, lembra?). Para daí em diante o PHP continuar o seu processamento. Lembre-se que tudo o que foi descrito acima vale para CADA QUERY enviada. Chegando ao fim do script, o PHP fornece o seu produto ao Apache, que o formata, codifica, etc... e envia em gentis pacotes ao cliente através da rede.

Agora, o que aconteceria se enviássemos menos queries? Conseguem ver a vantagem? Este é o motivo pelo qual é muito importante usar de forma eficiente e inteligente os recursos que os servidores de bancos de dados oferecem. Isso deixa os códigos mais elegantes e limpos, o sistema gerlamente fica mais seguro, mais fácil de fazer manutenção, e otimizado (sem contar que dá pra cobrar uma grana a mais pelo serviço mais profissional).

Dou o artigo como encerrado por aqui. Em breve escrevo mais sobre otimização e segurança no lado dos BDs, e no PHP em si.

See ya.
-----------
keepReading