Se você instalou o Maven para Rodar com o Windows e está tentando usar o Oracle JDeveloper ou alguma outra IDE da Oracle e as coisas não estão funcionando muito bem, talvez seja a hora de ajustar algumas configurações no seu Windows.
Baixe o Maven do site da Apache próprio para o Windows, descompacte e mova a pasta com o Maven para a pasta Arquivos de Programas ou para o diretório de sua escolha.
Em propriedades do sistema do Windows, adicione a variável de ambiente M2_HOME com o valor do caminho do Maven
Adicione a variável de ambiente M2 nas variáveis de ambiente com o valor %M2_HOME%\bin
Adicione a variável de ambiente MAVEN_OPTS com o valor -Xms256m -Xmx512m
Adicione a variável de ambiente JAVA_HOME. Ela deve apontar para o diretório raiz do JDK (o diretório do JRE não serve para nada).
Inclua %M2% na variável de ambiente Path
Inclua %JAVA_HOME%\bin na variável de ambiente Path
No prompt de comando execute mvn –version para verificar se o Maven instalou ok.
Olha, dei uma lida no Sommerville e lá está escrito mais ou menos o seguinte:
Requisitos funcionais:
É
a definição das funcionalidades que um sistema de software deve
fornecer. Esse tipo de requisito informa como o sistema deve trabalhar
os dados de entrada e quais informações devem ser geradas na saída.
Serve
para definir o comportamento do sistema em situações específicas. Os
requisitos funcionais também servem para definir o escopo do sistema de
software ao limitarem explicitamente o que o sistema deve ou não deve
fazer.
Requisitos não funcionais:
Esse
tipo de requisito trata das limitações nos serviços ou funções
oferecidas pelo sistema baseando em parâmetros como “número de
transações por segundo”, “número de usuários operando o sistema ao mesmo
tempo” ou limitações impostas por padronizações, por exemplo.
Requisitos
não funcionais muitas vezes se aplicam à implementação e operação do
sistema como um todo ao contrário de focar em funcionalidades e ou
serviços individuais de sistemas.
Na
verdade, há uma linha não muito clara entre o que é requisito funcional
e não funcional. Dependendo da abordagem isso pode ficar confuso.
Um
requisito de usuário de segurança como limitar o tempo de acesso de
usuários autenticados, pode se enquadrar como requisito não funcional.
Entretanto
quando visto com mais detalhes, o requisito de limitar o tempo de
acesso de usuário pode se desdobrar em outros requisitos claramente
funcionais.
Esse desdobramento pode levar o requisito da limitação do tempo de acesso a ser tratado como um requisito funcional.
Isso
mostra que requisitos de um sistema de software são interligados e um
requisito pode gerar limitações, influenciar ou mesmo acabar gerando
outros requisitos.
Os requisitos de sistema entretanto não só especificam serviços ou funcionalidades do sistema.
Eles também especificam o que é necessário para assegurar que os serviços e funcionalidades sejam efetivamente entregues.
Aí galera, segue a minha visão sobre o assunto depois de dar uma lida no Sommerville.
Um
dos objetivos do processo de elucidação de requisitos é conhecer o
trabalho que os stakeholders (interessados no projeto) querem
implementar no sistema, de forma a ajudá-los em suas atividades.
Durante
a elucidação de requisitos, os engenheiros de software trabalham junto
com os stakeholders para entender o domínio da aplicação.
Os
engenheiros de software levantam as atividades trabalhadas, os
serviços, as funcionalidades que precisam ser implementadas no sistema,
bem com tomam conhecimento da performance desejada e assimilam as
limitações impostas pelo hardware, dentre outros pontos.
Dado
que pessoas, incluindo stakeholders, normalmente tem dificuldades em
definirem requisitos de forma abstrata, muitas vezes eles são levantados
a partir de exemplos da vida real, mais fáceis de serem obtidos.
Pessoas
são capazes de descrever como enfrentam situações particulares ou são
boas em descreverem como seria possível, a elas, melhorarem seus métodos
de trabalho.
Levantamento
de histórias e cenários é uma ferramenta poderosa para que engenheiros
de software capturarem esse tipo de informação, normalmente descrita em
linguagem natural.
De
posse dessas histórias e cenários, o engenheiro de software os utiliza
nas reuniões com os stakeholders para definir quais funcionalidades do
software devem ser implementadas e ou deprecadas.
Para saber mais:
SOMMERVILLE, Ian. Software Engineering: Tenth Edition. 10. ed. Boston: Pearson, 2016. 796 p. ISBN 13: 978-0-13-394303-0. –
Esses
dias eu estava acessando alguns sites e começou a dar aquele maldito
erro informando que a conexão não é confiável, cada vez que tentava
acessar sites do governo.
Isso
acontece porque o governo emite seus certificados de segurança e por
algum motivo o certificado raiz não consta na instalação do Windows e
Linux. Fica faltando e é uma droga.
Como faz para resolver esse B.O?
O
incomodado tem que sair procurando o certificado certo, fazer o
download e instalar. É um inconveniente no calor das entregas das
tarefas do escritório, fora que se formatar o computador, tem que fazer
tudo de novo.
Isso é um saco para quem manja de TI e deve ser Aramaico para quem é de humanas.
Esse funcionário público que teve essa ideia merece uma caixa de Bis de presente. Quem o conhecer, mande os parabéns!
Uma
vez encontrado um arquivo com todos certificados, bastaria descompactar
e instalar os certificados, mas aí o problema complica:
São 164 certificados (em 2022)!
Cada um tem que dar uma meia dúzia de cliques nos locais certos.
Se fizer errado, o certificado não instala direito, fica tudo zoado e não funciona.
Há risco de esquecer de instalar alguns certificados.
Há o risco de ficar reinstalando certificados já instalados.
O processo é demorado pra caramba, leva cerca de 1 hora por computador, muito tempo para uma pequena empresa, por exemplo.
“Ainda bem que sei programar” entra a partir desse ponto.
Após uma breve internetada, achei um script de PowerShell, o ajustei para as minhas necessidades e mandei rodar.
Como eu fiz?
O código pronto está aí embaixo. em linhas gerais:
Baixei e descompactei o arquivo em um diretório temporário
Abri o editor do PowerShell e naveguei até o diretório
Dei um “ls>diretorio.csv” para listar o diretório em um arquivo csv
Abri o arquivo no Excel e com umas fórmulas, montei o caminho dos arquivos
Depois usei essa informação para montar o script
Instalou todos certificados de uma vez em menos de 1 minuto.
Na prática fazer isso pela primeira vez levaria o mesmo tempo que fazer manualmente, mas dessa forma todos certificados foram instalados corretamente (com certeza), com os cliques corretos e sem esquecer de ninguém. Fora que nas próximas, supostamente sofrerei menos com a instalação de certificados, fora que hoje 07/2022 eu tive de repetir essa instalação e rodou em minutos, pois eu já tinha feito o caminho das pedras 🙂
Programadores entenderão:
O script está aqui, é específico para minha máquina e não segue nenhuma das boas práticas de programação, mas resolveu o B.O.
Um
Schmitt trigger é um circuito comparador com histerese implementado
pela aplicação de realimentação positiva à entrada não inversora de um
comparador ou amplificador diferencial.
Ele é um circuito ativo que converte um sinal de entrada analógica em um sinal de saída digital.
O
circuito é chamado de “gatilho” (trigger) porque a saída retém seu
valor até que a entrada mude o suficiente para disparar uma mudança no
sinal de saída.
O
Schimitt trigger possui dois níveis de disparo que são o ‘limiar
superior’ e o ‘limiar inferior’ conforme indicado na função de
transferência exibida abaixo:
Os
eixos horizontal e vertical correspondem respectivamente à tensão de
entrada e de saída. T e −T são os limites de comutação, e M e −M são os
níveis de tensão de saída.
O diagrama abaixo compara o comportamento de um circuito Schimitt triger com um buffer, ambos não inversores.
Configuração inversora e não inversora:
Na
configuração não inversora, quando a entrada é maior que o limiar
superior, a saída é alta. Quando a entrada está abaixo do limiar
inferior, a saída é baixa e, quando a entrada está entre os limiares
inferior e superior, o valor na saída do circuito é constante.
Na
configuração inversora, quando a entrada é maior que o limiar superior,
a saída é baixa. Quando a entrada está abaixo do limiar inferior, a
saída é alta e, quando a entrada está entre os limiares inferior e
superior, o valor na saída do circuito é constante.
Esse
comportamento de limiar de disparo duplo que o sinal de saída muda
quando o sinal de entrada atinge valores limiares distintos, é chamada
de histerese. Podemos até dizer que o Schimitt trigger possui memória e
pode atuar como um multivibrador biestável (latch ou flip-flop).
Existe uma estreita relação entre os dois tipos de circuitos: um Schimitt trigger pode ser convertido em um latch e vice versa.
Schimitt trigger serve para fazer o condicionamento de sinais em circuitos digitais reduzindo o ruído dos mesmos, particularmente reduzindo (não elimina completamente em alguns casos) o efeito de repique (bounce) de chaves eletromecânicas. Também são utilizados em configurações com feedback em loop negativo, implementando osciladores de relaxamanto que encontram aplicação em geradores de função e fontes de alimentação chaveadas.
Há várias maneiras de se implementar um circuito Schmitt trigger e uma delas seria pela utilização de um amplificador operacional.
Pode-se
fazer um conversor analógico-digital utilizando um amplificador
operacional cuja entrada analógica recebe o sinal e a saída do
amplificador operacional fornece o sinal de saída digital.
Isso
é possível por conta do alto ganho do amplificador operacional e quando
o sinal passa de um certo limite, a saída satura ou corta imediatamente
como em um processo de avalanche.
Abaixo
seguem dois diagramas básicos (não são circuitos completos), um
utilizando a entrada não inversora e outro utilizando a entrada
inversora de um amplificador operacional:
Comparador não inversor:
Para
o comparador não inversor os dois resistores R1 e R2 formam um somador
de tensão paralela. Ele soma uma parte da tensão de saída à tensão de
entrada, aumentando-a durante e após a comutação, que ocorre quando a
tensão resultante está próxima de zero. Este feedback positivo paralelo
cria a histerese necessária que é controlada pela proporção entre as
resistências R1 e R2. A saída do somador de tensão paralela é em relação
ao terra, então o circuito não precisa de um amplificador com entrada
diferencial. Como os amplificadores operacionais convencionais têm uma
entrada diferencial, a entrada inversora é aterrada para criando o ponto
de referência zero volts.
Comparador inversor:
Para
a versão utilizando o comparador inversor, a atenuação e a soma são
separadas. Os dois resistores R1 e R2 atuam apenas como um divisor de
tensão (atenuador “puro”). O loop de entrada atua como um somador de
tensão simples que soma uma parte da tensão de saída em série à tensão
aplicada no circuito de entrada. Este feedback positivo em série cria a
histerese necessária que é controlada pela proporção entre as
resistências de R1 e a resistência do conjunto R1 e R2. A tensão efetiva
aplicada à entrada do amplificador operacional está flutuando, logo, o
amplificador operacional deve ter uma entrada diferencial.
Maiores detalhes sobre essa configuração pode ser vista na Wikipedia e está bem detalhada no livro The Art of Electronics.
Na eletrônica digital:
A implementação desse tipo de circuito é representada pelos símbolos abaixo e normalmente estão dentro de circuitos integrados:
Símbolo
que representa um Schmitt trigger. Ele possui o desenho de uma curva de
histerese dentro do símbolo lógico de um buffer, cuja saída pode ser
normal ou inversa (com a bolinha). Detalhes acerca do comportamento de
um circuito integrado Schmitt trigger deve ser verificada na
documentação do componente, que é fornecida pelo fabricante.
O
código binário refletido (reflected binary code – RBC), também
conhecido como código binário refletido (reflected binary RB) ou código
cinza (Gray code – depois dos estudos de Frank Gray), consiste da
ordenação do sistema numeral binário de maneira tal que dois valores
binários sucessivos tenham apenas um bit de diferença entre ambos.
O
código Gray foi inicialmente projetado para minimizar o efeito de
ruídos aleatórios causados pelo chaveamento de dispositivos
eletromecânicos como relés.
Hoje
em dia o código Gray é largamente utilizado para facilitar a correção
de erros em sistemas de comunicação digital como em televisão e em
alguns sistemas de TV a cabo.
Considerando
um sistema de posicionamento eletromecânico que faz uso de uma contagem
binária, é muito improvável que interruptores físicos consigam comutar
simultaneamente à medida que ocorre o posicionamento desse sistema e
essa falta de sincronismo causa ruídos no circuito. Para contornar essa
limitação, foi criado o Gray Code, que somente uma chave por vez muda de
estado à medida que o posicionamento acontece, contornando o problema
da falta sincronização na atuação das chaves mecânicas.
Abaixo
segue uma tabela exibindo a diferença entre o código binário e o código
Gray. Conforme dito, note que no código Gray, apenas um bit muda entre o
valor anterior e o valor posterior.
Aplicações:
Em matemática pode ser aplicado na resolução do problema da Torre de Hanoi.
Émile Baudot utilizou o código Gray nos telégrafos em 1878.
Frank
Gray patenteou em 1953 um método para converter sinais analógicos para o
código Gray utilizando válvula,que fez o sistema “pegar o seu nome”.
Minimização de circuitos booleanos (lógica digital) na rotulação dos eixos do mapa de Karnaugh.
É
utilizado em sistemas de posicionamento tanto lineares como rotativos
(encoder). Inicialmente era eletromecânico e atualmente utiliza sensores
óticos, de efeito hall ou usa outras tecnologias eletrônicas.
Figura: Petruzella
Também pode ser aplicado em outras áreas como algoritmos genéticos, minimização de circuitos eletrônicos e correção de erros, por exemplo.
O Game Design Document (GDD) é muito mais que um documento de conceito ou proposta de negócio.
É
normal que um GDD tenha algo entre 50 e passe de 200 páginas. O
propósito do GDD não é servir de apoio para vender uma ideia. Pelo
contrário, seu principal objetivo é ser um guia de referência ao
processo de desenvolvimento de um jogo (game).
O
GDD tem que focar no modo de jogo (gameplay), roteiro (storyline),
personagens, interface e regras do jogo. O GDD deve especificar o
projeto com detalhes suficientes e de tal forma que seja possível, em
teoria, jogar o jogo sem o uso de um computador.
Inclusive
poder jogar uma versão em papel do jogo construida a partir do GDD é na
verdade um modo barato de se entender e depurar o projeto do jogo. A
prototipagem em papel sempre deve ser considerada durante o processo de
desenvolvimento do game.
Devido
ao tamanho do GDD, um índice deve ser inserido logo após a página de
título do documento. Esse documento tem que ser entendido como parte do
processo de desenvolvimento do jogo e deve ser atualizado constantemente
à medida que o projeto é desenvolvido.
Como
boa prática deve-se ter certeza que o GDD esteja disponível a todos no
projeto de tal forma que os membros do time possam fazer as atualizações
conforme o necessário a qualquer tempo (obviamente um controle de
versionamento tipo GIT deve ser adotado).
O GDD deve conter em sua descrição basicamente os seguintes elementos, não se limitando à lista abaixo:
Interface do jogo
– indicando os elementos do jogo, tempo de produção, custo, requisitos
das interfaces, viabilidade da interface, audiência e gênero do jogo.
Mundo do jogo
– níveis e elementos presentes em cada nível do jogo bem como a
descrição dos mesmos. Inclui arte, cinemática, animações, itens
disponíveis e informações acerca de itens perigosos.
Habilidades dos personagens e itens – como funciona o ataque e defesa dos personagens, o que faz cada NPC, o que e como os personagens podem pegar de itens.
Game engine
– o que pode ser feito e o que não pode ser feito no desenvolvimento do
jogo. Esta parte do GDD serve para manter todos desenvolvedores
alinhados com os recursos disponíveis e comportamento geral do jogo
abordando tópicos como número de personagens por tela, animações por
personagem, restrições de câmera, paleta do mapa de textura e outras
informações que padronizem o desenvolvimento do game.
Você
utilizará como game engine a interface 2D do GameSalad, ou utilizará a
engine 3D do Unity? Sites exibidos logo a seguir. Essa decisão, por
exemplo, é definida na seção Game Engine.
Tenha
em mente que o GDD pode variar dependendo no nível de detalhes e
demandas do projeto, mas é para isso que ele serve e o que ele
basicamente deve conter.
Fonte: NOVAK, Jeannie. GAME DEVELOPMENT ESSENTIALS: AN INTRODUCTION. 3. ed. United States: Delmar Cenage Learning, 2012. 514 p. ISBN 13: 978-1-111-30765-3.
À medida que o tempo passa e que uma música é tocada conforme indicado na figura abaixo, ocorre o seguinte processo:
Diagrama geral da conversão Analógica para digital
Um sistema de sincronismo, gera um sinal de clock que vai sincronizar o trabalho todo.
Esse
sinal de clock de tempos em tempos dispara uma ordem para que seja
“tirada uma foto” da música que está tocando. Em outras palavras: o
clock aciona um circuito para tirar uma amostra do sinal de áudio.
Essa amostra do sinal de áudio corresponde ao volume do som que está sendo tocado, é uma voltagem que pode ser maior ou menor.
Esse
amostra indicando a intensidade instantânea do som é enviada para um
conversor analógico digital que converte esse valor para um número
digital, composto por zeros e uns.
Por último esse número digital é gravado na memória.
Na
hora de tocar a música, basta fazer o caminho contrário: Ir lendo na
mesma velocidade que foram gravados esses números e ir convertendo esses
números para intensidade de som (converter de digital para analógico)
para depois acionar o alto falante e reproduzir a música.
Abaixo
tem o diagrama em blocos de um circuito integrado conversor Analógico –
Digital mais antiguinho com saída em dados paralela (D0 – D9) para ser
gravado na memória:
E
aqui o diagrama em blocos de um conversor Analógico – Digital, mais
moderno com interface SPI para conectar em um Arduino, por exemplo:
Pergunta originalmente postada o Quora, em nov/2016
Em circuitos digitais quando:
Um sinal é ‘ativo baixo’, significa que o sinal irá executar sua função quando seu nível lógico for 0
Um sinal é ‘ativo alto’, significa que o sinal irá executar sua função quando seu nível lógico for 1
Considerando o sinal ‘habilita_clock’, a figura abaixo mostra um exemplo de sinal ativo alto no lado esquerdo e um exemplo de sinal ativo baixo no lado direito da figura.
Diferença entre ‘ativo alto’ e ‘ativo baixo’.
Simples assim. Espero que ajude. Dê uma setinha para cima se você achar útil.
Resposta originalmente postada no Quora em 16/07/2019
Tem sempre alguma coisa que a gente faz..
Vou citar uma aqui..
Certa feita tive de instalar um dual boot, Linux e Windows.
O Windows teve um update logo depois da instalação e zoou grandão o GRUB. O computador parou de funcionar.
Saquei meu script ‘reparagrub’ e rodei ele.
Programadores entenderão:
sudo mount /dev/sdb7 /mnt
for i in /sys /proc /run /dev; do sudo mount --bind "$i" "/mnt$i"; done
sudo chroot /mnt
update-grub
grub-install /dev/sda
update-grub
exit
