Sexta-feira, 17 de setembro de 2010 às 11:50 horas da manhã meu voo chega no Brasil. Yupiiiiii!

Domingo, 26 de setembro de 2010 meu voo de volta para Santiago, Chile deixa a cidade de São Paulo.

Serão 9 dias muito, muito felizes para mim. Depois de 5 semanas completamente sozinha em Santiago, rever todos vocês terá um gosto especial.

Amo vocês. (toda emo).

Então, esse é mais um post me lembrar como resolver a chatice que é instalar a gem de Postgresql.

* Se a gem for instalada pela linha de comando é só setar ARCHFLAGS:

$ sudo env ARCHFLAGS=”-arch i386″ gem install postgres
ou se a máquina for 64 bits:
$ sudo env ARCHFLAGS=”-arch x86_64″ gem install postgres

Agora, como o assunto da moda é RVM e Bundler, não vale alterar o Gemfile para não instalar a gem. Uma solução é fazer export do ARCHFLAGS ou colocar diretamento no .bashrc.

* Se a gem for instalada via bundler, a coisa mais fácil é setar o ARCHFLAGS ou colocar no .bashrc

1) Selecionando as linhas:
- CTRL+V para ir para o VISUAL MODE e selecione as linhas que você quer comentar;
- Digite : (dois pontos)
- Digite s/^/#/
- ENTER

2) Informando as linhas:
- No console do Vim digite :X, Y s/^/#/
Onde X é a primeira e Y é a última linha que você quer comentar.

Note:
s/// faz a substituição.
^ é diz que é para alterar o início das páginas
# é o símbolo de comentário de ruby, use o símbolo de comentário da sua linguagem.

Na época, eu tive a idéia de apresentar palestrar sobre o tema em faculdades de TI em São Paulo, onde eu morava. Semanas depois de iniciar o projeto e contatar algumas faculdades, recebi uma proposta para trabalhar no Chile e acabei encaixotando a idéia até decidir minha vida.

Hoje, morando no Chile, eu pretendo colocar o tema em discussão novamente e pensar em como eu posso contribuir mesmo morando longe de São Paulo.

No futuro eu quero falar sobre o assunto nas faculdades aqui no Chile também.

Um bom ponto de partida para mim é descobrir mais mulheres que trabalham com tecnologia no Brasil e manter contato com elas. Atualmente eu participo de um grupo só para mulheres de tecnologia chamado DevChix e recomendo o ingresso de outras brasileiras por lá.

O mais legal em participar do DevChix é que o pessoal é super respeitoso. E o mais importante, entende a dificuldade de ser mulher no mercado de TI.

Embora pareça coisa do tempo das cavernas, é muito comum discriminação com mulheres que trabalham em TI.

Eu mesma já fui ignorada N-vezes em reuniões ou decisões técnicas em empresas que trabalhei e, quando uma mulher em uma situação dessas levanta a voz ou impõe seu direito de participação a molecada sempre insinua que é TPM.

O legal de ter uma lista só para mulheres é poder compartilhar esse tipo de experiências e ouvir alguns conselhos sem parecer “coisa de menininha”. Portanto, eu encorajo todos os programadores a convidar suas colegas de trabalho à entrar no grupo.

DevChix é um grupo internacional, logo, o pessoal fala inglês por lá. Embora o grupo seja muito receptivo e não se importe se usou o Google Translate para escrever alguma coisa, nós decidimos que não importa a língua em que você escreva e sim o que você quer dizer. Logo, mandem suas mensagens também em português.

Para isso, inicie o assunto (subject) do e-mail como [Português] ou [Portuguese] e mande sua mensagem.

Para aquelas que ainda não se sentirem confortáveis em mandar mensagens em português para a lista, eu encorajo-as à ao menos me mandar um e-mail para que possamos manter contato e quem sabe pensar juntas em como tornar as mulheres mais participativas.

Meu e-mail: thais.camilo@gmail.com

De fácil leitura, é um livro compreensível até para aqueles que não são fluentes em inglês. Muito bem dividido em seus capítulos e tópicos, não permite que o leitor sinta-se cansado mesmo falando sobre um tema que costuma ser massante: empresas.

Aliás, esse é o desafio do livro: quebrar todos as crenças que a maioria das empresas seguem, mostrando que uma empresa pode, e deve, ser um lugar menos rígido e inflexível. Baseado no sucesso da própria empresa, a 37Signals, eles falam sobre temas que cercam uma empresa: cultura, código de conduta, produtividade, crescimento, empregados, competidores entre outros.

Desde que trabalhava na empresa do meu pai, uma fábrica de materiais para fechamento de embalagens, moldada com regras e crenças como a maioria das empresas, eu acreditava que as coisas deveriam ser um pouco mais leve mas não sabia por onde começar.

Quando finalmente comecei a trabalhar com desenvolvimento web percebi que esse era o lugar. Desde então, procurei por empresas que se parecessem com isso. Quer saber como é? Vai lá: http://www.amazon.com/Rework-Jason-Fried/dp/0307463745

Sou programadora há quase 9 anos, todos eles com desenvolvimento web.

Desde meu primeiro trabalho como programadora nunca tinha ido atrás de emprego, normalmente ele vinha atrás de mim através de amigos e colegas de trabalho. Já fiz projetos com C, C++, Phyton e Java além de trabalhar com ASP, PHP, Perl e mais recentemente Ruby.

Em meados de 2007 eu trabalhava feliz e contente com Perl até que um amigo me falou sobre uma vaga de Ruby on Rails. Há 2 anos atrás, não era tão fácil encontrar pessoas que já programavam Rails no Brasil. Por esta razão, o contratante estava mais focado em encontrar pessoas que pudessem se encaixar no perfil da startup que ele estava criando ao invés de buscar alguém com experiência na tecnologia. Sorte minha!

Depois de um longo verão feliz, as coisas começaram a mudar e eu me vi querendo mudar de emprego e continuar com a tecnologia. Acabei saindo da empresa e me encontrei tendo que procurar um novo emprego.

Depois de um currículo enviado aqui, outro currículo enviado ali eu me dei conta das mudanças que Rails causou nas entrevistas de emprego.

Currículo é um padrão mundial. É através dele que o empregador conhece um pouco da história do candidato. Embora atualizar currículo seja uma tarefa responsável por muita dor de cabeça, eu estava já estava preparada para essa parte.

O que eu não estava preparada era para as novas solicitações dos empregadores: twitter, blog, github, linkedin,working with rails, personal website, pet project, comunidades que participa, projetos sociais, projetos open source, etc.

Haviam 6 meses que eu não andava muito empolgada com meu dia-a-dia. Embora Rails me motivasse a trabalhar, o clima diário da empresa fazia o trabalho inverso. Com isso, eu mal tinha empolgação para gastar as horas diárias que todo programador dedica para manter-se informado. Quem dirá, manter toda essa lista de requisitos atualizada e fluindo.

Fora isso, eu nunca estive nos primeiros lugares nos rankings das pessoas que mais postam em listas de discussões, não tinha um blog, tampouco site pessoal e nem tinha pet project em produção. Também, nunca fui muito de usar todos os poderes de redes sociais, inclusive o linkedin e working with rails.

Parte desse anonimato está diretamente ligado ao fato de que a maioria das programadoras não se sentem confortáveis em se tornar tão pública em listas de tecnologia e afins mas esse  é um assunto para outro post.

O fato é,  não tenho dúvidas de que uma pessoa consiga o emprego mesmo sem todos esses requisitos preenchidos. Fora que, é bem frustante a primeira vez que alguém te pede essa lista de informações e você simplesmente não tem.

O working with rails, por exemplo. Esta é uma rede social de programadores Rails. O fato de não ter conexões e/ou  indicações por lá por significar duas coisas:

1. Eu não uso a rede
2. Eu não sou uma pessoa recomendável

Neste caso, vai depender de quanto o empregador está interessado em conhecer de mim para tirar as conclusões corretas. É claro que, também depende dele pensar se o fato de eu não usá-la faz de mim uma programadora “menos engajada”. Neste caso eu preciso contar com a sorte, o bom senso para a minha experiência prová-lo o contrário.

Minha conclusão: as coisas mudaram mas você não precisa mudar. Só vale a pena preencher todos esses requisitos se você realmente acredita que vale a pena e que isso pode te trazer bons frutos. Tempos atrás eu diria que não vale a pena.
Hoje, venho mudando minha opinião mas isso também cabe em outro post.

Definição:

Pair programming é uma técnica de desenvolvimento de software onde 2 programadores trabalham juntos em uma estação de trabalho. Mais detalhes consulte a Wikipedia: http://en.wikipedia.org/wiki/Pair_programming.

Trabalhei com programming apenas em 1 empresa por 9 meses. Deste período, tirei ótimas e péssimas experiências.

Durante os momentos em que você divide o computador com outra pessoa, você divide também detalhes de uma vida virtual, como:

• organização: como você organiza documentos, projetos, músicas, etc
• escolhas: quais aplicações você usa e de que forma você as usa, como: temas, hotkeys e configurações.
• habilidades: velocidade de digitação, quanto você aproveita das aplicações que usa e até mesmo quanto conhecimento você tem sobre a aplicação que está desenvolvendo.

Claro que, uma vez em que a dupla é bem entrosada esse compartilhamento de informações só tende a ser mais e mais produtivo. A pergunta de um milhão de dólares é: “E quando esse entrosamento não acontece?“

Se ambos não estiverem dispostas à aprender com a experiência, o convívio se torna menos saudável com o passar dos dias.

Pair programming não funciona se alguma das partes se sente tão capacitado a ponto de pensar que sozinho faria o trabalho melhor. Nestes casos, o pair programming torna-se uma experiência intrusiva e negativa.

Para alguns programadores, principalmente os que se sentem ótimos profissionais, é muito difícil entender esse tipo de situação. Para tornar a coisa um pouco mais genérica, eu costumo comparar pair programming com dirigir um carro tendo um passageiro ao seu lado no banco da frente.

Situação 1: Indo por um caminho conhecido.

Imagine-se indo para uma festa, você está dirigindo o seu carro e conhece o caminho até lá. Ao seu lado, tem um passageiro, pode ser um amigo ou apenas um conhecido.

Se você tiver alguma dúvida sobre o caminho ou acabar entrando em uma rua desconhecida,  a pessoa pode pegar um guia e ajudar, sugerir um caminho mais rápido ou quem com menos trânsito.

Ao chegar à festa ambos aprenderam alguma coisa ou simplesmente compartilharam o bom tempo.

Situação 2: Um novo mundo.

Agora, imagine-se indo para outra festa. Você continua dirigindo só que agora você não sabe o caminho. Ao seu lado encontra-se uma outra pessoa, um amigo ou quem sabe apenas conhecido.

Durante o caminho você pede conselhos sobre qual caminho você deve tormar.

O passageiro por sua vez, te ajuda com o que ele sabe ou consulta um guia e te dá dicas de como chegar ao local desejado.

Ao chegar à festa vocês aprenderam um novo caminho, e mais uma vez tiveram uma boa experiência.

Situação 3: O começo do fim

Agora, imagine-se indo para uma festa, não importa se você conhece o caminho. Ao seu lado uma outra pessoa nas mesma condições anteriormente citadas.

Você continua dirigindo, só que agora o passageiro gostaria de ser o motorista. Qualquer dúvida que você tenha o passageiro olha para você e diz “Eu deveria ter vindo com meu próprio carro, teria sido melhor” ou “Se eu estivesse dirigindo isso não teria acontecido”. O que você faz?

Provavelmente ambos chegarão à festa mal humorados e tentarão a todo custo evitar esse tipo de situação novamente.

Talvez, se você estivesse no carro uma discussão aconteceria mas, durante o pair programming você está em uma corporação e algumas coisas não devem e não são ditas.

Antes de dividir o computador com alguém, pense nisso.

Depois de um tempo a quantidade e a qualidade das informações que eu produzia servia apenas como rascunhos e meu perfeccionismo não me permitia publicá-los. O tempo passou e não tenho idéia de onde foi parar o meu blog assim como alguns dos meus antigos rascunhos.

Atualmente eu escrevo parte do que eu leio e estudo, isso minimiza meus prejuízos dada a facilidade que eu tenho de esquecer as coisas.

A partir de hoje eu tenho um desafio, largar de mão o perfeccionismo compartilhando minhas idéias.