thegoodfellas/blogset-br huggingface dataset:
dependo do sistema. No meu caso e um .so. Apos criado o arquivo, basta roda-lo pra criar o Makefile e depois uma simples chamada ao make cria os arquivos.PS.: O arquivo extconf.rb deve estar no mesmo diretorio em que os arquivos escritos em C.DICA: Veja a documentacao da funcao dir_config do modulo mkmf aqui: http://ruby-doc.org/stdlib/libdoc/mkmf/rdoc/files/mkmf_rb.html#M000549hugo@hugo-laptop:~/Desktop/posts/rb$ ruby extconf.rbcreating Makefilehugo@hugo-laptop:~/Desktop/posts/rb$ makecc -I. -I/usr/lib/ruby/1.8/i486-linux \ -I/usr/lib/ruby/1.8/i486-linux \ -I. -D_FILE_OFFSET_BITS=64 \ -fPIC -fno-strict-aliasing \ -g -g -O2 -fPIC -c matematica.ccc -shared -o matematica.so upcase.o matematica.o \ -L. -L/usr/lib -L. -Wl,-Bsymbolic-functions \ -rdynamic -Wl,-export-dynamic \ -lruby1.8 -lpthread -ldl -lcrypt -lm -lchugo@hugo-laptop:~/Desktop/posts/rb$E possivel testar facilmente se o modulo Matematica esta acessivel atraves de um require 'matematica'.hugo@hugo-laptop:~/Desktop/posts/rb$ irbirb(main):001:0> require 'matematica'=> trueirb(main):002:0> Matematica::fatorial 5=> 120irb(main):003:0> Matematica::raiz_quadrada 2=> 1.4142135623731irb(main):004:0>ReferenciasEu comecei a estudar a Ruby C API atraves do projeto RubyPython, mas pra entender muita coisa eu usei como referencia o livro Programming Ruby, 2nd edition, que tem o capitulo 21 dedicado a API. Tambem usei uma apresentacao de slides com o titulo de Ruby C Extensions, que tem como autor Mark Volkmann. Eu tentei olhar a documentacao no site oficial da linguagem, mas foi dificil de ter acesso e eu recomendo fortemente o livro, tanto pro uso da API quanto pra aprender Ruby e a apresentacao mostra muitos pontos rapidamente e com exemplos.Num futuro proximo escreverei um post sobre como fazer Ruby se comunicar com Python e vice-versa, com interface em ambos lados. Tentarei mostrar um pequeno exemplo, mas talvez nesse meio tempo eu escreva sobre algo diferente ou ate mesmo detalhar mais um pouco uma das duas APIs ou aproveitar o feedback recebido e mostrar algo em que os autores dos comentarios que chegaram a mim queiram ver ou aprender.Ate o proximo post ;-)
My Acceptance in Google Summer of CodeMy proposal has been sent to Python Software Foundation, to work on Pip, and my abstract was:"The goal is to make pip less error-prone, work well in python2.x andpython3.x, make the tests more internet-independent, run platformindependently, add needed features by developers, write moredocumentation and make people love it and see that easy_install's agehas gone."I was very happy because my proposal was accepted and now I can work in a well known opensource project, with different people around the world working with me - this is a great oportunity Google, PSF and Pip guys are giving me and I will enjoy the most!So, I got my job started in May 24 and this post is about my first two weeks.First Two Weeks: Cotinuous Integration ServerMy first two weeks were about setting up a continuous integration server with builds for python2.4, python2.5 and python2.6, both in Ubuntu Server 9.10 and Windows 2008 Server. Ian Bicking gave me access to a server (in cloud) and I used Hudson CI Server to create the buids. Access it here: http://ci.cloudsilverlining.org/view/pipI added some documentation while getting this work done and some other work, related to continuous integration, like some features requests in the Issue Tracker have been done too.The MeetingsMy mentors Carl Meyer, Ian Bicking and Jannis Leidel, decided with me, to have weekly meetings in IRC, on Thursday, 10:00 PM (UTC), in #pip channel at Freenode. I am very lucky, because my mentors are really cool guys, are always helping me and the meetings are informal and I feel free to speak.We had a meeting through Skype (me, Carl and Ian) and I started it a bit nervous, because it had too long I do not talk only in english to people, but they understood my intentions and the meeting was quick and focused.The second meeting was with all of them, but just through IRC and it took a bit longer, but we discussed more stuff and for what I realized, I was doing a good job.The LessonI got a lesson from this all: learn by yourself, don't depend on your college/school, learn english as soon as possible and help the community.I started programming when I was 14. It had a good time learning C and algorithms and getting help through IRC. When I was 16 I started working in a research group, in my school, and I was the youngest guy and I have learned too much there and I knew great people. I learned Python, Agile methods, top technologies and other things with them, and I was still in high school. Now I am in my first college year, 18 years old and I realize that I am lucky, because I thoroughly enjoyed the opportunities I had. And if I've not took english classes when I was younger, I could not have learned what I learnt about computing, software and all around these.In PyConBrasil 2008 I asked an advice to Bruce Eckel, and his advice was basically: "Do something for the community". And I am doing it since that!So,
Depois de ver os esforcos de Robert Lehmann para criar um mecanismo de i18n pro Sphinx, de forma a tornar possivel manter multiplas traducoes da documentacao oficial do Python eu decidi dar uma olhada no site e acabei traduzindo algumas strings.Bem, a primeira coisa que eu notei foi que o meu amigo Hugo Maia Vieira ja havia traduzido alguns arquivos e pareceu ter grandes interesses em traduzir a documentacao.Entrei em contato com o Robert hoje, perguntando sobre o sitema que ele esta criando e sobre quao estavel esta o sistema de traducoes. Ele deixou bem claro que esta totalmente em beta, mas que haveria possibilidades de criar traducoes, e que era pra eu avisa-lo quando eu fosse alterar uma quantidade grande de arquivos, que ele iria tentar nao fazer bagunca no sistema :)A Ideia de um Mini-SprintHa pouco tempo o pessoal da Python Software Foundation comecou a patrocinar sprints, comecando com o Packaging Sprint, em Montreal. Dois caras do projeto distutils, tambem participantes do Google Summer of Code 2010, fizeram um mini-sprint ha poucos dias, e parece que foi bem interessante.Pois bem, eu tive a ideia de fazer um mini-sprint pra traduzir um pouco da documentacao do Python 3, e ver que bicho da.A comunidade brasileira de Python e imensa, e eu creio que essas traducoes serao uteis a todos. Alem disso, se conseguirmos realizar com sucesso o sprint, seremos pioneiros!Alem do mais, e uma forma de ajudar o Robert com ideias de como facilitar a forma que as traducoes sao feitas.Onde e QuandoEstou pensando em organizar o mini-sprint na quarta-feira (14/07/2010), comecando as 19:00 e terminando no maximo 23:00, chat atraves do canal #python-docs-br, na rede Freenode.Os documentos que eu vejo como mais importantes sao (nao nessa ordem):tutorialfaqlibraryhowtowhatsnewinstallusingglossaryreferenceComo ParticiparBasta aparecer no canal #python-docs-br na Freenode antes das 19:00, no dia 14/07/2010 e dizer que quer participar!Crie uma conta no http://pootle.python.org/ e comece a brincar um pouco pra ver como e o sistema, assim no Sprint teremos menos problemas. Depois de ler o livro The Elements of Style eu decidi comecar a blogar em ingles, e agora eu estou com um blog usando Jekyll + Disqus + Amazon S3 + Amazon EC2 em blog.hltbra.net.O primeiro post que eu escrevi foi sobre o livro The Practice of Programming.O novo feed e http://feeds.feedburner.com/hltbra. Acabaram de me pedir "orientacoes", e eu comecei a me lembrar do que eu estudei quando estava comecando a programar.Resolvi colocar nesse post um resumo do meu inicio, e fazer algumas recomendacoes.Eu comecei a me interessar por computadores logo que ganhei o meu primeiro, quando eu tinha 10 anos, e o que eu mais gostava de fazer era ficar no mIRC nos fins-de-semana e madrugada. Ate que um dia, o irmao de um amigo meu resolveu falar pra eu comecar a aprender a programar, e me passou uma apostila de C da UFMG.Primeira apostila: Apostila de C da UFMGEu nem sabia o que era linguagem, e ja fui estudando umas apostilas de logica que eu achava na internet, e logo em seguida comecei a estudar a tal apostila de C da
UFMG que o Vitor Padilha havia me recomendado. Eu tinha uns 12 anos, e nao entendia muita coisa, ai brinquei uma ou duas semanas e desisti. Me senti um merda. Fiquei brincando com mIRC scripting ate que com uns 13 pra 14 eu resolvi voltar a aprender a programar.Eu sempre usei IRC, e na epoca eu usava a BrasNet. Muitas pessoas do #C me ajudaram na epoca, inclusive pessoas de comunidades do Orkut, como o professor Paulo Motta, que me ajudou muito no meu inicio, via MSN/Gtalk.Eu fiquei nessa de aprender por mais de um ano, e nesse meio tempo muita coisa, tudo pelas dicas da galera da BrasNet.A apostila de C da UFMG sempre foi uma lenda, e muitas pessoas a recomendam ate hoje! Depois de estudar muito C, vi que ela e legal para dar uma passada superficial pela linguagem, mas nao e tao legal pra ter como referencia.Eu nao a recomendaria hoje em dia.Primeiro livro: C Completo e TotalO Paulo falava muito sobre esse livro, e eu decidi baixar e comecar a le-lo no computador. O livro e uma biblia, tem umas 800 paginas!Tem muita coisa interessante no livro que nao esta totalmente ligado a linguagem C - no inicio eu me lembro de explicacoes sobre stack, heap e etc, que achei muito legal, pois eu nao havia lido isso em lugar nenhum. Acho que foi fundamental eu ter gasto meses nesse livro, e com certeza aprendi muito com ele.Um ponto fraco do livro e que tem muitos exemplos de coisas que so funcionam com bibliotecas da Borland no sistema, e algumas pessimas praticas.E um livro razoavel pra ter como referencia.O melhor: The C Programming Language, 2nd editionO livro e muito foda. E o melhor material sobre C (c89/k&r) que eu ja li ate hoje. O livro e bem pequeno, mas e fantastico. Os autores sao: Dennis Ritchie e Brian Kernighan, duas lendas, e ambos autores do UNIX.E uma otima leitura, recomendo a todos que querem aprender C, le-lo. Ele e conhecido como K&R2.Ha poucos dias o Zed Shaw fez umas criticas a esse livro no twitter, falando sobre algumas ma praticas usadas em exemplos do livro.Eu concordo com o Shaw em alguns pontos, mas os exemplos sao muito sucintos e adequados, e isso facilita muito pra quem esta aprendendo.E claro que ha muita coisa de C que so e possivel aprender lendo codigo e conversando com pessoas. Por isso eu recomendo frequentar o canal ##c na Freenode, pra quem esta aprendendo C. Ja obtive muita ajuda la tambem (depois que eu parei de usar a BrasNet).Muitas Man PagesEssa semana eu estava conversando no almoco com alguns amigos da Globo.com sobre documentacao de linguagens, e eu falei sobre o meu inicio, em que eu tinha um Slackware numa maquina virtual,e usava internet discada, e logo, tudo o que eu tinha pra estudar C eram as man pages.Sao documentacoes EXCELENTES. Segundo o Everton Carpes, o motivo disso e a maturidade, ja que a GLIBC tem uns 30 anos.Recomendo muito que todos aprendam a fazer consultas pelas man pages, antes de
ir ao Google.Antes que eu me esqueca: leiam a man page do scanf, ele e muito mais poderoso do que os livros mostram.Lendo codigo dos outrosComo eu nao poderia deixar de falar, ler codigo dos outros e uma das melhores maneiras de aprender uma linguagem nova.Um que me marcou foi o codigo do MINIX. Eu, obviamente nao entendia nada de sistema operacionais, mas eu queria ver como programadores C de verdade escreviam codigo, e la aprendi alguns padroes que eram usados na epoca, alguns truques com pre-processador e etc.Na epoca o host de projetos opensource mais famoso era o SourceForge, e de la eu ja baixei muito codigo pra ler, e me lembro de um ircbot que o Isaque Dutra estava escrevendo em C, eu comecei a hackear pra aprender como funcionava a comunicacao pela rede, e era tao newbie que nem sabia usar o CVS (que era o SCM usado no SourceForge naquela epoca).ConclusaoAcho que e fundamental que todo programador aprenda alguma linguagem que seja de mais baixo nivel, como experiencia de vida mesmo, porque e necessario aprender a escovar bits e se virar com os poucos recursos existentes.Apesar de ter estudado muito C, nunca escrevi nenhuma biblioteca/framework interessante em C,mas sinto que criei uma base bem solida pra evoluir desde entao.
fazer uma retrospectiva no fim. Sempre que chega no tempo combinado da duracao do dojo, e feito uma retrospectiva. A maneira mais basica de fazer a retrospectiva e dividir o quadro (ou flip chart) em duas colunas: O Que Foi Bom, O Que Foi Ruim. Algumas pessoas gostam de colocar uma divisao entre as duas colunas pra pegar informacoes sobre o que pode ser melhorado.Um exemplo de uma imagem de retrospectiva de um dojo com duas colunas pode ser visto na seguinte imagem:O problema e que na retrospectiva que acontece nos dojos ficam muitas palavras ao vento. Na maioria das vezes nao da pra criar um plano de acoes para melhorar o processo. A retrospectiva acaba ficando mais como licao e compartilhamento de visoes, sem ter, de fato, acoes de melhorias. O ponto e que a maioria das retrospectivas feitas nos dojos sao, a meu ver, mal aproveitadas.Como Olhar Para O PassadoHa algumas maneiras de recolher informacoes do passado. O objetivo nesse momento da retrospectiva e entender o que aconteceu, e os membros da equipe precisam compartilhar suas historias individuais e integra-las com as dos outros membros. Algumas maneiras de alcancar tal objetivo sao:Linha de tempo colorida: E criada uma linha de tempo no quadro ou em algum lugar onde possa ser colado post-its e escrever os acontecimentos na linha de tempo. Post-its coloridos com frases descritivas sao usados para indicar os sentimentos da equipe em determinado lugar na linha de tempo. Normalmente e usada a cor verde para o que foi proveitoso, rosa ou vermelho para o que foi estressante e amarelo para o que for neutro. Talvez seja necessario colocar uma legenda para as cores ao lado da linha de tempo pra que ninguem se perca.Galeria de arte (art gallery): O facilitador pede a equipe que cada um desenhe uma imagem do que o projeto se parece pra eles, depois cola as imagens em algum lugar visivel a todos. Assim que todos terminarem o facilitador pede que cada explique o seu desenho. Pode parecer estranho, mas as pessoas sao muito boas em encontrar metaforas pro que e dificil de ser explicado com palavras. Um relato interessante citado no livro Agile Coaching foi de uma retrospectiva em que um membro desenhou um boneco de palitinhos dentro de uma caixa, e quando foi explicar pra equipe o desenho ele disse que era assim que ele se sentia no projeto - ele trabalhou muito isolado dos outros, e era como se ele nao fizesse mais parte do projeto.Ha uma variacao de art gallery que o Patrick Kua desenvolveu que e muito interessante, o nome e Mr. Squiggle.Funciona da seguinte maneira: o facilitador desenha alguns tracos em papeis (podem ser usados post-its) e entrega um papel pra cada membro da equipe, contendo os mesmos tracos criados pelo facilitador. De a equipe 5 minutos pra desenharem nos papeis o que o projeto representa pra eles, usando os rabiscos que o facilitador colocou no papel. Depois peca que cada um explique seu desenho para a equipe.O interessante do Mr. Squiggle e que cada um faz um
desenho totalmente diferente, mesmo iniciando com os mesmos tracos.Bad Smells"If it stinks, change it" Avo do Kent Beck, discutindo sobre como criar os filhos Assim como com codigo, e possivel ver Bad Smells em retrospectivas - aqueles indicios de que ha algo errado.Ideias da ultima iteracao sao ignoradas E pedido a equipe novas ideias sem discutir o que aconteceu na ultima iteracao. Isso nao funciona, pois os problemas sao evitados.Palavras ao vento Varios itens estao nas colunas "O que foi bom" e "O que nao foi bom", mas nenhuma acao e tomada em relacao aos dados recolhidos. No fim das contas a retrospectiva serviu apenas como uma conversa e licao de vida.Mudar o mundo Algumas equipes criam listas com coisas a serem melhoradas sem considerar a viabilidade de fazer aquelas acoes na proxima iteracao. Isso traz desapontamento a equipe, porque nao conseguiram fazer o que planejaram, e a cada retrospectiva sao adicionadas mais acoes.Acoes sem "Donos" Acoes que foram criadas e nao possuem donos, algo como "Melhorar a comunicacao" e "Fazer mais refactoring", nao deveriam ser acoes, pois sao problemas que devem ser trabalhados. Se nao houver discussao, a equipe nao vai saber como implementar tais "pseudoacoes".Falta de tempo para melhorar A equipe leva cinco minutos depois de uma apresentacao de uma release ou demo pra conversar brevemente sobre os acontecimentos e chama isso de retrospectiva. Esse e um sinal de que a equipe nao ve beneficios em retrospectivas.Peneirando InformacoesDepois que foram recolhidas informacoes suficientes da equipe e necessario gerar insights. Caso haja alguma informacao que ainda nao foi compreendida, a equipe deve esclarece-la - nao deve ser pedido diretamente para a pessoa que escreveu a nota explicar, deve ser pedido a equipe. Caso haja frases genericas como "Ambiente de testes quebrado" ou "Cliente muito ocupado", deve ser pedido exemplos pra tornar mais facil de ilustrar o problema pra todos.Depois de andar sobre a timeline procurando por insights e a hora de escolher os topicos mais importantes pra focar. Uma das tecnicas e votacao por pontos (dot voting). Cada membro da equipe tem tres pontos que pode colocar em qualquer topico que ache que e mais prioritario - inclusive pode usar os tres pontos em um topico so. Os topicos com maior pontuacao farao parte do planejamento de acoes (action planning).Apos extrair os topicos que a equipe quer focar, procura-se por melhorias no processo que a equipe possa fazer na proxima iteracao.Olhando pro FuturoA segunda metade da retrospectiva deve olhar pra proxima iteracao, que e quando a equipe vai trabalhar o gostaria de mudar no processo. Sera necessario mais que concordar que mudancas sao necessarias, a equipe deve trabalhar nas acoes levantadas pra implantar as mudancas.Antes de comecar a criar acoes novas, um tempo deve ser dedicado para revisar o que aconteceu com as acoes da ultima retrospectiva. Se nao foram terminadas a equipe precisa entender o motivo antes de adicionar criar mais acoes. Na maioria dos casos e porque as acoes nao tinham dono ou porque a equipe "nao teve tempo".Um tempo deve ser investido na retrospectiva pra trabalhar num plano
de acoes realista, que seja claro pra todos da equipe. Para que as acoes fiquem prontas a equipe precisa termina-las. O facilitador combina com a equipe quanto tempo sera gasto com as melhorias no processo na proxima interacao, lembrando que as acoes serao feitas enquanto a equipe continua trabalhando no plano do release, ou seja, enquanto continuam a desenvolver software.Como Criar O Plano de AcoesAssim como no desenvolvimento de software, a equipe deve dar passos de bebe (baby steps) na hora de criar as acoes pra serem implementadas na proxima iteracao. Nem sempre as acoes sao problemas que podem ser corrigidos - as vezes sao estudos sobre algum problema, estabilizar um estilo de codigo, etc.Bas Vodde tem um texto excelente de como criar planos de acao, que as autoras do livro Agile Coaching resumiram no livro.Para ter acoes que funcionam, a equipe precisa, alem de identificar o que precisa ser alterado, dizer como serao implementadas as mudancas. O processo de recolher as acoes que Bas Vodde usa e o seguinte: cada acao tem um objetivo a longo prazo e uma acao para ser feita agora. Por exemplo:Objetivo a longo prazo: Ter testes de aceitacao automatizadosAcao para agora: Fulano vai automatizar o teste ABC usando XYZ.No exemplo citado por Bas Vodde a equipe consiste de oito membros. Inicialmente cada membro gera um conjunto de acoes - separadamente - cada uma com um objetivo a longo prazo e uma acao para ser feita; a equipe tem 10 minutos pra gerar as acoes.Apos geradas as acoes, a equipe se divide em duplas. Durante 10 minutos cada dupla agrupa suas acoes e seleciona as 5 mais prioritarias.Depois que as duplas selecionarem 5 acoes, sao gerados grupos de 4 pessoas. Cada grupo agrupa suas acoes e seleciona apenas 4 de todas as 10 acoes selecionadas (2 duplas selecionaram 5 acoes cada) - durante o limite de 10 minutos.Para finalizar, a equipe inteira reune-se e de todas as 8 acoes selecionadas (2 grupos de 4 pessoas e cada grupo selecionou 4 acoes), seleciona as 3 mais importantes pra serem implementadas na proxima iteracao.A vantagem dessa tecnica e que ela reune tanto esforco individual quanto em grupo, alem de ter que haver um consenso entre todos os membros da equipe sobre quais sao as prioridades. Devagar e com passos de bebe. Independente do numero de acoes geradas inicialmente, no fim, apenas tres acoes sao selecionadas. Selecionar acoes demais e um erro, que ja foi descrito anteriormente como bad smell (Mudar o Mundo).Depois da retrospectiva as acoes precisam ser planejadas na proxima iteracao. A equipe combina como serao priorizadas as acoes e post-its com as acoes podem ser grudados no quadro, para que nao sejam esquecidos durante a proxima iteracao.Um Formato Pra ComecarHa varios formatos de retrospectivas, alguns mais complicados que outros. Acima foi descrito um formato, mas nao e recomendavel que seja usado da primeira vez. Antes da retrospectiva comecar e necessario arrumar uma sala pra fazer a retrospectiva e material como canetas, papel e post-its - um quadro seria muito bom.Um exemplo de como dividir a retrospectiva, citado
desenhos funciona.ChecklistNo livro Agile Coaching ha no fim de cada capitulo uma checklist que mostra os pontos principais pra executar com sucesso o que foi descrito no capitulo. No capitulo sobre retrospectivas a checklist se resume a:Comece a retrospectiva olhando pro passado para entender o que aconteceu o o porque. De tempo suficiente a equipe para contar a historia inteiraGaste a segunda metade da retrospectiva olhando pro futuro e decidindo o que ira no plano de acoesProcure por bad smells que estao atrapalhando a equipe a ser mais efetiva. Se as retrospectivas nao estao melhorando o processo, pense em como voce poderia melhora-lasAche os problemas que a equipe mais quer consertar. Use a votacao por pontos para focar no que a equipe gastara suas energiasNao adicione mais acoes durante a iteracao antes da proxima retrospectiva. Ate mesmo duas ou tres acoes terminadas a cada iteracao podem causar um impacto significante por varios mesesSe as acoes da ultima retrospectiva nao foram finalizadas, procure saber os motivos antes de adicionar maisReferenciasO livro Agile Coaching e excelente, a maior parte do conteudo do post e baseado no capitulo 13 dele. Ha um livro so sobre retrospectivas, Agile Retrospectives. Tem um livro que eu nunca li, o Project Retrospectives, mas ja fiz umas pesquisas no site deles, que por sinal tem um material muito bom.Updates:Adicionada foto dos desenhos feitos pelos aspiras na retrospeciva (Mr. Squiggle)
a Ruby API e depois sobre a integracao das duas, pra tentar chegar em como o RubyPython funciona.Ate o proximo post ;-)Updates:24/02/2010 - O Magno Lima me alertou que eu tinha escrito fibonnaci mas tinha implementado um fatorial. Corrigido!