Pedro Franceschi

  • Archive
  • RSS
  • Ask me anything

Porque eu troquei o TextMate/Emacs pelo Vim

Hoje faz quase 3 meses desde que eu comecei a usar o Vim pra valer. E quando digo “pra valer”, quero dizer que passei a usá-lo no dia-a-dia como meu editor de texto principal, e não apenas para fazer edições simples em arquivos por SSH. Antes de contar minha história com editores de texto e como está sendo minha experiência com o Vim, darei um spoiler: não estou arrependido da minha escolha - muito pelo contrário.

Fui apresentado formalmente ao TextMate em 2009 pelo @benjaminjackson quando nós trabalhávamos juntos. Desde então passei a usá-lo para *tudo* (programação, obviamente, e até para escrever textos), porque o Xcode (que eu usava até então) falha miseravelmente (na minha opinião) no que deveria ser sua função principal: editar código. Sempre o achei lento e ineficiente nisso.

O TextMate me serviu muito bem por 4 anos. Afinal, ele tem features que realmente encantam um (ex-)usuário do Xcode, como o “Command + T” para abrir arquivos, “Command + Shift + F” para fazer buscas de texto no projeto inteiro, etc. Mas depois de algumas horas programando nele, o movimento de alternar a mão entre o “centro” do teclado e as setas (que são *essenciais* para editar qualquer coisa no TextMate) começava a incomodar. Eu percebi, depois de 4 anos, que passava mais tempo tentando colocar o cursor no lugar exato do que editando o código em si. Isso começou a me irritar porque eu sabia que poderia ser mais eficiente se conseguisse programar sem esse tipo de interrupção.

Comentando com um amigo na época (início de 2012, se a memória não me falha), ele, como um bom evangelista do Emacs, me apresentou ao seu editor de texto favorito. O engraçado foi que a primeira coisa que ele me disse foi: “o Emacs é tão fantástico que dá até pra jogar Tetris dentro dele!”, e não algo como “olha como eu sou rápido editando com ele… duvido que o TextMate faça isso aqui, ó!”. Isso me deixou atento para algo que meses mais tarde seria óbvio para mim: o Emacs é um bom sistema operacional, só falta um editor de texto decente.

Mesmo assim, na época dei uma chance para o Emacs me conquistar. Tentei de tudo para torná-lo usável. Baixei várias configurações prontas que (teoricamente) tornariam a vida de um usuário iniciante mais fácil, remapeei algumas combinações de teclas que usava com frequência para algo mais óbvio e que não precisasse de três mãos para digitar, baixei temas visualmente agradáveis e mesmo assim não conseguia ser produtivo e usá-lo realmente no dia-a-dia. Quando precisava ser produtivo, acabava voltando pro bom e velho TextMate, sempre com a sensação de que não ganharia nada com o Emacs mesmo com muita prática.

E ao mesmo tempo que coisas legais do Emacs me chamavam a atenção (como a integração dele com Lisp, que é de dar inveja a muita IDE) e eu comentava sobre ele no Twitter, algumas pessoas de lá insistiam que eu deveria experimentar o Vim, que na época eu só usava para editar arquivos remotos por SSH. E como todo bom participante de uma editor war, sempre retrucava esses engraçadinhos que falavam mal do Emacs. :P

Um dia eu perdi a cabeça com o Emacs tentando fazer algo que me parecia muito óbvio, mas a complexidade de keystrokes envolvidas me irritou. Resolvi abandoná-lo, embora não estivesse 100% satisfeito com o TextMate. Deixei o haterismo/editor war/zoeira de lado e pensei em dar uma chance ao Vim, embora estivesse preparado para mais uma possível decepção produtiva como aconteceu com o Emacs. Quem me motivou a me arriscar com o Vim foi o @henrydubugras, que passou literalmente dias me falando o quanto o Vim era fantástico. Marquei o início da minha experiência com o Vim nesse tweet para as futuras gerações. :P

Para ter uma ideia de como funcionava o Vim, abri o Terminal, digitei “vimtutor” e fiz o tutorial básico de como usá-lo, que dura menos de 20 minutos. Também comprei o screencast Smash Into Vim I, do Peepcode, para dar uma ajuda em estabelecer um workflow inicial. O screencast é excelente e pela primeira vez acreditei que talvez essa mudança para o Vim poderia ser realmente promissora.

O pessoal do Twitter me recomendou a usar o MacVim ao invés do Vim “clássico” de linha de comando, já que não poder usar o mouse de forma nenhuma pode ser um tanto quanto assustador no início (e recomendo o mesmo para quem queira começar com o Vim, pelo menos num primeiro momento). Bom, baixei o MacVim e estava pronto para começar a programar!

A primeira semana com o Vim foi dolorosa. Se adaptar ao modal-editing (isso é, ter que ativar um modo especial sempre que você quer inserir texto no arquivo) parecia impossível e uma ideia absurda, que só ficou clara para mim depois de alguns dias lutando contra o teclado. Aliás, a grande maioria das coisas do Vim aparentemente não fazem sentido algum no início, mas com o uso fica claro como cada detalhe contribuí para torná-lo um editor de texto incrivelmente ágil e prático.

Muita gente não entende a complexidade de migrar de um editor de texto “normal” para o Vim. Para isso, entender a filosofia dele é fundamental. A ideia básica do Vim é permanecer sempre com as mãos na parte central do teclado. Assim gasta-se menos tempo com deslocamentos desnecessários das mãos e sim com a edição em si. Embora pareça complicado no início não usar o mouse e nem as setas, é isso que torna o Vim tão eficaz. Como li por aí em algum blog, o Vim te torna um “cirurgião de texto”, o que é pertinente. E se adaptar a ele até chegar num nível de edição cirúrgica é o que dá trabalho. Como o @AlexandreTorres disse outro dia, “Vim é um gosto adquirido, você o odeia até imergir nele”.

Bom, voltando a minha experiência, os dias se passaram e na segunda semana eu já era bem menos lesado usando o Vim. Nesse período, comecei a buscar as configurações perfeitas para deixar o editor exatamente como eu queria. A aparência dele é algo que pelo menos para mim é bastante importante. Já que eu passo várias horas por dia olhando para o meu editor, ser bonito e atraente é um pré-requisito para mim. Com o colorscheme Bad Wolf e o Powerline, consegui ter uma aparência visualmente legal (e até melhor que a do TextMate, na minha opinião) para um editor de linha de comando, o que me motivou de certa forma a ir em frente.

image

A aparência do meu Vim

Ao mesmo tempo, comecei a buscar plugins para tornar a vida no Vim mais fácil e rápida: o CtrlP para funcionar como um substituto do “Command + T” do TextMate, o TComment para comentar blocos de código como o “Command + /” faz, e outros que só são realmente úteis no Vim, como o YankRing, que cria uma espécie de clipboard dos yanks (copies) e deletes. Aos poucos usar o Vim deixou de ser algo doloroso e se tornou algo bastante agradável. Com mais ou menos um mês de uso eu já era tão eficiente quanto era no TextMate, e a partir daí foi impossível voltar atrás.

Quando eu precisava abrir o TextMate por algum motivo, sempre me perguntava como passei tanto tempo adorando programar de forma tão ineficiente. Para mim é realmente bizarro dizer isso de um programa que me acompanhou durante 4 anos ininterruptos no meu trabalho. A mudança para o Vim fazia cada vez mais sentido e se tornava mais e mais definitiva a cada dia.

Usando o Vim para *todo* tipo de edição de texto que eu fazia, fui instalado plugins e aperfeiçoando meus vimfiles para ter a melhor experiência possível sempre e ficar cada vez mais ágil. Passei a criar gosto por ler sobre o Vim, sobre novos plugins e sobre como outros usuários o usam. A comunidade em volta dele ajuda usuários novatos a se adaptarem, além de ter um suporte excelente e ser muito receptiva e amigável. E se você precisar de algum plugin/configuração específica para o seu Vim, acredite: alguém já o fez e colocou no GitHub. É procurar e encontrar. Isso é com certeza uma vantagem trazida por uma comunidade de um editor de texto que já tem mais de 20 anos de idade: sempre tem alguém trabalhando em coisas legais e resolvendo problemas.

Mesmo tendo me apaixonado pelo Vim, hoje não desprezo o Emacs. Ele é um editor de texto incrivelmente poderoso, que ainda faz algumas coisas que o Vim não consegue devido a forma com que ambos foram pensados. Um exemplo é o Minimap, recurso belíssimo do Sublime Text 2, que já conseguiram replicar para o Emacs mas não para o Vim por uma questão conceitual de como a “interface” do editor é renderizada na tela. Nem tudo na vida são flores. :P

Nesses 3 meses realmente me surpreendi com o poder do Vim. É, de fato, um software incrivelmente poderoso, customizável e pensado na agilidade. Essas características o fazem ideal para mim e é por isso que não penso em voltar atrás para o TextMate. Tudo o que eu tinha nele eu tenho no Vim, de forma igual ou melhor. Isso sem contar na eficiência que ganhei seguindo a risca a filosofia de edição do Vim.

Para quem quiser, meus vimfiles estão no GitHub. Fiz eles praticamente do zero quando comecei com o Vim e fui adaptando às minhas necessidades, então acredito que funcione bem para quem quer começar.

Acho que a moral dessa história é: não tenha medo de tentar algo novo. Às vezes as coisas diferentes das quais estamos acostumados (e que muitas vezes temos medo por não conhecermos direito) podem se adequar melhor a você. Foi o meu caso com o Vim. E você? Como foi sua experiência com ele? Conta aí! :)

  • 1 month ago
  • 1
  • Permalink
  • Share
    Tweet

Renderizando um átomo de carbono tridimensional com Javascript (“Tribute to carbon atom”)

Já faz algum tempo que eu queria fazer alguma coisa usando o Three.js, uma biblioteca Javascript que facilita a criação de 3D e ainda consegue renderizá-las usando WebGL ou Canvas (o que é ótimo).

Então nessa madrugada resolvi tentar renderizar um átomo de Carbono (uma espécie de homenagem a ele) usando a biblioteca, e o resultado foi bem interessante. Irei relatar como fiz isso, mas antes veja o resultado final da renderização clicando aqui ou na imagem abaixo. (Nota: é preciso do WebGL habilitado para que a renderização funcione. Caso você use o Safari, siga essas instruções para habilitá-lo)

Foi relativamente fácil fazer essa renderização usando o Three.js. Basicamente se trata de colocar duas fontes de luz, posicionar o núcleo (cada próton e neutron), desenhar a trajetória de cada elétron, posicionar cada elétron e repetir isso a cada frame renderizado.

A matemática usada é pura e simples trigonometria que se aprende no colégio. Cada elétron tem um raio e um ângulo de órbita (em relação ao eixo x), que é fixo, e um ângulo de rotação (em relação a sua posição inicial), que é atualizado a cada frame. Ao renderizar o frame, as posições dos elétrons são recalculadas (para x, y, e z) a partir do ângulo e raio de órbita e ângulo de rotação. Simples assim, e funciona em menos de 200 linhas de Javascript.

Tomei cuidado em fazer os raios das órbitas dos dois primeiros elétrons de tamanhos diferentes para indicar as diferentes camadas eletrônicas. Isso fez com que o modelo ficasse mais didático/”real”, o que eu achei interessante.

Além disso, é bom deixar claro que esse modelo não tem como objetivo ser totalmente fiel a realidade, então não venha reclamar do tamanho dos elétrons e/ou do posicionamento dos prótons e neutrons no núcleo. Essa brincadeira foi só pra me divertir um pouco na madrugada, e acabou produzindo um resultado interessante! :P

Até a próxima!

    • #projeto
    • #átomo
    • #química
    • #3d
    • #javascript
  • 8 months ago
  • Permalink
  • Share
    Tweet

Reestruturação + migração para a DreamHost

Com as férias, finalmente tive tempo para fazer uma unificação decente dos meus servidores/domínios, que sempre foram muito zoneados… O meu servidor de DNS, por exemplo, apontava para uma série de IPs diferentes, cada um de um serviço do domínio em uma máquina diferente. Estava confuso e comecei a ficar de saco cheio dessa putaria bagunça resultante de criar configurações na mão para tudo nos servidores, do zero.

Então resolvi migrar tudo para a DreamHost. Me perguntaram no Twitter o porquê de eu escolher a DreamHost logo de cara, e o motivo é: facilidade e preço. Vários amigos têm servidores por lá, gerencio os servidores de dois deles e sei que o serviço é minimamente bom a ponto de atender minhas necessidades. Vale a pena lembrar que não existe serviço de hosting perfeito. Já usei outros três (Locaweb, HostGator e NetworkSolutions) e digo: todos têm um ponto (muito) fraco e irritante.

Além disso, a DreamHost tem VPS com 300MB de RAM (o suficiente para os meus serviços web, pelo menos) + painel de controle com Apache, Nginx, MySQL e SVN configuráveis (o que eu já cansei de mexer na mão também…) + bandwidth e armazenamento ilimitado por US$15, então acho que no final a comodidade acaba valendo a pena.

Fiz o cadastro na DreamHost, porém a ativação não foi instantânea devido um problema na autorização do meu cartão. Entrei em contato com o suporte e embora a demora, depois de 12 horas tudo estava resolvido e ativado. Hora de começar a migração (e de roer as unhas).

Mudei o nameserver do domínio para a DreamHost, cruzei os dedos e esperei o DNS propagar. Em 4 horas a Velox já pegava o novo endereço. Uma coisa que eu sempre fiz (e acho interessante) é manter o DNS hospedado em uma empresa diferente da de hosting. Dessa forma, caso aconteça algum problema em uma das duas empresas, você tem uma espécie de “separação da chave do cadeado” que pode salvar sua vida numa emergência. Ok, ok, eu sou paranóico e eu sei disso. :P

A migração do SVN foi a parte mais trabalhosa. Eu tinha 72 projetos hospedados num servidor da DreamHost de um amigo e tinha que passá-los para a minha conta agora. Gerei o dump dos projetos no servidor original usando o seguinte comando:

svnadmin dump project | gzip > dump_project.gz

Então copiei os dump pelo scp para o meu servidor novo, recriei cada projeto manualmente no painel de SVN da DreamHost e apliquei os dumps usando esse comando:

gunzip -c dump_project.gz | svnadmin load project

Fiz um bash para automatizar o processo e duas horas depois tudo estava copiado no servidor novo.

Depois do SVN, faltava migrar as páginas HTML estáticas, o que não deu muito trabalho usando o painel da DreamHost. Criei uma landing page para o pedrofranceschi.com (que ficou bem interessante) e mudei o endereço do blog para blog.pedrofranceschi.com. Essa era uma reestruturação que eu queria fazer faz tempo.

E por falar em blog, a única coisa que eu não migrei foi ele, pois prefiro deixá-lo hospedado no Tumblr e ter menos uma coisa pra me preocupar. Somente adicionei o CNAME do Tumblr para o subdomínio blog e alterei o domínio nos Settings do Tumblr

Resumindo: depois de dois dias a migração está completa, minha vida está menos bagunçada e mais unificada, e o esforço valeu a pena. Ah, e se você sentir algum problema de estabilidade ou lentidão, por favor me avise, obrigado!

    • #migração
    • #dreamhost
  • 10 months ago
  • Permalink
  • Share
    Tweet

Projeto novo: Quasar

Nos últimos dois meses estive trabalhando em quase total segredo num projeto novo para iPads jailbroken. Mais precisamente, estava trabalhando no meu maior projeto (até o momento) para iOS.

Ele se chama Quasar e é um gerenciador de janelas para iPad. É isso mesmo: com ele você pode rodar suas aplicações em janelas, assim como fazemos num sistema operacional de Desktop! É possível redimensionar, mover, fechar e colocar em full-screen uma janela.

É muito mais fácil vê-lo em ação do que tentar ficar descrevendo-o, então aqui segue uma vídeo-demonstração:

E algumas screenshots dele rodando:

O Quasar está disponível na Cydia Store por US$9.99, compra lá! :)

    • #Projeto novo
    • #quasar
    • #jailbreak
    • #cydia store
  • 1 year ago
  • 3
  • Permalink
  • Share
    Tweet

Inter-process communication in iOS.

Almost any modern operating system has a kernel-based inter-process communication (IPC) interface. That’s not different in Apple’s iOS. IPCing is useful when tweaking around, mainly to integrate SpringBoard and other processes that are running simultaneously.

Fortunately, Apple provides CPDistributedMessagingCenter, that is a high-level wrapper to Darwin’s kernel-based IPC. It is a private wrapper that acts behind the scenes of a big part of iOS.

CPDistributedMessagingCenter works with a server/client interface. The server receives calls for a registered notification, and the client sends the notifications with an optional userInfo NSDictionary. Here are some examples:

Client (send notifications):

https://gist.github.com/2322190

Server (receive notifications):

https://gist.github.com/2322157
    • #technical
    • #objective-c
    • #tweaking
  • 1 year ago
  • 1
  • Permalink
  • Share
    Tweet
← Newer • Older →
Page 1 of 4

About

Lorem ipsum sit dolor amet. Hello World. White and Nerdy. That's what you will find here.
pedrohfranceschi@gmail.com

Twitter

loading tweets…

  • RSS
  • Random
  • Archive
  • Ask me anything
  • Mobile

Effector Theme by Carlo Franco.

Powered by Tumblr