Mais um post interessante digno de filosofar.

Steve Ballmer (CEO da Microsoft) disse que a Microsoft está adotando uma nova política e a partir de agora estão trabalhando para que os produtos da empresa garantam: interoperabilidade, oportunidade e escolha.

O Lucas comenta:

E agora, comunidade open-source? Vocês reclamavam que não tinham acesso ao código de fonte dos produtos da Microsoft.O mesmo ainda não está disponível (depois dessa eu não duvido de mais nada…), mas em breve, tudo estará perfeitamente documentado. Satisfeitos? Podemos esperar melhorias nos programas que serão diretamente e indiretamente beneficiados depois dessa medida? Tomara que sim.

Negócios são negócios, não tem jeito! Quando conversamos, discutimos ou até brigamos para defender nossas idéias, vocês podem ter certeza que o Ballmer tem um relatório em cima da sua mesa com tudo isso em números! Eles não estão adotando uma nova política para agradar o cliente, por algum motivo eles se sentiram incomodados ou ameaçados e estão mudando para não perder o mercado.

Quando a Microsoft começar a se incomodar com o número de usuários Linux, com certeza ela vai diminuir o preço de seus produtos e porque não até deixá-lo gratuito?

Mudança de política? Com certeza não! A política da Microsoft foi e sempre será ganhar dinheiro ou ser a número 1 do mercado.

Esse post me fez lembrar de um fato que aconteceu em 2003, quando estava apresentando meu projeto de conclusão do curso técnico. Na apresentação tive a infelicidade de dizer que procurei fazer o sistema para que ele ficasse simples e funcional.

Fiz minha apresentação, e no final um dos examinadores falou: “Meu jovem, seu sistema ficou muito interessante, mas quando você for vender seu sistema lembre-se de uma coisa: Tudo que é simples é barato e tudo que é barato, não presta!”.

Graças ao capitalismo, temos uma visão mercantil de tudo que nos cerca. O mundo é movido por essa visão e por isso é tão difícil aceitar que o software livre seja tão bom quanto os softwares proprietários.

Ninguém acorda cedo para trabalhar de graça não é?

O modelo de desenvolvimento do software livre nasceu com outro paradigma. É difícil acreditar que a “desigualdade nas trocas” seja uma coisa boa. O cara faz um software e em troca ganha agradecimentos, lembranças, doações que talvez não pagassem nem a hora de um programador. Lógico que existem projetos de softwares livres que envolvem muita grana. Não é novidade para ninguém que dá para fazer negócio com software livre. Mas mesmo assim para o usuário final, que acorda todos os dias cedo para trabalhar em troca de um salário no final do mês, é difícil aceitar esse novo paradigma. Quebra de paradigmas implicam em resistência.

As empresas de desenvolvimento de softwares proprietários impõem restrições para dificultar o crescimento do software livre. Mas esse é o mundo dos negócios. Se existisse uma perfeita compatibilidade entre o openoffice e o msoffice com certeza a Microsoft perderia uma fatia do mercado. Eles são malvados? Será que você faria diferente?

Esse assunto é muito delicado. Talvez isso que eu falei acima seja apenas mais um motivo pelo qual o Linux e outros softwares livres não “emplacam”.

Falei né? Está aqui!

Haha, Adorei esse site

http://www.tirasdoedi.com.br/

Acho que vou criar uma conta no Twitter para mim.

Para quem está começando a usar Linux, a primeira dificuldade encontrada é justamente a instalação de programas.

Quem vem do sistema do mau tem o costume de ir lá no superdownloads escolher algum programinha, faz o download, dá um clique duplo no arquivo baixado e começa a instalação NNF (Next, Next, Finish) e pronto, o aplicativo está pronto para usar.

Quando esse tipo de usuário vem para o mundo linux ele se depara com uma série de nomes estranhos como: pacotes, repositórios, até o nome “Gerenciador de pacotes” assusta, não é? Sem falar que apenas o root que pode instalar programas e ainda tem aquela tela preta (o terminal) que todo mundo usa e ele acaba falando: Linux é sistema para programador!

Permitam-me fazer uma citação:

“[..] o mundo moderno, a despeito de aparentemente confuso, complicado e ostensivamente enganoso, não é impenetrável, não é indecifrável - desde que seja feita as perguntas certas - é ainda mais intrigante do que imaginamos. Basta adotar uma nova maneira de vê-lo.”, Levitt (2005).

Esses usuários novos não sabem a diferença entre difícil e diferente. Não é porque digitar um comando no terminal é diferente que isso passa a ser difícil não é? Como Levitt falou, precisamos adotar uma nova maneira de ver o mundo e ver o que essas ferramentas têm a oferecer a você.

Vamos comparar o processo de instalação entre o sistema do mau e o Linux.

No sistema do mau, você vai caçar na internet (com sorte vai achar) o programa desejado. Vai dar inicio o processo de download e esperar algum tempo (dependendo do tamanho do programa). Vai procurar a pasta onde o seu programa foi salvo após o download e vai dar inicio ao processo de instalação. Sendo bastante generoso você vai passar por no mínimo quatro telas com informações que a maioria dos usuários comuns não vão entender (isso é, se ele tentar ler :P). Com um pouco de sorte, esse programa vai gerar um atalho na área de trabalho ou você vai ter que procurar numa listagem não classificada de programas lá no menu iniciar. E vai ser feliz com seu programa.

No Mandriva Linux, você pode instalar o programa a partir do terminal. (Ah, não!! Lá vem você com o terminal…) Abra o terminal, você vai entrar com o usuário administrador do sistema e digitar: urpmi nome_do_programa. Pronto! O Mandriva linux vai caçar o programa desejado nos repositórios da internet, vai fazer o download, vai instalar e vai jogar num menu organizado em sua área de trabalho.

E ai, o que é mais difícil? Lógico que existe uma série de fatores que inviabilizam a aceitação do usuário final ao sistema Linux como compatibilidade de softwares, jogos, etc… Mas com certeza o maior fator é sim o preconceito do usuário.

Pense nisso

Primeiramente gostaria de agradecer os elogios sobre a série de artigos sobre o VIM. Atendendo a pedidos da galera, peguei todos os comandos que mostrei nos três posts e coloquei em apenas uma página

A propósito, tenho que concordar com o Aurélio, é muito chato arrumar essas tabelinhas Clique abaixo e pegue o seu:

Beleza! Vamos continuar falando do nosso querido e amado editor: vim.

Quando o assunto é flexibilidade de janelas, abas, o vim oferece mais um recurso interessante: o split. Ele permite a divisão do mesmo arquivo na mesma janela. Assim você pode editar várias partes do mesmo arquivo em pontos diferentes. O comando é :split.

É possível usar a visualização vertical aqui também com o comando :vsplit.

Para alternar de uma janela para outra use o comando Ctrl+ww

Outra dica valiosíssima que vai deixar muito desenvolvedor de queixo caído é a tecla de atalho Ctrl+Shift+p que permite autocompletar código.

O truque dessa tecla de atalho está na hora que você importa as bibliotecas. Além das propriedades e métodos, ele também completa nome de variáveis e nome de funções. Eu testei esses recursos com as linguagens PHP, Python e C.

Interação com terminal

Quem está programando, precisa testar a aplicação. E não é nada legal ficar fechando o vim para usar o gcc ou o interpretador do python no terminal, não é? Com o comando :shell você abre um terminal dentro do vim. Assim você pode testar o que precisar e para sair é só fechar com o comando exit.

Quando o assunto é interação com o shell ainda dá para jogar a saída de um comando do terminal dentro do vim com o comando :r! <comando> . Exemplo: :r! cat /etc/passwd . Vai aparecer algo assim:

Nossa última tabelinha:

Concluindo

O vim é foda um editor de texto muito poderoso. Se você aprender a usá-lo com certeza ele vai deixar muitos editores modo gráfico para trás. Existe a documentação interna do próprio vim, que tem tudo que você precisa saber sobre ele, para acessá-la digite o comando :help.

Foquei esse artigo em recursos que podem ajudar o desenvolvedor. Se vocês conhecem outras funcionalidades ou comandos interessantes, deixem aqui no comentário desse post.

Até a próxima

Hoje vamos brincar com janelinhas e abas.

Imagine a seguinte situação: você tem um arquivo CSS e um arquivo (X)HTML. Você está montando aquele layout em CSS e precisa ficar mexendo com os dois arquivos ao mesmo tempo. O Vim deixa você trabalhar com mais de um arquivo na mesma tela com o comando :new. Veja como fica:

Para alternar as janelas use o comando Ctrl+WW. Para abrir um arquivo na nova janela, use o comando :open.

Você pode não gostar da visualização horizontal das janelas. É possível abrir um novo arquivo numa coluna vertical com o comando :vnew . Para alternar e abrir arquivos, a regra é a mesma:

Dá para trabalhar com várias “novas janelas” mas quanto mais janela, pior fica a visualização delas. Para resolver esse problema, é possível trabalhar com abas. Não, não estamos falando do firefox Dá para trabalhar com abas no vim também com o comando :tabnew. Isso mata o problema da visualização. Para navegar entre as abas use o comando :tabnext ou Ctrl+(PageUp | PageDown). Olhe como fica:

Voltando as tabelinhas, abaixo segue uma com os comandos feitos nesse post, com alguns comandos que não citei acima:

Legal né? Ainda tem mais coisa que vou colocar no terceiro (e talvez último) post dessa série.

Você está procurando um ambiente de desenvolvimento completo, sem frescura, use o VIM! É sério… O VIM é um editor muito poderoso!

Vou dar algumas dicas aqui que me ajudam bastante no meu dia-a-dia:

Inicialmente vou colocar uma tabelinha dos comandos mais comuns que provavelmente qualquer usuário vai usar:

Certo, já sabemos copiar, colar, recortar… (no final desse post quero ver todo falando <ESC> + y, <ESC>+p em vez de ctrl+c e ctrl+v :P)

Agora, mais uma tabelinha que pode facilitar a vida de vocês:

A mesma sintaxe funciona para recortar e copiar, vou colocar as tabelinhas só para constar:

O vim deixa colorida das palavras reservadas das linguagens de programação. Ele associa a extensão do arquivo para começar a marcação. Caso não apareça a cor use o comando:

Mais uma tabelinha recheada de comandos:

Essa função de localizar strings é muito útil para localizar funções numa biblioteca.

Vou separar em dois ou três posts tudo que eu quero escrever sobre o Vim. Por hoje é só. Qualquer dúvida, poste nos comentários…

A duplinha urpmq + grep pode ser uma mão na roda quando você não sabe o nome de um pacote. As vezes a saida do comando urpmq é muito extensa e não é legal ficar procurando o pacote que você deseja.

Exemplo: Você quer saber o nome do pacote que contem o módulo que permite que o apache converce o PHP?

$ urpmq -y apache | grep php

A saida desse comando vai ser algo assim:

[edgar@localhost ~]$ urpmq -y apache | grep php
apache-mod_php
apache-mod_suphp
apache-mod_suphp4
apache-ssl-mod_php

Olhá lá nosso pacote