Herberth Amaral » Misc

Brincando com monkey patching

Herberth Amaral — Sat, 10 Jul 2010 15:52:58 +0000

Segundo a Wikipedia, monkey patch é uma técnica utilizada para modificar atributos, funções e métodos em tempo de execução, ou seja, sem precisar mexer na implementação.

Somente algumas linguagens dinâmicas suportam monkey patching, como Ruby, JavaScript, Smalltalk e Perl. Há linguagens dinâmicas que não tem suporte, como é o caso do PHP (apesar de ter algumas formas de obter um resultado parecido).

Eis um exemplo simples de patching com Python:

def sayHiToMe(me):
print 'Hi, '+me

sayHiToMe('Herberth') # Hi, Herberth

def sayHello(me):
print 'Hello, '+me

sayHiToMe = sayHello

sayHiToMe('Herberth') # Hello, Herberth

Isto é possível porque o Python trata suas funções e métodos como objetos. Tanto é que você pode chamar uma função/método utilizando o método __call__:

def sayHiToMe(me):
print 'Hi, '+me

sayHiToMe.__call__('Herberth') #Hi, Herberth

Uma coisa mais interessante é modificar métodos de classe em tempo de execução e a modificação ficar valendo para todos os objetos:

class Teste:
def meuTeste(self):
print 'Testando...'

def meuOutroTeste(self):
print 'Testando denovo...'

primeiroTeste = Teste()
primeiroTeste.meuTeste() #Testando...

Teste.meuTeste = meuOutroTeste
primeiroTeste.meuTeste() #Testando denovo...

Este é um dos motivos pelos quais você tem que passar a referência do objeto para cada método da classe

Monkey patching pode ser muito útil quando necessitamos de um mock/stub para testar uma determinada classe/método: você pode criar o método que vai substituir o médoto em questão sem precisar perder a referência do método original. Exemplo:

class Email:
def sendMail(self,from,to,subject,message):
print 'Enviando email...'
self.mailSent = True

def Cliente:
def cadastro(self,nome,telefone,email):
# salva o cliente no banco de dados e no fim envia um email
self.mail = Email()
self.mail.send('admin@loja.com','cliente@teste.com','blah','blah blah!')

# não queremos que o método da classe Email apresentada acima envie um email
# a cada de cadastro do cliente. Por isso, vamos fazer um patch para o método sendMail.

def sendFakeMail(self,from,to,subject,message):
self.mailSent = True

originalMail = Email.sendMail #salva a referencia original de sendMail
Email.sendMail = sendFakeMail
c = Cliente()
c.cadastro('Herberth','999-9999','meu@email.com')
assert c.mail.mailSent #verifica se o email foi enviado
Email.sendMail = originalMail # restaura o sendMail original

Legal, não?

Sem posts relacionados.

O melhor modelo de curriculo para desenvolvedor que eu ja vi

Herberth Amaral — Fri, 21 May 2010 12:12:56 +0000

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:

# E ae galera..
#
# 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 ",
: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 ",
: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.

Sem posts relacionados.

Motivos e dicas para desenvolvedores terem blogs

Herberth Amaral — Wed, 19 May 2010 15:16:15 +0000

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:

- 11 motivos para se ter um blog de uma vez por todas

- 28 tipos de posts para abastecer seu blog infinitamente

Sem posts relacionados.

Dicas simples para melhorar o carregamento do WordPress e obter um melhor rank no Google

Herberth Amaral — Mon, 03 May 2010 10:49:21 +0000

Blogs são famosos por demorarem carregar. Tem alguns que passam de alguns megabytes na página inicial. Felizmente, o Google percebeu que um dos fatores de satisfação do usuário é o baixo tempo de carregamento de uma página e resolveu adotar o tempo de carregamento fator de rankeamento.

Nest post eu dou algumas dicas de como melhorar a performance do WordPress, tanto no servidor quanto no cliente. Com alguns outros plugins e alguma observação básica, é possível diminuir o número de requisições, compactar documentos de texto (html, css e js) e conseqüentemente diminuir o tempo de carregamento.

Dica #1: Instale o YSlow e saiba onde seu blog peca na performance.

O YSlow é um plugin do Firefox que mostra alguns pontos em que seu blog (ou site) pode ser otimizado.

Pra blogs, é normal ter o “Make fewer HTTP requests” no vermelho. O uso indiscriminado de plugins é a causa disso. Um exemplo: há vários plugins que usam jQuery, mas se há o risco de você estar incluindo o jQuery duas vezes na sua página. São duas requisições a mais de ~24KB, na melhor das hipóteses.

Dica #2 – Desabilite plugins desnecessários ou substitua-os

Alguns plugins podem ser bacanas e tal, mas pense se eles são realmente necessários. E se forem, se tem o seu conteúdo otimizado. O AddToAny, por exemplo, é um plugin legal para compartilhamento do seu conteúdo em N redes sociais, mas ele tem todos os ícones das redes em arquivos separados (até a versão 0.9.9.5.1. Na versão mais nova consertaram isso). Isso quer dizer várias requisições à mais no seu blog.

Há plugins também que inserem outros arquivos JavaScript que estão fora do seu controle. Por exemplo, o IntenseDebate é triste com isso (não tenho muitas informações com relação ao Disqus): além de algumas requisições pro domínio deles (em que o conteúdo não é servido) o plugin inclui um script de terceiros (Quantserve) sem sua autorização. Eu ainda não mexi no código dele, mas acredito ser possível servir tais scripts de forma estática.

Dica #3 – Instale o AutoOptimize

O AutoOptimize é um plugin muito fácil de usar e que ajuda a diminuir drasticamente o número de requisições fazendo com que seu CSS e JavaScript seja concatenado e servido em uma única requisição. Uma coisa interessante que eu notei é que alguns plugins colocam JS indiscrinadamente no topo da página e o AutoOptimize corrige (mesmo que parcialmente) estes problemas colocando-os no final.

Dica #4 – Tempo de carregamento também tem a ver com seu servidor também – Use o WP Super Cache.

O carregamento da interface consome a maior parte do tempo de carregamento de uma página, mas o WordPress é uma engine pra blogs bem grande e isso quer dizer que ele pode ser lento se mal configurado.

O WP Super Cache ajuda na performance fazendo que o WordPress não precise renderizar todo o conteúdo toda vez que um usuário acessa a página. Além disso, ele comprime seu conteúdo com gzip, fazendo com que o tamanho do conteúdo de tezto seja diminuído em cerca de 70% e com isso o tempo de carregamento da página diminui.

Apesar do WP-Supercache fazer um excelente trabalho, ele não faz todo. Há algumas configurações, como as ETags que podem ser feitas para melhorar o desempenho do seu blog e algumas outras configurações como servir conteúdo estático sem cookies (lembrem-se: cookies aumentam o tamanho do header HTTP fazendo com que talvez seja necessário mais de um pacote IP para enviar a requisição e assim diminuindo o desempenho). Essas e outras configurações dependem do seu serviço de hospedagem e pode ser complicado fazer com que eles mudem alguma coisa no servidor que hospeda o seu blog.

Dica #5 – Tente colocar o máximo de conteúdo externo dentro do seu domínio.

Esta dica visa principalmente diminuir o número de consultas DNS que seu browser faz.

Isso só não serve para arquivos que são estáticos e são largamente utilizados, como o jQuery: pra este caso, uma fonte externa (CDN – Content Delivery Network) é recomendada.

Referências:
O Google quer seu site seja rápido: Saiba como otimizar o carregamento das suas páginas
Caching tutorial

Sem posts relacionados.

Boas Festas!

Herberth Amaral — Fri, 25 Dec 2009 09:53:45 +0000

Galera, aí vai meu voto de boas festas:

lol

Brincadeiras a parte, espero que todos nós tenhamos um 2010 melhor que o 2009. Boas festas

Sem posts relacionados.

Foco e produtividade – A tecnica do Pomodoro.

Herberth Amaral — Tue, 22 Dec 2009 01:07:15 +0000

O que?! Vai dizer que você caiu nessa denovo?

Quem nunca passou por uma situação parecida com essa aí de cima que jogue a primeira pedra!

1 – O problema

Esse tipo de situação acontece com muitos profissionais todos os dias. E, no meu ver, o principal problema é a liberdade. Digo, não a liberdade em si, mas o seu mau aproveitamento. Muitos de nós, profissionais de TI, não somos questionados sobre o que estamos acessando e que horas estamos acessando, desde que entreguemos tudo no prazo. Daí você já viu: hora extra, noites sem dormir e finais de semana em casa para cumprir com aquele prazo…

Várias metodologias foram criadas para sanar o problema da procrastinação. Uma delas é o famoso Getting Things Done (GTD) ou no seu título em português: A arte de fazer acontecer. O GTD tem seus pontos fortes e fracos. Dos pontos fortes, o principal é que ele fornece um “framework” para organização de vários níveis de tempo: desde de como vai ser cada hora do seu dia até planos para daqui dez anos. O ponto fraco é quase o mesmo que dá o ponto forte, pois, por ser um “framework”, ele é genérico. A maioria das coisas que eu li nele são simplesmente frutos do bom senso comum.

2 – A Técnica do Pomodoro

A técnica do pomodoro é um pouco diferente. Ela é simplesmente prática, vai direto ao ponto e é bem simples: você trabalha 25 minutos, pausa 5, trabalha mais 25 e pausa mais 5 e assim por diante. Cada 25 minutos corresponde a um Pomodoro. Depois de 4 pomodoros, você pode fazer uma pausa maior (25 minutos).

Cada Pomodoro é indivisível, ou seja, você não olha seu Twitter, email, chat ou responde à sua mãe quando ela pede uma sugestão pro almoço durante estes 25 minutos. Totalmente focado no trabalho. A mágica da técnica do Pomodoro é que você sabe que você terá seus 5 minutinhos de descanso pra olhar seu Twitter, seu email, zuar o colega do lado e talvez até beber uma água (e esse tempo geralmente dá pra fazer isso tudo! Experiência própria.)

Essa explanação foi bem básica. Você pode conferir mais detalhes no livro disponível gratuitamente em PDF.

3 – Um pouco de história

A técnica foi criada por um sujeito italiano chamado Francesco Cirillo. O Francesco estava passando por maus bocados com os estudos pois ele não conseguia se concentrar nos estudos. Foi aí que ele olhou pra cima de sua geladeira, viu um Pomodoro (aqueles timers em forma de tomate que são usados na cozinha) e pensou consigo mesmo: “Será se eu consigo me concentrar só nisso durante 10 minutos?”. Dito e feito. O sujeito pegou o timer, ajustou pra 10 minutos e desceu a lenha no livro. Wow! E ele conseguiu se concentrar por 10 minutos.

Vai um tomatinho aí?

O episódio descrito acima aconteceu em meados da década de 1980. De lá pra cá, ele vem experimentando diferentes timeboxes (diferentes tempos para o Pomodoro), também vem ministrando palestras e organizando workshops e chegou na conclusão que 25 minutos é o tempo que funciona bem para maioria das pessoas. Mas isso é somente um conselho, você pode colocar um timebox mais curto ou mais longo, dependendo da sua necessidade.

4 – Mãos à massa! Já!

Com o GTD você tem N desculpas para procrastinar. Com o Pomodoro não. São apenas 25 minutos, o que é que lhe custa? Teste por uma ou duas horas e veja qual foi o resultado.

Há pessoas que tem dificuldade (ou preguiça) de fazer a lista de tarefas e ainda sim utilizam a técnica do Pomodoro. Elas conseguem sucesso porque conseguem eliminar a ansiedade. Elas sabem que terão os 5 minutinhos pra fazer o que está em segundo plano e sabem que isso irá faze-las render no trabalho.

5 – Minha experiência

No início é cansativo. Os 25 minutos não parecem passar nunca e os 5 minutos são simplesmente muito curtos. Dá vontade de desistir. “Po, isso não é humano”, pensei eu. Mas depois de dois dias de trabalho utilizando a técnica eu já consegui me acostumar.

Hoje eu tenho 4 meses de Pomodoro. Cinco minutos é tempo suficiente pra fazer muita coisa. De fato, 5 minutos hoje parecem mais suficiente para muita coisa. Eu tenho um nível de produtividade que eu invejável pelo Herberth de 4 ou 5 meses atrás, não sofro mais da ansiedade do email não lido ou do tweet não respondido, não tenho medo de ignorar o Google Talk (tem uma parte do livro que fala como lidar com interrupções, é bem interessante) e meu serviço rende bem mais.

O mais legal de tudo é quando as pessoas começam a sincronizar pomodoros. Além de divertido, essa forma de fazer as coisas ajuda para que você não desista.

6 – Timers para o Pomodoro

Bem, eu imagino que a maioria das pessoas que estão lendo esse post não tem um timer de cozinha. Então, há alguns programinhas legais para ajudar você a praticar a técnica do Pomodoro. Segue a lista de alguns deles:

(Essa lista pode aumentar. Comente esse post se você achar um que não está listado aqui).

Galera, acho que é isso. Bom Pomodoro pra vocês também!

P.S: Esse post foi escrito com 2 pomodoros e duas interrupções. Nesse meio tempo eu tive 14 tweets não lidos (thank you, ChromedBird), 4 emails a mais na minha caixa de entrada, duas conversas não respondidas no Google Talk e minha mãe realmente pediu uma sugestão para a janta

Sem posts relacionados.

Ano novo, coisas novas pra aprender.

Herberth Amaral — Sat, 19 Dec 2009 11:43:19 +0000

Esse ano foi o melhor da minha vida em questões profissionais e de conhecimento. Desses 6 anos que eu me interesso por TI, esse foi o que eu mais aprendi e o que mais me agregou experiência. Vou começar com uma retrospectiva antes de passar para o planejamento:

1 – Retrospectiva

A Infobits, juntamente com seu Grupo de Web, me deu experiência mais gerencial, mesmo coordenando poucas pessoas. Eu era e ainda sou um cara muito técnico e participar de um projeto como esse, em que eu tinha que coordenar e orientar pessoas, me ajudou a ver o outro lado da moeda. Sair do nível técnico para o gerencial é complicado. Ainda bem que eu tenho uma equipe pequena agora: menos gente, menos preocupação, mais comunicação, mais ágil.

Ter sido demitido foi uma das experiências mais marcantes que tive. Mexeu com meu ego (que por sinal não é pequeno) e eu me focei a ver o que eu tinha feito de tão errado pra ter merecido isso, já que boa parte da justificativa do meu ex-chefe não fazia sentido pra mim. A retrospectiva de um ano de empresa foi uma coisa tão foderosa, que eu atribuo mais de 80% do meu conhecimento adquirido neste ano às coisas que eu aprendi nesse processo. Até brinquei com um amigo esses dias, dizendo que se eu soubesse o quanto isso te faz evoluir, eu procuraria ser demitido mais vezes. Por exemplo, eu não teria tido o interesse ou a iniciativa de ter ajudado a iniciar o nosso Coding Dojo se não tivesse sido demitido.

Vendo pelo lado acadêmico, esse ano também foi o mais produtivo: eu apresentei e publiquei 6 trabalhos e pretendo seguir o ritmo no ano que vem, mas mais voltado pra minha linha de pesquisa (Recuperação de Informação).

Quase ia me esquecendo do Coding Dojo: apesar de termos somente duas reuniões até agora, eu tou colocando muita fé nele.

2 – Para o próximo ano

Enfim, foi um ano cheio e eu estou prevendo que o próximo ano não será muito diferente, pois será o ano que eu irei me graduar. Daí vocês já tiram: monografia “comendo solta” o ano inteiro

Seguindo o conselho dos Pragmatic Programmers de aprender ao menos uma linguagem por ano, eu vou escolher as minhas aqui agora:

Lua é uma linguagem de programação brasileira que tem atraído muita gente no exterior, mas é pouco conhecida/valorizada aqui no Brasil. Pelo que eu pude ver, Lua é uma linguagem de altíssimo nível, bonita, elegante e que pode me ensinar alguma coisa valiosa. Outro motivo por escolher Lua é minha vontade de aprender mais sobre programação funcional. Isso me passa para a próxima linguagem:

Pra mim, Scala começou a ganhar atenção quando o Twitter começou a substituir Ruby por Scala no seu backend. Mas não é somente por isso que eu escolhi Scala em detrimento de Haskell, Erlang, Scheme ou Lisp. Eu realmente queria aprender todas elas, mas acho que Scala pode ser um bom começo. O objetivo é aprender programação funcional, certo?

Esse ano eu comecei a aprender Ruby para apresentar um trabalho. A linguagem é legal, mas eu ainda estou longe de ser um cara competente em Ruby. Por isso, Ruby vai ser uma das linguagens que irei aprender no próximo ano. Ruby é bastante usada em alguns Coding Dojos do mundo todo e por isso vai ser legal usar Ruby no DojoMoc.

3 – Além de programação

Eu ainda pretendo continuar com meus estudos sobre desenvolvimento ágil, voltado principalmente para técnicas de desenvolvimento (pair programming e TDD, principalmente), automatização de tarefas de produção de software, produtividade e arquitetura de software.

No meio acadêmico, eu pretendo procurar aplicar tudo isso aí em cima no processo de desenvolvimento do produto que será minha monografia (fazer um crawler de pequena/média escala não é tarefa fácil…). Pretendo também continuar publicando pra ver se em 2011 eu já entre em algum programa de mestrado, mesmo como aluno especial.

Ultimamente eu tenho pensado muito em desenvolvimento OpenSource. Ontem mesmo eu fiz um hack para a lib de autocomplete do jQuery para substituir a YUI numa página que eu estou mexendo no trabalho e pretendo tirar as gambiarras melhora-lo para disponibilizar pra galera. É coisa pequena, mas é um começo

Agora é esperar 2011 chegar e ver se eu consigo cumprir pelo menos a metade disso aí

4 – Livros

Ganhei alguns livros no meu aniversário e tenho outros encostados. São eles:

O Silmarillion – J.R.R Tolkien
O Caçador de Andróides – Philip Dick
As Crônicas de Nárnia – C.S Lewis
Eragon – Christopher Paolini

Há alguns outros que eu não tenho que eu quero ler:

Blue Ocean Strategy, uma sugestão do Fábio Akita.
The art of Unit Testing – Osherove Roy
Clean Code: A Handbook of Agile Software Craftsmanship – Uncle Bob.
The Art of Agile Development – James Shore
Agile Estimating and Planning – Mike Cohn

Esses são os maiores títulos. Não sei se consigo dar conta de ler todos eles com uma monografia a fazer, mas não custa tentar

Até mais!

Sem posts relacionados.

“A gente nao quer so codigo… a gente quer codigo, controle de versao e bug track”

Herberth Amaral — Thu, 10 Dec 2009 09:18:42 +0000

Tá certo. A paródia da música dos Titãs não ficou boa. Mas acho que já deu pra sacar do que este post trata.

Enfrentar as matérias de programação na faculdade para quem já trabalha com desenvolvimento deve ser um saco para muita gente. Os professores geralmente não trabalham na área, não sacam nada além da linguagem e ainda tem coragem de nos fazer de trouxa, explicando como é a sintaxe da linguagem, como fazer algumas coisas básicas (leia-se CRUD) e acham que está tudo ok. Não está. Óbvio que não. Então, eu tenho algumas coisas a dizer para tais professores (e para os alunos também).

1 – Ensinar algumas coisas sobre a sintaxe e mostrar um CRUD não é o suficiente.

Precisamos mais além disso para desenvolver um trabalho final decente. Nós, alunos, precisamos aprender a nos virar, mas precisamos saber com o que devemos nos virar. Coisas básicas como indentação de código deveria ser cobrada. Separation of Concerns deveria ser incentivado e cobrado desde o início, por exemplo.

Não serei injusto. Algumas coisas como “comente seu código para documenta-lo” nos é ensinada. Isso é importante para quem está começando, pois saber se orientar dentro do próprio código é uma boa. Mas é algo insuficiente. Eles não ensinam como código pode ser autodocumentado, como bons nomes de variáveis podem ajudar nisso, como codificar “de cima para baixo” e outras coisas relacionadas a codificação.

2 – Nos passar trabalhos em grupo não necessariamente nos ensina a trabalhar como uma equipe.

Há vários trabalhos finais para fazermos e a forma mais fácil de fazer isso é deixar um para cada um. Dá pra eliminar vários problemas de comunicação e sincronização de código assim. Acho que já deu pra perceber que não aprendemos muito sobre ferramentas para desenvolvimento em equipe…

Quem for tentar desenvolver em equipe, provavelmente o fará enviando código por email, trocando pen-drives ou enviando via compartilhamento de arquivos, se tiver na mesma rede (impressionante, mas já vi “profissionais” trabalhando assim) e notarão o trabalho que isso dá. Obviamente, dá pra notar que não tivemos uma aula sobre controles de versão…

3 – O trabalho não acaba com a entrega…

Quem trabalha com desenvolvimento de software há um tempo sabe do que eu estou falando. De acordo com esse paper, mais de 90% dos custos de um software estão na sua manutenção. Vendo por esse lado, não estamos fazendo nem 10% do trabalho que deveríamos fazer.

Várias práticas de programação importantes são feitas durante a manutenção. Uma delas é a adição/mudança de recursos. Se fizéssemos isso, perceberíamos que coisas como refatoração e testes unitários são importantes.

4 – Metodologias são sempre bem vindas

Uma das dúvidas de quem começa a desenvolver é: como devo proceder, qual metodologia adotar. Um professor tem que ser um guia para um aluno escolher um método de trabalho. Praxis? XP? Scrum? PDCA? Sair fazendo na doida não é das melhores escolhas

Na matéria de Engenharia de Software, nós temos uma visão teórica de cada uma dessas metodologias. Uma matéria de programação com um projeto pra entregar poderia ser um cenário perfeito para coloca-las em prática.

5 – Conclusão

Matérias como essa são muito desperdiçadas na nossa universidade. E eu imagino que seja em outras também. Se você é professor, comece a pensar nisso e pense em como você pode ajudar a mudar o quadro aqui exposto. Se você é aluno, cobre isso do seu professor. Ou pelo menos tenha a boa vontade de estudar sozinho

Sem posts relacionados.