Copiando código JavaScript de terceiros.

Por ser uma linguagem interpretada e por rodar no cliente, o JavaScript permite “bisbilhotar” o código dos outros. Mas não se sinta culpado por isso. Os programadores vivem copiando coisas e essa é uma atividade salutar na linguagem. Alguns minificam as bibliotecas mas a maioria as deixa legíveis mesmo. Ao exibir o código de uma página, você verá um texto parecido com o exemplo abaixo:

<script type=”text/javascript” src=”//service.maxymiser.net/api/us/amil.com.br/df1463/mmapi.js”>

Este comando anexa o arquivo [ nmapi.js ] à página atual do mesmo provedor.

Ao acessar o endereço, você pode achar uma série de funções, minificadas ou não. Se você tiver que desminificar a biblioteca, poderá usar um dos utilitários oferecidos online, gratuitamente:

Já para minificar o código podemos usar o site do Dean Edwards:

As páginas a seguir foram testadas no site beautifier.io:

Código Minificado

Código deminificado. Observe que os nomes originais das variáveis não podem, obviamente ser recuperados.

Você pode, por exemplo, usar uma função que está em outro site (outro domínio, na verdade) para validar um cpf em sua própria página. Isso economiza um bocado de tempo de programação. Mas é aconselhável você copiar e analisar o código antes de usá-lo em sua própria aplicação. Procure por algum item que inviabilize seu uso, como:

  • O código tem copyright e não é livre;
  • Não há garantias de que aquele código estará sempre lá;
  • As funções executam instruções que podem vir a ser riscos de segurança.

Eu já vi páginas web que pararam de funcionar porque o programador simplesmente anexou código de outro domínio. Quando esse código mudou de endereço, um sistema importante perdeu a consistência. Definitivamente, não faça isso, mesmo que você esteja sob grande pressão. Seu gerente tem a obrigação de aliviar esse stress.

CONCEITOS DE OOP (Programação Orientada a Objeto)

Dois conceitos importantes a dominar em Programação Orientada a Objeto são classe e objeto. A programação orientada a objetos (seu acrônimo em inglês é OOP) tornou-se popular no final dos anos 1990, quando a linguagem C++, de Bjarne Stroolstrup, passou a ser “a linguagem” de programação dos profissionais de computação. Outras linguagens orientadas a objetos como Delphi, Eiffel e Python foram usadas, mas C++ foi uma febre entre programadores. Até hoje ela é importante na programação do produto Windows.

Bertrand Meyer [Meyer, 1997] definiu o que é “qualidade de programa” ou seja, as características que fazem com que um programa seja bom. Dentre elas está alterabilidade (ou “Manutenibilidade”). É a capacidade de alterar facilmente um programa quando os requisitos são alterados, por exemplo. A OOP vem de encontro a esse item de qualidade.

Fatores Externos de Qualidade de Software (Bertrand Meyer)

Correção: característica do software que realiza as tarefas como foram definidas em sua especificação de requisitos.
Robustez: um software é robusto se realiza as suas tarefas de forma correta mesmo quando submetido a condições anormais.
Extensibilidade: característica de um software poder ser facilmente adaptado a inclusões e alterações de requisitos.
Reusabilidade: característica de um software que pode ser reutilizado ao todo ou em parte por outros softwares.
Compatibilidade: facilidade de se combinar o software com outros softwares. Essa característica é importante porque raramente um software é construído sem interação com outros softwares.
Eficiência: refere-se ao bom uso que o software faz dos recursos de hardware, tais como memória e processadores.
Portabilidade: é a facilidade de se utilizar o software em diferentes ambientes de hardware e software.
Verificabilidade: é a facilidade de se preparar rotinas para se verificar a conformidade do software com os seus requisitos.
Integridade: é uma característica relacionada à segurança de dados, programas e documentos. Integridade é a habilidade de proteger tais componentes contra acessos não autorizados.
Facilidade de uso: também denominada usabilidade, é a facilidade com que o software pode ser aprendido e utilizado, inclusive por pessoas com deficiência.

Fatores de Internos de Qualidade de Software

Modularidade: característica de um software que é constituído por unidades denominadas módulos.
Legibilidade : deve ser possível para um programador qualquer ler e entender o programa.
Manutenibilidade: facilidade de realizar manutenção em um software.

A forma com um software é construído permite atingir os fatores internos de qualidade. Os fatores internos de qualidade permitem atingir os fatores externos de qualidade. A Orientação por Objetos é um paradigma cujas características permitem a obtenção de software modular, legível e de fácil manutenção.”1

Costuma-se usar ferramentas nos próprios programas’, que permitem obter um feedback do usuário a cada momento (geralmente no fim de uma sessão). Assim ele ou ela podem informar automaticamente sobre seu grau de satisfação com o produto. Consulte a metodologia NPS (net promoter score2) e a ferramenta wootric3.

1– Veja [ http://portal6.pbh.gov.br/dom/Files/unidade.pdf ]

2https://pt.wikipedia.org/wiki/Net_Promoter_Score

3https://www.wootric.com/

A programação orientada a objetos (OOP) foi criada no início da década de 1970 no Xerox Corporation’s Palo Alto Research Center1. A OOP nasceu para atender aos critérios de qualidade de software, para torná-los possíveis dentro do desenvolvimento e de uma etapa até então desprezada: a manutenção . [MEYER, 1997], citando Lientz e Swanson, observa os custos de manutenção de software (portanto quando já está teóricamente pronto) por assunto:

1http://www.dba-oracle.com/t_object_database_model.htm

AssuntoCusto %
Modificação de requisitos de usuários41,8
Mudanças no formato dos dados17,6
Correções de emergência12,4
Correções de rotina9,0
Mudanças de hardware6,2
Documentação5,5
Melhoria de eficiência4,0
Outros3,4

Estimou-se que os custos do processo de manutenção, chegavam a 70% do custo do software. A OOP nasceu, portanto, para baratear a manutenção. Vamos tomar o exemplo da mudança no formato de dados. Antes da OOP, quando um conjunto de dados se alterava, era preciso modificar várias partes do sistema: A impressão de relatórios, a exibição dos dados na tela, a gravação em meio físico, a recuperação, a crítica. Com a OOP, os dados sabem como realizar essas operações. Idealmente, uma modificação nos dados leva à alteração automática das operações em todo o sistema.

Classes e objetos

Para começar, OOP trabalha com classes. Uma classe define a estrutura, os tipos de dados que a estrutura contém e os métodos e comportamentos usados para manipular os dados. Quando definimos uma variável que faz parte de uma classe, temos um “objeto”1. Muitas linguagens de programação lidam de forma natural com isso JavaScript, por exemplo, adapta o conceito de função para criar classes e seus objetos.

1 – [MEYER, 1997]é uma excelente referência sobre o assunto. Veja os itens 1.3 a 2.6 da obra.

Imagine que você precisa fazer um programa para cadastrar armas portáteis. Em nossa definição, arma portátil é toda aquela que pode ser carregada por uma pessoa apenas. Vamos melhorar a definição: arma portátil é toda aquela que pode ser carregada por uma pessoa apenas, sem chamar a atenção de outras pessoas. Assim, um revólver, uma pistola, uma faca, um machado curto são armas portáteis. Suponha uma hierarquia entre essas armas:

  1. Armas portáteis
    1. Armas de fogo
      1. pistola
      2. revolver
    2. Armas de eletrochoque
      1. taser
      2. stunt gun
    3. Armas brancas
      1. faca
      2. punhal
      3. machado

A lista não é extensa e nem pretende ser. É apenas um exemplo bem simples. Suponha então que eu queira definir uma classe de “armas portáteis”, de acordo com a lista acima. Se eu definir a classe “Arma” tenho de incluir uma informação sobre o que é essa arma: Arma de fogo, eletrochoque ou branca. Assim, parece razoável que eu tenha um descritor “Tipo”, dando essa informação.

Regra#1 das classes: Toda classe precisa de um construtor, um método para criar seus objetos na memória.

class Arma {
constructor(Tipo, SubTipo) {
this.Tipo = Tipo;
this.SubTipo = SubTipo;
}
}
Exemplo em JavaScript

O trecho acima quer dizer que, na hora de criar um objeto da classe Arma, tenho de informar o tipo e o subtipo. O operador “this” serve para definir uma variável interna à classe. Ele quer dizer que estou falando do Tipo que é usado internamente ao objeto, e não o que é passado por parâmetro. Quer dizer também que a variável Tipo informada no parêntesis não será usada lá dentro da classe. Será usada outra variável de mesmo nome mas que não altera a primeira. O mesmo podemos dizer em relação a subtipo. Confuso ? Redundante ? Vou esclarecer. O construtor é chamado de método e dá as ordens para a criação adequada do objeto na memória. O segredo é usar o comando “new”. Vamos ver no console JavaScxript:

Criando a classe Arma() em JavaScript.
fogo
console.log(p.SubTipo)
revolver
var a=p.Tipo
undefined
a
“fogo”
Saída do programa JavaScript.

Note que todas as variáveis (ou objetos) criados à semelhança daquela classe são iguais em estrutura e métodos. Se eu mudar a definição da classe num programa, todos os objetos pertencentes a ela serão automaticamente alterados. É isso que Bertrand Meyer quer dizer em seu estudo. Assim, lá vem a regra#2:

Regra#2 das classes: Toda classe precisa ser modificável, sem alterar o resto do programa.

Essa regra é desafiadora. Imagine que você criou o seu cadastro de armas, com suas telas, com gravação de informação num banco de dados, com relatórios. Se o seu cliente muda de ideia sobre as informações que irão no cadastro, você precisará alterar o programa aquelas partes todas. Mas se você usar corretamente as características da OOP, só precisará alterar um trecho: a classe Armas. Isso porque a classe Armas tem seus métodos. Ela terá, por exemplo, um método para fazer relatório, um método para gravar dados no banco de dados (no caso de Java, por exemplo), um método para mostrar o cadastro numa tela de computador ou num celular etc. Assim, alterando a classe, não é preciso alterar mais nada. Já adianto que na teoria é fácil. Mas na prática é preciso muita disciplina.

Vamos supor que, no caso de armas de fogo, só possam existir pistolas e revólveres. E vamos supor também que pistolas só possam ser aquelas homologadas para uso das polícias com munição .40, enquanto revólveres sejam apenas de uso particular, com munição .38. Sabemos que essa não é a realidade, mas estamos fazendo uma simplificação. Nossa classe ficaria assim:

class Arma {
constructor(Tipo, SubTipo, Municao) {
this.Tipo = Tipo;
this.SubTipo = SubTipo;
this.Municao = function(SubTipo) {
var Municao = “”;
if (SubTipo == ”pistola”) { Municao = “.40” }
else if (SubTipo == ”revolver”) { Municao = “.38” }
else
{ Municao = “” }
return(Municao);
}; // function
}; // constructor
}; // class Arma
Alteração da classe em JavaScript.

Eu defini uma função que vai colaborar com a inicialização de todos os objetos daquela classe. Essa função é defMunicao() e cria dados automaticamente para qualquer objeto da classe.

Note que JavaScript não trabalha com classes do mesmo modo que C++, Smalltalk, ou Java. Ela usa uma adaptação através de funções que lhe dão o “estilo” de linguagem OOP.

Existe banco de dados orientado a objeto ?

Primeiro precisamos refinar a pergunta. Um banco de dados orientado a objeto OODBMS é aquele que não segue o modelo de linhas e colunas (ou t-uplas). ou seja, não segue o modelo relacional. Tal sistema torna bem fácil traduzir as especificações de modelos orientados a objetos (classes) para os métodos de armazenamento. Considerando que os modelos baseados em classe são criados numa ferramenta CASE (como o Sparx Systems / Enterprise Architect) e que não tenho visto modo de traduzir automaticamente isso para om OODBMS, a resposta à pergunta acima tem de ser: não. Apesar de tais bancos existirem em teste no âmbito das universidades, os bancos de dados mais usados são os relacionas Oracle, MySql, MariaDB e PostgreSQL Nenhum deles orientado a objeto. O ideal seria que o armazenamento e recuperação de dados do banco (ou persistência de dados, como dizem) fosse feito com as características da própria linguagem OOP, de modo transparente. A Oracle tem feito pesquisas nesse sentido com a linguagem Java e a tecnologia DAO (Data Access Object) desde 2001. Em 2016, a Oracle publicou artigo1 relacionado a OOP e a linguagem, PL/SQL.

Três dos fundamentos da tecnologia OO são classes, objetos e mensagens. Uma classe descreve um grupo de objetos que têm relacionamentos, comportamentos e também possuem propriedades semelhantes. Um objeto abrange dados e funções relacionados em um pacote completamente independente. Como os objetos são “moldados” a partir de uma definição de classe comum, cada instância de um objeto dentro de uma classe herda todos os mesmos comportamentos e definições de dados. O coração de um banco de dados orientado a objetos é a persistência de objetos, e é o processo de armazenamento e recuperação de objetos que compreende o coração do gerenciamento de dados do objeto.”2 Outro aspecto crucial é a compatibilidade de soluções OOP de persistência com aplicações antigas, baseadas puramente em DBMS. Uma promessa interessante que irá alterar o modo como os novos programas são feitos é o banco de dados não-relacional MongoDB. Em breve estará disponível mais uma obra desta série: “MONGODB DE ZERO A CEM POR CENTO”, falando desse notável produto.

1– Ver [Burleson, 2020]

2– Ibdem

Características das linguagens OOP

Segundo Meyer, uma linguagem orientada a classes (i.e. a objetos) precisa apresentar as seguintes características:

Noção de classe: A noção de classe deve ser o conceito central da linguagem. A noção de classe é introduzida em JavaScript na especificação ECMA Script 2015. Na verdade, números são classes; strings também. Tanto é verdade, que existem propriedades e métodos para números, por exemplo.
Afirmações: A linguagem deve tornar possível equipar uma classe com afirmações (pré-condições, pós-condições, e invariantes), baseadas em ferramentas para produzir documentação a partir dessas afirmações e, opcionalmente, monitorá-las em tempo de execução.
Módulos: As classes devem ser os únicos módulos disponíveis.
Classes como tipos: Todo tipo deve ser baseado em uma classe. Em JavaScript, os tipos de dados (inteiro, ponto flutuante, booleano, indefinido, null, string, array etc), apesar de também terem métodos de declaração que se assemelham aos das linguagens antigas, na verdade são definidos colo classes, havendo uma equivalência do método comum de declarar com o método de classe. No caso da linguagem, os tipos são classes pré-definidas. Mesmo os operadores aritméticos, são na verdade propriedades de classes, podendo ser representados também pelos símbolos mais tradicionais (*, /, +. – etc).
Computação baseada em características: A chamada de uma característica deve ser o mecanismo primária da computação.
Ocultamento da informação: Deve ser possível para o criador de uma classe especificar que uma característica está disponível para todos os clientes, para nenhum cliente ou para clientes específicos.
Tratamento de exceções: A linguagem precisa prover um mecanismo para recuperar-se de uma situação anormal não esperada. Parra atender a essa característica, o JavaScript usa as declarações throw, try, catch e finally. Iremos conhecê-las mais tarde.
Tipagem estática: Um sistema de tipos bem definido deve, impondo um número de tipos regras de declaração e compatibilidade, garantir a segurança do tipo em tempo de execução nos sistemas que aceita.
Genericidade: Deve ser possível escrever classes com parâmetros genéricos formais representando tipos arbitrários.
Herança simples: Deve ser possível definir uma classe como herdada de outra.
Herança múltipla: Deve ser possível para uma classe herdar quantas outras forem necessárias, com um mecanismo adequado para desambiguar conflitos de nomes.
Herança repetida: Regras precisas devem governar o destino dos recursos sob herança repetida, permitindo que os desenvolvedores escolham, separadamente para cada herança herdada repetidamente recurso, entre compartilhamento e replicação.
Genericidade restrita: O mecanismo de genericidade deve suportar a forma restrita.
Redefinição: Deve ser possível redefinir a especificação, assinatura e implementação de um recurso herdado.
Polimorfismo: Deve ser possível anexar entidades (nomes nos textos do software representando objetos de tempo de execução) para objetos de tempo de execução de vários tipos possíveis, sob o controle do sistema de tipos baseados em herança.
Dynamic binding: Chamar um recurso em uma entidade sempre deve acionar o recurso correspondente ao tipo do objeto de tempo de execução anexado, que não é necessariamente o mesmo em diferentes execuções da chamada.
Interrogação de tipo em tempo de execução: Deve ser possível determinar em tempo de execução se o tipo de um objeto está em conformidade com um tipo estaticamente determinado.

Concurso para o Exército Brasileiro.

Está aberto processo seletivo para militares temporários nível fundamental, técnico e superior.

O militar temporário pode servir por até 8 anos em um quartel em que for designado (renovação de contrato anual baseado em desempenho e necessidade do Exército).

Nível Fundamental:
Cabo Especialista Temporário (CET)
Salário bruto aproximado: R$3.441,37

  • Eletricista Predial;
  • Eletrônica, Mecatrônica ou Eletro-Eletrônica;
  • Instrumento Musical (Bumbo, Clarineta Soprano Mib, Clarinete Soprano em Sib, Flugerlhorn Sib, Horn Sib Fá e Mib, Saxofone Soprano em Sib, Tarol, Trombone Tenor, Tuba Mib e Tuba Sib);
  • Motorista categoria D e/ou E;
  • Pintor de Pistola (Funelaria).

Pré-requisitos do processo seletivo:

  • Ser voluntário;
  • Ser brasileiro nato ou naturalizado;
  • Ter exclusivamente entre 19 e 35 anos de idade na data da incorporação;
  • Ter altura: homens no mínimo 1,60m e mulheres no mínimo 1,55m;
  • Ter concluído o ensino fundamental, em Estabelecimento de Ensino reconhecido pelo MEC;
  • Diplomas/Certificados dos demais Cursos realizados pelo(a) candidato(a) que sejam habilitados para área de interesse do Exército Brasileiro;
  • No caso de Motorista categoria “D” e/ou “E”, ser habilitado na categoria correspondente.

Nível Técnico:
Sargento Técnico Temporário (STT)
Salário bruto aproximado: R$ 5125,50

  • Administração;
  • Contabilidade;
  • Enfermagem;
  • Farmácia;
  • Informática;
  • Instrumento Musical (Clarinete, Contrabaixo, Harpa, Oboé, Percussão/ Xilofone, Saxofone Alto Mib, Trompa e Violoncelo);
  • Logística;
  • Mecânica de Auto;
  • Manutenção de Aeronave;
  • Radiologia.

Pré-requisitos do processo seletivo:

  • Ser voluntário;
  • Ser brasileiro nato ou naturalizado;
  • Ter exclusivamente entre 19 e 37 anos de idade no ano da convocação;
  • Ambos os sexos;
  • Ter altura: homens no mínimo 1,60m e mulheres no mínimo 1,55m;
  • Ter diploma do Ensino Médio Técnico, em Estabelecimento de Ensino reconhecido pelo MEC, que habilite o(a) candidato(a) a exercer o cargo da área de interesse do Exército Brasileiro;

Nível Superior:
Oficial Técnico Temporário (OTT)
Salário bruto aproximado: R$9.510,48 a R$11.295,65 (após 2 anos) ou R$14.016,50 (se tiver pós-graduação de interesse do Exército)

  • Administração;
  • Comunicação Social;
  • Contabilidade;
  • Direito;
  • Enfermagem;
  • Enfermagem com especialização em Intensivista/UTI;
  • Engenharia Civil;
  • Fisioterapia;
  • Informática;
  • Medicina;
  • Farmácia;
  • Odontologia;
  • Veterinária;
  • Outro curso superior concluído ou estar cursando (Oficial Combatente Temporário).

Pré-requisitos do processo seletivo:

  • Ser voluntário;
  • Ser brasileiro nato (Art. 12 da Constituição Federal/1988);
  • Ambos os sexos;
  • Ter exclusivamente até 38 anos de idade no ano da convocação;
  • Ter altura: homens no mínimo 1,60m e mulheres no mínimo 1,55m
  • Ter diploma de nível superior das áreas de interesse do Exército Brasileiro: Biológicas, Saúde, Exatas, Humanas, Sociais Aplicadas, Engenharias, Letras e Assistência Religiosa (Católica e Evangélica), em estabelecimento de ensino reconhecido pelo MEC;
  • Caso necessário, possuir especialização na área de interesse do Exército.

Mais informações disponíveis em: http://www.2rm.eb.mil.br/servicomilitar/

Certificados

Nesta página você conhece a lista de aprovados, lê seus testemunhos e confere seus certificados e currículos.

Nota sobre as vacinas contra o SARS-CoV-2

3 de julho de 2020 – Artigo de Reinaldo Guimarães

Talvez o fato mais espetacular ocorrido no panorama farmacêutico internacional nas últimas décadas foi a emergência e atual hegemonia dos medicamentos desenvolvidos por rota biológica, mormente no campo de macromoléculas, em substituição à mais que centenária rota de síntese química. Para as grandes empresas farmacêuticas esse fato colocou um problema e abriu uma imensa oportunidade. O problema foi a escassa competência tecnológica e fabril das farmacêuticas nessa nova rota: a oportunidade foi a descoberta daquela competência na indústria de vacinas. A resultante foi o início de um intenso processo de fusões e, principalmente aquisições de indústrias de vacinas por grandes empresas farmacêuticas. Entre 2005 e 2012, as 13 maiores compras e fusões desse tipo movimentaram cerca de US$ 220 bilhões e transformaram, em 2012, as farmacêuticas GSK, Sanofi, Pfizer, Merck e Novartis nos maiores produtores globais, sendo então responsáveis por cerca de 75% do mercado global de vacinas[1]. Atualmente o ranking pode estar modificado, mas o panorama permanece o mesmo

[ Leia mais ]

Alvin Toffler: ‘3ª onda’ é única opção para o Brasil

15 de agosto, 2002 – Publicado às 08h54 GMT

“Toffler – Bom, cada país é um caso diferente. Quando estive no Brasil muitos anos atrás, o presidente José Sarney planejava gastar milhões de dólares na construção de uma ferrovia que ligaria o norte ao sul do país. Eu disse na época que não era uma boa idéia. Outras coisas eram mais importantes. Era melhor usar o dinheiro para alimentar as crianças e desenvolver a agricultura para o consumo doméstico. Outra parte poderia ser usada para melhorar a educação. Uma pequena parte deveria ser destinada ao desenvolvimento da tecnologia para a terceira onda.”

[ Leia mais ]

Saúde Mental De Magistrados/As E Servidores/As No Contexto Da Pandemia Da Covid-19

O Comitê Gestor Nacional de Atenção Integral à Saúde de Magistrados e Servidores do Poder Judiciário, no uso de suas atribuições previstas na Portaria nº 06/2016 do Conselho Nacional de Justiça, solicita sua participação na pesquisa “Saúde Mental de magistrados e servidores no contexto da pandemia da COVID-19”.

Este questionário se destina a magistrados/as e servidores/as do Poder Judiciário e tem como objetivo identificar possíveis fatores de risco à saúde mental considerando o atual contexto da pandemia da COVID-19, bem como situações de isolamento ou confinamento social a que se veem submetidos, como forma de prevenção ou contenção do contágio.

[ Leia mais ]

Por que as videoconferências nos esgotam psicologicamente?

Especialistas concluem que a ausência de contato físico exige mais atenção

JOSÉ MENDIOLA ZURIARRAIN – El Pais
06 MAY 2020 – 12:23 BRT

A crise do coronavírus atingiu em cheio as organizações. Elas se viram obrigadas a forçar o teletrabalho, exceto em casos imprescindíveis, para evitar a interrupção das atividades. Esse novo formato enviou milhares de pessoas para suas casas e as forçou a adaptar nelas um novo espaço de trabalho, que precisa ser compartilhado com os demais moradores. E a tecnologia veio em seu socorro, com um desempenho tão bom que é possível até mesmo realizar reuniões por videoconferência, obtendo resultados, a priori, semelhantes aos de um encontro cara a cara. Mas é assim mesmo? Alguns especialistas alertam que o uso de ferramentas para videoconferências aumenta o nível de estresse dos participantes.

[ Leia mais ]