sábado, 9 de julio de 2016

Artículos en OTN en Español.


Listado de artículos publicados en OTN en Español.
---
RuGI

domingo, 6 de septiembre de 2015

[4 de 97]. A perfeição é inimiga do bom o suficiente.

“‘Perfect’ is the Enemy of ‘Good Enough’”


A rigor e com toda a honestidade, a frase completa é: "A ‘perfeição’ é inimiga do ‘bom o suficiente’", e ela é creditada igualmente a Voltaire e a Leonardo Da Vinci.


mandala.png


Aqui um extrato do que ele escreve no livro 97 things Every Software Architech Should Know:
---


Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations.  Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about "buffer gets" and non-unique indexes and demand attention.

My advice: Don't give in to the temptation to make your design, or your implementation, perfect! Aim for "good enough" and stop when you've achieved it.

Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.


---


Eu pensei em iniciar dessa forma a revisão dessa regra, quando me lembrei que no podcast de JavaHispano #36; durante a entrevista com Eduardo Pelegri (responsável pelo Glassfish), enquanto comentava sobre a especificação inicial das JSP’s  lhe perguntaram o que ele achava dessa especificação e como tinham chegado a ela.


Eis aqui uma transcrição de suas palavras.


“Uma especificação que é tecnicamente perfeita, mas não tem apoio na indústria, é inútil….
Você tem que ter uma especificação que é tecnicamente válida…
Não é só questão de dizer:
‘Esta é a melhor especificação que eu poderia fazer’
senão:
'Esta é a melhor especificação que todos poderíamos fazer juntos”
Entrevista com Eduardo Pelegri por Abraham Otero (10:12min)


Eu imagino vários gurus reunidos tentando chegar a um acordo sobre como deveria ser a especificação (minha mente geek vê-los como uma reunião de Ent’s), eu imagino todos  tentando obter uma especificação que considerasse a melhor de suas propostas. Eu também imagino como seria difícil chegar a um acordo em que provavelmente mais de um deles tivesse que subjugar seu ego para permitir que outras propostas fossem aceitas.


Se cada um tivesse agarrado com unhas e dentes o seu ideal de perfeição provavelmente a especificação teria levado mais tempo para sair e talvez a história seria outra.


Neste ponto você está ciente de tudo o que a regra adverte:
não é apropriado aferrar-se ou alienar-se para obter um aplicativo ou um fragmento de código perfeito, e melhor ajudar a preencher esse tempo com coisas que poderiam dar mais valor ao nosso aplicativo.


  • Quanto? Ou quanto tempo isso é o bastante?
  • Como saber que já temos o suficiente?
  • Em que medida devemos parar de busca a perfeição?


Eu acho que o principal indicador é o tempo gasto procurando por essa perfeição.


Se esse tempo que investimos em pesquisar, refatorar e maquiar nosso código à procura de perfeição mais do que o tempo necessário para:
  • Adicionar novas funcionalidades para o nosso aplicativo.
  • Corrigir erros de alto impacto.
  • Enfrentar novos requisitos.


...É hora de parar e aceitar que já temos dado uma boa ou suficiente solução para o que solicitaram.


Eu fico com a última frase de G. Nyberg que diz:
“Lembre-se que o desenvolvimento de aplicativos não é um concurso de beleza, assim que pare de procurar defeitos e pare de perder tempo perseguindo a perfeição.”


Afinal de contas, é difícil agradar a todos.... não é? ;)


clean_code.jpg
---


---------------------
Créditos:
A imagem é de: J Eberl
A imagem da porta aparece no livro:
---------------------

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
------------------------------------------------------

domingo, 26 de julio de 2015

1 de 97. Para o usuário final a UI é o sistema.

1 de 97. Para o usuário final  a UI é o sistema.

"For the end user, the interface is the system"

Vinayak Hedge







Esta é a regra que aparece no livro "97 things Every Software Architech Should Know" escrita por Vinayak Hedge editado, é claro, por O'Reilly.

Para o mundo da programação é uma frase muito clara, mas que ocasionalmente é esquecida, ou ao menos não lhe damos a devida importância.

O comentário de Vinayak Hedge chama a atenção para o relevante que pode ser conseguir uma UI muito boa, que possibilite uma boa interação e tenha a UX suficiente para que a UI deixe ver a totalidade do produto de software.

E esta regra, também, se encaixa perfeitamente no desenvolvimento do GO-Live do sistema em que eu colaboro atualmente.

Ao usuário final não lhe importa se abaixo da UI, você está fazendo:
- Transformação de exceções
- Tradução de mensagens
- Invocação do demônio da WS

Não lhe interessa se a gente está:

- Usando messaging (JMS)
- Invocando sistemas legacy
- Fazendo a gestão de segurança

Não, ele só se preocupa que o seu "comboBox" tenha os valores esperados e a mensagem de resposta traga uma descrição que ele possa entender (ufa!).

E é verdade, ele não precisa de preocupar :)

Fazer tudo isso de maneira transparente para o usuário final, eu acho que é uma das maiores satisfações que podemos ter....mas, eu devo admitir que às vezes dá vontade de dizer educadamente que ele deveria levar em conta a complexidade do processo para reconsiderar os seus comentários insensíveis ao nosso trabalho.

Tudo isso me faz lembrar de um comentário repetido de um de meus professores durante meus estudos de engenharia:


"Garotos! Para conferir a tarefa, eu parto do fato de que todos vão me dar o que eu pedi, se vocês quiserem aumentar a nota ... façam uma tarefa bonita".


Às vezes a gente pensa que o produto final é o que a gente considera o mais importante durante o desenvolvimento, e então negligenciamos muitas coisas e esquecemos os detalhes.


O que é interessante sobre esta regra é que, ao menos para mim, me faz lembrar que devemos cuidar os detalhes de qualquer coisa ....., pois como dizem no México:
o diabo está nos detalhes.


Vocês acreditam nisso?

;)





---
RuGI
Isaac Ruiz Guerra.

------------------------------------
Autor da foto acima:: Charlie_tj
http://www.flickr.com/photos/charlie_tj/5574623651/
------------------------------------
Eu vi a piada em:
coderfacts.
------------------------------------