Good Platform = (Bitcoin + Blockchain )*HighTech Software+OpenSource/securityDistributed

Here's why it matters from a policy perspective... about Blockchain with open source software 

The computer code undergirding each major cryptocurrency and open blockchain project is developed as open source software. Regulators and policymakers looking into cryptocurrencies but unfamiliar with open source software may have an incorrect mental model: one wherein software-based systems are (and must be) developed by one or a handful of for-profit companies. While plenty of important software projects are developed in this way (e.g. Microsoft’s Windows or Oracle’s RDBMS), open source projects are different and that difference can and should help shape public policy.

Open source software is collaboratively produced, shared freely, published transparently, and developed to be a community good rather than the property or business of a single company or person. When a project is developed open source there isn’t a single chokepoint in the development process, no company or individual that makes, owns, and sells the software. Just as there is no single company that powers the Bitcoin network, neither is there one company that makes the software that, when run on internet connected computers, creates that network. This decentralization in technology production has several profound benefits and can be difficult to grasp for those not familiar with software development.

To better understand the power and nature of open source, it is helpful to first understand a bit about one particularly successful piece of open source software: Linux, the open source operating system.

Good Platform = (Bitcoin + Blockchain )*HighTech Software+OpenSource/securityDistributed 

Supervised and Unsupervised machine learning techniques

One of the main questions I hear in Artificial Intelligence (AI) classes is about what it is and when to use supervised and unsupervised machine learning techniques.

Today these questions are asked by non-programmers or beginners, because the amount of information on what supervised learning is and how to implement really has to be accessible to those who know or who know and have experience.

These terms imply that they are different models.

Making a metaphor, imagine students being supervised by a teacher who passes a specific goal or target and shows several examples so that they can have a direction on how to learn to perform their task to better reach the target. In the unsupervised, the teacher gives examples, but does not indicate the target to be reached. Students are free to draw their conclusions from the examples.

These techniques address different problem solving.

Which one to use will depend on the business objective.

TARGET :  BUSINESS OBJECTIVE

Machine Learning # Deep Learning

Machine Learning # Deep Learning 

Para aclarar, sencillo, las diferencias entre MACHINE LEARNING y DEEP LEARNING, diremos que Machine Learning consiste en un conjunto de algoritmos que parten de un conjunto de datos de entrada y tratan de clasificarlos automáticamente o bien de inferir nuevos datos.

Entre estos algoritmos se encuentran la :

1. regresión lineal, 
2. regresión logística 

Estos las redes neuronales. 

Son métodos de fuerza bruta que normalmente funcionarán tan bien como bueno y amplio sea el conjunto de datos de entrada.

Ejemplos de aplicaciones de estas técnicas son:

• Reconocimiento de caracteres en una imagen
• En base a un elevado número de variables de entrada (nº de habitaciones, superficie, antigüedad, etc.) determinar el precio óptimo de una vivienda
• Clasificar noticias, artículos, películas, etc. por categoría y hacer recomendaciones personalizadas
• Detección del uso fraudulento de cuentas bancarias
• Detección de enfermedades en base a datos médicos del paciente

En el aprendizaje definimos un mapa de vectores con referencia en los datos.

Estos algoritmos pueden trabajar con un gran número de variables de entrada y la dificultad normalmente consiste en recolectar los datos con los que alimentarlos.

Pero en todo momento hablamos de datos en bruto: diferencias entre pixeles de una imagen o correlaciones entre datos, no hay un verdadero entendimiento de los valores de entrada.

Aquí es donde entra el Deep Learning, que añadiría la parte de representación de datos, de esa forma el sistema sabría que una película dramática contiene normalmente la pérdida de alguien querido o una relación amorosa truculenta, que el estómago y el hígado forman parte del aparato digestivo o sabría que las caras muestran diversas expresiones: alegría, tristeza...

Por tanto, es Deep Learning es un área de investigación clave en los próximos años...

La conclusión sería la siguiente, mi visión:

Deep Learning = Machine Learning + Semántica

O Lookup no Java EE 6 

É mais simples, podemos utilizar injeção de dependência e é compatível com as implementações anteriores.
Existe mais de uma maneira de fazê-lo, e aqui tentaremos abordar uma forma considerada boa prática.
Para saber mais sobre o assunto, pesquise por Portable global JNDI name que foi introduzido no Java EE 6 

A imagem abaixo demonstra como é possível fazer o lookup direto e o equivalente utilizando a injeção de dependência.

Importante: Esta é uma forma simples, porém em uma aplicação corporativa não é uma boa prática.

Não deve fazer, segundo as boas práticas de estratégia de implementação.

Mas quais são os problemas desta abordagem?
 
Existem alguns problemas relacionados à portabilidade, e uma limitação em termos de nomes. O lookup JNDI, é possível saber mais detalhes sobre o assunto, no wesbite do Java .

Nas versões mais antigas do Java EE, é possível minimizar este problema adicionando nomes lógicos nos descritores, deployment plan e fazendo lookup utilizando java:comp/env.

No Java EE 6 não é muito diferente, porém existem algumas facilidades:
 
1) Não é necessário adicionar itens aos descritores da aplicação (web.xml e ejb-jar.xml)
2) Alguns lookups são possíveis sem nenhum descritor, outros com apenas o deployment plan.

Abaixo é demonstrado como é feito um lookup a base de dados utilizando os recursos do Java EE 6:
(boa prática)

Em uma aplicação web, o @Resource é o responsável por colocar as informações, as quais você teria que colocar no web.xml

O Deployment plan, continua sendo o mesmo arquivo com o mapeamento entre os nomes lógicos e os nomes físicos. Como varias informações são fornecidas com o uso de annotations, este arquivo acaba sendo um pouco mais enxuto. 

Lookups de EJBs no Java EE 6:
 
Nos casos dos EJBs tem uma diferença, que melhorou no meu ponto de visão. Em lookups locais não é necessário nenhum tipo de descritor. No caso de lookups remotos apenas é necessário o deployment plan para fazer o mapeamento.

Outra diferença é que ficou mais simples de fazer o lookup, bem como é possível utilizar a injeção de dependência:

Object result = context.lookup(CepRepositoryBeanLocal.class.getName());
CepRepositoryBeanLocal service = (CepRepositoryBeanLocal) result;

E o código acima pode ser trocado por
 
@EJB CepRepositoryBeanLocal service;

Utilizando o @EJB, o container irá cuidar de prover uma implementação de CepRepositoryBean para a interface de negócio CepRepositoryBeanLocal.


Download dos exemplos:
Ambiente: JDK 1.6.24, JBoss 6.0, Eclipse 3.6

TDD What ? New or old ? Good or no ?

Currently or since I know myself as a professional, software failures are largely responsible for costs and time in the software development process.

While it is not possible to remove all existing errors in a given application, it is possible to considerably reduce the number of errors using a more elaborate testing infrastructure, which allows for identifying and removing defects earlier and more effectively.

These defects can result from various causes such as errors of knowledge, communication, analysis, transcription, coding, etc. There are basically three ways to handle software flaws:

1. Fault-avoidance: With appropriate specification, design, implementation and maintenance activities always aiming to avoid failures in the first place. It includes the use of advanced software construction methods, formal methods, and reuse of trusted software blocks.

2. Fault-elimination: Analytical compensation for errors committed during specification, design and implementation. Includes verification, validation and testing.

3. Fault-tolerance: real-time compensation of residual problems such as changes out of specification in the operating environment, user errors, etc.

Due to the fact that fault-avoidance is economically impractical for most companies, the technique of fault elimination is generally adopted by software manufacturers

In the US, do these errors move the software market by approximately 50 billion dollars, and in Brazil and South America? We can see that there is a culture of everything by the result, and after delivery by delivery, in many projects and forgotten the quality be it in the software architecture or in the choice of the project implementation strategy, the DEADLINE is focused by the DEADLINE.

Another point is the bureaucratization of technical activities, process must exist but these should also be support to the objectives and not against the objectives that includes being agile, safe, reusable, practical and that make a culture in the company be it with 10 professionals or with 100 In a company.

The culture of testing is old, as it says in King Chelomoh's Cohelet book, nothing new is just not revealed.

The practice involves the implementation of a system starting with test cases of an object, this is old, I at least have known these techniques since 1999, I will cite only one that defends this idea [Gelperin and Hetzel 1987]. Minimize the errors by focusing on the tests, and today as we are in the era of "JS frameworks", there is a semantics of confusing the implementation framework with work process framework with tools of griffe, which does not apply if they are not tested in the process by All, for all, not only by the 18-year-old project architect, this 18-year-old nowadays grant the role of software architect, senior software development positions to good early professionals, but with little experience, which For me 1996 was almost impossible to have a Jr. level in my classificatory parts of technical activities of the profession, I thought more imperative implementation than clear techniques, there have been many improvements, but today TDD - Test driven development can be put at high risk If you do not have experience in IT projects with software development with serious errors and also great achievements.

In many different techniques, used in the market and tested in the academic world, and professional can, I say by myself also, that the use of this technique is possible to reduce the complexity of software, increasing the maintainability of it. Failures are easily identified even in the development stage thanks to continuous feedback given to the programmer. The test units created allow you to more easily evaluate new defects that may have been inserted in the software facilitating the development of successive releases.

But a detail the professionals who do this are also with attributes of programmers, systems analysts know the world of implementation, this is my opinion for the success of TDD, adjust to lead to good results.

One good choice use systems development with MDA - Model Driven Architecture

One good choice use systems development with MDA - Model Driven Architecture

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution. 

One choice to solving problem of process of development is using MDA as good choice and with development tools integrate. Can implement with languages as Java, Python, C++.

Every system development lifecycle process involves the following types of lifecycle activities:

• Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
• Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
• Testing activities to verify that a system satisfies its requirements.
• Deployment activities to make the system available to its users.

Furthermore, there are many types of approaches or lifecycle models, bellow :
 1. Iterative,
 2. Waterfall,
 3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process.

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...

Como reforçar as atividades essenciais de um projeto ou de processo

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, e de acordo com o livro do matemático Alkhaziri em meados do século 19 onde os grupos para empreender e ajustar produção faziam um esboço de um plano usando cálculos e figuras, que podemos dizer da fronteira do Norte da África ao Oriente Médio já utilizavam avançados métodos para  que os esforços de otimização tinham o objetivo de “ reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um esforço ou custo mais baixo ”.  As atividades essenciais devem controlar a produção em a cada revisão estar melhor para objetivar menor esforço e alcance dos objetivos.

Qualquer planejamento a ser executado para a otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman e Alkhaziri exploram as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada. Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

• não está relacionado ou é impactado muito levianamente pelo processo de negócio;
• pode gerar interpretações diferentes;
• não é impactado apenas pelo processo, mas também por  fatores externos;
• não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Patrono ou Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio. Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman e Alkhaziri aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.

Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management System).
Uma notação deve ser como um "idioma" na nossa comunicação.