thegoodfellas/blogset-br huggingface dataset:
Percebo que o Estagio IV esta acabando.....falta terminar os relatorios...e entregar...e ai acabou a graduacao....nem acredito.... O que resta e aguardar a hora da festa!!!O final esta proximo....e o inicio de uma carreira comecando!!!!Boa semana para todos e em especial para mim...G.A.B.I Como nao parar e pensar olhando esta foto!!??Esta Diva dos Cinemas abriu as portas para a libertacao feminina...Com seu famoso vestido na cena do filme: O pecado mora ao ladode direcao de Billy Wilder, lancado nos EUA em 1955, Genero de Comedia. " Historias me fascinam...eu entro dentro dela...me imagino em um conto de fadas...as vezes com bruxas e monstros me perseguindo e as vezes sonho com alguem em um cavalo branco....Ahhhhh...as historias mexem com nossos sentidos...mexem com nossos sonhos..."Eu conto historias...e a cada fim de um conto ou durante ele eu tenho mais certeza que e isso que eu gosto de fazer...ver os olhinhos brilhando e fixados em mim....e uma sensacao maravilhosa...!!! Eu amo contar historias e quando possivel sempre acompanhada de meu fantoche favorito...o "Zeca"....como eu amo este muleque!!!! Nasceu em 14 de setembro de 1983, na cidade de Londres, era cantora e compositora de soul, jazz e R&B do Reino Unido. Lancou em sua curta carreira meteorica dois albuns : " Frank" e "Back to Black",o segundo que lhe deu seis indicacoes ao Grammy.Hoje dia 23/07, foi encontrada sem vida em sua casa.Sempre sera lembrada por sua marcante voz e pelos escandalos com drogas e alcool.Uma marcante historia na musica!!! Estas latas foram usadas para fazer um conjunto de cozinha, a proxima postagem sera a do conjunto pronto..... Saudades ficarao de ti Pele, que foi meu amigo e companheiro por 11 anos em minha vida, voce so faltava falar, com seu olhar eu sempre te entendia, talvez um dia possamos nos encontrar!!! Voce foi escolher a noite do dia 23/12/2010 para nos deixar, nunca mais os Natais serao os mesmos e as noites de Virada de ano, com voce latindo sem parar....este ano foi tudo um silencio...somente ficamos com as lembrancas e uma dor no peito!!! Te amo Pele!!!! Nos ultimos anos tenho a felicidade de ter trabalhado em equipes que utilizam open source para o desenvolvimento de suas aplicacoes e percebo entre as equipes algumas diferencas em como elas lidam com isso.Acredito que a partir do momento que voce escolhe usar tecnologias abertas, a forma com que sua equipe lida com esse tipo de desenvolvimento pode ser crucial para a produtividade e o bom andamento do projeto.Vou listar alguns comportamentos diferentes que voce pode ter:Acho que Open source e como qualquer outro tipo de software (Rendimento baixo)Voce, ou sua equipe, acha que open source e como qualquer outra forma de desenvolvimento, a unica diferenca e que ela na maioria das vezes e gratuita.Voce acha que ela esta la para te servir, que basta instalar, rodar, e tudo tem que funcionar como as outras tecnologias fechadas que voce esta acostumado.Voce reclama quando encontra falhas na aplicacao, e comeca a usar isso de desculpa para o desempenho da equipe.Pode ate ser que, em projetos maiores e mais consolidados
(ubuntu, mysql, apache), um comportamento como esse nao seja tao prejudicial. Mas pensando em projetos menores, como o proprio Rails ou Ruby Gems, uma postura como essa nao lhe trara um bom aproveitamento.Sou apenas um usuario (Rendimento medio)Voce entende melhor como funciona o desenvolvimento open source, mas se posiciona como mero usuario.Se algo nao atende suas necessidades voce procura por outras solucoes ou espera ate que o problema seja resolvido.Voce acha que e um grande problema quando algo assim acontece, pois sabe que vai impactar o rendimento da equipe.Esse tipo de comportamento e um pouco melhor do que o anterior. Equipes em que trabalhei que agiam assim com o tempo ate acabavam sendo mais criticas para escolher entre as tecnologias (vendo se o projeto ainda e ativo, reputacao, etc) e acabavam contornando problemas, mas ainda eram meros usuarios e de vez em quando travavam por problemas nao tao complexos.Eu contribuo (Rendimento alto)Sua equipe sabe o que e open source e lida com ele com espirito de contribuicaoSe algo nao atende suas necessidades voce:faz um fork do projeto e manda um patch pra equipe que o esta desenvolvendocria um outro projeto open que faca o que voce precisa (se os que existem sao muito diferentes da sua necessidade)entra em contato com com a equipe que o desenvolve e reporta o seu problema (e se possivel os ajuda a soluciona-lo)Fica feliz quando encontra um bug pois ve uma oportunidade de contribuirEssa situacao eu encontrei na equipe que trabalho no momento (Gonow) e foi surpreendente ver o quao mais produtivo e trabalhar assim.Contribuindo para os projetos voce atende suas necessidades de uma forma mais rapida. Voce nao precisa esperar ate que alguem resolva seu problema, o codigo esta la e equipes open source sao extremamente receptivas e gratas por receber patches e novas features (portanto que sigam o foco do projeto e as regras para contribuicao).Contribuir nao e tao dificil quanto parece, voce vai melhorando aos poucos, vai entendendo melhor como cada projeto funciona, aumenta sua capacidade de ler e entender codigo dos outros, ve bons exemplos de codigos, entre outros. So ha ganhos.Voce ate treina seu ingles!Lancar projetos open source tambem e de grande valia. Em um projeto la na Gonow precisavamos de algo que calculasse distancias entre lugares. Existiam gems que calculavam mas todas faziam isso a partir do raio, nenhuma fazia a partir da rota. Desenvolvemos nossa solucao para isso (o go_maps) e o lancamos como open source. Tivemos ganhos logo nos primeiros dias, pois alguns usuarios reclamaram de coisas que ele nao tinha e percebemos que iamos precisar tambem. Tivemos esse feedback antes mesmo de lancar nosso projeto aos clientes.Portanto fica a dica, se voce pretende usar open source, saiba que nao e apenas um software gratuito, ele e um software colaborativo. Incentive sua equipe a contribuir, se possivel dediquem tempo do proprio projeto para isso, uma vez que esses softwares sao parte do projeto.E isso pessoal, nos vemos amanha no Rails Rumble!
O pessoal da comunidade Ruby comecou com a ideia de cada um descrever seu ambiente de trabalho em seu blog e passar a bola para outros desenvolvedores. O Rafael Rosa me colocou na brincadeira e estou aqui postando o meu ambiente. E uma boa pra ver se eu animo a postar no blog de novo, desde o comeco de outubro que eu nao posto.Maquina / Sistema operacionalAtualmente tenho trabalhado em um Mac mini, com sistema operacional Mac OS X (Snow Leopard). Na verdade aonde estou estamos usando estacoes de pareamento, sao 3 Mac minis, cada um com dois teclados, dois mouses e dois monitores, e 5 ou 6 desenvolvedores se revezam para usa-los.Ainda nao estou muito certo se prefiro linux ou mac para trabalhar, sempre usei linux no servico (geralmente ubuntu) e um macbook em casa. Ultimamente estou com mac no servico tambem, a experiencia esta sendo boa apesar de que por algum estranho motivo eu me sinto mais rapido num linux. Talvez eu goste mais do terminal do linux.TerminalComo um desenvolvedor ruby tenho a felicidade de ter um terminal aberto 100 % do meu tempo. Nao conseguiria trabalhar com um sistema operacional sem um bom terminal.Geralmente deixo uma aba aberta para o log do servidor local e outra para uso generico. Quando estou no Linux costumo usar o Vim dentro do terminal como editor de textos, entao uma aba fica reservada pra ele. No mac acabo usando o Mvim, porque no terminal do mac o vim nao fica muito legal.EditorComo ja falei no topico acima, meu editor de textos e o Vim. Ja uso ele ha uns 2 ou 3 anos e nao o troco por nenhum outro. Logico que em algumas linguagens uma IDE e totalmente necessaria, mas como trabalho com Ruby um bom editor de textos (como o Vim) e mais do que suficiente.Nao uso o vim porque me acho mais rapido com ele ou algo do genero. Uso ele por afinidade mesmo. Me sinto muito bem com ele, gosto de aprender comandos novos com frequencia e acho ele uma ideia genial. E, logico, depois de um tempo usando me tornei mais rapido nele do que nos outros.NavegadorPara desenvolver eu sou 100% Firefox, nao consigo usar outro. Para uso pessoal eu ja passei por varios, opera, firefox, chrome e ja faz uns meses que estou testando o Safari, tenho gostado.OutrosBom, e isso, dentre outras coisas uso o Git para versionamento, algumas ferramentas que desenvolvo para uso pessoal para facilitar algumas tarefas, como o Donald para solucionar conflitos no Git. Uma boa ferramenta de integracao continua e essencial em uma equipe tambem. Nao escuto musica enquanto desenvolvo, mas converso bastante.Passo a bola pro Ricardo Bernardelli, Renato Nitta e para o Mauricio de Amorim.Abracos. Esses dias no servico precisamos usar single table inheritance em alguns models do nosso projeto.Por exemplo, eu tenho a classe:E duas outras que herdam dela:Esses models utilizam a mesma tabela no banco de dados (questions) que contem uma coluna "type" que diz se a questao e uma MultipleChoiceQuestion ou e uma SingleChoiceQuestion.O problema e que ao usar
esses models em um formulario aninhado com accepts_nested_attributes, por mais que eu colocasse um hidden_field dizendo qual era o type da question, o Rails nao salvava ele (o campo ficava nulo no banco).Procurando pela internet encontrei uma solucao que achei interessante e resolveu meu problema. Foi uma resposta que o KandadaBoggu deu no forum stackoverflow.O atributo type e protegido por padrao em classes que herdam de ActiveRecord::Base, para solucionar o problema podemos sobrescrever o metodo que define isso na nossa classe question:
Depois de um bom tempo insistindo, e com a ajuda tambem do pessoal da minha equipe que sempre incentivou (exigiu? =P) essa pratica, hoje em dia ja se tornou natural para mim escrever o teste antes da implementacao.Minha ideia ao escrever esse post e lhe dizer alguns motivos de porque eu acho que voce tambem deveria fazer isso.#1 Uma pratica de designJa dizia o pessoal do livro The Rspec Book que BDD nao e uma pratica de testes e sim uma pratica de design. Usamos o BDD para nos guiar sobre o que deve ser criado para satisfazer as necessidades de nosso produto, sem desperdicios. Se voce escreve o teste depois voce nao se beneficia disso.#2 Nao se influenciar pela implementacaoQuando voce escreve o teste voce deve se concentrar no que voce espera de sua aplicacao, sem pensar em como voce vai implementar isso. Se voce pensar na implementacao antes ou, pior, voce implementar antes do teste, voce pode criar um teste influenciado pela implementacao. O que pode fazer com que sua implementacao tenha mais coisa do que o necessario e, ainda, pode fazer com que seu teste saiba demais sobre a implementacao e a engesse.Voce deveria poder trocar a implementacao sem precisar alterar o teste (refatoracao), se seu teste sabe demais sobre a implementacao, talvez voce nao consiga fazer isso e tenha grandes prejuizos (todo mundo tem que ficar alterando os testes a cada mudanca).Escrever o teste antes vai deixar seu codigo mais enxuto e sem desperdicios, focando apenas no necessario.#3 Mais facil se certificar que o teste funcionaQuando voce escreve o teste antes voce faz com que ele falhe e, apos a implementacao, ele deve passar. Isso ja e uma prova de que seu teste esta cobrindo o que voce esta criando. Se voce escreve o teste depois voce nao tem tanta certeza sobre essa cobertura e, se voce nao tem o costume de retroceder a parte implementada pra ver se o teste realmente falha, talvez voce crie testes que nao cubram nada de novo.#4 Nao ter o "dever" de escrever o teste depoisSe voce escreveu antes voce usufruiu de diversos beneficios e no final ja estava com tudo pronto, o teste realmente se mostra parte do desenvolvimento (o que ele e de fato). Se voce nao o fez, no final de tudo voce ainda tem que escrever os testes, o que pode parecer um fardo (tudo esta "pronto" e eu tenho que "perder" tempo com o teste).ConcluindoSe sua equipe escreve testes depois, eu lhe digo que vale muito a pena tentar mudar essa ordem. Diria ate que nao faz sentido escrever o teste depois.Nao e tao dificil assim obter essa pratica, basta um pouco de disciplina e, se precisar de ajuda, dicas sobre como testar determinada coisa, me coloco a disposicao pra conversar. Nao sou nenhum expert de testes, mas gosto bastante de falar sobre o assunto, me adiciona no gtalk, e-mail, twitter ou o que voce preferir que eu tento ajudar com o que eu puder.Ate o proximo post! Ontem a noite lancei mais uma versao da gem
Donald, dessa vez consegui adicionar algumas features novas.Donald e uma gem que eu fiz para tratar conflitos do GIT, quando o conflito ocorre voce executa o comando "donald" e ela abre os arquivos conflitados no seu editor de texto favorito (no inicio ela foi desenvolvida para o vim, mas ai abri espaco para outros editores).Novas features:Abrir arquivos no vim ja procurando por conflitos: agora quando voce estiver usando o vim (mvim e gvim tambem) a gem ja abrira os arquivos fazendo uma busca por "HEAD", que e um texto comum a todos os conflitos. Sendo assim basta apertar "n" para ir para o proximo conflito.Configurar seu editor padrao: agora voce pode configurar o editor de textos que mais usa (se nao for o vim) para que o Donald utilize ele por padrao sem ser necessario passar nenhum parametro adicional. Para isso basta configurar a variavel padrao $EDITOR em seu sistema.Um jeito de fazer isso e adicionar a seguinte linha ao arquivo ~/.bashrcexport EDITOR="mate"Isso e um exemplo para configurar o textmate como o editor padrao. Voce pode ate configurar um editor que a gem nao cobre, como o gedit, por exemplo.Para maiores informacoes visitem o repositorio do projeto.Para atualizar sua gem execute:sudo gem update donaldAbracos.
Trabalhando ha algum tempo em equipes ageis percebo que algumas coisas nao sao muito bem compreendidas por quem decide formar uma equipe assim, em boa parte dos casos.O que mais percebo em conversas, ou ate em algumas equipes que ja trabalhei, e que o desenvolvimento agil muitas vezes e visto pelo gerente como uma ferramenta para motivar a equipe. O pessoal fica feliz porque esta trabalhando com tendencias da moda, cola post it aqui e ali e tudo flui bem, tudo continua como era antes, apenas diminuimos a documentacao.Se voce pensa assim, saiba que pode esta cometendo um grande erro e voce pode levar seu projeto a falencia.Ser agil nao e facil como parece, os principios por tras do manifesto exigem uma equipe muito bem preparada.Nossa maior prioridade e satisfazer o cliente, atraves da entrega adiantada e continua de software de valor.O principal objetivo de ser agil e entregar valor ao cliente, entregar cedo e de forma continua. Para chegar a esse objetivo voce nao vai desenvolver em modulos, fazer toda uma parte do sistema e depois ir pra outra e nao voltar nessa parte tao cedo. Voce vai desenvolver um todo, que funciona, de forma simples, e ficar melhorando todas as partes desse todo incrementalmente e continuamente.Isso exige muito mais maturidade da equipe do que um projeto nao agil. Para fazer essa refatoracao continua (e criacao de novas funcionalidades) nesse sistema em constante mudanca voce vai precisar de, no minimo, uma otima cobertura de testes.Aceitar mudancas de requisitos, mesmo no fim do desenvolvimento. Processos ageis se adequam a mudancas, para que o cliente possa tirar vantagens competitivas.Se entrega de valor ja faz com que voce tenha que adaptar e evoluir um codigo constantemente, imagine mudancas de requisitos no meio do projeto.Aonde eu quero chegarO que eu estou querendo dizer com isso tudo e que desenvolvimento agil na minha opiniao e a maneira mais eficaz de se desenvolver software, se a decisao for minha eu com certeza vou optar por ela. Mas que fique bem claro que essa e uma forma de desenvolvimento dificil, que exige bastante da equipe.Chegaria ate a dizer que nao e viavel criar uma equipe agil apenas com desenvolvedores inexperientes. Digo isso porque geralmente uma equipe iniciante, para atender a demanda flexivel de um projeto agil, acaba criando codigo dificil de lidar e, em pouco tempo, gera um projeto engessado, dificil de expandir.Lembre-se:Processos ageis promovem um ambiente sustentavel. Os patrocinadores, desenvolvedores e usuarios, devem ser capazes de manter indefinidamente, passos constantes.A velocidade de entrega de valor deve ser constante, mesmo apos um tempo de projeto.Se voce gerente, deseja formar uma equipe agil, tome essa decisao de forma consciente, sabendo que ha muito trabalho a fazer, que sera preciso investir na equipe. Que desenvolvimento agil exige muito comprometimento por parte de todos e aponta falhas.Uma vez que voce sabe que desenvolvimento agil nao e mais facil ou mais tranquilo que os demais e mesmo assim deseja adota-lo, querendo obter o real valor dele, seja bem vindo =) Recentemente vi um post do Yehuda Katz sobre como ele usa o
GIT e me empolguei para escrever tambem.Antes de mais nada, gostaria de dar os devidos creditos ao @rogerio_augusto porque foi ele quem me ensinou boa parte dos itens que vou escrever hoje.Pull e PushBom, vou comecar pelo mais basico, enviar e receber commits do repositorio remoto.Geralmente o pessoal acredita que a formula e essa:commito alguma coisafaco pull para ver se tem alguma coisa no remotofaco push para enviar para eleIsso ate que funciona, mas eu prefiro uma outra abordagem que deixa a arvore dos commits mais organizada.O pull nada mais e do que um fetch (baixa objetos e referencias do remoto) mais merge (junta duas ou mais historias).Imagine que voce baixou tudo que estava no remoto e fez um commit. Enquanto voce trabalhava outra pessoa enviou alguma coisa para o remoto que voce nao tem. Se voce fizer um pull, a arvore dos commits ficara assim:Para nao ter que criar um repositorio remoto para o exemplo, eu fiz o merge entre dois repositorios locais, mas o resultado e o mesmo.Com o merge ele mostra que os commits foram feitos em paralelo, mas as vezes essa informacao nao e tao relevante, e vale mais a pena deixar a arvore organizada. Por isso quando eu vou fazer isso, ao inves de eu dar um pull pro remoto, eu faco um rebase. Por exemplo:git fetchgit rebase origin/masterOu, mais facil de usargit pull --rebase origin masterCom o rebase o git faz um stash de seus commits que ainda nao existem no remoto, baixa os branchs do remoto e recoloca seus commits apos o que veio dele. Ficaria assim:Viram? O git passou o seu commit para depois dos commits que vieram do repositorio (apesar deles poderem ter ocorrido antes) e assim manteve a arvore organizada e facil de entender.Tem gente que fala que assim voce perde a real historia dos commits, mas eu discordo. Para casos em que a historia e relevante eu uso o pull normal para deixar registrado o que aconteceu (por exemplo, estou criando uma aplicacao a partir de uma outra open source e a original foi atualizada, ai sim eu faco um pull para mostrar que sao commits de equipes diferentes que andaram em paralelo), mas para os casos de commits dentro da mesma equipe trabalhando numa mesma tarefa, acho que vale mais a arvore se manter legivel.Merge com a opcao squashGeralmente eu uso branchs para separar as historias do projeto que estao sendo criadas, sendo assim, imagine a seguinte situacao:Voce criou um branch a partir do master para fazer sua historia. Nesse seu branch voce fez 23 commits, que foram totalmente uteis para voce se organizar, integrar mais facilmente, etc.Entao voce terminou sua historia e vai fazer o merge para mandar sua nova funcionalidade para o remoto, entao voce faz:git checkout mastergit pull origin master (imaginando que voce nao commitou nada no seu master, senao o mais correto e git pull --rebase)git checkout seu_branchgit rebase mastergit checkout mastergit merge seu_branchgit push origin masterCom isso voce atualizou seu master, integrou as atualizacoes do master com o seu branch, fez o merge do seu
branch no master e ai sim enviou os seus 23 commits.Ate ai voce fez tudo perfeitamente, mas existe uma outra ferramenta que pode te ajudar a se organizar, a opcao --squash do merge.Quando voce faz o merge com --squash (git merge seu_branch --squash) o git leva as atualizacoes pro seu branch mas como se elas nao tivessem sido commitadas. Ai voce faz um unico commit e manda so ele para o master.Para quem esta olhando o master, faz mais sentido ver um commit por funcionalidade, enquanto para quem esta desenvolvendo a funcionalidade os 23 commits sao uteis. Entao agindo assim a gente ajuda todo mundo. Ficaria assim:git checkout mastergit pull origin mastergit checkout seu_branchgit rebase mastergit checkout mastergit merge seu_branch --squashgit add .git commit -am "Minha funcionalidade"git push origin masterOpcao stash do git mergeUma outra ferramenta util e o stash. Imagine que voce vai fazer uma atualizacao pequena no seu projeto e resolveu fazer no branch master mesmo (para aplicacoes que dividem o projeto em dois remotos - producao e desenvolvimento - eu acho isso totalmente normal). So que enquanto voce esta fazendo voce percebe que sera uma atualizacao grande e seria mais interessante fazer isso num branch a parte (ou alguem te chamou para fazer outra coisa e voce nao vai poder continuar aquilo no momento). Entao voce esta com algumas modificacoes sem commitar mas voce nao vai poder commitar no master, porque nao esta concluido, etc.Para isso voce pode usar o stash, voce faria assim:git stash (o git guarda todas as suas modificacoes em um lugar a parte e seu branch atual passa a ficar como se ninguem tivesse mexido - voce pode usar git status para confirmar)git checkout -b seu_branch_novogit stash apply (suas modificacoes voltam a aparecer, pode confirmar com git status)git commit -am "Primeiro commit da minha funcionalidade"git stash clear (apaga tudo o que estava no stash)git checkout masterCom isso voce fez como se tivesse comecado desde o inicio em um branch novo.Voce consegue tambem criar e gerenciar mais de um stash, mas geralmente um so satisfaz minha necessidade.Opcao track do git branchVamos a mais uma situacao. Seu colega comecou uma funcionalidade em um branch a parte e depois de alguns dias pediu para voce ajudar ele nessa tarefa.Voce tem que trabalhar nesse mesmo branch dele, entao voce decide criar o branch dele localmente. Voce faz:git branch branch_delegit checkout branch_dele (voce poderia ter usado git checkout -b branch_dele e fazer tudo de uma vez)git pull origin branch_deleCUIDADO!Quando voce fez o primeiro comando voce criou um novo branch a partir do que voce tem em seu branch atual. E pode ser que voce tem coisas nele que nao deveriam estar no branch do seu colega, pode ser ate conflitante com as tarefas dele e alem disso o merge vai baguncar legal a arvore dele. Se voce fizer um rebase pode ate piorar mais porque voce tera que dar um --force para reescrever a historia dele e ele tera que se atualizar. Bom, enfim, essa situacao pode gerar resultados nao esperados.Para isso o mais indicado seria:git fetchgit branch branch_dele --track