Skip to content

Instantly share code, notes, and snippets.

@klauswuestefeld

klauswuestefeld/gist:1207171

Created September 9, 2011 19:59
Show Gist options
  • Save klauswuestefeld/1207171 to your computer and use it in GitHub Desktop.
Save klauswuestefeld/1207171 to your computer and use it in GitHub Desktop.
Download ZIP
O Verdadeiro Bazar
We couldn’t find any files to show.
@klauswuestefeld
Copy link
Author

"Klaus, ainda não entendi como isso [o novo compartilhamento de código P2P do Sneer]
vai ajudar um programador ou um arquiteto por exemplo, pode citar um exemplo?"

Vários momentos:

-4) Antiguidade: Pioneiros da computação compartilhavam programas e snippets de código ad hoc.

-3) Idade das Trevas: O grosso do software utilizado pelas pessoas era proprietário, publicado por empresas.

-2) Renascença: Shareware e Software Livre.

-1) Semana de Arte Moderna: SourceForges e GitHubs da vida.

  1. Momento atual. Não é praticável compartilhar mudanças em projetos de software direto com os amigos, sem passar pelos faraós. A dificuldade e o overhead de se empacotar, compartilhar e referenciar cada projeto/componente de software no IDE+Maven+Github+Jira+Hudson requer q eles sejam grandes.

0.1) Com o advento do compartilhamento de código P2P do Sneer ou qq um dos vários projetos de computação soberana, passa a ser praticável compartilhar mudanças de software direto com os amigos, sem faraós. Ainda é difícil fazer isso. Terra de pioneiros. A cultura de compartilhamento distribuído legada do git, por repositório, ainda tem granularidade grossa demais. Testes automatizados ainda não são regra no mercado. Design-by-contract ainda é alquimia somente para iniciados. O repositório git médio ou o pacote Linux médio contém algo tipo "sistema de câmbio do Vectra GLX" q é grande e complexo demais pra compartilhar, não encaixa direito em outros carros sem altas marretadas. Coisas como OSGi e Maven se preocupam com controle de dependências e assemblies .NET são um avanço em relação aos jars. Mas o Maven, por exemplo, não resolve direito incompatibilidades de dependencias em Y: pega a versao mais nova das duas dependencias declaradas e reza pra q dê certo. Tooling ainda é rudimentar. Pior: ainda é necessário. OSGi é usado por pouquissimos projetos por ser fantasticamente burocratico e XML-ridden. Ainda é bem diferente, imprevisível rodar sistemas no ambiente de produção ou direto da IDE.

  1. As pessoas começam a quebrar os "sistema de câmbio do Vectra GLX" em coisas menores e mais reutilizáveis tipo "Câmbio Para Chevrolet" + "Encaixe para Vectra GLX". Um monte de pessoas refaz esse mesmo trabalho. Uma pancada desses componentes morre. Quanto maiores e mais complexos, tanto maior a chance de morrerem, serem alterados, serem forkados, serem predados e despedaçados em componentes menores.

  2. Começam a emergir novos modelos de componentes e dependências: os "Mavens", os "OSGis", os ".NET Assemblies", os "Bricks", os "Gems", os containers do futuro: sem burocracia, sem trocentos XMLs. Os próprios modelos/containers de componentes passam por uma seleção feroz. O segredo está em conseguir compor componentes de granularidade cada vez mais fina.

  3. Quanto menores e mais coesos os componentes, maiores as chances de sobreviverem e se popularizarem. São as coisinhas q se manifestavam em 2011 ainda como snippets de código nas respostas dos fóruns ou em mega-toolboxes excludentes (escolheu uma não pode usar outra) tipo JRE ou CLR, que vem com um milhao de pecinhas das quais vc usa meia dúzia. Chegamos finalmente no nível do "parafuso", do "cabo elétrico", do "rolamento" reutilizável e da "caixa de câmbio" genérica.

Vários ambientes e modelos já surgiram visando esse santo graal da componentização: Objetos, CORBA, COM/DCOM, etc. Não vai ser um avanço técnico isolado que vai finalmente trazer sucesso mas a pressao evolutiva brutal da necessidade de milhões de pessoas de compartilharem pedaços de software com seus amigos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment