Atualização de software interestelar: a incrível missão da NASA com as Voyagers

Como desenvolvedor sei bem como é aplicar um patch num software em produção. Nesse tipo de situação temos que agir para detectar, corrigir e implementar a atualização o quanto antes e com o menor impacto possível aos usuários. No meu caso, a disponibilização de um patch é extremamente simples e rápida – na casa dos segundos – uma vez que a distância entre mim e o computador servidor é cerca de 6 km apenas.

Dito isso, você imagina como seria atualizar um software em um computador localizado a mais de 24 bilhões de km da Terra? Isso é mais de 160 vezes a distância entre a Terra e o Sol!

Representação da sonda Voyager no espaço profundo com o Sol ao fundo, distante mais de 24 bilhões de quilômetros.

Essa é a missão na qual uma equipe de engenheiros de software da missão Voyager da NASA está trabalhando. Os esforços é para ajudar a estender a vida útil de nossos exploradores interestelares – as espaçonaves Voyager – e garantir que ambos continuem a explorar o espaço interestelar nos próximos anos.

A equipe da NASA está carregando um patch de software para evitar a recorrência de uma falha que surgiu na Voyager 1. Essa atualização tem como objetivo evitar que o problema ocorra novamente na Voyager 1 ou surja em sua gêmea, a Voyager 2.

Em 2022, a Voyager 1 começou a enviar relatórios de status distorcidos, apesar de continuar operando normalmente. Os engenheiros da missão levaram meses para identificar o problema, que fazia com que o sistema de articulação e controle de atitudes da nave direcionasse comandos incorretamente, escrevendo-os na memória do computador em vez de executá-los. Um desses comandos perdidos acabou distorcendo o relatório de status do sistema antes que ele pudesse chegar aos engenheiros, aqui na Terra.

Aspecto do Centro de Controle das Missões Voyagers na NASA em 1977.

A equipe determinou que o sistema havia entrado em um modo operacional incorreto; no entanto, eles não conseguiram determinar a causa e, portanto, não têm certeza se o problema pode surgir novamente. O patch do software deve impedir isso.

“Este patch é como uma apólice de seguro que nos protegerá no futuro e nos ajudará a manter essas sondas funcionando o maior tempo possível. Essas são as únicas espaçonaves a operar no espaço interestelar, então os dados que eles estão enviando de volta são excepcionalmente valiosos para nossa compreensão de nosso universo local.”

Suzanne Dodd, gerente de projeto da Voyager do JPL

Pelas distâncias, as instruções do patch levarão mais de 18 horas para viajar até as espaçonaves. Por causa da idade das espaçonaves e do tempo de atraso de comunicação, há algum risco de que o patch possa substituir o código essencial ou ter outros efeitos não intencionais. Para evitar riscos, os engenheiros de software da NASA passaram meses escrevendo, revisando e verificando o código. Como precaução de segurança adicional, a Voyager 2 receberá o patch primeiro e servirá como um banco de testes para sua irmã gêmea. A Voyager 1 está mais longe da Terra do que qualquer outra espaçonave já construída pela humanidade, tornando seus dados mais valiosos.

O upload do patch, realizado em outubro de 2023, será seguido de uma leitura da memória do sistema para garantir que ele esteja no lugar certo. Se nenhum problema imediato surgir, a equipe emitirá um comando para ver se o patch está funcionando como deveria.

Aspecto atual do Centro de Controle de Missões da NASA.

É verdadeiramente impressionante pensar que a NASA é capaz de transmitir dados entre a Terra e as sondas Voyager a uma taxa de apenas 160 bits por segundo, sendo que seus computadores possuem 50 anos de idade e se afastam de nós a incríveis 16 km/s em média!

Para mim, isso é um testemunho do incrível avanço da tecnologia e da engenhosidade humana, uma vez que, mesmo a uma distância tão grande, somos capazes de manter uma linha de comunicação e continuar a aprender mais sobre o nosso universo. É um feito notável que continua a inspirar minha admiração e respeito pela exploração espacial. E você, o que acha disso?

Fonte: NASA

Usando variáveis de ambiente no Node.js

As variáveis de ambiente (environment variables) são aquelas definidas fora do código de nossa aplicação, mas que mesmo assim podemos fazer uso delas.

Elas são armazenadas como ‘chave-valor’ num arquivo em separado, do tipo texto, que pode ser facilmente editado, de acordo com a nossa conveniência, sendo bastante úteis para configuração de ambiente operacional, onde podemos guardar definições de caminhos de arquivos, bancos de dados, URL, chaves de autenticação etc., pois seus valores podem ser alterados a qualquer momento, sem que precisemos recompilar a aplicação.

No Node.js podemos facilmente utilizar essas variáveis através do objeto process.env, que é um objeto global e, por isso, pode ser acessado em qualquer módulo da aplicação.

Existem várias formas para definição e leitura de variáveis de ambiente, mas neste artigo trataremos do uso do pacote dotenv, um módulo de dependência que carrega as variáveis de ambiente a partir de um arquivo texto externo à aplicação diretamente no objeto global process.env do Node.js.

A instalação pode ser feita usando o npm ou yarn, conforme comandos a seguir:

Figura 1. Comando de instalação do pacote dotenv usando o NPM.
Figura 2. Comando de instalação do pacote dotenv usando o Yarn.

Após a instalação do pacote dotenv na pasta raiz do projeto, devemos criar um arquivo chamado .env, que armazenará nossas variáveis de ambiente, conforme figura 3.

Figura 3. Aspecto de uma estrutura de projeto Node.js, onde vemos o arquivo .env na pasta raiz do projeto e seu conteúdo.

👉 Por convenção, uma variável de ambiente deve ser escrita com letras maiúsculas e seu valor não deve estar entre aspas.

No arquivo de definição da aplicação (app.ts, por exemplo) importamos o módulo dotenv usando um require antes de qualquer outro código, conforme código da figura 4.

Figura 4. Típico arquivo app.ts, onde importamos o módulo dotenv usando o require.

Com a importação do módulo dotenv, podemos ler qualquer variável de ambiente contida no arquivo .env, a partir do objeto process.env, conforme código de exemplo contido na figura 5, onde lemos a variável de ambiente HTTP_PORT.

Figura 5. Leitura da variável de ambiente HTTP_PORT, a partir de process.env.

⚠️ Para concluir, é importante lembrar do cuidado em se armazenar dados sensíveis no arquivo .env, como senhas de bancos de dados e chaves de criptografia. Por essa razão é altamente recomendável incluir a referência ao arquivo .env no arquivo .gitignore.

Eu DBA – O Início da Saga

Neste artigo vamos fazer uma viagem ao passado – lá pela segunda metade dos Anos 80 – para relatar um pouquinho de minha história – e de muitos jovens da época – com a programação de computadores até me tornar o que sou hoje: DBA (administrador de bancos de dados).

Numa época de condições financeiras nada favoráveis e disponibilidade de recursos de aprendizagem escassos a gente se virava como podia – revistas emprestadas, poucos livros disponíveis e até mesmo uma “colinha” em exemplares nas bancas para pegar um trechinho de código que pudesse ajudar nos estudos.

Naquela época a Internet nem imaginava existir, ainda mais nos moldes que a conhecemos hoje, e as leis brasileiras restringiam bastante a entrada de novas tecnologias no país – e até hoje somos atrasados tecnologicamente.

Como sempre gostei de matemática – anos depois acabaria por me graduar em Matemática e depois me especializar em Informática – desvendar-me pelo mundo da computação era um desafio muito prazeroso.

Desde o começo o meu foco foi pelo desenvolvimento para bancos de dados. Sempre achei incrível a programação para o armazenamento e recuperação de informações e uma de minhas primeiras ideias era criar um banco de dados para armazenar os dados dos meus livros.

É aí que começa a saga com os computadores pessoais, mais especificamente com o TK 90X.

logo_tk_90x
Figura 1. Logomarca do TK 90X color computer.

O TK 90X, produzido pela Microdigital em 1985, foi o primeiro clone brasileiro do microcomputador inglês ZX Spectrum produzido pela Sinclair Reseach. Utilizava como linguagem de programação residente o BASIC Sinclair (hoje temos a poderosa C#). Seu processador era um Z80A, de 8 bits (hoje temos os processadores de 64 bits nos notebooks e tablets), com um Clock de 3,58 MHz (o meu smartphone atual é 850 vezes mais veloz). A Memória RAM era de incríveis 48 Kbits (o meu smartphone atual tem 22 mil vezes mais memória que isso) e resolução de vídeo era de 192 x 256 pixels (as resoluções 4K hoje em dia suportam 3840 × 2160 pixels), com uma quantidade de cores suportada de 8 cores, com 2 tons cada (os monitores atuais suportam mais de 16 milhões de cores).

tk_90x
Figura 2. TK 90X color computer. Meu primeiro computador pessoal.

Na época, um regulamento brasileiro especial permitia que a indústria local pudesse produzir e vender cópias de computadores estrangeiros (só para o mercado doméstico) e por isso obteve um grande sucesso no Brasil, iniciando muitos jovens da época na arte da programação de computadores, entre os quais eu.

Era sofrido, mas era incrível naquela época, sem recursos, sem Internet, sem literatura adequada, sem instrutores, sem outras pessoas com quem conversar a respeito – na época éramos eu e meu primo e amigo, então proprietário do TK 90X, dividindo experiências e conhecimentos adquiridos na programação de computadores.

tk_90x_programas_para_jovens_programadores       banco_de_dados_para_tk_90x
Figura 3. Dois dos raros livros disponíveis no Brasil na época voltados para a programação.

Quando me tornei proprietário do TK 90X é que pude me aprofundar mais nos estudos, durante as noites-madrugadas, depois que a TV ficava livre e disponível. Sim, o TK 90X não possuía monitor e tínhamos que liga-lo à TV para poder funcionar. E naquela época não tínhamos TV em cada cômodo da casa como hoje em dia não, heim?

basic_tk_90x
Figura 4. Aspecto da tela da TV com o a interface do TK 90X e um trecho de código em linguagem BASIC de programação.

O chato era que o aparelho não possuía sistema de armazenamento permanente, ou seja, ao desliga-lo se perdia toda a programação feita e no dia seguinte tínhamos que iniciar a programação do zero! Já deu pra imaginar que não dava pra criar grandes programas desta forma né? Tinha que adquirir um gravador de fita K7 – isso mesmo, os dados permanentes eram armazenados em fita K7, na velocidade padrão de uma fita K7, dá pra imaginar isso? E você ainda reclama da lentidão de seu computador atual…

tk85
Figura 5. Aspecto de um ambiente de trabalho com o TK 90X na época. Imagem da Internet.

Com o advento do gravador de fita K7 pude armazenar meus primeiros programas de bancos de dados, sendo estes os eventos iniciais de minha saga na programação para bancos de dados, o que ainda realizo até os dias atuais, mas com as grandes facilidades da época atual, como linguagem de programação de alto nível e recursos de pesquisa e computacionais altamente avançados, além da Internet e os grupos de discussão especializados existentes por todo o ambiente virtual, tendo passado antes pelas gerações do MSX, CP 500 da Prológica, IBM PC XT, toda a família x86 até os PCs e notebooks atuais.

gradiente_expert
Figura 6. Computador MXS da Gradiente. Este já possuía cartuchos para gravação dos programas.  Foto da Internet.

cp500
Figura 7. Meu primeiro curso de programação foi com o CP 500, que já utilizava disquetes de 5 polegadas. Um avanço na época.

Hoje, não precisamos sair de casa. Não precisamos de cursos especializados. Não precisamos de mestres instrutores. Precisamos apenas da nossa capacidade matemática e a mesma garra e disposição que tínhamos nos anos primeiros da saga para construirmos grandes soluções que não ficam restritas apenas ao nosso ambiente computacional pessoal, mas atingem números que passam da casa dezenas de milhares de pessoas, através do ambiente compartilhado da Internet.

ambiente_atual
Figura 8. Aspecto atual do meu ambiente de trabalho em casa. Computadores avançados e Internet para conectar-me com o mundo.

E olhando assim para trás é que a gente percebe como a tecnologia avançou desde os incríveis Anos 80, onde tudo começou, e vendo as notícias de tecnologia atuais imaginamos como será daqui a 30 anos, com todo o avanço na área de robótica e inteligência artificial.

De minha parte, vou continuar com o meu foco na programação voltada para bancos de dados, mas sempre com os pés no momento presente, adequando os estilos, usando as melhores ferramentas disponíveis e idealizando as melhores soluções na gestão de sistemas de bancos de dados.

codigo_c_sharp
Figura 9. Aspecto da interface de programação atual utilizando linguagem C#.

programacao_mobile
Figura 10. Aspecto da interface de um aplicativo desenvolvimento para smartphones atuais.

O desafio de hoje não são os raros recursos disponíveis, mas sim a enorme variedade de ferramentas, ambientes e tecnologias disponíveis, logicamente aliados à velha disposição e garra de dominar os novos desafios e algo que só o tempo e a experiência de vida pode proporcionar: o conhecimento por experiência prática e não teórica. Smiley piscando

A saga continua!!!