SOA Gerando Valor e Como Vender SOA na CriseDavi Silva
Difícil vender arquitetura orientada a serviços (SOA)? Mostre os benefícios tangíveis e intangíveis e o processo fica mais simples.
Objetivo: definição de SOA, como SOA pode gerar valor, uma arquitetura de referência e SOA e metodologia ágeis.
(atualizada em 13/Jul/2010)
SOA Gerando Valor e Como Vender SOA na CriseDavi Silva
Difícil vender arquitetura orientada a serviços (SOA)? Mostre os benefícios tangíveis e intangíveis e o processo fica mais simples.
Objetivo: definição de SOA, como SOA pode gerar valor, uma arquitetura de referência e SOA e metodologia ágeis.
(atualizada em 13/Jul/2010)
Pair Programming
Quality
more attention on errors, less bugs
More discussions on solutions
Gambiarras not allowed
Different perspectives and sources of information
Ownership
Truck Factor > 1
All team members know whats going on
No Single Point of Failure
Productivity
Pairs keep focus
People are more afraid to interrupt
Variations
expert-expert
expert-novice
novice-expert
Don't pair
Repetitive and non-thinking tasks
Competitive environments
People don’t want to share their knowledge
Management does not encourage the practice
Environment
1 computer, 2 monitors, 2 keyboards, 2 mouses
Rotate typer
Remote
Knowledge Sharing
I know, I teach
Develop patience
Develop communication skills
I don't know, I learn
Humbleness
Teaming
Everybody feels responsible
We built together, we solve together
95% more satisfaction
Shared goals
Technology Startups Ecosystem in China - Lessons to other ecosystemsDaniel Cukier
At the beginning of November 2016, I joined a group of 54 entrepreneurs delegation to meet Chinese startups. We had an intense week visiting companies such as Alibaba, Baidu, JD, etc, talking with entrepreneurs, investors and other ecosystem agents. Is there innovation in China? Can we consider that Chinese startups are successful? What does China represents to the futuro of technology development? What the Brazilian and other ecosystems can learn from this example? What went wrong? What went right? This slides bring some insights from this trip. They are an invite for debate about the role of the giant in the technological and economical international scene.
Software Startup Ecosystems Evolution - The New York City Case StudyDaniel Cukier
Startup ecosystems started to emerge in different parts of the world since the 2000s. They normally focus on specific areas and present different characteristics and dynamics. Also, each ecosystem has its own path of evolution over time. In this paper, we analyze the dynamics of these ecosystems by taking the New York case study as an example. We show what stages ecosystems pass through, the requirements for each of these phases and why it is possible for many ecosystems to evolve until reaching a self-sustainable level of maturity. This research can bring a better understanding of the evolution of software startup ecosystems and what role their actors play in this development. The results can be used as a basis for ecosystem stakeholders to reflect and act concretely on improving the maturity of their local environments.
Resulting from the technological revolution from the last decades, we observed many software startup ecosystems emerging around the globe. Having tech entrepreneurs as their main agents, some ecosystems exist for more than 50 years, while others are newly born. This difference in terms of evolution and maturity makes the task of comparing different tech hubs a challenge. Moreover, nascent ecosystems need a clear vision of how to develop their community to evolve towards a fruitful and sustainable ecosystem. This paper proposes a maturity model for software startup ecosystems based on a multiple case study of two existing ecosystems. By determining the maturity level for each ecosystem, it is possible not only to compare different realities, but mainly to identify gaps and propose customized practical actions that can lead to real improvements in the existing ecosystems, taking it to the next level of development, promoting innovation.
Pair Programming
Quality
more attention on errors, less bugs
More discussions on solutions
Gambiarras not allowed
Different perspectives and sources of information
Ownership
Truck Factor > 1
All team members know whats going on
No Single Point of Failure
Productivity
Pairs keep focus
People are more afraid to interrupt
Variations
expert-expert
expert-novice
novice-expert
Don't pair
Repetitive and non-thinking tasks
Competitive environments
People don’t want to share their knowledge
Management does not encourage the practice
Environment
1 computer, 2 monitors, 2 keyboards, 2 mouses
Rotate typer
Remote
Knowledge Sharing
I know, I teach
Develop patience
Develop communication skills
I don't know, I learn
Humbleness
Teaming
Everybody feels responsible
We built together, we solve together
95% more satisfaction
Shared goals
Technology Startups Ecosystem in China - Lessons to other ecosystemsDaniel Cukier
At the beginning of November 2016, I joined a group of 54 entrepreneurs delegation to meet Chinese startups. We had an intense week visiting companies such as Alibaba, Baidu, JD, etc, talking with entrepreneurs, investors and other ecosystem agents. Is there innovation in China? Can we consider that Chinese startups are successful? What does China represents to the futuro of technology development? What the Brazilian and other ecosystems can learn from this example? What went wrong? What went right? This slides bring some insights from this trip. They are an invite for debate about the role of the giant in the technological and economical international scene.
Software Startup Ecosystems Evolution - The New York City Case StudyDaniel Cukier
Startup ecosystems started to emerge in different parts of the world since the 2000s. They normally focus on specific areas and present different characteristics and dynamics. Also, each ecosystem has its own path of evolution over time. In this paper, we analyze the dynamics of these ecosystems by taking the New York case study as an example. We show what stages ecosystems pass through, the requirements for each of these phases and why it is possible for many ecosystems to evolve until reaching a self-sustainable level of maturity. This research can bring a better understanding of the evolution of software startup ecosystems and what role their actors play in this development. The results can be used as a basis for ecosystem stakeholders to reflect and act concretely on improving the maturity of their local environments.
Resulting from the technological revolution from the last decades, we observed many software startup ecosystems emerging around the globe. Having tech entrepreneurs as their main agents, some ecosystems exist for more than 50 years, while others are newly born. This difference in terms of evolution and maturity makes the task of comparing different tech hubs a challenge. Moreover, nascent ecosystems need a clear vision of how to develop their community to evolve towards a fruitful and sustainable ecosystem. This paper proposes a maturity model for software startup ecosystems based on a multiple case study of two existing ecosystems. By determining the maturity level for each ecosystem, it is possible not only to compare different realities, but mainly to identify gaps and propose customized practical actions that can lead to real improvements in the existing ecosystems, taking it to the next level of development, promoting innovation.
Why Google Cloud is so special? Stories from a cloud userDaniel Cukier
Hoje em dia temos muitas opções quando se trata de serviços e provedores de Cloud. Diante de tantas possibilidade, o que deveria simplificar a vida do time de tecnologia das empresas vira uma dor de cabeça. Qual a melhor nuvem? Qual a mais barata? Quais recursos eu perco ou ganho com determinado provedor? Se eu usar tal serviço, eu vou ficar preso a ele para sempre? Nessa palestra, Daniel contará sua experiência real utilizando várias nuvens, porque sua escolha atual de usar a Google Cloud e como usar seus recursos.
Introduction to Functional Programming with ScalaDaniel Cukier
Scala é uma linguagem funcional que roda na JVM. Ela possui todas as vantagens da programação funcional, com a vantagem de ser facilmente integrada com Java, além de possuir uma stack completa de desenvolvimento e deploy. Nessa palestra, daremos os primeiros passos para quem quer trabalhar com Scala. Falaremos de imutabilidade, Traits, funções e expressões lambda entre outros tópicos
O assunto startup está na moda no Brasil, principalmente nos últimos 2 anos. Mas como é de fato trabalhar numa startup? Vale a pena largar tudo para começar seu próprio negócio? O mundo de startup não só um mar de rosas não! Quais são os problemas que uma startup enfrenta? Como fugir das armadilhas? Como encontrar parceiros e investidores? Nessa palestra serão contados casos reais de startups, tanto de sucesso como de fracasso, bem como alguns aprendizados que foram acumulados.
Selecting Empirical Methods for Software EngineeringDaniel Cukier
Presentation on how to write good Master and PhD dissertations.
Empirical Methods, Software Engineering, science, computer science, software, methods, positivism, epistemology, onthology, construtivism, critical theory, pragmatism, case study, research action, ethnography
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.
Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the things designed themselves.
This presentation was created by Richard P Gabriel (www.dreamsongs.com) and presented at IME-USP - São Paulo on 30/Mar/2011 sponsored by CCSL (ccsl.ime.usp.br)
1. Uma introdução a
Domain Driven Design
Daniel Cukier
danicuki@ime.usp.br
IME-USP
quinta-feira, 26 de fevereiro de 2009
2. Padrões
Um padrão é uma regra de três partes que
expressa a relação entre um certo contexto1, um
problema 2 e uma solução 3
2
quinta-feira, 26 de fevereiro de 2009
3. O que é DDD
✦ Livro de Eric Evans (2004)
✦ Padrões
✦ Boas práticas
✦ Experiência
3
quinta-feira, 26 de fevereiro de 2009
4. Foco: Domínio
✦ Alinhamento com negócio
✦ Isolamento entre domínios
✦ Reutilização
✦ Mínimo acoplamento
✦ Independente de tecnologia
4
quinta-feira, 26 de fevereiro de 2009
5. DDD
A volta da Orientação a Objetos?
5
quinta-feira, 26 de fevereiro de 2009
6. Padrões no DDD
[Contexto.]
[Discussão do problema.]
Resumo do problema.
Discussão da solução.
Por esta razão:
Resumo da solução.
Conseqüências, implementação, exemplos.
[Contexto resultante.]6
quinta-feira, 26 de fevereiro de 2009
7. DDD
Colocando o
Blocos de
modelo de
construção do
domínio para
MDD
funcionar
Refatorando
para compreender Projeto
profundamente o estratégico
modelo
7
quinta-feira, 26 de fevereiro de 2009
8. Colocando o modelo
de domínio para
funcionar
quinta-feira, 26 de fevereiro de 2009
10. Model Driven Design
Domínio
guia
Modelo Refatoração Design
Desenvolvedores
Software não serve
perdidos e tecnologia
para o domínio
inadequada
aperfeiçoa
10
quinta-feira, 26 de fevereiro de 2009
11. Blocos de
Construção do
Model
Driven
Design
quinta-feira, 26 de fevereiro de 2009
12. Arquitetura em Camadas
Interface
de Usuário
Aplicação
Domínio
DDD
Infra-estrutura
12
quinta-feira, 26 de fevereiro de 2009
13. Entidades
13
quinta-feira, 26 de fevereiro de 2009
14. Objetos de Valores
✦ Pra quem não precisa de identidade
✦ Imutáveis
✦ Descrevem coisas
✦ Ciclo de vida rápido
✦ Exemplos: Strings, números, cores
14
quinta-feira, 26 de fevereiro de 2009
15. Agregados
Interface
Entidade
Agregado
Objeto de Objeto de
Entidade
Valor Valor
quinta-feira, 26 de fevereiro de 2009
16. Fábricas
✦ Quando construir (Agregados) for complexo
✦ Devem ser sempre abstratas
✦ Não fazem parte do modelo, mas do domínio
16
quinta-feira, 26 de fevereiro de 2009
17. Serviços
1. A operação não faz parte de nenhuma
Entidade ou Objeto de Valor
2. Interface fala a língua do Domínio
3. Sem estado
17
quinta-feira, 26 de fevereiro de 2009
18. Módulos
✦ Agrupe conceitos do modelo, não código
✦ Baixo acoplamento / alta coesão
✦ Nomes da Linguagem Ubíqua
Modelo = História
Módulo = Capítulo Módulo = Capítulo
Módulo = Capítulo Módulo = Capítulo
Módulo = Capítulo Módulo = Capítulo
18
quinta-feira, 26 de fevereiro de 2009
19. Repositórios
Código
b usca
Cliente
Repositório
cria Entidade
Agregados Agregados
Agregados
Agregados
Agregados
Entidades
mo ve
Entidades
Entidades
re
Entidades
Entidades
Entidades
19
quinta-feira, 26 de fevereiro de 2009
20. Linguagem Model
Ubíqua Driven Design
exp
ress
am
ode
nomes da lo c
omo
Módulos
Serviços
Objetos Entidades acess
o com
Valor
antémde
enc m
sula integrida Repositórios
ap
comsul ncapm
e co com
m la
a
co psu
ac
ca
es
en
ocs
om
Fábricas encapsula
com Agregados
20
quinta-feira, 26 de fevereiro de 2009
21. Refatorando
para compreender
profundamente
o modelo
quinta-feira, 26 de fevereiro de 2009
22. Interfaces de Intenção Revelada
Eu faço
exatamente isso.
Não precisa se
preocupar como
22
quinta-feira, 26 de fevereiro de 2009
23. Funções sem Efeitos Colaterais
✦ Colocar tudo que for possível em funções,
principalmente em cálculos complexos
✦ Onde não der, usar Comandos que fazem
poucas operações e não retornam objetos do
domínio
23
quinta-feira, 26 de fevereiro de 2009
24. Asserções
✦ Testes de unidade
✦ Usar facilidades da linguagem
✦ Testam o comportamento dos Comandos
24
quinta-feira, 26 de fevereiro de 2009
25. Linguagem Model
Driven Design
Ubíqua
dese expressa
n
usanhadas modelo
do através de
Interfaces
de Intenção
Revelada
torna efeitos
cria seguras colaterais
e simples explícitos com
Funções
sem Efeitos Asserções
Colaterais torna
composição
segura
quinta-feira, 26 de fevereiro de 2009
27. Contexto Delimitado
As células existem porque sua
membrana define o que está dentro ou
fora e determina o que pode entrar
27
quinta-feira, 26 de fevereiro de 2009
28. Integração Contínua
Testes
codificação
Novo
Elemento do
Modelo Implementação
✦ Testes automatizados
✦ Processo de build automático
✦ Sincronização diária
✦ Relatórios
28
quinta-feira, 26 de fevereiro de 2009
29. Mapa do Contexto
Modelo no Mapa de
Contexto Modelo no
Tradução
Contexto
29
quinta-feira, 26 de fevereiro de 2009
30. Núcleo Compartilhado
Compartilhado
Mapa de
Tradução
✦ É mais difícil fazer mudanças
✦ Evita (mas não elimina) duplicações
30
quinta-feira, 26 de fevereiro de 2009
31. Produtor-Consumidor
✦ Testes automatizados
✦ Cliente-Fornecedor
31
quinta-feira, 26 de fevereiro de 2009
32. Conformista
✦ Time fornecedor não tem interesse em ajudar
✦ Tira complexidade de tradução entre contextos
✦ Mesma linguagem ubíqua
✦ Parecido com Núcleo Compartilhado, mas
cliente não tem poder de modificação
32
quinta-feira, 26 de fevereiro de 2009
33. Camada Anti-corrupção
Seu sistema Camada Anti-corrupção Outro Sistema
Classe Serviço Adaptador Interface
elegante A A complicada
Outras coisas Tradutor 1 Coisas
bem feitas irrelevantes
Fachada
Classe
Classe cara Tradutor 2 bagunçada
Ok, isso a Serviço Adaptador Você nem
gente tem que B B quer saber
refatorar
33
quinta-feira, 26 de fevereiro de 2009
34. Caminhos Separados
✦ Quando integrar custa caro e o benefício é
pequeno
✦ Contexto delimitado que não tem nenhuma
conexão com os outros
34
quinta-feira, 26 de fevereiro de 2009
35. Resumindo
1. Trabalhando com um modelo
2. Blocos de construção
3. Refatorando e evoluindo
4. Refinando, destilando
35
quinta-feira, 26 de fevereiro de 2009
37. Núcleo Serviço de
Linguagem Contexto Integração
Conformista Compar- Hospedagem
Publicada Delimitado Contínua
tilhado Aberto
Camada Interfaces de Model
Contornos Linguagem Arquitetura Mapa do
Anti- Intenção Driven
Conceituais Ubíqua em Camadas Contexto
corrupção Revelada Design
Fechamento Funções sem
Caminhos Núcleo Núcleo Objetos de
de Efeitos Entidades
Separados Abstrato Segregado Valores
Isso não é tudo
Operações Colaterais
Classes Subdomínios Núcleo do Mecanismos
Asserções Serviços Módulos
Isoladas Genéricos Domínio Coesivos
Nível de Sentença da
Ordem Núcleo
Conheci- Visão do Agregados Fábricas
que Evolui Destacado
mento Domínio
Arcabouço Camadas de
Metáfora
Componente Responsa- Repositórios
de Sistema
Plugável bilidade
quinta-feira, 26 de fevereiro de 2009
38. Referências
✦Evans, Eric - Domain Driven Design, Addison-
Wesley - 2004
✦http://www.infoq.com/resource/minibooks/
domain-driven-design-quickly/en/pdf/
DomainDrivenDesignQuicklyOnline.pdf
38
quinta-feira, 26 de fevereiro de 2009