Lendo o post do Fabio Kung [aqui] achei muito interessante a maneira como ele conseguiu mostrar onde os repositórios (do modo DDD de se desenvolver sistemas) se encaixam e porque usá-los.
As vezes explicar o porquê de se usar um repositório se parece com a explicação (a algum iniciado na tecnologia oo) do porquê de tanta indireção nos sistemas "oo".
quarta-feira, 27 de fevereiro de 2008
quarta-feira, 20 de fevereiro de 2008
O primeiro mashup agente nunca esquece...
Um mashup é um website ou uma aplicação web que usa conteúdo de mais de uma fonte para criar um novo serviço completo.
Definição da wikipédia.
Há alguns anos estava trabalhando num sistema web um "quase-portal", no projeto foi me pedido para que oferecesse um "atalho" para o email corporativo (na época hospedado numa empresa terceirizada). Foi ali que compus meu primeiro mashup tive que me virar para aproveitar o serviço (já pago) d'outro site no "quase-portal", foi algo simples naquele momento tenho certeza que nem tinha idéia do que havia feito.
terça-feira, 19 de fevereiro de 2008
Entrevista com Refraction, codificador do projeto PCSX2 - um emulador do Playstation 2.
Se há um grande projeto do qual posso afirmar que complexidade é o ponto alto, é o PCSX2, um emulador da famosa máquina Playstation 2.
Esse projeto conta com um time de desenvolvedores que entre outras várias coisas constroem software de maneira ágil.
Fiz a entrevista com Alex (conhecido como Refraction) e tive várias boas surpresas, por exemplo, eles usam visual studio 2005, tratam o projeto como um hobby não um trabalho... enfim melhor ler pra entender.
Entrevista traduzida:
Leandro:Primeiro qual o seu nome, onde você mora, alias conte-nos um pouco da sua história no desenvolvimento de software?
Alex: Meu nome é Alex, moro em Plymouth, Inglatera, desenvolvimento de software pra mim sempre foi um hobby, comecei com Visual Basic no ano de 2000, logo entre 2002 e 2003 eu fiz meu primeiro emulador (bom e velho *chip8!) usando a linguagem C, cuja tinha mexido um pouquinho pouco tempo antes, eu então passei para a bagunça que é a emulação do GameBoy, isso foi um gancho para trabalhar no time do PCSX2, comecei ajudando bem pouco, então Saqib (formalmente conhecido asadr) perguntou-me se queria juntar-se ao time, ai eu fui pra lá.
Leandro:Como nasceu o time do PCSX2?
Alex: PCSX2 foi criado pelos desenvolvedores do PCSX, Linuzappz e Shadow. Eles tinham terminado com muita acurácia a emulação do PS1 e descobriram o que o próximo passo lógico era dar gás a emulação do PS2, então o PCSX2 nasceu.
Leandro:O time de desenvolvimento é bem integrado?
Alex: Não tanto, o que você quis dizer com integrado, perto um do outro? na amizade sim, mas não tão perto perto perto. Embora nos continuemos bem.
Leandro:Que ferramentas vocês utilizam neste projeto?
Alex: Usamos sourceforge SVN e Visual Studio 2005. Alguns plugins, uso da **SDL, DirectX e OpenGL pra fazer o que for necessário para obter sucesso.
Leandro:O time de desenvolvedores segue algum padrão que vocês estabeleceram?
Alex: Nós não seguimos padrão nenhum, até porque isto é um hobby não um trabalho :)
Leandro:Há algum desenvolvedor responsável por coordenar as ações/atividades do projeto?
Alex: Não ia durar muito coordenando, às vezes dizemos "larga de ser preguiçoso e faça algum código" mas isto quase não é feito :p
Leandro:Vocês tem metas atribuídas por alguém ou apenas o desejo de construir bom software?
Alex: Definitivamente o desejo de construir bom software. Ultimamente o objetivo é ter uma boa emulação do PS2, mas isso é o jeito que as coisas vão.
Leandro:Qual é o melhor e o pior aprendizado que você pode ter no projeto?
Alex: Você quer dizer no projeto? Hmm, eu suponho que seria o ***timming do PS2, isto é dor além palavras.
Leandro:Você conhece algum dos membros pessoalmente?
Alex: Eu conheço dois dos meus testadores beta, CKemu e General Plot, eu conheci ambos.
Leandro:Que tipo de mecanismos vocês usam para se comunicarem?
Alex: Normalmente MSN e IRC, embora IRC tende ser menos sério.
Leandro:Qual recado você pode deixar para os usuários ansiosos?
Alex: Hmmm, no momento as coisas estão paradas, tudo que posso dizer é que em breve os usuários não precisarão ficar tristes por não possuírem o console, esperançosamente iremos ter uma alternativa grátis pra vocês, mas eu não tenho a data exata deste momento:)
Leandro:O cara Brasileiro no projeto (GoldenFinger) está ativo?
Alex: Não atualmente, ele até falou de uma volta, ele está inativo por anos, acredito que ele está ocupado no momento :)
Thanks
Refraction
*chip8 = uma máquina bem simples, que tem como forma de interação um teclado numérico, bem conhecida porque quem começa a desenvolver emuladores.
**SDL = Uma API cross-platform para escrever jogos ou tratar multimídia.
*** Timming = é clock interno (que também deve ser emulado) da máquina PS2.
Impressões:
Incrível como um software tão complexo pode ser construído por pessoas que estão geograficamente distantes. Só como ressalva o PCSX2 em processadores dual core (seja X2 (AMD), ou duo (Intel)) já está rodando em média de 20 a 50 fps.
Links interessantes:
Página oficial
Código fonte
Blog oficial
Forum oficial
Página de downloads
Beta releases
SVN Browser
A entrevista original:
Leandro:First what is you name, where you live actualy, btw tell us a bit of your history on computer software?
Alex: my name is Alex, i live in Plymouth, England, software development for me has always been a hobby, i started with VB back in 2000 and meddled in little bits here and there, then in 2002-2003 time i made my first emulator (good old chip8!) in C, which id picked up merely a few months before hand, i then went on to mess with Gameboy emulation then got hooked on the PCSX2 Team's work, i began helping out on bits, then Saqib (formally known as asadr) asked me to join the team, it went from there.
Leandro:How was born the PCSX2 team?
Alex: PCSX2 was created by the developers of PCSX, Linuzappz and Shadow. They had pretty much finished accurate PS1 emulation and figured the logical next step to fuel their coding needs would be to move on to PS2 emulation, so PCSX2 was born.
Leandro:The development team is quite integreted?
Alex: Not quite sure what you mean here, do you mean "close"? in a friend sort of way yes, but not close close. We get along fine though.
Leandro:Which tools you use on this project?
Alex: We use sourceforge SVN and Visual Studio 2005. some plugins use SDL, DirectX and OpenGL to do what they need to succeed.
Leandro:All the team follow some pattern that you stabelished?
Alex: We dont really follow any pattern, after all it is a hobby, not a job :)
Leandro:Some of the developers are responsible for coordinating the actions / activities of the project?
Alex: Not much coordinating goes on, sometimes we go "stop being lazy and do some coding" but thats as far as it goes :p
Leandro:You have targets set by someone or just the desire to build the good software?
Alex: definately the desire to build good software. Ultimately the goal is to have good PS2 emulation, but thats a way off yet.
Leandro:What is the best and the worst learning you could retrive from the project?
Alex: Do you mean part of the project? hmm, i suppose it would be the timing of the PS2 system, its a pain beyond words.
Leandro:Do you know some member personality?
Alex: I know 2 of my beta testers personally, CKemu and General Plot, i have met them both.
Leandro:What kind of mechanism you use to comunicate between members?
Alex: usually MSN and IRC, although IRC tends to be less serious.
Leandro:What scrap you can tell for anxious users?
Alex: Hmmm, at the moment things are a little dry, all i can say is hopefully soon users wont need to worry about not owning the console, hopefully we will have a free alternative for you, but i have no dates of completion :)
Leandro:The Brazilian guy on project (GoldenFinger) is active?
Alex: Not currently, hes talked about comming back as he was inactive for a few years, but i think hes a bit busy at the moment :)
Thanks
Refraction
Esse projeto conta com um time de desenvolvedores que entre outras várias coisas constroem software de maneira ágil.
Fiz a entrevista com Alex (conhecido como Refraction) e tive várias boas surpresas, por exemplo, eles usam visual studio 2005, tratam o projeto como um hobby não um trabalho... enfim melhor ler pra entender.
Entrevista traduzida:
Leandro:Primeiro qual o seu nome, onde você mora, alias conte-nos um pouco da sua história no desenvolvimento de software?
Alex: Meu nome é Alex, moro em Plymouth, Inglatera, desenvolvimento de software pra mim sempre foi um hobby, comecei com Visual Basic no ano de 2000, logo entre 2002 e 2003 eu fiz meu primeiro emulador (bom e velho *chip8!) usando a linguagem C, cuja tinha mexido um pouquinho pouco tempo antes, eu então passei para a bagunça que é a emulação do GameBoy, isso foi um gancho para trabalhar no time do PCSX2, comecei ajudando bem pouco, então Saqib (formalmente conhecido asadr) perguntou-me se queria juntar-se ao time, ai eu fui pra lá.
Leandro:Como nasceu o time do PCSX2?
Alex: PCSX2 foi criado pelos desenvolvedores do PCSX, Linuzappz e Shadow. Eles tinham terminado com muita acurácia a emulação do PS1 e descobriram o que o próximo passo lógico era dar gás a emulação do PS2, então o PCSX2 nasceu.
Leandro:O time de desenvolvimento é bem integrado?
Alex: Não tanto, o que você quis dizer com integrado, perto um do outro? na amizade sim, mas não tão perto perto perto. Embora nos continuemos bem.
Leandro:Que ferramentas vocês utilizam neste projeto?
Alex: Usamos sourceforge SVN e Visual Studio 2005. Alguns plugins, uso da **SDL, DirectX e OpenGL pra fazer o que for necessário para obter sucesso.
Leandro:O time de desenvolvedores segue algum padrão que vocês estabeleceram?
Alex: Nós não seguimos padrão nenhum, até porque isto é um hobby não um trabalho :)
Leandro:Há algum desenvolvedor responsável por coordenar as ações/atividades do projeto?
Alex: Não ia durar muito coordenando, às vezes dizemos "larga de ser preguiçoso e faça algum código" mas isto quase não é feito :p
Leandro:Vocês tem metas atribuídas por alguém ou apenas o desejo de construir bom software?
Alex: Definitivamente o desejo de construir bom software. Ultimamente o objetivo é ter uma boa emulação do PS2, mas isso é o jeito que as coisas vão.
Leandro:Qual é o melhor e o pior aprendizado que você pode ter no projeto?
Alex: Você quer dizer no projeto? Hmm, eu suponho que seria o ***timming do PS2, isto é dor além palavras.
Leandro:Você conhece algum dos membros pessoalmente?
Alex: Eu conheço dois dos meus testadores beta, CKemu e General Plot, eu conheci ambos.
Leandro:Que tipo de mecanismos vocês usam para se comunicarem?
Alex: Normalmente MSN e IRC, embora IRC tende ser menos sério.
Leandro:Qual recado você pode deixar para os usuários ansiosos?
Alex: Hmmm, no momento as coisas estão paradas, tudo que posso dizer é que em breve os usuários não precisarão ficar tristes por não possuírem o console, esperançosamente iremos ter uma alternativa grátis pra vocês, mas eu não tenho a data exata deste momento:)
Leandro:O cara Brasileiro no projeto (GoldenFinger) está ativo?
Alex: Não atualmente, ele até falou de uma volta, ele está inativo por anos, acredito que ele está ocupado no momento :)
Thanks
Refraction
*chip8 = uma máquina bem simples, que tem como forma de interação um teclado numérico, bem conhecida porque quem começa a desenvolver emuladores.
**SDL = Uma API cross-platform para escrever jogos ou tratar multimídia.
*** Timming = é clock interno (que também deve ser emulado) da máquina PS2.
Impressões:
Incrível como um software tão complexo pode ser construído por pessoas que estão geograficamente distantes. Só como ressalva o PCSX2 em processadores dual core (seja X2 (AMD), ou duo (Intel)) já está rodando em média de 20 a 50 fps.
Links interessantes:
Página oficial
Código fonte
Blog oficial
Forum oficial
Página de downloads
Beta releases
SVN Browser
A entrevista original:
Leandro:First what is you name, where you live actualy, btw tell us a bit of your history on computer software?
Alex: my name is Alex, i live in Plymouth, England, software development for me has always been a hobby, i started with VB back in 2000 and meddled in little bits here and there, then in 2002-2003 time i made my first emulator (good old chip8!) in C, which id picked up merely a few months before hand, i then went on to mess with Gameboy emulation then got hooked on the PCSX2 Team's work, i began helping out on bits, then Saqib (formally known as asadr) asked me to join the team, it went from there.
Leandro:How was born the PCSX2 team?
Alex: PCSX2 was created by the developers of PCSX, Linuzappz and Shadow. They had pretty much finished accurate PS1 emulation and figured the logical next step to fuel their coding needs would be to move on to PS2 emulation, so PCSX2 was born.
Leandro:The development team is quite integreted?
Alex: Not quite sure what you mean here, do you mean "close"? in a friend sort of way yes, but not close close. We get along fine though.
Leandro:Which tools you use on this project?
Alex: We use sourceforge SVN and Visual Studio 2005. some plugins use SDL, DirectX and OpenGL to do what they need to succeed.
Leandro:All the team follow some pattern that you stabelished?
Alex: We dont really follow any pattern, after all it is a hobby, not a job :)
Leandro:Some of the developers are responsible for coordinating the actions / activities of the project?
Alex: Not much coordinating goes on, sometimes we go "stop being lazy and do some coding" but thats as far as it goes :p
Leandro:You have targets set by someone or just the desire to build the good software?
Alex: definately the desire to build good software. Ultimately the goal is to have good PS2 emulation, but thats a way off yet.
Leandro:What is the best and the worst learning you could retrive from the project?
Alex: Do you mean part of the project? hmm, i suppose it would be the timing of the PS2 system, its a pain beyond words.
Leandro:Do you know some member personality?
Alex: I know 2 of my beta testers personally, CKemu and General Plot, i have met them both.
Leandro:What kind of mechanism you use to comunicate between members?
Alex: usually MSN and IRC, although IRC tends to be less serious.
Leandro:What scrap you can tell for anxious users?
Alex: Hmmm, at the moment things are a little dry, all i can say is hopefully soon users wont need to worry about not owning the console, hopefully we will have a free alternative for you, but i have no dates of completion :)
Leandro:The Brazilian guy on project (GoldenFinger) is active?
Alex: Not currently, hes talked about comming back as he was inactive for a few years, but i think hes a bit busy at the moment :)
Thanks
Refraction
quinta-feira, 14 de fevereiro de 2008
Práticas comuns em construção de sistemas
Introdução
Há uma prática difundida em projetos de software no mundo todo, o uso de diversos ambientes para a construção de sistemas. Em resumo funciona assim, o sistema é construído num *Ambiente de Desenvolvimento*, passa para um *Ambiente de Homologação* e finalmente vai pra *Produção*.
Um ambiente pode ser entendido como um local físico no computador (uma pasta ou computador) mais um conjunto de softwares auxiliares para execução do produto(software). Nesse ambiente é que fica os aplicativos necessários para que aplicação seja executada. Por exemplo: um projeto web feito em asp, normalmente utiliza os seguinte aplicativos: o servidor web IIS, um SGBD qualquer e os arquivos .asp; num projeto web para Java necessita de um container web, um SGBD, a JVM e os códigos(.class, .jsp). O importante é notar que estes aplicativos devem estar em todos ambientes e com as mesmas versões, para que o desenvolvimento seja eficaz, executável e testável em todos ambientes. A replicação de estrutura entre os ambientes.
Ambiente de Desenvolvimento
Quando se desenvolve (código mesmo) ou dá manutenção nas aplicações de uma empresa usa-se o ambiente de desenvolvimento. Nesse ambiente é que fica o código em desenvolvimento que pode ser testado também, ou seja, gerá código executável (não exe, mas no sentido de código funcional).
Existem vários elementos que fazem parte desse ambiente um deles é o...
Source Code Control: São ferramentas que agilizam o processo de unificar o local onde os códigos ficam, os mais conhecidos são: CVS, SVN e Source Control (MS).
E neste ambiente que os *diversos desenvolvedores constroem o código* e "comitam" ( o ato de jogar o código no servidor de código ) e testam. Obviamente a ferramenta mais utilizada neste local é um IDE (VS2008, Eclipse, Netbeans, DephiSuite ...) e o sistema de versionamento de códigos.
Ambiente de Homologação
O sistema vem pra esse ambiente quando já o mesmo já foi produzido e testado no ambiente de desenvolvimento. Esse ambiente pode ser entendido como *ambiente de testes finais*, antes de ir para o usuário gestor do sistema.
É comum neste ambiente *encontrar falhas*, criar um lista com check-list sobre os erros encontrados e repassar-los aos desenvolvedores, para *fix* (outro termo usado para designar o conserto de alguma falha).
O importante é notar que neste ambiente é *ótimo se os testadores forem externos ao desenvolvimento*, ou seja, outra equipe mesmo irá homologar (o ato de certificar que o software está bom para ir para prateleira) o software, usar a mesma pessoa que desenvolve para homologar pode induzir a falhas terríveis.
Algumas empresas de código fechado, neste ambiente não há como ver o código fonte.
Produção
Aqui o produto já está na mão do usuário final, já está em uso oficial, importante notar aqui se todos os comentários de DEBUG foram limpados do código, se todos os dados fictícios de testes foram removidos, se as senhas para acesso ao SGBD foram trocadas, enfim *aqui é sistema final*.
Versões e nomenclaturas
Quando estamos a procura de um software nos preocupamos com várias coisas como qualidade, quem produziu se o mesmo é grátis, de código fonte, pago...
Muitas vezes nos deparamos com produtos com alguns sufixos como M, B, RV, RC...
Para o entendimento dessas diversas siglas utilizaremos um exemplo simples um sistema de gestão de RH, conhecido como OpenRh.
Se tiver:
*OpenRh.1.0.0.1A * - Significa que o software ainda é Alfa. (testes internos com os testadores da empresa)
*OpenRh.1.0.0.1B* - Significa que o software ainda é Beta. (testes externos com os usuários finais)
*OpenRh.1.0.0.1RC* - Significa que o software é o Release Candidate. (Provável versão final, uma após a B)
*OpenRh.1.0.0.1* - Significa que o software é o final. (Também conhecido como de produção ou ainda stable)
ps: as vezes utiliza-se algumas nomenclaturas como .final ou .stable para definir que o software já está pronto para o mercado.
Para entusiastas ainda há a possibilidade de adquirir software enquanto estão em ambiente de desenvolvimento.
*OpenRh 2.0.0M1* - Significa que o software que teve alguma mudança significativa e assim foi feito um Marco esse marco normalmente é numerado logo pode se ter M1 M2 M3... (Milestone)
*OpenRh 2.0.0R301* - Significa que o software está na revisão 301 no repositório de códigos, aqui a cada commit o usuário (mais fanático) pode testar software feito no dia.
Obviamente esses nomes podem sofrer algumas alterações mas o sentido continua o mesmo.
Ps: Também há o .src que é exatamente o código fonte do projeto em questão.
Conclusão
A principio parece mais burocracia ao desenvolvimento de sistema, todavia as grandes empresas tem notado em experiências sólidas que o uso de diversos ambientes reduzem e muito a quantidade de erros que os sistemas poderiam ter ao serem lançados.
Questões gerenciais ficam bem facilitas com o uso de diversos ambientes. O uso de um repositório de código hoje é essencial, necessário. Seguir boas práticas que grandes empresas seguem pode tornar seus problemas mais gerenciáveis, estar preparado para mudança é o rumo da T.I.
Texto: Autor desconhecido.
Há uma prática difundida em projetos de software no mundo todo, o uso de diversos ambientes para a construção de sistemas. Em resumo funciona assim, o sistema é construído num *Ambiente de Desenvolvimento*, passa para um *Ambiente de Homologação* e finalmente vai pra *Produção*.
Um ambiente pode ser entendido como um local físico no computador (uma pasta ou computador) mais um conjunto de softwares auxiliares para execução do produto(software). Nesse ambiente é que fica os aplicativos necessários para que aplicação seja executada. Por exemplo: um projeto web feito em asp, normalmente utiliza os seguinte aplicativos: o servidor web IIS, um SGBD qualquer e os arquivos .asp; num projeto web para Java necessita de um container web, um SGBD, a JVM e os códigos(.class, .jsp). O importante é notar que estes aplicativos devem estar em todos ambientes e com as mesmas versões, para que o desenvolvimento seja eficaz, executável e testável em todos ambientes. A replicação de estrutura entre os ambientes.
Ambiente de Desenvolvimento
Quando se desenvolve (código mesmo) ou dá manutenção nas aplicações de uma empresa usa-se o ambiente de desenvolvimento. Nesse ambiente é que fica o código em desenvolvimento que pode ser testado também, ou seja, gerá código executável (não exe, mas no sentido de código funcional).
Existem vários elementos que fazem parte desse ambiente um deles é o...
Source Code Control: São ferramentas que agilizam o processo de unificar o local onde os códigos ficam, os mais conhecidos são: CVS, SVN e Source Control (MS).
E neste ambiente que os *diversos desenvolvedores constroem o código* e "comitam" ( o ato de jogar o código no servidor de código ) e testam. Obviamente a ferramenta mais utilizada neste local é um IDE (VS2008, Eclipse, Netbeans, DephiSuite ...) e o sistema de versionamento de códigos.
Ambiente de Homologação
O sistema vem pra esse ambiente quando já o mesmo já foi produzido e testado no ambiente de desenvolvimento. Esse ambiente pode ser entendido como *ambiente de testes finais*, antes de ir para o usuário gestor do sistema.
É comum neste ambiente *encontrar falhas*, criar um lista com check-list sobre os erros encontrados e repassar-los aos desenvolvedores, para *fix* (outro termo usado para designar o conserto de alguma falha).
O importante é notar que neste ambiente é *ótimo se os testadores forem externos ao desenvolvimento*, ou seja, outra equipe mesmo irá homologar (o ato de certificar que o software está bom para ir para prateleira) o software, usar a mesma pessoa que desenvolve para homologar pode induzir a falhas terríveis.
Algumas empresas de código fechado, neste ambiente não há como ver o código fonte.
Produção
Aqui o produto já está na mão do usuário final, já está em uso oficial, importante notar aqui se todos os comentários de DEBUG foram limpados do código, se todos os dados fictícios de testes foram removidos, se as senhas para acesso ao SGBD foram trocadas, enfim *aqui é sistema final*.
Versões e nomenclaturas
Quando estamos a procura de um software nos preocupamos com várias coisas como qualidade, quem produziu se o mesmo é grátis, de código fonte, pago...
Muitas vezes nos deparamos com produtos com alguns sufixos como M, B, RV, RC...
Para o entendimento dessas diversas siglas utilizaremos um exemplo simples um sistema de gestão de RH, conhecido como OpenRh.
Se tiver:
*OpenRh.1.0.0.1A * - Significa que o software ainda é Alfa. (testes internos com os testadores da empresa)
*OpenRh.1.0.0.1B* - Significa que o software ainda é Beta. (testes externos com os usuários finais)
*OpenRh.1.0.0.1RC* - Significa que o software é o Release Candidate. (Provável versão final, uma após a B)
*OpenRh.1.0.0.1* - Significa que o software é o final. (Também conhecido como de produção ou ainda stable)
ps: as vezes utiliza-se algumas nomenclaturas como .final ou .stable para definir que o software já está pronto para o mercado.
Para entusiastas ainda há a possibilidade de adquirir software enquanto estão em ambiente de desenvolvimento.
*OpenRh 2.0.0M1* - Significa que o software que teve alguma mudança significativa e assim foi feito um Marco esse marco normalmente é numerado logo pode se ter M1 M2 M3... (Milestone)
*OpenRh 2.0.0R301* - Significa que o software está na revisão 301 no repositório de códigos, aqui a cada commit o usuário (mais fanático) pode testar software feito no dia.
Obviamente esses nomes podem sofrer algumas alterações mas o sentido continua o mesmo.
Ps: Também há o .src que é exatamente o código fonte do projeto em questão.
Conclusão
A principio parece mais burocracia ao desenvolvimento de sistema, todavia as grandes empresas tem notado em experiências sólidas que o uso de diversos ambientes reduzem e muito a quantidade de erros que os sistemas poderiam ter ao serem lançados.
Questões gerenciais ficam bem facilitas com o uso de diversos ambientes. O uso de um repositório de código hoje é essencial, necessário. Seguir boas práticas que grandes empresas seguem pode tornar seus problemas mais gerenciáveis, estar preparado para mudança é o rumo da T.I.
Texto: Autor desconhecido.
quarta-feira, 13 de fevereiro de 2008
Bom link para ler...
Muito tempo sem postar nada. Venho com apenas um link parar o novo Livro de Martin Fowler - DSL (WIP).
Assinar:
Postagens (Atom)