How to attract talents to your Startup?

Long term purpose instead of money

Differentiate from big companies to attract talents.

Work tableWhen I started Playax with my partner Juliano, we did not have money to pay high salaries for tech talent in São Paulo, one of the most expensive cities in Brazil. Our startup was a high-tech innovative platform in the music industry, so we needed the best developers to create complicated algorithms. On a first try, we offered bellow average salaries, but even if some developers were interested in the company’s challenges, they did not accept the job. When we started to offer equity, we attracted exactly the people we wanted to our team: people with passion and long-term commitment with the company. Moreover, people willing to give up high salaries in exchange of being part of the company’s construction and purpose. 

Continue reading

DevOps patterns to scale web applications using cloud services

This article was accepted to publication at SPLASH 2013Wavefront Experience track.

Scaling a web applications can be easy for simple CRUD software running when you use Platform as a Service Clouds (PaaS). But if you need to deploy a complex software, with many components and a lot users, you will need have a mix of cloud services in PaaS, SaaS and IaaS layers. You will also need knowledge in architecture patterns to make all these software components communicate accordingly.

In this article, we share our experience of using cloud services to scale a web application. We show usage examples of load balancing, session sharing, e-mail delivery, asynchronous processing, logs processing, monitoring, continuous deployment, realtime user monitoring (RUM). These are a mixture of development and system operations (DevOps) that improved our application availability, scalability and performance.
Continue reading

Domain Driven Design em Teatro

Apresentamos hoje na Agile Brasil a peça de teatro sobre “Domain Driven Design”, com algumas melhorias desde a última versão. Quem quiser, pode conferir o roteiro aqui. Mais uma vez, fizemos uma música bacana, um Xote! Segue a letra da música e abaixo o roteiro, que está no git:

Xote do DDD

Sou consultor, estrategista sou doutor
Te pergunto seu cliente:
quem é teu fornecedor?
Se não existe tua sina é conformista
Dessa equipe a minha vista
Tu depende sim sinhô

Dê Dê Dê
Não resolve os problemas,
Mas ajuda a entender

Dê Dê Dê
Só clareia as perguntas
que você vai responder
Continue reading

Software Developers Retreat (dia 3)

O terceiro dia do nosso retiro de desenvolvedores acabou!

Standup Meeting

Standup Meeting

O sol estava brilhando e bateu forte na nossa janela. Como o pessoal tinha ido dormir um pouco mais tarde, também acabamos acordando um pouco mais tarde. Como de costume, fizemos nosso standup meeting as 11h. A moça que contratamos para limpar a casa e cozinhar não veio nesse dia. Acabamos tendo que dar um jeito com as tarefas da casa. Continue reading

PLoP – A conferência de padrões

PLoP Portland História

Em agosto de 1993, Kent Beck e Grady Booch patrocinaram um retiro na montanha, onde um grupo de pessoas chegou a um consenso sobre os fundamentos em padrões de software. Ward Cunningham, Ralph Johnson, Ken Auer, Hal Hildebrand, Grady Booch, Kent Beck e Jim Coplien se basearam fortemente nas ideias de Alexander e suas próprias experiências, formando um casamento entre objetos e padrões. O grupo concordou que estávamos prontos para construir, sobre as fundações do trabalho de Erich Gamma sobre padrões orientados a objetos, e usar esses padrões da mesma forma que Christopher Alexander usa seus padrões para planejamento urbano e construções arquitetônicas. O encontro do grupo se deu ao lado (side) de um monte (hill), daí o nome Hillside.

Continue reading

SPLASH (antiga OOPSLA)

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.

Continue reading

DDD – Introdução a Domain Driven Design

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage,  uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software utilizando técnicas de Orientação a Objetos. O que seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um contexto (1), um problema (2) e uma solução (3).

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk. Quando se fala em Orientação a Objetos pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da Orientação a Objetos também tem coisas como:

  • Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do domínio é algo essencial quando se faz DDD (o pessoal de métodos ágeis já sabe disso faz tempo);
  • Favorecer reutilização: os blocos de construção, que veremos adiante, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares;
  • Mínimo de acoplamento: Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos;
  • Independência da Tecnologia: DDD não foca em tecnologia, mas sim em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia usada não seja importante, mas essa não é uma preocupação de DDD.

Todas essas coisas são bem exemplificadas e mostradas na forma de vários padrões em DDD. Mas o livro também mostra muitos padrões que não dizem respeito a código ou modelagem. Aparecem coisas que estão mais ligadas a processos (como Integração Contínua) ou a formas de relacionamento entre times que fazem parte do desenvolvimento de um sistema complexo. Eric Evans dividiu o livro em quatro partes, que apresentaremos a seguir.

Continue reading