thegoodfellas/blogset-br huggingface dataset:
nas costas, (pois voce esta no Brasil, na Russia a mochila colocaria voce nas costas) nao esqueca sua toalha, polegar em riste e vamos pegar carona nessa nova aventura...Miniaturas, RPG, Super-Herois, Historias em Quadrinhos, Herois Japoneses, Filmes, Moda, Decoracao, WebDesign, Programacao, Hardware, Animes, Series, Jogos e Tecnologia. Tudo bem juntinho no seu quarto, o 4oGeek!O quarto ja tem ate promocao!Sorteio: Livro O HOBBITAutor: J.R.R. TOLKIENNumero de paginas: 295Preludio de O Senhor dos Aneis, O Hobbit conquistou sucesso imediato quando foi publicado em 1937. Vendeu milhoes de copias em todo o mundo e estabeleceu-se como um classico moderno. E um dos livros mais influentes de nossa geracao e agora voce pode levar esse super sucesso direto pra sua prateleira.A entrega sera feita diretamente no endereco do ganhador.Promocao valida para todo o territorio nacional.O Ganhador sera divulgado la no Blog no dia 10/04/2011Participe da Promocao!!!
de diversas familias de classes.Builder: Separa a construcao do objeto de sua representacao.Factory Method: Cria uma instancia de diversas classes derivadas.Object Pool: Evita aquisicao e liberacao custosa de recursos atraves da reciclagem de objetos que nao estao mais em uso.Prototype: Uma instancia completamente inicializada que e copiada ou clonada.Singleton: Uma classe onde somente uma instancia pode existir.Regras importantes:As vezes, padroes de criacao sao concorrentes: ha casos em que Prototype ou Abstract Factory podem ser usados de forma benefica. Em outros momentos, sao complementares: Abstract Factory pode armazenar um conjunto de Prototypes onde os objetos sao clonados e retornados; o Builder pode usar um dos outros padroes para implementar os componentes que sao construidos. Abstract Factory, Builder e Prototype podem usar Singleton na sua implementacao.Abstract Factory, Builder e Prototype definem um objeto de fabrica que e responsavel por conhecer e criar a classe de objetos de produto e o torna um parametro do sistema. Abstract Factory tem o objeto de fabrica produzindo objetos de diversas classes. Builder tem o objeto de fabrica que constroi um produto complexo incrementalmente, usando um protocolo complexo correspondente. Prototype tem o objeto de fabrica (aka prototype) que constroi um produto atraves da copia de um objeto de prototipo.As classes da Abstract Factory sao implementadas por Factory Methods, mas tambem podem ser implementadas usando Prototype.Abstract Factory pode ser utilizada como uma alternativa a Facade para esconder classes especificas da plataforma.Builder foca na construcao passo a passo de um objeto complexo. Abstract Factory enfatiza a familia de objetos de produto (simples ou complexos). Enquanto no Builder o produto e retornado como uma etapa final, no Abstract Factory o produto e retornado imediatamente.Builder esta para criacao assim como Strategy esta para algoritmo.Builder sempre constroem um Composite.Factory Methods sao normalmente chamados dentro de Template methods.Factory Method: criacao atraves de heranca. Prototype: criacao atraves de delegacao.O design frequentemente comeca usando Factory Method (menos complicado, mais customizavel, subclasses proliferam) e evolui para Abstract Factory, Prototype ou Builder (mais flexiveis, porem mais complexos) conforme o designer descobre onde e necessaria uma maior flexibilidade.Prototype nao requer subclasse, mas requer uma operacao Initialize. Factory Method requer subclasse, mas nao requer Initialize.Designs que utilizam padroes Composite e Decorator podem tambem obter beneficios do Prototype.
Durante os meus 11 anos trabalhando com desenvolvimento de software, pude perceber diversos comportamentos em nossa area que devemos evitar, a fim de nao cairmos em fatores como problemas de relacionamento com os colegas de time, queda de produtividade e qualidade durante os processos de desenvolvimento de software. Desta forma, preparei 11 conselhos - um para cada ano. Dizem que, se conselho fosse bom, a gente nao dava, vendia. Porem, as praticas comportamentais a seguir tem funcionado bem para mim e para os colegas de profissao que observo pratica-las. Espero que funcionem bem para voce, tambem. Boa leitura!1) Seja construtivo: ao ver um erro, trecho de codigo ou ate uma arquitetura que voce nao concorde, nao condene o trabalho feito por outros colegas. Se voce considera ter um conhecimento de causa melhor, entao de nao somente dicas, mas tambem mostre um exemplo pratico, em forma de codigo, de como o trabalho realizado pode ficar melhor. Ficar jogando pedras no telhado do vizinho fara somente com que voce passe uma imagem de alguem intragavel, que so quer aparecer as custas dos outros, alem de afastar seus colegas. Tenha em mente que o mesmo insulto que voce faz aos outros de alguma forma se voltara contra voce.2) Respeite os novatos: voce nao nasceu sabendo tudo. Ja passou pela mesma curva de aprendizado que outros profissionais que acabaram de entrar no mercado estao passando. Entao nao desanime seu colega novato quando perceber que ele ainda nao possui niveis de maturidade em analise e codigo como os seus. Ajude-o a progredir, em vez de traumatiza-lo. Ele sera eternamente grato a voce por isso. Pode ter certeza que, como o mundo da voltas, ele se lembrara de voce caso em algum momento da vida ele esteja por cima e, voce, precisando de um emprego. Se ele tera boas ou mas recordacoes de voce, so dependera de suas atitudes para com ele no presente.3) Respeite os antigos: sabe aquele profissional que trabalha na empresa desde longa data e faz manutencao de um software que possui tecnologia antiga que sera migrada para uma tecnologia nova para a qual voce foi contratado? Nao subestime-o. Nao pense que ele e o obsoleto da historia e que voce esta na crista da onda. Ele possui um conhecimento que voce simplesmente esta longe de dominar: os processos e o negocio da empresa. Seja muito legal com ele, escute todas as suas consideracoes, absorva ao maximo sua experiencia e seus conselhos e tenha-o como o seu tutor, nao como o seu concorrente. Nao tente pular os degraus a forca. Ate porque este cara que voce menospreza e considera obsoleto pode se atualizar e aprender as tecnicas modernas que voce preza tanto no maximo em 12 meses, enquanto voce ainda tera que comer muito arroz com feijao para entender todo o negocio da empresa, os meandros dos componentes, das dlls antigas registradas e do banco de dados.4) Nao (des)arrume o codigo demais: se voce foi solicitado a fazer uma manutencao corretiva ou evolutiva no software, procure os pontos onde o codigo deve ser mudado. Nao
de uma de heroi, querendo mudar o codigo inteiro, a nao ser que voce possua um dominio pleno daquela parte especifica do software e tenha tempo sobrando para fazer a mudanca. Voce nao sabe o porque de alguns metodos existirem. Querer apaga-los ou muda-los completamente sera como dar um tiro no pe, pois voce gastara mais tempo que o necessario e podera fazer com que erros que nao ocorriam antes da manutencao passem a ocorrer.5) Nao pire na tecnologia: o mercado de desenvolvimento de software ira sempre trazer novidades que julga serem "boas praticas". Antes de querer sair aplicando tudo o que e novo, faca a si proprio as seguintes perguntas:- A arquitetura de software que utilizamos na empresa ja possui uma organizacao e performance adequadas?- Estou querendo aplicar esta novidade por necessidade? Ou por pura vaidade?Pense muito bem e, antes de aplicar novidades, sugira, demonstre com exemplos praticos que e benefico aplica-las. Nao saia fazendo as coisas ao seu bel prazer. Ate porque, depois que voce fez a mudanca, tudo estara muito claro para voce, mas o resto do time ira penar para entender. Um dia voce saira da empresa e seus colegas devem ter condicoes de entender o codigo que voce fez. Tenha o bom senso de aplicar tao somente as novidades que a empresa e seus companheiros de time precisam para o desenvolvimento de uma arquitetura simples, clara, coesa, fortemente orientada a reuso e com facilidade de manutencao do codigo. Quem gosta de complicar e nao tem o pensamento de desenvolver para o time, nao esta sendo inteligente. Esta sendo, no maximo, um "intellisense nonsense". Nao seja egoista, pense como time!6) Nao empaque: muitas vezes perdemos muito tempo tentando decifrar questoes tecnicas ou de negocio durante o desenvolvimento ou manutencao de software, enquanto um colega que esta do nosso lado poderia "encurtar o sofrimento" e nos auxiliar, pois ja solucionou algum problema parecido. Se voce perceber que o tempo esta passando e que nao esta conseguindo chegar a uma solucao, nao tenha vergonha de perguntar a um colega. E claro, a empresa deve proporcionar um ambiente colaborativo, onde as pessoas se ajudem com boa vontade e sem aqueles preconceitos competitivos do tipo "como e que voce e analista se nao sabe fazer isso?" Todo profissional possui seus pontos fortes e seus pontos a melhorar. Em um ambiente colaborativo, todos somente tem a ganhar com a troca de conhecimentos. Principalmente a empresa, com o consequente aumento da produtividade.7) Nao gaste seu tempo com bobagens: a internet e uma poderosa ferramenta para o desenvolvedor de software que sabe explora-la. Portanto, aproveite-a durante o expediente, navegue e faca as suas pesquisas, mas com o objetivo de solucionar as questoes inerentes ao seu trabalho. E claro que, quando bater aquele stress, nao ha problemas em ler os e-mails pessoais, fazer alguma ligacao extra trabalho, ir tomar um cafe e conversar um pouco sobre assuntos aleatorios para descontrair. Nao somos maquinas. Mas nao exagere, mantenha o foco. Cada empresa por onde voce passar oferecera um leque de aprendizados tecnicos e de negocio. Estude os
exatamente ao que ele esta perguntando. Nao de voltas tentando demonstrar toda a sua erudicao tecnica, pois, desta forma, ele, alem de nao entender a sua explicacao, podera acha-lo arrogante (se o colega for levar para o lado da maldade) ou maluco (se o colega for levar para o lado da piedade).A objetividade tambem deve sempre ser levada para o desenvolvimento do software, desde seu nome, ate as camadas que farao parte dele. Alguns exemplos:a) Se o objetivo do software for "estoque de produtos", e muito mais pratico e claro nomea-lo "Estoque de Produtos" do que "Thunder Cats".b) Nomes de variaveis, metodos e camadas sao muito importantes para que o time entenda o software. Entao, nao abuse da criatividade e nomeie, por exemplo, a variavel de quantidade de produtos como qtdProdutos em vez de observeAndCount e o metodo de obtencao de produtos como ObterProdutos() em vez de GetThings(). Se o objetivo de uma camada da arquitetura for acesso a dados, basta nomea-la com o seu objetivo primario, em vez de chama-la de "Data Cave".c) Ha uma corrente que diz que codigo bem feito nao precisa de comentarios. No mundo dos sonhos, e assim que a coisa funciona. Porem, no mundo real, o codigo pode estar muito bem feito, mas sempre ha aquele trecho meio obscuro, nao tem jeito. Ha situacoes em que e de muito bom gosto inserir um comentario que explique o que determinado trecho de codigo faz. Afinal, "comentarios existem para comentar".d) Nao reinvente a roda: nao faca um codigo de dificil entendimento so porque e bonito e utiliza recursos eruditos. O que e bonito aos seus olhos pode ser aterrorizante aos olhos dos outros. O que pode ser simples, deve sempre continuar simples.
na pratica sempre resulta na duplicacao desnecessaria de codigo. E quase sempre mais eficaz utilizar uma implementacao bem feita do que um "mero design pattern".Nao difere significantemente de outras abstracoes: alguns autores alegam que os design patterns nao diferem significantemente de outras formas de abstracao, e que o uso da nova terminologia (emprestada da comunidade de arquitetura) para descrever o fenomeno existente no campo da programacao e desnecessario. O paradigma Model-View-Controller e aclamado como um exemplo de um "pattern" que precede em muitos anos o conceito de "design patterns". Tambem ha o argumento de que a contribuicao primaria da comunidade Design Patterns (e o livro da Gang of Four) foi o uso do padrao de Alexander como uma forma de documentacao; uma pratica que frequentemente e ignorada na literatura.
fazer um catch da mensagem de erro antes que a mesma seja mostrada ao usuario e nao mostrar nada ou uma mensagem sem significado algum.- Hard code: incorporar pressupostos do ambiente de um sistema em sua implementacao.- Fluxo de lava: manter codigo indesejavel (redundante ou de baixa qualidade) porque remove-lo e muito caro ou trara consequencias imprevisiveis.- Sequencia Loop-switch: codificar um conjunto de etapas sequenciais usando switch dentro de um loop.- Numeros magicos: incluir numeros inexplicaveis em algoritmos.- Strings magicos: incluir strings literais no codigo, para comparacoes, como tipos de eventos etc.- Soft code (codigo leve): nao armazenar a logica de negocio no codigo fonte, mas em arquivos de configuracao.- Codigo macarronico: programas cuja estrutura e dificil de compreender, especialmente por causa da mistura de estruturas de codigo.Anti-patterns metodologicos:- Copiar e colar um programa: copiar e modificar um codigo existente em vez de criar solucoes genericas.- Golden hammer (martelo de ouro): presumir que uma solucao favorita e universalmente aplicavel.- Fator de improbalidade: presumir que seja improvavel que um erro conhecido possa ocorrer.- Otimizacao prematura: codificar pensando somente na eficiencia, sacrificando o bom design, manutenibilidade e, muitas vezes, a propria eficiencia.- Programar por acidente: tentar chegar a uma solucao atraves de modificacoes sucessivas no codigo para ver se funciona.- Reinventar a roda: nao adotar uma solucao existente e adequada.- Reiventar a roda quadrada: nao adotar uma solucao existente. Em vez disso, adotar uma solucao customizada com um desempenho muito pior que a existente.- Silver bullet (bala de prata): presumir que uma solucao tecnica favorita pode resolver um processo ou problema maior. - Tester Driven Development (Desenvolvimento Orientado ao Testador): projetos de software onde novos requisitos sao especificados em relatorios de erros.Anti-patterns de gerenciamento de configuracao:- Dependency hell: problemas com as versoes dos produtos exigidos.- DLL hell: gerenciamento inadequado das dynamic-link libraries (DLLs).- Conflito de extensao: problemas com diferentes extensoes para as versoes do pre-Mac OS da MC OS, na tentativa de corrigir as mesmas partes do sistema operacional. - JAR hell: superutilizacao de multiplos arquivos JAR, normalmente causando problemas de versionamento e localizacao, devido ao nao entendimento do Java class loading model.
Este post e composto de trechos extraidos da Wikipedia.Em programacao orientada a objeto, um God Object (Objeto Deus) e um objeto que sabe muito e faz muito. God Object e um exemplo de anti-pattern.A ideia basica por tras da programacao estruturada e que um problema grande seja quebrado em muitos problemas menores (estrategia dividir e conquistar) e solucoes sao criadas para cada um destes problemas. Assim que os problemas pequenos sao resolvidos, o problema como um todo tambem sera. Portanto, ha somente um objeto de quem um objeto precisa saber tudo: ele mesmo. Alem disso, ha somente um objeto de quem um objeto deve resolver um conjunto de problemas: ele mesmo.O codigo baseado em God Object nao segue esta abordagem. Em vez disso, a maioria da funcionalidade global e codificada em um unico objeto "sabe-tudo", que mantem a maioria das informacoes do programa inteiro e fornece a maioria dos metodos para manipular os dados. Devido ao fato que este objeto mantem muitos dados e requisita muitos metodos, seu papel no programa se torna como se fosse um "Deus". Em vez de objetos se comunicando diretamente, os outros objetos dentro do programa confiam a um God Object a maioria de suas informacoes e interacoes. Uma vez que o God Object e referenciado por muitos outros codigos, a manutencao se torna mais dificil do que em um design dividido de forma mais equilibrada.God Object e um analogo orientado a objeto de nao usar subrotinas em linguagens procedurais, ou em usar muitas variaveis globais para armazenar informacao de estado.Enquanto a criacao de um God Object e normalmente considerada uma ma pratica de programacao, esta tecnica e ocasionalmente utilizada em certos ambientes de programacao (como microcontrollers), onde ha um ligeiro aumento de desempenho e a centralizacao do controle e mais importante que a manutenibilidade e o codigo elegante. O sonho Sonhe com aquilo que voce quer ser,porque voce possui apenas uma vidae nela so se tem uma chancede fazer aquilo que quer.Tenha felicidade bastante para faze-la doce.Dificuldades para faze-la forte.Tristeza para faze-la humana.E esperanca suficiente para faze-la feliz.As pessoas mais felizes nao tem as melhores coisas.Elas sabem fazer o melhor das oportunidadesque aparecem em seus caminhos.A felicidade aparece para aqueles que choram.Para aqueles que se machucamPara aqueles que buscam e tentam sempre.E para aqueles que reconhecema importancia das pessoas que passaram por suas vidas.* * *Clarice Lispector Ontem, depois de muito tempo, percebi algoque a acontece a muito tempo!So percebi ontem, sei la, me senti um idiota.Como pode estar tao na minha cara e eu deixar passar!Bem, deixa pra la ne!O fato e que quanto mais vivo, mais me convencoque a o ser humano, em sua maioria, vive de conveniencias.Me convem ser amigo de tal pessoa, serei amigo!Me convem tratar bem tal pessoa, tratarei bem!Me convem nao dar a minima para um fato, ignorar,eu ignoro, eu nao dou a minima, eu deixo pra la!Talvez por isto eu nao tenha percebido antes o que percebi ontem.A pessoa la fazendo o seu trabalho e tentando daro maior destaque possivel aos erros dos outros!Porque isto?Nao sei!Nao quero saber!Mas se
ela queria que ficasse feio para quem errou,acabou ficando feio pra ela!AffTadinha!Era a oportunidade de mostrar dignidade e dizer:"Ei, vem ca, voce errou! Vamos corrigir isto aqui!"Mas nao, convem dar enfase aos erros e jogar pedras!Sabe,"Nao gosto de gente que e incapaz de fazer qualquer coisa,mas gosta de dar palpites sobre como semeamos nossas acoes,plantamos nossos pensamentos, regamos nossas conquistas.Por picardia, so por isto!"O tolo que adora dar palpites sobre o nosso jardim,jamais cuida de suas plantas.
Mesmo que ja tenhamos fracassado repetidas vezes, precisamos tentar de novo, ate que consigamos prosseguir(...) (...) Essa pessoa aqui tem o instinto certo para tentar. e insistir em tentar!Claro, as vezes a gente escolhe e a atitude errada. So que, ficar insistindo e batendo na mesma tecla so faz e roubar tempo e energia da gente. So faz e impedir que a gente trabalhe pelo surgimento de um novo caminho, entao, quem sabe, nao esta na hora de novas escolhas...Hein?Por isto eu insisto, eu tento!E isso, eu acho, e sobriedade. E e dentro da gente mesmo que precisamosreunir forcas pra permitir que o mundo siga... porque ele ja seguiria, por ele mesmo, ainda que sem a gente.Entao, nao vejo maldade em escolher como o meumundo deve seguir...Eu sei...E bem dificil manter a energia positiva as vezes.A gente se indigna, perde um pouco de perspectivamas temos que continuar acreditando que vai dar certo!Ai, a gente recomeca.Claro que...Nao temos controle sobre tudo, mas nem por isso vamos perder a fe que nos mantem acreditando.Por isto, mesmo que ja tenha fracassado repetidas vezes, preciso tentar de novo, ate que consiga prosseguir(...) (...) Essa pessoa aqui tem o instinto certo para tentar. e insistir em tentar!(Amem.) Lembrar voce me faz sentir gosto de vento. Desses que passam morosos e fechamos os olhos como se pede um alento. ou quem sabe voar. Se eu soubesse tocar bem violao musicava as suas lembrancas. so para tocar no banheiro, ou numa tarde bonita quando estou esquecido. Eu lembro muito de voce, de seu rosto, seu sorriso!E voce para mim tem cheiro doce. perfume de flor. Nos somos responsaveis por aquilo que temos,que sentimos, que vivemos, que escolhemos, que,que, que...O outra(o) so pode nos ajudar a aproveitar o que somos!Nada lhe posso dar que ja nao exista em voce mesmo. Nao posso abrir-lhe outro mundo de imagens, alem daquele que ha em sua propria alma. Nada lhe posso dar a nao ser a oportunidade, o impulso, a chave. Eu o ajudarei a tornar visivel o seu proprio mundo, e isso e tudo. * * *Hermann Hesse Parece sempre um pouco inevitavel. a gente coloca a responsabilidade de sermosfelizes em outras pessoas.Minhas atitudes, minha vida, meu jeito de ser,minhas loucuras, nao dependem das outras pessoas!O que voce e nao depende de ninguem!O que voce faz depende so do seu querer!O que voce sente e seu, e nao precisa agradar minguem!Quanto da responsabilidade sobre a nossa propria vida a gente nao outorga aos outros? Nos somos responsaveis por nossa vida!"Voce me faz sentir um idiota.""Ele me deixou tao triste... "Quando a gente pensa assim acaba atribuindo ao outro um poder que ele nao tem, o poder de determinar aquilo que a gente e, faz, sente.A inseguranca (ou ciume, ou raiva, ou qualquer outro sentimento), E voce que sente, e e somente voce mesmo o responsavel.Assuma o SEU poder, que e o de decidir como VOCE ira se sentir... Pessoas com vidas interessantes nao tem frescuras. Interessam-se por gente que e o oposto delas. Aceitam um convite para fazer o que nunca fizeram.
Estao dispostas a mudar de cor preferida, de prato predileto. Comecam do zero inumeras vezes. Nao se assustam com a passagem do tempo. Sobem no palco, tosam o cabelo, compram passagem so de ida.Para os rotuladores de plantao...um bando de inconsequentes. kkkkkk Idiotas!Ter uma vida interessante nao e prerrogativa de uma classe. E acessivel a medicos, donas de casa, operadores de telemarketing, professoras, fiscais da Receita, ascensoristas. etc...Gente que assimilou bem as regras do jogo (trabalhar, casar, ter filhos, morrer e ir pro ceu), mas que, assim como eu, desconfia dos clubes que lhe aceitam como socio. Qual e relevancia do que e nos perguntado numa ficha de inscricao, num cadastro para avaliar quem somos? Nome, endereco, estado civil, RG, CPF. Aprovado. Bem-vindo ao mundo feliz?Sera?prefiro ser o Dono do meu clube!E a entrada ta liberada, pra quem quiser!Quem nao quiser...Quem nao quiser...Aaaaa...que se f...:-)Uma vida interessante e menos burocratica, mas exige muito mais.