thegoodfellas/blogset-br huggingface dataset:
Quantas vezes estamos bem, felizes, sorrindo e do nada cometemos um erro, um grave. O que sentimos? Frustracao com certeza. Culpa muita das vezes, porque achamos que somos os culpados e queremos que o tempo volte e tente reparar nosso erro. Que tristeza e errar. Mas estou aqui para que saiba que errar tambem pode ser bom, pode ser pro nosso bem.Hoje, eu cometi um erro, reprovei em uma materia da faculdade, e foi um conjunto de falhas, a minha primeira avaliacao fiquei com nota media, a segunda, eu fui banida do grupo por problemas entre os integrantes e na terceira avaliacao que era pra suprir a segunda (que nao fiz), tirei nota baixa.Me sinto bastante triste, ja que esse blog e um blog pessoal tambem quero desabafar aqui, porque muita das vezes tento fazer parte de grupos de "amigos", que considerava muito mas que nao souberam me ajudar quando precisei, ao inves disso me humilharam. E eu, burra digamos assim, nao soube resolver, nao quis fazer o trabalho que era pra semana seguinte.Bom, resumindo, estou triste mas sei que Deus e maior. E depois desse sentimento de culpa e tristeza, veio sentimento de pena, primeiro pena pelas pessoas que possuem dificuldades em determinadas areas e nao conseguem aprender como eu. Pena tambem pelas pessoas que hoje passam pelo que eu passo, de achar que o erro so faz mal... Ele faz mal mas ele nos ensina licoes que levaremos pra vida.Uma delas e sempre fazer o melhor de si, e se nao conseguir passar na disciplina, por exemplo, nao se culpe, se voce nao conseguiu agradar alguem, se voce frustrou alguem, nao se culpe nao. Voce fez o melhor. Aprendo bastante com esses erros, sinto-me triste, culpada, mas feliz ao mesmo tempo por aprender.Nao se sinto mal, errar e humano. Muitas pessoas nao sabem lidar com seus erros, acham que estao sempre certos, e ficam forcando a barra dizendo que estao certos e pronto. Mas voce precisa assumir seus erros. Voce errou pronto, siga em frente e nao erre mais. Eu assumo que errei, pois nao me dei por completo, achei que seria facil passar, mas nao foi.Aprenda com suas falhas. Viva cada dia sabendo que Deus nos fez limitados para vermos que Ele e ilimitado. Deus fara o que voce nao conseguiu fazer.Deus te abencoe meu querido! Na tarde do dia 30/04/2010, ocorreu o 1o NSI Tech Talks, um evento mensal sobre tecnologia organizado pelo Nucleo de Pesquisa em Sistemas de Informacao (NSI) do Instituto Federal Fluminense (IFF).O evento foi pensado inicialmente como uma especie de workshop interno (nossa equipe tem cerca de 30 pessoas distribuidas em diversos projetos), mas acabamos por decidir fazer um evento aberto. No nucleo temos desde pesquisadores doutores ate alunos de curso tecnico, todos abrangendo um leque bastante amplo de habilidades e conhecimentos.A primeira edicao foi organizada em pouco mais de uma semana e, por consequencia, nao foi tao divulgada como deveria, mas mesmo assim houve publico em um bom numero. Na apresentacao "OpenOffice: Dominando a Fera com Python", Gabriel Monnerat mostrou em detalhes como
o Python e usado para realizar a automacao do OpenOffice.org, com o projeto OOOD, criado pelo proprio em uma parceria do NSI com a empresa francesa NEXEDI, utilizado principalmente para conversao de documentos e como resolver questoes de escalabilidade, concorrencia e como contornar instabilidades do OpenOffice.Na segunda apresentacao do dia, "Collaborative Coding: Git+Github", Hugo Lopes Tavares explicou como funcionam os sistemas de controle de versao, mostrando as diferencas entre VCS centralizados e distribuidos e expos o funcionamento do Git, um dos mais modernos e eficientes DVCS disponiveis, e mostrou como o Github pode tornar simples e eficiente o compartilhamento de codigo e o desenvolvimento colaborativo de software livre.Para as proximas edicoes ja estao agendadas palestras com temas como manipulacao de video com gstreamer e Python, lean thinking aplicado ao desenvolvimento de software, clean code e qualidade de codigo, heuristicas para extracao de frames significativos em videos, analise de licencas para software livre, o framework web Grok, tecnicas para criacao de DSLs em Python e integracao continua.Pretendiamos disponibilizar os videos das apresentacoes, mas muito infelizmente tivemos um problema com o som dos videos e ate agora nao conseguimos resolver. Caso haja alguma novidade em relacao aos videos, posto aqui. Tambem infelizmente, confiamos demais nos videos e - adivinhe! - nao tiramos fotos.Enfim, o 1o NSI Tech Talks, a meu ver - mas sou suspeito para falar, claro! - foi, exceto em termos de registro, um sucesso e so tende a melhorar. E um evento muito interessante, de palestras com um nivel tecnico bem mais alto do que se costuma encontrar, e uma otima fonte para quem se interessar em questoes atuais sobre desenvolvimento de software.O evento possui um site (sim, nos temos que melhora-lo), onde serao divulgadas as novas edicoes.A segunda edicao ja esta marcada para a proxima segunda-feira, 31/05/2010, as 15 horas, no auditorio Reginaldo Rangel, no Instituto Federal Fluminense (antigo Cefet) em Campos/RJ.
.padawan {color: blue}.jedi {color: green}Sempre que leciono Programacao Orientada a Objetos, quando estou falando de encapsulamento, eu mostro uma pequena historia para desmistificar a lenga-lenga de que "encapsulamento e ter atributos privados". Fiz, para publicar no blog, uma versao em forma de dialogo. Tentei minimizar o tom professoral, mas o texto nao nega a origem. Segue.- Ai cara, a galera criou um fork de orientacao a objetos, e uma das coisas que ficou como exercicio foi criar um programa orientado a objetos que calcule o fatorial de um numero, mas sem utilizar estruturas de repeticao. Essa e facil, implementei rapidinho! Ve ai se ficou legal:- Este programa calcula certinho o fatorial, mas nao faz o que foi pedido, porque isso ai e tudo menos orientado a objetos.- Mas como nao? Eu utilizo uma classe e um metodo! Logo, estou programando orientado a objetos, nao?- Nada disso! O fato de utilizar abstracoes e terminologia de OO como classes e metodos nao torna automaticamente um programa orientado a objetos. E muito comum ver programas completamente procedurais escritos em linguagens orientadas a objetos. Logo de cara, pense comigo: ha sentido em um objeto fatorial no contexto deste programa? Voce criou um metodo chamado fatorial e uma classe Fatorial. Nao tem uma coisa errada ai? Afinal, fatorial e uma classe ou um metodo?- Bom, que fatorial e um metodo esta claro. Agora eu ja nao estou mais tao seguro em relacao a ser uma classe.- Entao, se fatorial e um metodo, e so pensar qual e o objeto que tem a responsabilidade de oferecer esse metodo. Objetos pilha tem metodos push e pop, que inserem e retiram um elemento de si mesma. Objetos conta bancaria oferecem saques e depositos em si proprios. Pensando assim, qual objeto deve oferecer o calculo do fatorial?- Ahhhhh!!! O numero e que deve oferecer um fatorial! E tao obvio! Entao fica assim:- Mas isso continua do mesmo jeito. Como voce disse, procedural. Foi so uma mudanca estetica, certo?- Mais ou menos. Nomes sao importantes e nos ajudam a pensar mais claramente a respeito dos problemas. Pensa ai, como e que a gente pode melhorar mais isso ai? Se eu chamar um new Numero(), o que este meu objeto vai representar? Qual e o seu significado? Nao ta faltando nada ai nao?- Ah, claro! Qual e o numero do meu Numero... Um atributo!- Certo! Manda ver entao!- Realmente, esta ficando cada vez mais com cara de codigo OO. Mas ainda esta estranho, pois eu posso fazer algo assim:Numero numero = new Numero(3);numero.fatorial(5);- Nao faz o menor sentido eu pedir a 3 para calcular o fatorial de 5.- E o que isto significa?- Ja estou entendendo: o raio do metodo ainda e procedural, e ele e que esta baguncando a historia toda...- Esse metodo e procedural. Se ele fosse escrito em C, seria exatamente igual (tirando o public, claro!). Na programacao procedural, rotinas processam dados. E exatamente isto que o nosso metodo fatorial faz. Na OO, a comunicacao se da por troca de mensagens, nao por fluxos de dados. Ou seja: quando voce
pede a 3 para calcular um fatorial, deve ser o fatorial de quem?- De 3, claro.- Entao...- Rala peito, parametro!- Agora ferrou! Como fazer a parada funcionar?- Voce ainda esta pensando de modo procedural. Ali dentro do metodo, voce quer o fatorial de quem?- De valor - 1.- Entao por que voce esta pedindo o fatorial de valor novamente? Lembre-se que ali voce esta chamando fatorial sobre o proprio objeto, this. Se voce quer o fatorial de valor - 1, nao deveria chamar o fatorial sobre o objeto que representa valor - 1?- Perai, agora pegou aqui! Deixa eu pensar... Ta, tudo bem, eu entendi a sua ideia, mas nao sei como implementar.- Como e que voce obtem um objeto Numero que seja valor - 1?- Fazendo new Numero(valor - 1).- Entao esta pronto!- Ahhh claro!!! La vai!- Depois que voce ve pronto e muito, muito simples!! Agora sim!- A gente pode parar por aqui se voce quiser.- Como assim se eu quiser. Tem mais?- Imagine que eu estou usando seu codigo em uma aplicacao, e comeco a criar codigos como:long resultado = numero.fatorial();- Ai um belo dia eu faco o seguinte codigo:Numero numero = new Numero(50);long resultado = numero.fatorial();- E o resultado que obtenho e obviamente errado: -3258495067890909184. Estourou o tamanho do tipo long.- Poderia usar double?- Ate poderia, mas ja comeca a virar gambiarra, concorda? Fatorial, matematicamente, e uma funcao aplicada sobre um numero natural, que retorna um numero natural. Meter numeros reais na historia nao vai cheirar nada bem. De qualquer modo, a gente pode pensar com razoavel grau de seguranca que ninguem vai querer um fatorial de 50, e depois, se alguem pedir, a gente troca. Um dos preceitos da OO e o encapsulamento, sob o qual mudancas na implementacao interna de uma classe nao alteram o mundo exterior a ela. Como acreditamos que nosso programa esta orientado a objetos direitinho... Acreditamos, certo?- Sim, eu acho que agora esta ok, o atributo privado, so o metodo publico la fazendo so o que deve fazer... Eu acho que esta ok.- Podemos liberar esta classe para producao entao?- Manda ver!!- Agora imagine que voce escreveu este codigo e todos os 200 desenvolvedores da empresa estao utilizando esta classe em 30 aplicacoes.- Que responsa!- Pois e! Ai chega uma demanda dos usuarios de algumas das aplicacoes por fatoriais de numeros na casa dos 200.- A gente pode usar, sei la, BigInteger para representar o numero.- Voce esta confiando no encapsulamento da classe pra fazer isso? Tenta la.- Legal, so que isto vai quebrar TODAS as milhares de chamadas ao metodo fatorial (estamos imaginando aqui que fatorial e uma funcionalidade muito popular, ok?). Tudo bem, aqueles que querem fatoriais gigantescos nem vao reclamar tanto, mas e os que nao tem nada a ver com isso? E ainda sao obrigados a importar mais uma classe! E imagine que coisa fede ainda mais se criarmos um metodo getValor(). A solucao seria criar um metodo Frankenstein, tipo bigFatorial e manter o fatorial normal? Manter duas classes diferentes? E cade o desgracado fidumaegua do encapsulamento que
nao te salvou? Era tudo mentira isso de "mudancas na implementacao nao alteram o mundo externo"?- E aquele papo, de uma "mudancinha a toa" pro cliente ser um pesadelo de manutencao pros desenvolvedores.- Isso! E muitas vezes (como no nosso caso atual) isto e fruto de mau design.- E como resolver isso? Eu nao tenho ideia.- Na verdade ha um problema conceitual na nossa classe. Ou, dizendo de outro modo, nao esta suficientemente OO.- Como assim?- Primeiro, ha um vazamento no encapsulamento: o tipo de retorno de fatorial. Ele espelha exatamente a implementacao interna, o modo como a classe Numero armazena o atributo valor. Se houver futuramente uma alternativa a BigInteger e quisermos elimina-lo, estaremos escolhendo novamente entre quebrar os clientes ou fazer gambiarras de duplicar metodos. Ter simplesmente "atributos privados" nao e o bastante. Linguagens como Python nao tem suporte a membros privados e nao deixam de ter encapsulamento por isto. Encapsulamento e um conceito, nao uma palavra-chave como muita coisa que se le por ai faz supor.- Certo.- Este vazamento de encapsulamento e causado pelo problema conceitual de que falei. Quando criamos uma classe, a unica representacao daquele conceito no nosso modelo passa a ser a classe. Nos criamos uma classe para numeros, mas representamos numeros de duas formas: objetos Numero e objetos BigInteger. Deveriamos usar apenas uma. Pense: o que um fatorial retorna?- Um numero.- E o que e um numero no mosso modelo?- Entendi!! Um objeto Numero!(comeca a escrever o codigo)- Mas se eu quiser realmente encapsular por completo o tipo utilizado eu vou ter que...- Reescrever todos os operadores? Sim, nao tem outro jeito neste caso.- E entao?- A classe Numero agora e um numero de pleno direito dentro do software. Agora qualquer coisa que ela faz retorna outro objeto Numero. Tudo esta realmente encapsulado.- Mas continua um problema, aquilo que voce falou sobre ter duas representacoes. Internamente so vamos ter uma, mas o cliente da classe vai continuar vendo duas: o nosso objeto Numero e os numeros (int, long, etc) que a linguagem Java oferece. Alem disso, ter que reescrever todos os operadores da um trabalhao. Ali eu so reescrevi os que foram necessarios, em um caso real todos os outros teriam que ser reescritos tambem.- Bom, ai chegamos aos limites da linguagem Java em termos de orientacao a objetos. Se voce quiser, podemos parar por aqui.- Como assim "se voce quiser"? Eu nao acredito que ainda tem mais!?- Bom, podemos falar, por exemplo, de Ruby e colocar a orientacao a objetos em um nivel bem mais alto, tanto de simplicidade quanto de praticidade e poder. Partiu?(mas isso fica pra outro dia, ainda que, provavelmente, nao em outro dialogo...)
tambem e provavel que muitos nao vejam assim tanto problema no que expus. Coding dojos sao dinamicos e nao hierarquicos por definicao, portanto evoluem e se alteram com o tempo e com o contato de diferentes pessoas. Assim, o "desvio" de TDD pode ate nao ser um problema em si, afinal o coding dojo e um jogo, mas temos que perceber que estamos praticando sob o nome de TDD uma coisa que nao e exatamente TDD. E, na verdade, estamos praticando e aprendendo, uma vez que o coding dojo, pelo menos aqui no RJ, tem sido visto como ferramenta de aprendizado de programacao. Quando o desenvolvedor esta consciente que nos dojos e praticada uma variacao do TDD, tudo bem. Porem, no caso de um iniciante, nos temos, sim, um problema, pois as pessoas vao aprender como TDD algo que poderia ate mesmo ser considerado um antipattern.Talvez pelos problemas utilizados em dojos serem bastante simples, muitas vezes com apenas uma feature, a unica forma de ter mais de um metodo de teste acaba sendo a fatoracao das classes de teste por expectativas e nao por features. Na verdade, nao sei nem se isto e um problema para todo mundo. Pessoalmente, e algo que nao gosto e que me incomoda, me soa como se o codigo estivesse pulando e gritando "ei, eu estou errado, voce nao esta vendo?". Mas e o meu ponto de vista. E ai, qual e o seu?
exclusivamente de Python, que ocorre periodicamente em diversos lugares. Neste vou ministrar um minicurso chamado "Coisas que ate Guido duvida: Metaprogramacao em Python". Para quem ficou boiando, "Guido" se refere a Guido Van Rossum, criador da linguagem Python. O nome, claro, e uma piada: nao ha nada que eu va dizer que surpreenderia o sujeito que criou a linguagem, mas eu gostei do trocadilho e, afinal, marketing e tudo... :-P O PythOnCampus tera minicursos de manha e a tarde e palestras a noite, confira a programacao. Se as tarefas da organizacao permitirem, pretendo assistir ao minicurso de MongoEngine e participar do coding dojo a tarde. Mas duvido que consiga...Para completar, esta semana ainda tem Bienal do Livro aqui em Campos, mas sobre isto, se eu escrever algo, e assunto para meu outro blog.
La vou eu participar do meme de descrever o ambiente de trabalho em 7 itens:Sistema OperacionalSou um felicissimo usuario do Ubuntu 10.10, sistema operacional que sera trocado em breve, mais precisamente em abril deste ano, pelo Ubuntu 11.04.EditorEclipse Helios para Java. GEdit - devidamente tunado por gedit-plugins, gmate e Batraquio - para todo o resto. Por "todo o resto" entenda-se mais de 95% do meu tempo atual, com Ruby, Python, JavaScript, HTML, HAML, CSS, LaTeX, RST, markdown, plain text e o que mais vier. Este texto, por sinal, esta sendo escrito no GEdit. Hoje mesmo foi levantada uma discussao acerca de debugging na lista de discussao do (glorioso) NSI. Bom, nao ha maneira mais, digamos, tecnica de dizer isto, mas a verdade e que debugging simplesmente nao me faz falta na imensa maioria das situacoes. Na minoria, coisas como o pdb do Python atendem muito bem. TDD e passos de bebe tambem sao de grande ajuda para nao se necessitar de IDEs superpoderosas.TerminalO terminal e onde passo boa parte do tempo, entao ele precisa de duas coisas, ser eficiente e bonito. A eficiencia do terminal e item de serie (Linux rulz!) e a beleza e garantida por um fundo semitransparente, um esquema de cores esperto e a belissima fonte Monaco (a unica coisa que eu tinha inveja do Mac!).Alem disto, uso algumas conveniencias no prompt, como: mostrar informacoes do Git caso o diretorio corrente seja um repositorio; mostrar a versao e a gemset do RVM sendo utilizadas correntemente, caso exista alguma; e o Python virtual do virtualenvwrapper sendo utilizado, tambem caso exista.BrowserFirefox, Chrome, Opera para validar layouts, Seamonkey para a maioria do lixo que "so funciona no IE", Firefox (com Firebug e Web Developer) para todo o resto. Atualmente, eu nao preciso validar layouts no IE, portanto nao tenho configuracao para isto.SoftwareTweetDeck, Exaile, K3B, Gimp, Skype, Google Talk, VLC. Por sinal, procuro um bom cliente Twitter que nao use Adobe Air, que nao exija o Chrome e que nao seja o Echofon. Sugestoes?Codigo-fonteGit, obvio. E Subversion para projetos que ainda o utilizam.MusicaUso o Exaile como player, sempre com fone de ouvido, e - se eu nao estiver sozinho - com um dos fones um pouco fora do ouvido para sacar o ambiente e ouvir as conversas. Normalmente escuto musica brasileira (rock, indie, regional), metal (grindcore, death metal, crossover, hardcore) e coisas estranhas em geral (experimental, math metal, misturebas e por ai vai). Nao ouco musica, porem, o tempo inteiro. Ouvir ou nao e, quando ouco, o tipo de musica, dependem do tipo de trabalho, do meu grau de concentracao no momento e do ambiente.E voce, fala um pouco do seu ambiente ai! No dia 12/11/2010, realizou-se um PythOnCampus no IFF, em Campos dos Goytacazes/RJ. O evento, organizado por nos do Nucleo de Pesquisa em Sistemas de Informacao (NSI) do Instituto Federal Fluminense (IFF), foi muito legal!Apesar de ser uma sexta-feira vespera de feriadao, o evento contou com um bom publico (e boa parte dele ficou la ate depois das 22 horas) e com minicursos bem legais e palestras de altissimo nivel. Pela
Como qualquer um que tenha estado aqui pelos ultimos dois anos deve ter percebido, este blog esteve praticamente abandonado durante este periodo. A mim mesmo, a desculpa era sempre a mesma: eu estava esperando "o momento certo" para voltar a escrever no blog. Assim como na musica de Humberto Gessinger, "esperei chegar a hora certa por acreditar que ela viria". E, por certo, ela nao vem. Se formos esperar o momento no qual tudo estara calmo e tranquilo, ceu azul de brigadeiro, para colocarmos nossos projetos em pratica, nunca faremos coisa alguma. Assim, aqui estou eu reabrindo a casa. Por outro lado, se o presente escrito e so o manifesto de meia duzia de posts e outros dois anos de silencio, ninguem sabe. De qualquer modo, tudo vale a pena, ja dizia outro poeta. Vamos? Outro dia, em uma thread na lista de discussao do nucleo de pesquisa onde trabalho (a.k.a. glorioso NSI), debatiamos a respeito de uma palestra apresentada na Agile Conference 2009, chamada "Let's stop calling it 'agile'", em cujo resumo constava:Agile development has grown a lot since its rebeleous 2001 start. In fact, it has grown to be the mainstream way of developing software. The time has come to drop the word 'agile.' Agile development is just modern practices in software development. There is no need to explicitly mark practices as Agile. There is no need anymore for opposing camps. Keeping the word Agile and things like ""the Agile conference"" is holding the development of modern SW development practices back.Ou, em portugues:O desenvolvimento agil cresceu bastante desde seu inicio em 2001. De la pra ca, se tornou o modo "mainstream" de desenvolver software. E chegada a hora de abandonar a palavra "agil". Desenvolvimento agil e tao-somente o uso de tecnicas modernas no desenvolvimento de software. Nao ha necessidade de nomear explicitamente estas praticas como ageis. Nao ha mais necessidade para campos opostos. Manter a palavra "agil" e coisas como "a Conferencia Agil" e atrasar a evolucao das praticas modernas de desenvolvimento de software.Eu nao fui primeiro no NSI a repercutir a conversa: o Rogerio Atem ja falou sobre o assunto em seu blog. Com este post, quero apenas apresentar a discussao e oferecer meus dois centavos ao assunto. De cara, concordo plenamente com a ideia de que o termo "agil" tem feito mais mal do que bem hoje em dia. Principalmente por ser relativamente facil passar um verniz agil em um projeto ("olha, estamos fazendo Scrum, temos daily meetings, post-its no vidro da janela, e agora o analista de sistemas se chama scrum master, tem ate certificado"). Uma vez que esta na moda ser "agil", o modelo se prolifera como erva daninha. Mas isto e assunto para outro post.A discussao, inicialmente, era sobre o agilismo e a preponderancia, na academia, de um estranho ente teorico-pratico chamado "modelo tradicional". Minha opiniao e de que a camada pensante do mundo tradicional e cada vez mais um grupo deslocado em um mundo que ja nao mais compreende. Imagino como estariam fora de lugar em qualquer bom evento de desenvolvimento de software envolvendo