Archive for the ‘dica’ tag
O melhor modelo de curriculo para desenvolvedor que eu ja vi
No meu post anterior, eu falei sobre a importância de um desenvolvedor ter um blog e dei algumas dicas para quem quer ser um dev blogueiro. O que eu quero mostrar agora é uma forma criativa de criar um currículo para desenvolvedor. A idéia original é do railer Ilya Grigorik, que a apresentou neste Gist.
Segue abaixo o código traduzido do Ilya:
#
# Imagine você no outro lado da mesa: duas vagas de emprego, centenas de currículos,
# _todos eles_ idênticos. Sim, o RH da sua MegaCorp XYZ está usando métodos
# automatizados para analisar palavras-chave, e o departamento de cooperação da
# sua escola está tentando fazer você seguir um "modelo pré-definido".. Mas,
# a menos que você esteja procurando ser um robô na MegaCorp XYZ, designado
# à escrever casos de testes para códigos que nunca irão ver a luz do dia..
# faça um favor a você mesmo, e _seja diferente_. Seja ousado, droga!
#
# (Francamente, eu estou pegando no sono enquanto leio seus resumos..
# Me acorde! É sério!)
#
# => Coisas que nos importamos
#
# Sim, eu irei perguntar pra você sobre suas forças e fraquezas, mas na verdade,
# o melhor indicador de quem você é, é o que você faz no seu tempo livre. Projetos
# escolares são ótimos, assim como a experiência de trabalho. Mas se você
# escreveu uma biblioteca para jQuery no final de semana, você sabe,
# por diversão.. agora isso é massa. Isso diz muito, conte-me mais sobre ela.
#
# Você sabe o que isso mostra? Paixão. Você se importou o suficiente para
# fazer isso no seu tempo livre - o que te põe em menos de 10% de toda
# população de estudantes (sério).
#
# Mostre-me seu blog, conte-me uma história. Uma entrevista é sua oportunidade de
# mostrar suas coisas. Pegue meu laptop e me mostre um snippet de código que você
# se orgulha de ter feito, ou me conte sobre um problema que você está tentando
# resolver ultimamente.
#
#
# => Coisas inúteis
#
# Sua média escolar é provavelmente a coisa mais inútil para uma entrevista - de fato,
# parece que há uma correlação inversa. Quer dizer, claro que boas notas é uma coisa
# boa, mas elas não contam história, portanto não as mencione. Mesma coisa para
# hobbies do tempo de colégio: mostre-me seu trabalho recente.
#
# Ah, e não me deixe-me iniciar em coisas de palavra-chave. Eu sei que você é bom,
# mas eu duvido que você grok (http://en.wikipedia.org/wiki/Grok#In_hacker_culture)
# C/C++/Java & Erlang, todas ao mesmo tempo, depois de falar de CS 133. Saiba suas
# forças, mostre-as. Nada me impede de lhe contratar para uma vaga de Ruby
# se você sabe C++ de pé à cabeça.
#
#
# => Concluindo...
#
# Ser excepcional requer trabalho duro, mas acredite em mim, vale a pena.
# Deixe os seres automatizados irem aonde eles querem ir.. Para as MegaCorps
# que filtram palavras-chave e requerem currículos pré-formatados e impressos
# em 95% de brilho, idéias extra, papel A4. Mas você meu amigo, você é
# diferente... então seja diferente, droga!
#
# Muito obrigado,
#
# Ilya Grigorik - CTO / Fundador - postrank.com
# (twitter: @igrigorik, email: ilya@postrank.com, blog: igvita.com, github: github.com/igrigorik)
#
# P.S. Sim, nós estamos recrutando na PostRank. De fato, nós estamos sempre contratando,
# então se você acha que tem o que precisamos, mande-me uma mensagem, ou melhor,
# me mande algum código. Ficarei feliz em conversar.
#
# P.P.S. Eu levei 15 minutos para rascunhar um tipo _diferente_ de currículo. Você sabe,
# um que pode garantir uma entrevista. "Fork it", modifique-o, use-o, faça o que quiser.
# A idéia é: faça algo diferente.
class Estudante < ActiveRecord::Base
has_one :paixao, :conditions => "project.type = 'web'"
has_many :habilidades, :through => :practice
has_many :cursos_relevantes, :through => :universidade,
:include => :trabalho_em_grupo
has_and_belongs_to_many :projetos, :through => :github,
:foreign_key => "github.com/username"
validates_presence_of :time_agil
validates_presence_of :inovacao
validates_presence_of :oportunidades_de_aprendizado
def self.objetivo
"Aprender & melhorar minhas habilidades num ambiente que me possibilite " \
"aprender novas coisas enquanto eu me divirto e contribuo com projetos que" \
"terão impacto no usuário final"
end
def self.toolkit
{
:forte => %w(Ruby Rails JQuery CSS),
:familiar => %w(C++ Java Erlang Flex Flash SQL),
:quero_aprender => %w(MacRuby JRuby)
}
end
def self.experiencia
past = []
past.push {:empresa => "XYZ", :title => "Ruby Wrangler",
:data => (1.year.ago .. 6.months.ago),
:descricao => "Construí A por causa de B, responsável por X",
:reference => "John Smith <john @smith.com>",
:url => "http://awesome-rails-app.com"}
past.push {:company => "CDF", :title => "Server Admin",
:data => (6.months.ago .. Time.now),
:descricao => "Migrei X para a plataforma de cloud Y",
:reference => "Bob Smith <bob @smith.com>",
:url => "http://more-awesome-rails.com"}
past
end
def self.educacao
{
:universidade => "Waterloo",
:nivel => "2A",
:grau => "Bacharel em Ciência da Computação",
:notas => "Disponíveis sob requisição, dê uma olhada nos meus projetos."
}
end
def self.contact
contacts = []
contacts.push {:email => "name@me.com"}
contacts.push {:twitter => "username"}
contacts.push {:phone => "519-000-0000", :time => "10am - 6pm"}
contacts
end
def method_missing(method, *args, &block)
"Ficaria contente em responder qualquer questão sobre"\
" #{method}(#{args.join(',')})" \
"por favor, entre em contato para futuras discussões." \
end
end
</bob></john>
Depois dessa, o título deste post (principalmente a parte que fala de “modelo”) é irônica 
UPDATE:
Eu não estou incentivando ninguém a mandar este currículo para qualquer companhia, seja grande ou pequena. Eu achei a idéia de ser diferente legal e resolvi postar no blog. O que eu quis salientar aqui é que você deve ser diferente e confiar nos seus insights. Se você acha que garantiria uma entrevista com um currículo assim, vá em frente. Faça.
Motivos e dicas para desenvolvedores terem blogs
Você que é desenvolvedor, não importa a linguagem ou plataforma, tem muitos problemas e dúvidas enquanto trabalha. A solução adotada pela esmagadora maioria é recorrer ao Google que pode te levar à vários lugares onde é possível que você sane sua dúvida ou problema. Muitas vezes (no meu caso, mais de 90%) esses lugares são blogs de desenvolvedores.
Nesse post eu vou falar um pouco sobre a experiência de ter um blog, o porquê de um bom desenvolvedor ter um, qual engine de blog ter e quais funcionalidades seu blog deve possuir.
Os “porquês”
Os principais motivos que me levaram a ter um blog foi compartilhar informações e ter mais “visibilidade” no mercado.
As informações que você consegue em blogs foram de pessoas que tiveram a boa vontade de escrever sobre o assunto esperando pouco ou nada em troca, além de reconhecimento e alguns comentários.Ter um blog ajuda muito se você quiser ter reconhecimento. É nele que você pode mostrar pro mundo o quão você é bom e saber se o mundo lhe acha bom também.
Quem é que gosta de currículos? Aquele pedaço de papel que tem seus dados pessoais, experiências profissionais que você olha e fala “putz, poderia ter muito mais coisa aqui, eu sou muito mais que isso…”. Aí que entram os blogs: você fala do que você entende (bem, na maioria das vezes =), do que você gosta, do que você está trabalhando, no que você está engajado e muito mais que pode ser dito/escrito num blog. Não parece bem mais expressivo e informativo que um mero currículo?
Hoje, muitas empresas buscam profissionais com iniciativa, profissionais que amam o que fazem. Você pode passar horas do seu tempo livre codificando, pesquisando e descobrindo coisas novas, mas pouca gente saberá da sua paixão se você não publicar em isso em algum lugar. Blogs e ferramentas de micro blogging podem ser úteis nisso.
Ter um blog é quase como ter um filho e cada post é quase um parto. Você tem que pesquisar, ir atrás, testar, procurar fontes, ajeitar tudo antes de publicar alguma coisa. É um trabalho grande que só quem tem um reconhece os esforços para se manter um blog.
Os “comos”
Você pode criar um blog no WordPress, no Blogger ou no TypePad há mais plataformas, mas essas são as que eu mais ouço falar), mas eu preferi registrar um domínio (com um nome nada criativo e super megalomaníaco), pagar uma hospedagem e instalar o WordPress. Sinceramente, o WordPress pra mim não tem concorrentes: possui uma comunidade gigantesca, é usado por grandes blogs do mundo, tem um mundo de temas e plugins. Enfim, estou bem satisfeito com o WP.
Há alguns plugins que eu utilizo no WordPress pra facilitar minha vida de desenvolvedor blogueiro:
- Akismet – Excelente filtro de Spam. Provavelmente você não passará por isso no incício, mas depois de uns 2 ou 3 meses os spammers começam a incomodar bastante.
- CodeColorer – Sintax Highlighting do código que você posta. Eu preferi o CodeColorer por fazer a “colorização” no servidor (pra não depender de JavaScript pra faze isso) e os feeds ficarem coloridos também. Além disso, ele não é obstrusivo e bugado como outros que se vê por aí.
- IntenseDebate – Interessante para facilitar os comentários e facilitar sua vida de gerenciador de blog. Outro muito bom também é o Disqus.
Os “o que” e os “quando”
Eu admito que ainda não estou bom nisso. Eu prefiro publicar alguma coisa que eu não tenha visto no Google ou que o que eu vi não me agradou. Acho que é um bom filtro, mas você deixa de falar muita coisa que você está trabalhando (por exemplo, meu blog não tem nenhum post sobre .NET e eu trabalho com a tecnologia há quase um ano) ao troco de um pouquinho de exclusividade
Eu prefiro manter o ritmo de pelo menos um post a cada semana e pretendo aumentar isso, pois eu vejo mais de uma coisa interessante por semana que valham publicação. Só lembrando: blog útil e bom é blog constantemente atualizado. Se for pra não atualiza-lo sempre, é preferível nem ter (ou você quer deixar a prova do seu desleixo pra todo mundo ver? =).
O que fazer depois?
Um blog é somente uma plataforma para demonstração do que você é. Se você for comprometido com seu blog, você buscará bons conteúdos para ele e, de uma forma ou de outra, te levará a ter uma comunidade com a qual você deve se preocupar. Ter um blog me levou, mesmo que indiretamente, a fundar o primeiro CodingDojo (by the way: o coding dojo está em latência… estamos preparando algo grande pra comunidade de devs de Montes Claros. Aguardem!) de Montes Claros e com certeza influenciará outras iniciativas minhas.
Precisa de mais inpiração? Dê uma olhada:
Dica rapida: Usando ActionScript em expressoes de DataBinding para alinhar elementos na tela
Vamos ao ponto:
x="{Application.application.width/2 - meuLabel.width/2}"
y="{Application.application.height/2 - meuLabel.height/2}"
/>
O que o código acima faz é manter um label exatamente no centro da tela. Pra isso, ele coloca o seu X na metade da largura da tela menos a metade da própria largura. O mesmo acontece para o Y.
Ainda dá pra fazer mais combinações como esta:
x="{Application.application.width*0.8 - meuLabel.width/2}"
y="{Application.application.height/2 - meuLabel.height/2}" />
Neste caso, o Label estaria alinhado mais à direita, 80% pra ser mais preciso. Você pode combinar várias expressões de binding dentro de atributos de posicionamento de seus elementos.
Os exemplos acima funcionam bem em qualquer situação, mas há como economizar código:
x="{this.width/2 - meuLabel.width/2}"
y="{this.height/2 - meuLabel.height/2}" />
Nesse caso, eu estou usando container raiz como referencia. Se você deixar esse label dentro da sua aplicação, ele vai ficará posicionado exatamente no centro da mesma. Mas se estiver dentro de um módulo, ele estará no centro do módulo.
O mais bacana de tudo é que ele reposiciona o elemento caso a janela seja redimensionada.
Simples, não?
nota: post mais rápido da história: 5 minutos 
Plugins indispensaveis para desenvolvimento com jQuery
Algumas pessoas já me perguntaram quais são os plugins que eu mais uso quando estou desenvolvendo em JavaScript usando jQuery. Bem, aí vai a lista:
1 – Autocomplete.
Estupidamente fácil e intuitivo de usar, o autocomplete é o primeiro plugin que eu coloco na pasta de Scripts (isso quando eu não posso usar umCDN). É difícil eu me deparar com alguma aplicação que eu não o use. A documentação oficial disponível não é lá das melhores, mas há várias páginas na Web falando sobre o assunto.
2 – Datatables
Na minha humilde opinião, o melhor plugin de tabelas para jQuery. Com ele você pode criar uma tabela dinâmica com paginação, busca e ordenação e usando AJAX em pouquíssimas linhas de código. O único problema é que a convenção de código dele não segue tanto a convenção usada pelo jQuery ou por outros plugins (normalmente nota-se isso quando se precisa fazer algo mais complexo). O mais interessante é que ele está em constante desenvolvimento e apresenta melhoras bem significativas a cada nova versão.
3 – Validator
Do mesmo cara que criou o plugin do autocomplete, o jQuery validator é outro must-have na sua toolbox. Quem já fez validação de formulários em JavaScript na unha, sabe que esse plugin também é um salvador de vidas. Assim como o autocomplete, o validator não tem uma documentação oficial muito boa, mas é bem intuitivo e fácil de usar.
4 – jQueryTools
Mesmo com a nem-tão-verdadeira promessa de conter todas essas ferramentas em míseros 5.76 KB, o jQuery Tools é uma excelente ferramenta que até certo ponto é concorrente do jQueryUI. Com diversos componentes, como tabs, tooltips, exposé e overlay, o trabalho com jQuery se torna muito mais poderoso e divertido com essa ferramenta.
5 – jQuery UI
Por último, mas não mais importante: o jQueryUI. A versão 1.8.2 está bem completa e pra você que não gosta de ficar perdendo tempo desenhando janelinhas modais usando o lightbox, ou de fazer menus razoáveis (seja no estilo accordion ou tabs), o jQueryUI é pra você. Extremamente poderoso e simples de usar (assim como a maioria dos plugins decentes pra jQuery), o jQueryUI facilita muito a vida de pessoas que precisam de uma interface mais poderosa mas sem gastar muito tempo elaborando-a.
6 – FireQuery
Esse não é um plugin para jQuery na verdade, mas um plugin para o Firefox (melhor browser para desenvolvedores IMO) que dá uma mão e tanto na hora de trabalhar com jQuery no Firefox. Um dos principais recursos é o jQuerify, que adiciona o jQuery numa página que não o possui. Extremamente útil quando se sabe usar o console do Firebug. Além disso, ele mostra todos os elementos que possuem um EventListener usando o jQuery. Muito legal.
Mande sugestões de outros plugins indispensáveis para jQuery! See ya!
O que fazer quando seu codigo JavaScript se torna um monstro
Quando eu não conhecia jQuery e seus plugins, JavaScript era um tédio pra mim. É fato que uma biblioteca de alto nível (não só o jQuery, mas o mootools e o prototype, por exemplo) facilitam e deixam o desenvolvimento em JavaScript rápido e divertido, pois você não terá que se preocupar (muito) com detalhes de implementação de browsers.
Mas o que acontece quando, mesmo usando com alguma lib fodástica, seu código começa a ficar grande demais, complexo demais, fragmentado demais ou desorganizado demais? Isso é a minha definição de código monstro. Eis algumas dicas que podem te ajudar se você estiver passando por isso:
1 – Evite o Callback Hell
O jQuery mostra muitos exemplos usando funções anônimas como callback. De certo modo, isso é uma boa prática para situações simples, como o tratamento do evento clique de um botão:
alert('Fui clicado!');
});
Mas nem sempre isso é legal: muitas vezes você quer reaproveitar essa função para outros callbacks, como por exemplo:
$('#meuInput').blur(getClientes);
getClientes = function()
{
$.get('/clientes/get','',
function(data){
//trata os dados recebidos aqui
},'json')
}
Nesse caso, eu estou aproveitando minha função de callback getClientes para dois event listeners. Isso é bem legal, mas quando nosso código começa a crescer, nos esbarramos em outro problema: as funções globais.
2 – Evite funções globais
Isso quer dizer, ao invés disso:
$('#meuInput').blur(getClientes);
getClientes = function()
{
$.get('/clientes/get','',
function(data){
//trata os dados recebidos aqui
},'json');
};
Faça algo assim:
$('#meuInput').blur(Clientes.getClientes);
var Clientes = {
getClientes:function()
{
$.get('/clientes/get','',
function(data){
//trata os dados recebidos aqui
},'json');
}
};
Isto é, coloque suas funções dentro de objetos. Assim você evita funções globais e evita fazer código “estruturado”, passando a usar os recursos da orientação à objetos do JavaScript e deixando o mínimo de globals possível. Essa é a forma mais fácil que eu conheço de se evitar funções globais e organizar melhor seu código, mas há outras formas como o Module Pattern.
3 – O “this” aponta para diferentes lugares em diferentes contextos. Saiba como lidar com isso.
Você não está deixando mais todas as suas funções como globais, está encapsulando tudo dentro de objetos, reaproveitando código e feliz da vida quando percebe que o this não é mais this. Calma que eu explico.
Você já deve ter visto algo assim no jQuery:
$(this).html('fui clicado') ;
});
Isso faz com que, quando um link é clicado, o mesmo fique com o texto “fui clicado”. Deu pra notar que nesse caso, o this aponta para o elemento que disparou o evento. Mas olhe o seguinte exemplo:
{
texto:'Fui clicado',
init:function()
{
//this aponta para o objeto Cliente
$('a').click(this.aClickHandler);
},
aClickHandler:function()
{
//this aponta para o elemento "a" que disparou o evento
$(this).html(Cliente.texto);
}
};
Viu como “this” pode mudar de contexto? No exemplo acima, o problema de não ter o this apontando para o objeto Cliente foi facilmente contornado, mas você poderá precisar acessar o objeto pai de uma forma parecida com a this. Nesse caso, você pode passar um parâmetro para o evento usando o método bind() do jQuery, informando o contexto que ele foi chamado:
{
texto:'Fui clicado',
init:function()
{
//this aponta para o objeto Cliente
$('a').bind('click',{'self':this},this.aClickHandler);
},
aClickHandler:function(event)
{
var self = event.data.self;
//o self aponta para Cliente e o this aponta para
//o elemento "a" que disparou o evento
$(this).html(self.texto);
}
};
4 – Procure pelos patterns corretos.
Quem disse que padrões de projeto criam um vocabulário em comum na equipe não poderia ter dito algo mais pertinente: o uso de padrões faz com que o desenvolvedor foque nas funcionalidades da aplicação sem se preocupar com alguns detalhes de implementação.
O AjaxPatterns contém uma coleção bem legal e bem documentadas de patterns para Ajax e JavaScript em geral. Mas não espere ter problemas pra consultar os patterns: quanto mais se conhece sobre padrões, mais fácil é pensar em soluções de problemas e planejamento em geral.
5 – Deixe apenas um $(document).ready em todo o seu código
Eu diria isso para todos os event listeners que você possa vir a colocar, mas o $(document).ready é o mais crítico na minha opinião. No JavaScript não há sobreposição de eventos: se você colocar dos event listeners para um mesmo evento, os dois serão executados. Isso pode dar problemas, pois você pode deixar o $(docuement).ready em dois arquivos diferentes e você pode desejar que um evento execute antes de outro.
6 – Valide seu JavaScript
Browsers interpretam JavaScript de forma diferente, então é sempre bom ter uma padronização de código para que não tenhamos problemas com sintaxe em diferentes browsers. Uma ferramenta de validação bem legal é o jslint.
– EDIT–
Nem sei onde tava com a cabeça quando esqueci isso:
7 – Escreva testes!
Testes pode ser tido como documentação executável e facilita muito quando você pega um código de outro desenvolvedor que já tenha testes: é fácil de ver os modos de uso do código e você se sentirá seguro ao fazer algo e ver que os testes passam. Além do mais, você não precisa encher seu código de comentário pra explicar como ele funciona (comentar é bom, mas sem exageros);
Entretanto, testar JavaScript pode não ser tão fácil assim. É necessário mais disciplina e paciência do que é necessário para testar seu código backend, mas é algo que se adquire com o tempo.
See ya!
Criando screencasts no Linux
Eu vi algumas pessoas reclamando sobre a dificuldade de criar screencasts usando Linux. É, eu também tive algumas dificuldades. Nenhuma das ferramentas que eu consegui encontrar com minhas buscas não resolviam meu problema:
- Istanbul – Bonitinho, parece leve, grava legal, mas simplesmente dá um erro de IO (não entendi direito qual era o erro ) e não salva.
- xvidcap - Levíssimo, completo, mas tem problema com o PulseAudio e não grava o áudio do microfone. Tentei inicializa-lo com o comando padsp xvidcap, mas também não resolveu: mesmo chiado no som.
- recordMyDesktop - Grava áudio normal, mas as imagens tinham uma qualidade horrível. Parecia que ele atualizava uma parte da tela e esquecia da outra. Resultado: eu gravava um teste no VIM na linha de comando (preta) e quando eu passava pro GMail (verde) a tela ainda continuava preta…
Não sei o por quê, mas nem todos os programas que vem no Linux vêm com as configurações mais comuns já de cara. O problema é que eu não percebi que o recordMyDesktop encaixaria perfeitamente pra mim se ele já viesse com uma opção já marcada desde o início:
Estranho, não? Eu pensava que marcar “Full shots at every frame” resolveria meu problema, mas, inexplicavelmente, o “Encode On the Fly” resolveu. Apesar da tooltip dizer que essa opção consome mais poder de processamento, eu não notei tanto. A qualidade do vídeo ficou impecável e eu estou com os efeitos no máximo
Se após gravado o screencast você desejar edita-lo ou converte-lo, há uma gama de softwares para Linux mesmo que fazem isso. Para conversão eu uso muito o ffmpeg (não conheço nenhum outro melhor e mais completo) e me recomendaram o Avidemux para edição de vídeo. A única coisa que eu sinto falta agora é algo que coloque os caracteres digitados na tela e que destaque o clique do mouse.
See ya!
