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.
Tem
gente que tem muita dificuldade para ler e entender textos. Pense no
seu público. Dependendo da situação, um manual com figuras, sem palavras
pode ser a solução.
Há basicamente dois modos de criar um manual:
Criando o sumário (ou índice) primeiro
Faça o índice constando todos os tópicos e sub tópicos na sequência que o manual deve abordar.
Preencha cada um dos tópicos listados no índice.
Criando o sumário por último
Escreva sobre o produto da maneira que se sentir confortável, use parágrafos e sentenças pequenas, um para cada assunto.
Organize os parágrafos na sequência lógica que você entender melhor.
Agrupe os parágrafos em tópicos.
Mude o Word para o modo “Estrutura de Tópicos” (1) e configure o nível dos parágrafos na área de “Ferramentas de Estrutura de Tópicos” (2) conforme print abaixo:
Exemplo de estrutura de tópicos.
Feche o modo de exibição da estrutura de tópicos, vá para a página que você quer inserir o sumário (índice) e o insira selecionando a aba Referências (1) e clicando no ícone Sumário (2).
Exemplo de criação de índice.
Considerações ao criar manuais:
O manual deve ter capa, nome do autor nem que sejam as iniciais ou a matrícula funcional, número da versão, data da publicação e um email ou telefone para comunicar falhas.
A primeira versão do manual, mesmo revisada, sempre será uma droga. Basta divulgar para o público geral e alguém não irá entender o que foi escrito, irão achar erros e uma nova versão deverá ser liberada.
Peça para seu inimigo revisar o manual, é uma chance de estreitar laços profissionais e mitigar conflitos. Aceite as sugestões propostas.
Toda figura ou gráfico devem ser numerados e referenciados no texto. Colocou uma figura ou gráfico, o texto tem que falar claramente deles. Esses elementos gráficos não podem ser um boi voando no manual. Esses elementos gráficos devem estar localizados próximos de sua explicação escrita.
Manuais são lineares. O leitor não pode ficar trocando de páginas para entender o manual. Não fale na página 11 de um assunto abordado na página 5. Ou se junta os assuntos ou se repete o assunto.
Não use frases negativas como: não ligue, não feche, não solte e prefira frases afirmativas como: mantenha desligado, deixe aberto, assegure que esteja fixo.
Considere que alguns leitores irão entender melhor a frase “não deixe o motor da bomba ligado pois ele irá queimar, e outros leitores irão entender melhor a frase “para evitar que o motor da bomba queime, assegure que ele esteja desligado“. Em pontos importantes, coloque as duas frases.
NÃO USE LETRAS GARRAFAIS, NÃO FIQUE DESTACANDO O TEXTO COM NEGRITO E NÃO FIQUE USANDO O ITÁLICO COMO SE FOSSE PIPOCA DE CINEMA. ISSO VAI DEIXAR SEU LEITOR P*** DA VIDA. QUEM É ESSE AUTOR FOLGADO QUE FICA DANDO ORDENS IDIOTAS?
Evite usar letras em caixa alta bem como aplicar formatações em negrito e itálico constantemente. Isso polui o texto e o leitor pode fazer exatamente o contrário do que está escrito, só para desacreditar o manual. Note que acabei de colocar o texto negativo e positivo.
Ao usar siglas, para evitar confusões, sempre explique o que elas significam. Se o manual constantemente usa a frase “Guarde o Local Bem Trancado”, tudo bem associar com a sigla “GLBT”, desde que isso seja explicado na primeira vez que a sigla for utilizada como: Guarde o Local Bem Trancado (GLBT). Considere criar um dicionário de abreviações.
Coloque no rodapé o número das páginas no formato “Página 1 de 14”. Conforme figura abaixo, vá na aba “Layout” (1) do Word e use o recurso “Partes rápidas” (2). Escolha a opção “Campo” (3) e os campos “Page” e “NumPages” na janela que irá abrir.
Inserindo número da página atual e número total de páginas.
Formate a página com bordas. Isso é feito na aba “Design” (1), “Bordas de Página” (2). Configure na janela “Bordas e Sombreamento” (3) a borda da página de acordo com sua preferência.
Inserindo bordas na página.
Use
quebra de seções e quebra de páginas que fica na aba “Layout” para
organizar o texto e abuse do modo de exibição”Estrutura de Tópicos” que
fica na aba “Exibir” para organizar o documento inteiro, incluindo o
sumário.
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.
