thegoodfellas/blogset-br huggingface dataset:
o banco de dados seja o mesmo ao final do teste, para nao impactar testes futuros, como gerar estes dados ? Como garantir a estabilidade do ambiente ? e por ai vai.... Usar ou nao usar Mocks Quando devemos usar Mocks ? Para que eles servem ? Usando Mocks nao estamos fazendo com que o ambiente de teste seja forjado, fugindo da realidade ? e por ai vai... Que padroes adotar para testes Uma classe de teste para cada classe de negocio ? Quais padroes de nomenclaturas ? Como separar os namespaces e assemblies de testes ? e por ai vai...Nos sabiamos que nao seria facil, o comeco e a parte mais traumatica de qualquer novo desafio, e nao contentes com estas duvidas, fomos atras de respostas. Durante nossas pesquisas, vimos inumeros exemplo simples, como por exemplo, testando os Get e Set, testando o somar, subtrair, testando uma rotina de desconto, validacao de dados, enfim... De certa forma nos decepcionamos, a sensacao que tivemos e de que testes unitarios, cobertura de testes era uma lenda. Todo mundo dizia que era bom, todo mundo dizia que era importante, mas ninguem dizia como fazer de fato em um projeto real.Pois bem, nao desistimos, sabiamos da importancia dos testes, sabiamos que so dependia de nos. Estudamos mais um pouco, erramos mais um pouco, refatoramos muito e continuamos a escrever nossos testes.Na falta de padroes de mercado que nos dessem seguranca, seguimos de acordo com o que achavamos ser o mais correto e coerente baseado em tudo o que haviamos lido, feito e discutido. Decidimos que todas as classes seriam testadas, criamos um metodo generico para testar o mapeamento de todas as classes no NHibernate, separamos os testes em dois assemblies, um de testes de interface e outro para os testes do Selenium, para a nomenclatura usariamos em portugues de forma mais clara possivel, mesmo que as vezes o nome fique gigante rs.Bom, seguimos escrevendo nossos testes, buscando o maximo de cobertura possivel. Ainda existem alguns desafios como por exemplo a automatizacao dos teste de GUI, estamos amadurecendo no uso do Selenium e em breve postarei sobre isso.Bom, nao sei se consegui transmitir aqui a mensagem desejada. O que eu queria deixar claro e que fazer testes unitarios NAO e tao facil quanto parece. Existe uma grande possibilidade de voce desanimar e chutar o balde diante das dificuldades iniciais, e continuar desenvolvendo sem testes unitarios, a sensacao que voce pode ter no inicio e de que isso e uma lenda e nao funciona. Mas eu lhes digo, e apenas uma sensacao inicial, testes unitarios funcionam e eu nao consigo me imaginar desenvolvendo sem eles. Em breve postarei aqui sobre os beneficios que percebi apos adocao dos testes unitarios.Meu recado final e: Facam testes unitarios. Superem as dificuldades. No inicio eles nao serao os testes mais elegantes e eficientes do mundo, mas com o tempo voce pega o jeito, refatora os mesmos e logo logo nao conseguira mais programar sem eles, portanto, se for para desenvolver um projeto de software, faca testes unitarios, sempre que possivel.P.S.:E claro
que estes testes devem estar em um ambiente automatizado, com cobertura medida e tudo mais, mas isso e assunto para um outro post, neste limito-me a algumas das experiencia vividas com Testes Unitarios, sem nem mesmo entrar no merito do TDD ainda. Caso alguem tenha um livro para indicar sobre testes unitarios, padroes e boas praticas de testes unitarios, TDD para nos indicar, fiquem a vontade =) =). Fiquem a vontade tambem para compartilhar suas experiencias, vamos mostrar para o mundo que SIM, teste unitario funciona e e fundamental para o desenvolvimento de softwares de qualidade.Ate logo pessoal, um grande abraco.
temos que misturar tarefas de dois projetos diferentes, com prioridades e complexidades diferentes, com processos e equipes de homologacao diferentes.Algumas demandas de customizacao, prendiam membros da equipe por dias, atrapalhando a evolucao do ciclo.Motivado pelo desafio, buscamos customizacoes no processo e no ambiente, de forma a suportar este cenario. Eu admito que o resultado nao foi ruim, mas estava distante do ideal. O Projeto A estava controlado com as customizacoes e correcoes sendo atendidas no prazo. Por outro lado o Projeto B estava se movimentando a 30km/h, mas o product owner precisava que este projeto se movimentasse a 100km/h.Diante disso, em uma reuniao com o Product Owner, foi decidido pelo caminho talvez mais obvio: A divisao da equipe. Definimos um periodo de transicao, e uma data de corte, quando a equipe do projeto B seria desligada do projeto A. Fiquei como ScrumMaster do projeto B, sem ter que me preocupar mais com o legado e as manutencoes do projeto A. Ou seja, a partir de agora, eu e a equipe poderiamos ter Foco.Escolhi os membros que melhor se enquadravam e fizemos a migracao.Desde entao retomamos de forma mais consistente a adocao de Agile e o projeto esta comecando a ganhar mais volume e forca.Nos proximos posts comentarei mais sobre essa nossa nova experiencia, falando sobre as praticas que estamos utilizando, os padroes que estamos seguindo, as dificuldades que estamos encontrando, enfim, sobre nossa experiencia Agile.Por hora e isso, desculpem-me pelo afastamento, e espero nos proximos dias, semanas, meses, anos, compartilhar muitas experiencias de adocao de metodos ageis com voces.Abraco.
Ola pessoal, estou de volta e dessa vez vou falar sobre um dos temas mais polemicos do Extreme Programming que e o Pair Programming.O Pair Programming consiste em dois desenvolvedores atuando no mesmo problema no mesmo computador, sendo um o Piloto e o outro o Navegador. Semelhante ao que temos nas corridas de Rally :p .Bom, o primeiro grande desafio da programacao em par e convencer os nossos chefes de que nao sera improdutivo manter duas pessoas no mesmo computador full-time. O segundo desafio e a equipe, infelismente nem todos estao aptos a trabalhar com Pair Programming. Muitos, ao inves de serem navegadores, serao simplesmente passageiros, enquanto o piloto desenvolve o passageiro apenas contempla a paisagem e nao presta atencao nem mesmo no caminho que esta sendo tomado.Pois bem, na minha opniao, nao e necessario ter dois desenvolvedores juntos full-time nas tarefas do projeto, eu acredito mais no Pair Programming On Demand, ou seja, para tarefas mais especificas, desafios maiores, requisitos que possuem maior risco, complexidade. Ate porque, pensem comigo, para que ter dois desenvolvedores na implementacao de uma solucao simples, getters and setters, binds, dao's, ou seja, tarefas rotineiras que ja estao no sangue da equipe de desenvolvimento, nestes casos penso que Pair Programming nao agrega muito. Agora quando temos uma rotina complexa, onde temos um grande risco envolvido, ou uma refatoracao mais delicada, ai sim, acho que e muito valido a aplicacao do Pair Programming para que o problema, o desafio seja resolvido, por isso que digo que acredito mais no Pair Programming On Demand, ou seja, aquele que so e aplicado quando surge uma demanda especifica que justifique duas cabecas pensando no problema.Os defensores mais ferenhos da tecnica podem dizer que assim nao temos o codigo completamente compartilhado pela equipe, ou que nao inibimos o XGH, ou que decisoes podem ser tomadas por um unico programador. No caso das decisoes de design, eu diria que o ideal nao e nem envolver so dois desenvolvedores mas todos. Em nosso projeto o que tem acontecido e que quando detectamos algum ponto que pode ser melhorado ou quando nos deparamos com algum requisito que demandara a aplicacao de algum pattern ou criacao de alguma biblioteca nova, sentamos e discutimos.Com isso, quando forem aplicar Extreme Programming, como tudo na vida, usem e abusem do bom-senso e preste atencao na composicao da equipe, certifique-se que os sao porcos e nao galinhas, e para perceber isso basta observar o comportamento dos desenvolvedores quando nao estao pilotando, ou seja, se ele fizer um papel de navegador, tem grandes chances de ser um porco, se fizer papel de passageiro, tem grandes chances de ser galinha.E isso pessoal, nao tenham medo nem vergonha de "parear" em suas equipes, sem duvida nenhuma duas cabecas pensam melhor do que uma, mas tenhamos bom-senso, pares para get e set, factories, singleton, binds e outras atividades tao triviais do nosso dia-a-dia... na minha opniao nao fazem sentido.Um grande abraco. Nesta ultima quarta-feira, tive mais um dia no treinamento de Agile com o Vinicius Morgado. Na ocasiao discutimos sobre Domain Driven Design, dentre
varios pontos positivos do treinamento, posso destacar:- Design incremental - Nosso primeiro modelo e necessariamente imperfeito e trata-se apenas de uma abordagem exploratoria, sem necessidade de muito detalhamento, o detalhamento e realizado com o tempo a medida em que se explora e conhece o modelo. De forma incremental. ;)- O codigo deve ser a representacao exata do modelo. O programador deve olhar o codigo e ver o modelo, olhar o modelo e ver o codigo, como se fossem um unico artefato.- Em DDD, uma entidade e definida pela sua identidade e um VO e definido pelo seu valor- E desejavel que os VO's sejam imutaveis, ou seja, se precisar mudar o valor de um VO, elimine-o e crie um novo.Durante o treinamento, fizemos um modelo de alto nivel baseado em um estudo de caso, desenvolvendo o pensamento de forma orientada ao dominio. A aula foi bem interessante com todos estes topicos nos agregando bastante conhecimento e mais importante que isso, agregando valor. Porem eu gostaria de destacar e compartilhar com voces, uma frase do Vinicius durante a aula."Olhe as mudancas pelo aspecto do fundamento, nao pelas ferramentas."Essa frase surgiu durante uma discussao a respeito das evolucoes tecnologicas que nossa area sofre. E interessante olhar pela otica do fundamento, pois como ele bem ressaltou, o fundamento nao muda a cada ano ou a cada semestre, na verdade as ferramentas mudam bastante mas continuam girando em torno dos mesmos fundamentos ou pelo menos em fundamentos que sofrem poucas mutacoes.Acho interessante termos consciencia desta otica pois as vezes temos a sensacao de que quando acabamos de aprender XPTO, sai o XPTO 2.0.Apesar de ja ter percebido isso ha algum tempo, nunca tinha conseguido explicitar isso de forma tao clara como o Vinicius o fez nessa frase, portanto, fiquem com esta mensagem na cabeca. Procure enriquecer seu conhecimento no fundamento e nao apenas na ferramenta. Procure por Orientacao a Objetos, Design Patterns, Agile(Em sua essencia), SOA etc... enfim... estude, pratique, se dedique, DOMINE!!! Os fundamentos, os conceitos e nao apenas as ferramentas.Um grande abraco a todos.
Ola pessoal... ha mais de um mes que nao posto nada. Pois e, o mes de Julho foi pessimo, me envolvi em um projeto externo, critico para a empresa, agora as coisas estao estabilizando e estarei voltando a postar com mais frequencia.Pois bem, o mes de junho foi muito bom com o inicio da adocao oficial de praticas ageis e do Scrum, com o cumprimento de todas as metas.E senhores, ja o mes de Julho foi o caos e eu tenho que admitir para voces que nao foi facil.Houve falha de comunicacao na equipe em um determinado momento, ocacionando na sobreposicao de uma base de testes do desenvolvimento.Os valores do Agile ainda nao foram completamente absorvidos.Implantar Agile, ou melhor PENSAR Agile, VIVER Agile, SER Agile nao e tao simples quanto muitas vezes parece.Eu posso resumir Julho em uma frase: Nao fomos Ageis. Nem na postura, nem no pensamento, tampouco no comportamento. E isso e pessimo, e realmente frustrante. Mas.......... A boa noticia e que como bom Brasileiro e bom Potencial Agilista eu nao desisto, ou melhor nos nao desistimos.Na ultima segunda-feira, fizemos uma retrospectiva e levantamos muitos problemas, a grosso modo chegamos aos seguintes problemas e solucoes: 1 - Problema: Indisponibilidade do P.O Solucao: O P.O devera eleger um Sub P.O, alguem que na ausencia dele possa aprovar os sprints e priorizar o backlog. 2 - Problema: Nao realizacao das reunioes diarias Solucao: Colocamos no servidor, agendado para as 17:45 um script para enviar uma mensagem para a maquina de todos os desenvolvedores lembrando da Daily Meeting. 3 - Problema: Nao absorcao dos valores do Agile Solucao: Fixar na parede e proximo ao Kanban os valores e principios do Agile e toda vez que pegarmos um ao outro violando o principio deveremos apontar para o mesmo, indicando que estamos indo contra o que pregamos. 4 - Problema: Kanban nao muito claro Solucao: Divisao do kanban em outros quadros, agora teremos dois quadros para o kanban, um quadro tera dois projetos novos e o outro tera as atividades do produto atual em manutencao, separando o que e correcao de bugs e o que e customizacao. Alem disso teremos um terceiro quadro onde iremos colocar o BurnDown de cada projeto.Em resumo e isso pessoal. Tivemos ate mais falhas do que as descritas acima, mas sinceramente sao 01:09 da manha e meus neuronios ja nao estao fazendo muitas Sinapses, nao to me recordando dos outros itens rsrsrsE isso, Julho foi complicadissimo mas nao desistimos, nem desistiremos, seguimos firmes e fortes nessa batalha.Em breve trarei mais novidades, como a nova organizacao do Kanban, novidades no planning poker, dentre outras.Agora tudo o que mais preciso e durmir rsrsUm grande abraco a todos e uma otima noite.Ricardo Coelho. Boa noite galera.Hoje foi um dia corrido, foi dia de review e planning com o Product Owner.Desta vez, corrigindo uma falha cometida por mim no planejamento do primeiro sprint, toda a equipe participou das reunioes junto ao P.O.Aproveitamos o encontro para reforcar os principios do Agile e o papel do P.O, em resumo, explicitamos o seguinte:- Product Owner - Nortear
o desenvolvimento atraves da definicao e priorizacao do BackLog.(E a nossa bussola de negocio/valor) - Validar o resultado da entrega do sprint. - Estar disponivel para duvidas sempre que necessario.- Equipe - Se comprometer com aquilo que pode cumprir. - Se dedicar e se auto-organizar para entregar o que foi acordado. - Buscar melhorar a si mesma atraves das reunioes de retrospectiva.- ScrumMaster - Antes de mais nada e um membro da equipe e tem as mesmas responsabilidades da mesma. - Remover impedimentos da equipe. - Estimular e potencializar o rendimento da equipeApos este breve reforco dos papeis e mais uma passada nos principios do Agile, que agora guiam o departamento de desenvolvimento, iniciamos a review.Durante a review apresentamos o acordado para o primeiro sprint, durante a apresentacao o P.O fez algumas ressalvas como por exemplo quanto a usabilidade e layout. Em relacao a funcionalidades o mesmo ficou satisfeito com a entrega.O interessante foi que ja notamos um grande beneficio da adocao de Agile. O Feedback precoce. Ja discutimos mudancas na interface visando melhorar a usabilidade evitando que construissemos novas telas seguindo um padrao nao tao produtivo para o usuario.Apos a review ja geramos um insumo para o proximo sprint, que seriam os ajustes deste primeiro.Seguimos da review para o planning, onde discutimos a sequencia dos recursos a serem desenvolvidos.Apos discutirmos os recursos desejados e priorizados pelo P.O, fizemos uma lista com o que seria entregue em duas semanas(Definimos que trabalharemos com o sprint de 10 dias pois o de 5 dias ficou muito apertado). Alem disso, solicitamos ao mesmo uma definicao de PRONTO para o proximo sprint, dessa forma corrigimos mais uma falha do primeiro sprint, quando isso nao foi tao bem definido pelo P.O.Explicamos que era fundamental essa definicao para o proximo sprint pois essa definicao iria nos guiar como meta e consequentemente determinar o sucesso ou fracasso do sprint.Em suma a review e o planning foram isto, foi bem interessante pois sentimos que o P.O gostou e que o mesmo viu o desenvolvimento completamente aberto a mudancas, flexivel e focado em gerar valor para o negocio. Sem contar que sentimos que estamos dando passos seguros rumo ao sucesso do projeto alem de estarmos todos alinhados com o mesmo(P.O - Equipe - ScrumMaster).A ideia e ja colocar o software em producao em um cliente ao final do proximo sprint. Ou seja, ao final de cerca de um mes(Sprint 1 + Sprint 2), pretendemos ter um produto no ar, algo que jamais conseguimos com outras abordagens. As reunioes de hoje so me reforcaram o sentimento e certeza de que Agile e, atualmente, a melhor forma de se desenvolver projetos de software.Agora fico por aqui pessoal, feliz e ansioso pelos proximos sprints e evolucoes :)Amanha tem retrospectiva :) e em breve estarei de volta.Um abraco.Ate mais.
O jeito mais facil de escrever alguma coisa que voce quer que seja lembrado, e colocando uma musica que voce goste muito que se concentre em todos os seus pensamentos, e em todas as suas formas de ver a vida, que se focalise em como vai expressar tudo isso que esta passando em sua mente nesse momento, ai vocejoga tudo no papel ou no computador, assim voce esvasia sua mente, e coloca pra fora tudo que queria que todos soubesem sobre uma parte de voce que ninguem consegue ver ou ler,. Isso e uma forma muito boa pra se poder pensar muitas coisas e colocalas no pra fora sem que seja criticado ou que pensem que vocce e louco. E nesse cheiro de chuva vem fazendo mais agradavel ainda esse momento pois ele nos tras o casual da simplicidade e da modesta forma de se ver uma noite linda de chuva com nada pra fazer apenas pensar em como voce vai ocupar aquele tempo que esta se passando acada segundo dessa nossa vida tao simples e casual. Sinta e respire antes que tudo desmorone em tua cabeca, e voce veja que tudo era apenas um sonho, e nao exista mais chao pois arrancarao teu coracao e te darao motivos para sofrer mais por alguem que nao se importa se voce ainda respira ou se quer sente saudades suas. Ame mesmo que nao vale a pena ,mais nao se envolva se nao valer realmente pois coisas inuteis te tornarao alto o suficiente e te farao pobre de sentimentos, te fazendo regressar para uma vida mediocre e sem sentido. Nao tenho esperancas de tudo ser como antes mais espero que seja melhor. Apenas esperando para sobreviver mais um dia sem se quer voce me torne de novo e me faca como mais uma parte agradavel de voce me fazendo novamente regressar. Simples sem tanta preocupacoes apenas com breves momentos de flexibilidade, e de imensa conclusao de que coisas sao como deveriam ser, e assim nao precisao mudar apenas continuaram assim. Os pensamentos que mais nos prendem sao aqueles que nos faz refletir sobre a vida , aqueles que nos faz analisar o que somos, o que fomos, e o que queremos ser. Sao eles que nos prende nos afazeres, naquela relativa forma de que como se deve viver de verdade, tudo isso se reduz a meros pensamentos que apenas confundem e nos paralisa. Realmente nunca faremos aquilo tudo que queremos fazer nem, realizaremos tudo que se passa em nossa mente, mas mesmo assim nos fantasiamos com todas essas avalanches de pensamentos que a cada hora do nosso dia insistem em aparecer e nos sintonizar em todas essas questoes meramente ilustrativas que nos torna pessoas raramente felizes e condenadas. Mais isso tudo nao importa tanto pois cada um se fantasia e segue assim mesmo pois tudo isso sao partes de uma vida que esta se concluindo e esta se estabilizando sem forma e sem nexo completo so e apenas contraditorios e relevante forma de se ver e viver. As vezes eu acho que e dificil
so pra mim, mais nao e a dificuldade ou o problema que nos persegui, mais o achar que conseguimos resolver sozinhos, e o pensar que somos capazes de sermos pessoas que nos alto fortalecemos. Somos dependentes de Deus, e so ele e que pode nos fortalecer nos fazer feliz, Realizar nossos sonhos, so Deus e maior que nossos problemas, e maior que nossas dificuldades. so ele quem pode tudo, e e tudo.
As vezes penso que e dificil, penso que nao tem solucao, mais o que eu nao entendo e o que e isso tudo. Toda essa confunsao e o que me deixa sem saber o que fazer, mais a solucao nao e so tentar ir sem explicacao sem motivo, eu quero que preciso, toda essa mudanca e o que realmente tem que acontecer, e o que meu coracao deseja e o que vai me fazer feliz. Deus e o melhor pra mim, mesmo sem entender porque e essa conclusao de tudo isso que tenho, sem duvidas. UMA HISTORIA NOVA E LINDA ESCRITA PELO DEDO DE DEUS... Queria pedi pros visitantes do meu blog, comentem oque quiserem gostaria de saber o que estao achando das postagem, valeu (y) Passar o dia e facil, tudo tao rapido tanta coisa pra pensar. e fazer. e resolver. mais quando chega a noite tudo se acalma minha mente se anestesia ai caio em mim e sinto aquela saudade. aquela falta d seu sorriso. a falta da sua voz., a falta da sua presenca ,quando chega essa hora tudo ja fica mais dificil, tenho que me concentrar pra ser forte e nao te procurar nao me humilhar nao me render a sua falta e a saudade da sua presenca. Todas essas lembrancas tudo isso e o que me leva ate voce em toda noite de sono. Tudo fica mais confuso mais complicado mais estranho de se entender. As coisas em minha cabeca vem mais rapido, mais simples,mais nitido, Fica mais claro toda certeza de que acabo e que realmente nao foi por culpa minha, nao foi falta de falar o que se sente, foi por tempo, foi por tedio, foi por orgulho, foi por voce querer mais alguem pra controlar do que alguem pra amar, mais nao importa pois o tempo passa me lava me limpa, e vai removendo aos poucos voce de dentro de mim, me fortalecendo e ,e tornando mais resistente a todas essas lembrancas que ainda me manipulam, mais que com o tempo tem me deixado em paz. sinta e respire antes que tudo desmorone em tua cabeca, e voce veja que tudo era apenas um sonho, e nao exista mais chao pois arrancarao teu coracao e te darao motivos para sofrer ,mais por alguem qssSinta ue nao se importa se voce ainda respira ou se quer sente saudades suas. Ame mesmo que nao vale a pena ,mais nao se envolva se nao valer realmente pois coisas inuteis te tornarao alto o suficiente e te farao pobre de sentimentos, te fazendo regressar para uma vida mediocre e sem sentido. Nao tenho esperancas de tudo ser como antes mais espero que seja melhor. Apenas esperando para sobreviver mais um dia sem se quer voce me torne de novo e me faca como mais uma parte agradavel de voce me fazendo novamente regrear. Simples momentos, que apenas nos diz quem , Somos simples certos ,complexos sem sentidoapenas aqui desse jeito sem entender ou compreender so e apenas so um poucoalem, do que queremos e devemos ser.Somos quem queremos