sábado, 29 de agosto de 2015

WebSocket. Una visión general.


Hace unos minutos tuve el gusto y honor de terminar mi presentación en el JavaDayMX 2015 realizado en la ciudad de Guadalajara, México.

El instituto tecnológico de estudios superiores de occidente. (ITESO) fue la sede de este evento.

Esta ocasión decidí hablar sobre websocket's, un tema que si bien no es nuevo, sí es poco conocido aún, y, desde mi perspectiva una tecnología con mucho futuro (sí, también con muchos retos pero con futuro).

La presentación la hice con remark, y aquí está en link para que puedan verla:


Espero les sea de utilidad.
:)

---
@RuGI

lunes, 17 de agosto de 2015

[3 de 97]. Controlar os dados, não só ao código.

“Control the data, no just the code.”




Eli diz (extraído do livro  "97 things Every Software Architech Should Know"):


---
Control de data, no just de code.
Source code control and continuous integration are excellent tools for managing the application build and deployment process. Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls. If your build and deployment process includes a list of elaborate steps required for data updates, beware.


....


Database changes shouldn’t create a ripple in your build’s time-space continuum. You need to be able to build the entire application, including the database, as one unit. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends. At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.
---


Eu acho que antes a gente  não dava muita importância ao banco de dados (a partir da nossa  perspectiva de desenvolvedor), porque era uma tarefa, no melhor dos casos entediante, e na pior das hipóteses muito complexa para explicar aos clientes.


Mas à medida que nós participamos em projetos, descobrimos que o sucesso desses projetos começa com uma boa definição da camada de dados.


Também, conforme têm evoluído as metodologias e técnicas para o desenvolvimento e integração dos aplicativos, e com o advento dos métodos ágeis, eu acho que chegou a hora de dar aos bancos de dados o seu devido lugar na foto.


Um dos meus piores pesadelos sempre foi o de atualizar  uma tabela (parâmetro) e ao fazer COMMIT perceber que eu esqueci a cláusula WHERE,
Uma catástrofe !!!


Felizmente, ter um script para preencher inicialmente as tabelas de configuração sempre dão a tranquilidade de saber que você pode voltar ao último “estado correto”.


E esses scripts não estão sozinhos, temos também scripts para:
  • Criar / Apagar tabelas.
  • Criar / Apagar procedimentos armazenados (store procedures).
  • Criar / Apagar sequências
  • etc, etc.


E há um tipo de script que sempre fica no esquecimento: os scripts de migração ou de backup do banco de dados.


Se você ainda não esteve em uma conferência por telefone onde todo mundo está à beira da histeria, porque ninguém sabe o que faltou ao migrar para a nova e brilhante base de dados recém adquirida (por muitos milhares em $), leve sempre em conta a seguinte pergunta:


>>> Cara,  será que você não se esqueceu de migrar os store-procedure e  os triggers?


Se isso realmente acontecer, haverá um grande silêncio.
E o gerente de plantão dirá:
>>> Bem, vamos rever isso e, em seguida, a gente te liga.


Essa ligação nunca chega ;)


Enfim de volta ao ponto de partida, nestes tempos em que necessitamos ser mais ágeis, é uma boa ideia considerar essas estratégias para ter um pouco mais de controle sobre o nossos aplicativos e  criar um ambiente de desenvolvimento mais saudável e menos estressante .


Depois de tudo isso, só resta uma dúvida:


Você levou em conta os scripts de dados para fornecer uma solução integral para as suas aplicações?


Saudações!!


---


----------------------------------------------------- Autor da foto acima: brunociampi https://www.flickr.com/photos/brunociampi/2745217216
------------------------------------------------------

sábado, 1 de agosto de 2015

[2 de 97]. Comece com um esqueleto funcional.

“Start with a walking skeleton”.

Clint Shank


Seguindo os comentários do livro:
97 things Every Software Architech Should Know.

---
Start with a walking skeleton.

One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a Walking Skeleton . A Walking Skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it's time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.
---

Esta estratégia é uma das minhas favoritas, especialmente para integrações muito complexas ou que tenham uma média ou grande equipe  de desenvolvedores.

Concordo plenamente com o comentário de Clint Shank, em pequenos desenvolvimentos uma pessoa pode fazer tudo da sua própria maneira e não precisa  desse tipo de estratégia.

A ideia é simples, você deve alcançar um esqueleto funcional que vá de uma extremidade a outra da integração.

O objetivo também  é simples,   verificar que o caminho seja eficiente e  descobrir oportunamente as implicações que podem ter construí-lo, fortalecê-lo, modificá-lo.


Os objetos e serviços mock podem ajudar muito com esta estratégia.

Imagine um cenário hipotético, mas muito comum, temos de fazer a integração de vários sistemas, incluindo: um serviço de nível muito baixo (que ainda não tenha sido criado) passando por uma transformação dos dados (não totalmente definidos) seguida por uma tradução (um pouco confusa) e terminando com uma visualização dos dados (ainda em desenho).

Nosso esqueleto usaria objetos mock para:

  • Simular a invocação de serviços para o nível mais baixo.
  • Simular a transformação de dados, que receba a saída do passo anterior como entrada para este passo.
  • Traduzir um conjunto de dados válidos, mas arbitrários e retornar o formato esperado pela camada superior.
  • Mostrar o componente de visualização de dados com os dados arbitrários.


E o nosso esqueleto está completo. :)

A partir desse esqueleto pudemos crescer e fortalecer o nosso aplicativo, sem afetar  significativamente as camadas superiores. A construção do esqueleto nos ilumina o necessário para saber o custo de modificar qualquer um dos pontos de conexão;  de cada "bone" do esqueleto.
E saber o custo, ajuda a definir pontos de conexão mais fáceis de serem trocados.

E você?

Quantos esqueletos já encontrou pelo caminho?
Somente contam os que vemos no início, os que vemos ao final do projeto nem os mencione.

;)

---
RuGI Isaac Ruiz Guerra.

-----------------------------------------------------
Autor da foto acima: germeister
------------------------------------------------------