AgileAndArt

OOPSLA

Em 1985, um grupo de 4 pioneiros em programação orientada a objetos decidiu organizar nos EUA uma conferência sobre programação de sistemas orientados a objetos. No grupo estavam Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock, e a conferência foi chamada de OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications). A primeira OOPSLA aconteceu no Hotel Marriott, em Portland, Oregon, em novembro de 1986. Cerca de 600 pessoas participaram, 50 artigos foram apresentados e os participantes ouviram sobre Smalltalk, Lisp, Flavors, CommonLoops, Emerald, Trellis/Owl, Mach, Prolog, ABCL/1, prototypes, e programação concorrente e distribuída de pessoas como Danny Bobrow, Gregor Kiczales, Rick Rashid, Andrew Black, Dave Ungar, Henry Lieberman, Ralph Johnson, Dan Ingalls, Ward Cunningham, Kent Beck, Ivar Jacobson e Bertrand Meyer.

Essa gama enorme de tópicos e pesquisadores definiu o tom da conferência, que se tornou forum para alguns dos principais desenvolvimentos de software das últimas duas décadas. Foi na OOPSLA que nasceram coisas como cartões CRC, CLOS, Padrões de Projeto (Design Patterns, Self, métodos ágeis, arquiteturas orientadas a serviço (SOA), wikis, UML, TDD, refatoração, Java, compilação dinâmica, programação orientada a aspectos, só para citar algumas delas. Nem sempre falando sobre objetos, mas nunca deixando o assunto de lado, a conferência cresceu de 600 para 2500 participantes no seu pico, sendo ainda forte com cerca de 1300 pessoas mesmo depois do surgimento de uma série de conferências sobre padrões, Eclipse, EclipseCon, Agile e AOSD.

No final dos anos 90 – com o sucesso de Smalltalk e Java nos negócios e C++ na engenharia – OO se tornou amplamente adotada e a OOPSLA mudou de uma conferência que trabalhava para tornar OO prático e compreensível para trabalhar nos problemas do mundo sempre mutante da computação, tanto na inventando novas técnicas e tecnologias quanto melhorando e expandindo teorias. O que permaneceu foi a paixão por inovação e o hábito de criar comunidades.

Onward!

No começo dos anos 2000, algumas pessoas da OOPSLA sentiram que a conferência se beneficiaria muito se fosse criada uma nova trilha de publicação de artigos focados em ideias inovadoras além de OO, e em formatos de artigos que normalmente não seriam aceitos na OOPSLA. Nasce então a Onward!, coordenada por Richard Gabriel. Onward! foi a primeira conferência patrocinada pela ACM a dar voz a “artigos ideias” no âmbito da aceitação acadêmica. Muitas outras conferências seguiram esse modelo depois.

SPLASH

Na metade dos anos 2000, ficou claro que a estrutura de organização da OOPSLA e Onward jutas precisavam ser refatoradas, não apenas para que ambas existissem ao mesmo tempo, mas também para fornecer a possibilidade de incluir novas trilhas de artigos, mantendo a conferência nova e moderna. Depois de vários debates entre as comunidades, ficou finalmente decidido criar um guarda-chuvas de conferências: assim nasceu a SPLASH, a conferência da ACM em Sistemas, Programação, Linguages e Aplicações: Software para a Humanidade.

Desde 2010, a SPLASH tem mantido e administrado a OOPSLA, Onward! e uma variedade de outros eventos, como o Simpósio de Educadores, Workshop de Experiências, Painéis, etc. OOPSLA é hoje “apenas” a trilha técnica de artigos de pesquisa de alta-qualidade, que foi desde o início o coração desse conferência. Ao mesmo tempo, a OOSPLA aumentou o escopo de tópicos muito além de OO, aceitando hoje uma enorme variedade de artigos relacionados a programação. Ao criar a SPLASH como um guarda-chuvas de conferências, a comunidade pode agora sustentar novas trilhas de artigos que eventualmente não cabem na OOPSLA, mas que ainda sim são relacionados. Assim, permite-se o espaço para inovação, assim como aconteceu com a Onward!

E eu com isso?

Esse ano (2011), eu terei o privilégio de participar da SPLASH pela primeira vez (algo que eu já gostaria de ter feito há bastante tempo

A SPLASH tem um programa de Estudantes Voluntários, onde nós, estudantes, podemos participar da conferência de graça em troca de algumas horas de trabalho para ajudar na organização. Eu me inscrevi nesse programa de estudantes voluntários e fui aceito.

Além disso, eu tive dois artigos aceitos: um na Onward! e outro na PLoP (outra conferência que faz parte do guarda-chuvas da SPLASH). Para esses dois artigos, participarei do que eles chamam de Writers Workshop (Workshop de Escritores). O objetivo é trabalhar durante várias horas junto com os maiores (acreditem, são os maiores mesmo!) especialistas da área e anotar sugestões de melhorias para os artigos, que posteriormente farão parte das publicações científicas da conferência. Acima de tudo, é uma oportunidade maravilhosa de aprender muito e conhecer muita gente legal.

Depois que os artigos ficarem prontos (e bem melhorados após os comentários das pessoas na conferência) eu publico aqui nesse Blog.

Próximos passos

Ao longo da próxima semana, farei (na medida do possível alguns posts aqui nesse blog contando um pouco mais sobre essa conferência incrível. Farei, como de costume, várias fotos e, talvez, alguns vídeos. Dessa forma, consigo compartilhar um pouquinho dessa experiência quem não pôde ir desta vez!

Nesse vídeo eu mostro as principais vantagens do uso de Injeção de Dependência e Testes com Dublês (Stubs, Mocks, Fake Objects, Spy, Dummy Objects).

Vídeo

Slides

Transcrição

Injeção de Dependência e Testes com Dublês

1. Conteúdo• Exemplo• Injeção de Dependência (DI)• Testes com Dublês (Doubles)
2. Exemplo
3. Continuando o Exemplo• Criando interface
4. Dependência• PhoneLister depende da interface e da implementação• Como depender somente da interface?
5. Idéia Básica – Injeção Injeção Framework Injeção de Dependência
6. Tipos de Injeção• Injeção Por Construtor
7. XML
8. Usando na aplicação
9. Fábrica de Objetos• Singleton – Instância única compartilhada do objeto – Uso padrão, mais comum – Objetos de serviço sem estado (stateless)• Protótipos – Cada chamada cria um novo objeto• Escopos de Objetos Customizados – Objetos armazenados fora do controle do container (ex: request, session em uma aplicação Web)
10. Fábrica de Objetos
11. Vantagens de usar Injeção de Dependência• Ajuda a escrever código que é fácil de testar: é só criar objetos e atribuir as propriedades desejadas usando os setters• Facilita boas práticas de programação: uso de interfaces no lugar de classes• Não envasivo: o código do sistema depende o mínimo possível da API do Framework• Dependências são explícitas e evidentes• Como os componentes não precisam procurar colaboradores em tempo de execução, o código fica mais fácil de escrever e manter
12. Frameworks para todas as linguagens• Java – Spring, PicoContainer, HiveMind• PHP – DIContainer• .NET – Spring.NET, PicoContainer.NET• Python – PyContainer, Spring Python• Ruby – Needle• Perl – IOC Module• Flex – Flicc• mais em http://en.wikipedia.org/wiki/Dependency_injection
13. DI – Linha do Tempo
14. Construtor ou Setter?• Construtor com parâmetros deixa claro o que é preciso para criar o objeto• Usando construtor evita campos imutáveis de serem alterados• Cuidado: construtores com muitos parâmetros podem ser um indicativo de objeto com responsabilidades demais• Construtor é ruim se tiver parâmetros simples como Strings: com setter você cria um método que identifica o que a string significa• Receita geral: comece com construtor e mude para setter se a coisa ficar complicada demais
15. Testes com Dublês (Doubles) DoubleDummy Stub Spy Mock FakeObject
16. Dummy Object• Objetos que nunca são usados, só servem para preencher parâmetros
17. Stub• Provê alguns dados estáticos que serão usados nos testes• Não funciona para outras coisas além do que está no teste
18. Spy• Muito parecido com Stub, mas com a diferença de que “grava” algumas coisas
19. O que são Mock Objects? Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. “Pintside Thoughts: Mock Objects History” —Tim McKinnon
20. O que são Mock Objects?• Cada pessoa entende de um jeito diferente• Terminologia ambígua• Ficou famoso inicialmente na comunidade JAVA & TDD Comportamento Estado testa interação entre testa o resultado dessas objetos interações
21. Código Mock
22. Fake Object• Têm uma implementação completa, mas simples• Não vai para produção• Exemplo: banco de dados em memória 23
23. Mocks nas Linguagens• Java – EasyMock, JMock, Mockito• Ruby – Mocha, RSpec?• .NET – NMock, Rhino Mocks• Perl – Test::MockObjects• C++ – Google Mocks• PHP – Simple Test for PHP
24. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Preenche parâmetros
25. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Preenche dados para parâmetros os testes
26. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Preenche dados para dados eparâmetros os testes grava
27. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Preenche dados para dados e comporta-parâmetros os testes grava mentos
28. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Implemen- Preenche dados para dados e comporta- taçãoparâmetros os testes grava mentos +simples
29. QuizDublês + Injeção de Dependência = Testes
30. Referências
    http://www.springframework.org/documentation
    http://martinfowler.com/articles/injection.html
    http://martinfowler.com/articles/mocksArentStubs.html
    http://xunitpatterns.com/
    Anil Hemrajani, Agile Java Development with Spring, Hibernate and Eclipse

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures

Here are the slides the presentation slides about Ruby Robots I gave in RsOnRails

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

Palestrante: Prof.Dr. Giorgio Moscati

Horário: 16 horas

Resumo: Uma contribuição inovadora da USP nas suas origens, em 1969, em colaboração com o renomado Artista Concretista Waldemar Cordeiro participei de uma rica experiência em Arte Digital, que foi logo reconhecida por especialistas internacionais como inovadora, e continua sendo amplamente citada até hoje. Pretendo relatar nossa colaboração, sua receptividade pelos artistas e a relação que tem com diversas áreas da Ciência, Arte e Tecnologia. O trabalho foi inovador no campo das tecnologias de comunicação visual, pois é considerado um dos primeiros trabalhos que envolveu processamento de imagem num novo nível, que hoje é a base da comunicação visual na televisão, e nas imagens apresentadas para o lazer e marketing. Foi também precursor no campo da análise de informações obtidas na forma de imagens e para sua interpretação. Outro aspecto importante, frequentemente lembrado é o da potencialidade da colaboração entre  especialistas em áreas diversas, capazes de se comunicar e interagir, em abordagens inovadoras em campos anteriormente inexplorados.

Abstract: In 1969, in collaboration with the well known Concrete Artist Waldemar Cordeiro I was involved in a very interesting and rich experience in Digital Art that was at once recognized by international experts as innovative and is up to theese days widely cited. I intend to talk about our collaboration, its receptivity by artists in general and the computer art community, and its relation with art, science and technology. The results were considered innovative in the area of visualcommunication since it is considered as one of the first examples of image processinga a new level and nowadays is widely used in visual communication in TV and images presented for laisure and entertainment and marketing. The wok is also considered  a precursor of now widely used instruments for extracting/enhancing important informations hidden in scientific, medical, natureand other images, helping in understanding their possible important messages. Another importand aspect of this collaboration has been noted as an example of the potenciality of the collaboration of specialist of different areas, that succede in talking with each other, in finding innovative approaches in areas previously unexplored.

Bio:

Giorgio Moscati se formou como Engenheiro Mecânico e Eletricista em 1957 e como Bacharel em Física em 1959 na Universidade de São Paulo.
Obteve o título de Doutor em Física naUSP em 1962. Foi Professor de Física na USP de 1958 a 1998, Professor Titula a partir de 1975.
Ocupou as seguintes funções: Chefe do Departamento de Física da Faculdade de Filosofia, Ciências e Letras FFCL, de 1968 a 1969.
Diretor Pró Trempore, responsável pela implantação do Instituto de Física da USP – IFUSP(Campus São Paulo) no início de 1970.
Chefe do Departamento de Física Experimetal do IFUSP em diversas ocasiões e Vice Diretor do Instituto Astronômico e Geofísico da USP de 1979 a 1982.
Research Associate contratado pela Universidade de Illinois (Campus de Urbana Champaign) de 1963 a 1966 (Fulbright travel Grant).
Pesquisador Visitante da Universidade de Liverpool ? UK de 1970 a 1971 (Queen Scholar).
Coordenador de Ciências Exatas e Naturais do Conselho Nacional de Pesquisas (CNPq) de 1981 a 1983.
Diretor de Metrologia Científica e Industrial do Instituto Nacional de Metrologia, Normalização e qualidade Industrial ?INMETRO de 1990 a 1991.
Membro brasileiro do Comitê Internacional de Pesos e Medidas ?CIPM, em Paris França de 1995 a 2007, tendo sido Vice Presidente do mesmo de 2002 a 2007 e Presidente do Comitê Consultivo de Radiações Ionizantes ?CCRI/CIPM, de 1995 a 2007.

Local: Auditório Jacy Monteiro, IME-USP
Rua do Matão, 1010
Cidade Universitária – São Paulo

I’ve just read an excellent article from the Harvard Business review magazine: “How Pixar Fosters Collective Creativity”. The article is written by Ed Catmull, the cofounder of Pixar and the president of Pixar and Disney Animation Studios. He describes how is the creation process of Pixar movies, and how this process changed and evolved since Toy Story, the first movie from Pixar.

There are some points in the article I’d like to highlight.

What is creativity

• Creativity involves a large number of people from different disciplines working effectively together to solve a great many problem
• A movie, like a software, is not only a single idea. Movies and softwares contains literally tens of thousands of ideas.
• The leaders sort through a mass of ideas (and possible designs in software) to find the ones that fit into a coherent whole, which is very difficult task
• What is the key to be able to recover from fail? Talented people! And such people are not easy to find. What is equally though, of course, is getting talented people to work effectively with one another

The roots of pixar culture

• Smart people are more important than good ideas
• It is OK to hire people who are smarter than you
• In the process of creating a new movie (software), the first versions are very rough, but they give a sense of what the problems are, which in the beginning are many. Then we have to iterate, and each version typically gets better and better.
• If you give a good idea to a mediocre team, they will crew it up; if you give a mediocre idea to a great team, they will either fix it or throw away and come up with something that works.
• Deeply ingrained in Pixar culture is that everything they touch needs to be excellent.

Power to the creatives and a peer culture

• Creative power in a film (software) has to reside with the film’s creative leadership
• The creative vision propelling each movie (software) comes from one ow two people and not from either corporate executives or a development department (this point is similar to what Fred Brooks says about conceptual integrity. I don’t completely agree with that. I also like Richard Gabriel’s vision, that there are many hidden co-authors and the things designed themselves)
• Good artists understand the value of limits. I completely agree with this. This makes me remember a phrase from my theater director. He said that “an actor has to have the German discipline with the Brazilian creativity both at the same time. Hot side with cold side”.
• Everything in Pixar is done by peer reviewing. This works because all the participants have come to trust and respect one another

Technology + Art = Magic

• Walt Disney believed that when continual change, or reinvention, is the norm in an organization and technology and art are together, magical things happen
• Showing unfinished work each day liberates people to take risks and try new things because it doesn’t have to be perfect the first time
• At Pixar, we believe in this swirling interplay between art and technology and constantly try to use better technology
• Technology inspires art, and art challenges the technology
• The most efficient way to deal with numerous problems is to trust people to work out the difficulties directly with each other

Common wisdom says that science and art are entirely different beasts; moreover, a similar source of wisdom tells us that science is valuable to society while art is a luxury. Why else would schools drop art from their curricula over the past 20 years? But artists and scientists approach their work in similar if not identical ways.

This presentation was created by Richard P Gabriel and presented at IME-USP – São Paulo on 31/Mar/2011 sponsored by CCSL

Richard’s Bio

Richard P. Gabriel (Ph.D., Stanford University, 1981; MFA Creative Writing (Poetry), Warren Wilson College, 1998; ACM Fellow) performs programming language, creativity, and software engineering research at IBM Research. He is the author of five books. He played lead guitar in a rock ‘n’ roll band for 20 years.