O Grande Axioma da Vida

Se você não mudar quem você é, você continuará tendo o que sempre teve. “Fazer as coisas certas e não certas coisas” "Para ter mais amanhã, você precisa ser mais do que é hoje"


Há uma história muito interessante, chamada "O Tesouro de Bresa", onde uma pessoa pobre compra um livro com segredo de um tesouro.

Para descobrir o segredo, a pessoa tem que decifrar todos os idiomas escritos no livro. Ao estudar e aprender estes idiomas começam a surgir oportunidades na vida do sujeito, e ele lentamente (de forma segura) começa a prosperar.

Depois ele precisa decifrar os cálculos matemáticos do livro.

É obrigado a continuar estudando e se desenvolvendo, e a sua prosperidade aumenta. No final da história, não existe tesouro algum - na busca de segredo, a pessoa se desenvolveu tanto que ela mesma passa a ser o tesouro.

O profissional que quiser ter sucesso e prosperidade precisa aprender a trabalhar a sim mesmo com muita desciplina e persitência. Vejo com frequência as pessoas dando um duro danado no trabalho, porque foram preguiçosas demais para darem um duro danado em si mesmas.

Os piores são os que acham que podem dar duro de vez em quando. Ou que já deram duro e agora podem se acomodar.

Entenda: o processso de melhoria não deve acabar nunca. A acomodação é o maior inimigo do sucesso!!

Por isso dizem que a viagem é mais importante que o destino.

O que você é acaba sendo muito mais importante do que você tem.

A pergunta importante não é "quando vou ter?", mais sim, "no que vou me transformar?".

Não é "quanto vou ganhar", mas sim "quanto vou aprender?".

Pense bem e você notará que tudo o que tem é fruto direto da pessoa que você é hoje. Se você não tem o suficiente, ou se acha o mundo injusto, talvez esteja na hora de rever esses conceitos.

O porteiro do meu prédio vem logo à mente. É porteiro desde que o conheço. Passa 8 horas por dia na sua sala, sentado atrás da mesa. Nunca o peguei lendo um livro. Está sempre assistindo à TV, ou reclamando do governo, do salário, do tempo. É um bom porteiro, mas em todos esses anos poderia ter se desenvolvido e hoje ser muito melhor do que é. Continua porteiro, sabendo (e fazendo) exatamente as mesmas coisas que sabia (e fazia) dez anos atrás. Aí reclama que o sindicato não negocia um reajuste maior todos os anos. Nunca consigui fazê-lo entender que as pessoas não merecem ganhar mais só porque o tempo passou. Ou você aprende e melhora, ou merece continuar recebendo exatamente a mesma coisa.

Produz mais, vale mais? Ganha mais. Produz a mesma coisa? Ganha a mesma coisa. É simples. Os rendimentos de uma pessoa raramente excedem seu desenvolvimento pessoal e profissional.

Às vezes alguns têm um pouco de sorte, mas na média isso é muito raro. É só ver o que acontece com os ganhadores da loteria, astros, atletas. Em poucos anos perdem tudo. Alguém certa vez comentou que se todo o dinheiro do mundo fosse repartido igualmente, em pouco tempo estaria de volta ao bolso de alguns poucos. Porque a verdade é que é difícil receber mais do que se é.

Como diz Jim Rohn, no que ele chama do grande axioma da vida: "Para ter mais amanhã, você precisa ser mais do que é hoje". Esse deveria ser o foco da sua atenção.

Não são precisos saltos revolucionários, nem esforços tremendos repentinos. Melhore 1% todos os dias (o conceito de "Kaizen"), em diversas áreas da sua vida, sem parar. Continue, mesmo que os resultados não sejam imediatos e que aparentemente/superficialmente pareça que não está melhorando.

Porque existe, de acordo com Rohn, um outro axioma: O DE NÃO MUDAR.

Se você não mudar quem você é, você continuará tendo o que sempre teve.

"Fazer as coisas certas e não certas coisas"

Texto: Autor desconhecido.
 

Sistemas Especialistas

Inteligência Artificial – Aula 2010-10-13 – Professor Helmuth Grossmann

Sistemas Especialistas

São sistemas com foco em uma área especifica, busca tomar uma decisão igual ou próxima ao de um especialista da área. São comuns em sistemas do mercado financeiro, controle de consumo cartão crédito...

Podem ser de dois tipos:
  • Baseados em Casos (SEBC): Possui um banco com diversas situações e suas soluções, ao resolver novos problemas busca por um caso similar ou igual para determinar a solução.
  • Baseados em Regras (SEBR): Aplica algumas regras para resolver a situação.

Sistemas especialistas possuem uma base de conhecimento e um sistema/motor de inferência (metodologia para encontrar solução) separados, podem tomar decisões lógicas sob imprecisão ou com falta parcial de informações. Para construir um SE é necessário primeiro sistematizar o conhecimento do especialista (criar a base de conhecimento), após permitir que o sistema aprenda (inserir novos casos ou regras) e ter um bom motor de inferência para localizar um caso similar ou (se não encontrar caso ou não usar casos) aplicar as regras.

Os especialistas devem resolver problemas difíceis, explicar os resultados, aprender, reestruturar seu conhecimento e determinar as características relevantes de seu conhecimento.

O primeiro sistema especialista (SE) foi o DENDRAL, em 1965, automatizava raciocínio sobre estruturas químicas, usado meio acadêmico. Depois (1976) veio o MYCIN, pioneiro no uso de fatores de certeza, conseguia ultrapassar um clínico de perícia médica no diagnóstico de pacientes com meningite utilizando critérios (regras) para identificar 3 diferentes causas, este foi o software que deu impulso para investimentos nos sistemas especialistas. Em 1982 também ficou bastante conhecido o XCON, usado para configurar sistemas computacionais complexos. A partir dos anos 90 muitos SE's passaram a utilizar a lógica fuzzy, em busca de soluções mais precisas, rápidas e confiáveis, os SE's passaram também a utilizar soluções mistas com casos e regras.

Em Singapura, desde 1980, SE's são utilizados em setores bancários, financeiro, manufatura... no Japão sistemas com lógica difusa estão crescendo nos eletrodomésticos, na Alemanha são utilizados principalmente em indústrias pesadas. Nos EUA os SE's tem ênfase para o problema de “solução de negócios” e sistemas “ativos”, sistemas colaborativos com ampla base de conhecimento e compartilhamento do mesmo, exemplo sistemas de suporte a equipamentos HP, Dell...

No Brasil podemos citar os SE's :
  • Análise de crédito bancário (Pereira, 1995);
  • Análise de hepatopatias crônicas (Vieira, 1996);
  • Análise química qualitativa de minerais (Fernandes, 1996);
  • Sistema de apoio ao diagnóstico de problemas em computadores (Grossmann, 2001);

Outros exemplos/possibilidades:
  • Cálculos de penas no sistema judiciário;
  • Prospecção e detecção de petróleo;
  • Manutenção de redes de energia;
  • Classificação de pisos cerâmicos (UFSC);
  • Análise da qualidade de amostras de milho;
  • Análise de motores de compressores;
  • Diagnóstico médico;
  • Cotações de seguros...

Bom pessoal, eu vou me dedicar a criar um SE para operações com análise técnica em bolsa de valores, é possível também criar com análise fundamentalista (não conheço muito), ainda não decidi se vou usar apenas com regras, com casos, misto (mais provável), com lógica fuzzy, redes neurais etc, ainda preciso estudar mais. Até!


Engenharia de Software - Parte VI - Construção

Aula Engenharia de Software → 2010-09-24
Professor Cristiano

Práticas de Implementação → Programação → Desenvolvimento de Software → XP

XP → Técnicas pra desenvolver o software

A programação (Implementação → processo de escrita de uma programa baseado em uma especificação de projeto) veio antes da Engenharia de Software, Engenharia surgiu quando foi necessário criar sistemas comerciais e não apenas pesquisa para fins militares etc, foi quando os programadores não tinham o conhecimento das regras de negócio, ai foi necessário ter analistas, documentadores, testadores, suporte etc.

É muito importante ter um ambiente bom para se trabalhar durante a fase de implementação para que os programadores possam trabalhar da melhor forma, sem ter muitos problemas para resolver, um programador estressado faz um trabalho pior do que um bem humorado.

A melhor forma de implementar um software é utilizar uma série de incrementos e iterações. Isso é desenvolvimento incremental, ou seja, cada iteração do processo produz um novo incremento do software.

Modularidade: é um conceito fundamental para construção de software pois é mais fácil resolver um problema complexo quando ele é dividido em partes (módulos).

O custo de esforço diminui até determinado ponto utilizando modularidade, quando se transforma tudo em módulos o custo pra pensar e programar as interfaces de cada módulo e na sua integração é muito maior do que se não tivesse dividido em módulos.

Análise → Planejamento → Implementação/Construção → Implantação

Dentro da Implementação existe um conjunto de práticas...
  • Checar pré-requisitos e pós-requisitos;
  • Definir informação a ser ocultada, entradas, saídas e tratamento de erros
  • Projetar testes para os módulos
  • Analisar aspectos de eficiência
  • Pesquisar algoritmos e estruturas de dados, encontrar o melhor.

APÓS ESSAS PRÁTICAS PRÉ-CODIFICAÇÃO, INICIA-SE O REAL DESENVOLVIMENTO, ONDE AINDA SÃO NECESSÁRIAS OUTRAS PRÁTICAS COMO:
  • Desenvolver e documentar cada unidade de software
  • Conduzir e documentar os testes unitários → os testes de unidade servem para avaliar a parte individual de um programa (funções e métodos de classe) para ter certeza de que cada elemento individualmente faça a coisa certa.
  • Atualizar a documentação, se necessário
  • Atualizar os requisitos para o teste de integração → quem vai testar vai partir dos requisitos e verificar se todos foram desenvolvidos, se durante o desenvolvimento algum deles foi modificado é importante alterar para que o testador não pense que foi desenvolvido errado.
  • Avaliar o código e os resultados dos testes de acordo com critérios.
  • Teste de Integração → verificar se os módulos não tem erros associados a interface que impossibilitem a comunicação/integração... normalmente se usa alguma ferramenta automática para testar integração. Pode se ter uma abordagem não-incremental para o teste onde o sistema é agrupado por completo e testado somente no final, pior forma de testar, ou uma abordagem incremental onde o sistema é agrupado em etapas, cada etapa desenvolvida é testada antes de passa para próxima facilitando assim o isolamento do erro.


Engenharia de Software - Diagramas de Visão Estrutural

Os Diagramas Estruturais servem para visualizar, especificar, construir e documentar os sistemas, permitem que todos tenham a mesma visão/idéia do sistema. Os principais (Estruturais) são o Diagrama de Classes, Diagrama de Objetos, Diagrama de Componentes e o Diagrama de Implantação.

O Diagrama de Classes é um dos mais usados, ele que define as características dos objetos. Pode ser usado para modelar os dados que o sistema vai manipular servindo de base para o modelo ER, também é usado para modelar as relações entre os objetos (dependências, associações, generalizações), definir atributos e métodos de cada objeto e a visibilidade dos mesmos (private, public, protected). Algumas IDEs permitem gerar o código a partir deste diagrama. Este aqui é básico pra desenvolver OO.

O Diagrama de Objetos consiste em uma instância do Diagrama de Classes, no qual para cada classe temos a instância do seu objeto com dados reais e seus relacionamentos, normalmente utilizado para esclarecer os relacinoamentos entre as classes e facilitar a modelagem de estruturas complexas de dados. Ajuda identificar possíveis problemas que poderão acontecer com o sistema funcionando pois ao se trabalhar com dados reais pode-se simular algumas rotinas. Bem interessante, vale a pena dar uma estudada.

O Diagrama de Componentes mostra a estrutura de componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam, até aqui não entendi nada Bolívar, ok, um diagrama de componentes mostra as dependências entre componentes de software, incluindo os classificadores que eles especificam (isto é, classes de implementação -> interfaces do sistema) e os artefatos que eles implementam (isto é, arquivos de códigos-fonte, arquivos de código binário, executáveis, scripts). Eu relamente não consegui pensar em alguma utilidade para este diagrama, ele basicamente mapeia os arquivos do teu sistema e os relacionamentos entre eles, tipo, arquivo index.html ligado com login.php ligado com verificalogin.php. Editando aqui: Achei um conteúdo na Net onde usam este diagrama para mapear os módulos e como eles estão relacionados, qual módulo depende de qual pra funcionar etc, achei legal.

O Diagrama de Implantação/Implementação, assim como o Diagrama de Componentes, mostra os aspectos de implementação física, a estrutura do sistema em tempo de execução (run-time), tipo, qual máquina vai rodar o sistema, por qual protocolo (TCP/IP) se dará comunicação, quais as interfaces (celular, tv, geladeira, caixa auto-atendimento banco...), achei tosco interessanta para mostrar pros clientes, não ajuda muito pra desenvolver, pouco utilizado também.

Referências: Melo, Ana Cristina. Desenvolvendo Aplicações com UML. Rio de Janeiro: Brasport, 2002.

Inteligência Artificial - 8 Rainhas

Noite inspirada a minha, postando tudo que vem na cabeça. Você já ouviu falar do desafio das 8 rainhas no Xadrez? Bom, este é um exemplo em que se pode usar heurística para encontrar as soluções já que o número de combinações é um pouco grande, no Calc (Excel like), consegui montar duas soluções, segue abaixo.


X X X X X R X X
R X X X X X X X
X X X X R X X X
X R X X X X X X
X X X X X X X R
X X R X X X X X
X X X X X X R X
X X X R X X X X


X X X X X R6 X X
X R1 X X X X X X
X X X X X X R7 X
R2 X X X X X X X
X X R3 X X X X X
X X X X R4 X X X
X X X X X X X R8
X X X R5 X X X X

Segundo o professor Helmuth, existem 96 combinações /4 = 24 originais. Meu grupo ficou a cargo de desenvolver o programa pra encontrar as soluções, parece que vamos fazer em Java, gostaria de fazer também em C# e Pascal -> Delphi, daqui uns dias posto aqui os fontes e mais detalhes sobre IA, é muito show!