O ScriptNive é um script desenvolvido em batch, criado para fornecer soluções rápidas e eficazes para a maioria dos erros comuns encontrados em sistemas Windows. O NiveBoost é um script desenvolvido em batch, criado para fornecer otimização no Windows fazendo ele ficar rápido e leve.

O ScriptNive 1.6.8 oferece um menu com diversas opções para corrigir problemas em sistemas Windows 7 e versões posteriores. Este projeto foi desenvolvido com o intuito de ajudar usuários a resolver problemas básicos de forma rápida e eficiente.

• Informação Sobre ScriptNive: Abrirá este PDF com todas as funções e explicações técnicas sobre como usar o ScriptNive e NiveBoost independentemente da sua versão.

• Informações gerais do Computador: Executa várias linhas de código no CMD mostrando todas as configurações de hardware do seu computador, permitindo que você consulte informações detalhadas sobre o seu hardware.

• Crédito Do ScriptNive: Levará você Para um outro menu do scriptnive informando sobre quem é o criador do Script , Quais sites ele usou para poder criar ‘ferramentas’ e que ajudou no projeto.

• Verificar diagnóstico de erro: Inicia o “Monitor de Confiabilidade no Windows”, Que vai estar exibindo um diagnóstico de erros no seu sistema operacional.

• Otimizar Windows: Inicia o Script NiveBoost, que possui um menu amplo de formas de otimização e aceleramento do Windows.

• Esvaziar a Lixeira:Executa um comando que limpa a lixeira do sistema. Nota: Certifique-se de que não há itens importantes na lixeira antes de esvaziá-la.

• Ativar GodMode no PC: Vai rodar um comando secreto do Windows que vai criar um atalho na área de trabalho criando um arquivo que vai te dar várias permissões ocultas do Windows controlando e deixando a sua possibilidade de otimização maior.

• Solucionar erros no HD/SSD: Verifica a integridade do disco rígido (HD) ou (SSD) e corrige erros encontrados.

• Verificar Erros na RAM: Ativa o mdsched (Diagnóstico de memória do Windows) , Serve para verificar se alguma das memórias está com algum problema .

• Reparador de Sistema: Executa a ferramenta de verificação de arquivos do sistema (SFC), reparando arquivos corrompidos.

Limpar Arquivos Temporários e HD: Permite a limpeza de arquivos desnecessários ou temporários no HD, liberando espaço e melhorando o desempenho do sistema.

Limpar o Cache da DNS: Executa comandos para limpar o cache DNS, corrigindo possíveis problemas de conexão de rede. Nota: Esta função não reconecta automaticamente sua internet em caso de queda.

Painel de Controle: Abre o Painel de Controle do Windows, permitindo a personalização das configurações do sistema. Nota: Utilize esta função apenas se tiver conhecimento técnico adequado.

Gerenciador de Tarefas: Abre o Gerenciador de Tarefas do Windows, permite monitorar o consumo de algum softwares também pode estar finalizando tarefas do software. Nota: Utilize esta função apenas se tiver conhecimento técnico adequado.

Iniciar o MRT: Inicia a Ferramenta de Remoção de Software Malicioso (MRT) da Microsoft, que atua como um antivírus básico. Nota: Esta ferramenta não substitui um antivírus completo.

Atualizador de Programas: Faz uma varredura completa no seu computador por buscas de programas desatualizados e logo em seguida atualiza todos os programas.

Resolvendo Problemas de Som: Executa uma linha de comandos com a função de recuperar ou solucionar problemas na conexão de áudio tanto na entrada quanto da saída.

Reinstalar Software Problemático: Executa um Power Shell que utiliza o Chocolatey que é um gerenciador de pacotes para Windows que simplifica a instalação, atualização e gerenciamento de softwares.

Deletar Pastas Corrompidas: Executa uma sequência de comandos em cadeia para excluir pastas fantasmas ou pastas que estão sendo bloqueadas por algum tipo de bug.Nota: Verifique com cuidado qual pasta você quer deletar.

Reparo Completo do Windows: Executa uma sequência de comandos para reparo completo do sistema, incluindo reparos de HD/SSD e integridade do sistema operacional.

O NiveBoost 1.1.0 oferece um menu com diversas opções para otimizar o sistemas Windows , projetado para realizar atualizações que tornam o sistema mais leve, rápido e ágil. Importante destacar que este script utiliza apenas funções nativas do Windows e não requer a instalação de programas adicionais.

Informação Sobre NiveBoost: Abrir o PDF com todas as funções e explicações técnicas sobre como usar o ScriptNive e NiveBoost independentemente da sua versão.

Crédito Do NiveBoost: Leva você para outro menu do ScriptNive, informando sobre o criador do script e os sites usados para criar as ferramentas que ajudaram no projeto.

Recomendações Técnicas: Mostrará o menu com algumas recomendações de uso do NiveBoost. (Resumo do que se pode estar fazendo para evitar problemas futuros.)

Retornar ao ScriptNive: Estará encerrando o script NiveBoost e retornará para o ScriptNive.

Desabilitar Alguns Serviços Do Windows: Desativa serviços do Windows que não são essenciais para o funcionamento diário do sistema, liberando recursos e melhorando o desempenho geral.

Desabilitar Tweaks De Tarefas Agendadas: Desativa tarefas agendadas que realizam ajustes e operações que podem consumir recursos desnecessários, permitindo que o sistema opere de maneira mais eficiente.

Desabilitar Alguns Softwares do Windows: Desativa aplicativos pré-instalados no Windows que muitas vezes não são utilizados, reduzindo o uso de memória e recursos do sistema.

Remover Telemetria e Coleta de Dados: Desativa a coleta de dados e telemetria do Windows, preservando a privacidade do usuário e liberando recursos que seriam utilizados para essas funções.

Remover Features Não Usadas: Desativa várias funcionalidades do Windows que não são frequentemente utilizadas, otimizando o desempenho do sistema.

Remover Animações Inúteis: Desativa animações visuais que são utilizadas apenas por estética. Tornando o sistema mais rápido ao custo de uma aparência menos atraente.

Desabilitar Busca Web Na Barra De Pesquisa: Desativa a função de pesquisa na web da barra de busca do Windows, acelerando as buscas locais e reduzindo poluição visual .

Desabilitar Escrita De Cache De Navegadores e Streaming:Desativa a escrita de cache de navegadores e serviços de streaming, liberando recursos de armazenamento e melhorando a performance do sistema.

Desabilitar Propagandas na Tela de Bloqueio: Remove as propagandas exibidas na tela de bloqueio do Windows, proporcionando uma experiência de usuário mais limpa e rápida.

Otimizar o Edge: Ajusta o navegador Edge, removendo funções desnecessárias para que ele não consuma tanta memória e processamento tanto em segundo plano quanto em uso padrão.

Acelerar Windows: Executa uma série de comandos que aceleram o tempo de inicialização do Windows, removem arquivos desnecessários e temporários, e otimizam o sistema para um desempenho mais eficiente. Nota: quem possui essa SSD nvme m2 , não é recomendada a ativação por que pode acabar ocasionando crash no Windows. Recomendado criar um ponto de restauração.

1. Criar um ponto de Restauração: Antes de utilizar os scripts é recomendado fazer um ponto de restauração.
2. Reiniciar após execução:: Após utilizar qualquer comando do script, é recomendado reiniciar o computador.
3. Evitar execuções excessivas: Não execute os comandos de forma excessiva para evitar possíveis problemas futuros no sistema.
4. Segurança dos comandos: Todos os comandos utilizados são certificados pela Microsoft e seguros para resolver problemas básicos de forma eficiente.
5. Segurança em primeiro lugar: Caso você não sinta confiável ou está com receio de ativar algum dos comandos recomendo contatar um técnico de computação. Caso queira me contatar eu vou estar deixando formas de contato no final do PDF.

Acesse esse PDF para evitar possíveis erros na hora da instalação : Link

Caso seja necessário pode me contatar , Através Das minhas redes sociais.

Este projeto foi desenvolvido por Ryan Vinicius Carvalho Pereira. Agradeço por explorar o ScriptNive e espero que você encontre soluções rápidas e eficazes para os problemas do seu sistema Windows.

Se você gostou do projeto ou tem alguma sugestão, sinta-se à vontade para contribuir ou entrar em contato.

Obrigado por visitar o ScriptNive !!

O ScriptNive é um script desenvolvido em batch, criado para fornecer soluções rápidas e eficazes para a maioria dos erros comuns encontrados em sistemas Windows. O NiveBoost é um script desenvolvido em batch, criado para fornecer otimização no Windows fazendo ele ficar rápido e leve.

O ScriptNive 1.6.8 oferece um menu com diversas opções para corrigir problemas em sistemas Windows 7 e versões posteriores. Este projeto foi desenvolvido com o intuito de ajudar usuários a resolver problemas básicos de forma rápida e eficiente.

• Informação Sobre ScriptNive: Abrirá este PDF com todas as funções e explicações técnicas sobre como usar o ScriptNive e NiveBoost independentemente da sua versão.

• Informações gerais do Computador: Executa várias linhas de código no CMD mostrando todas as configurações de hardware do seu computador, permitindo que você consulte informações detalhadas sobre o seu hardware.

• Crédito Do ScriptNive: Levará você Para um outro menu do scriptnive informando sobre quem é o criador do Script , Quais sites ele usou para poder criar ‘ferramentas’ e que ajudou no projeto.

• Verificar diagnóstico de erro: Inicia o “Monitor de Confiabilidade no Windows”, Que vai estar exibindo um diagnóstico de erros no seu sistema operacional.

• Otimizar Windows: Inicia o Script NiveBoost, que possui um menu amplo de formas de otimização e aceleramento do Windows.

• Esvaziar a Lixeira:Executa um comando que limpa a lixeira do sistema. Nota: Certifique-se de que não há itens importantes na lixeira antes de esvaziá-la.

• Ativar GodMode no PC: Vai rodar um comando secreto do Windows que vai criar um atalho na área de trabalho criando um arquivo que vai te dar várias permissões ocultas do Windows controlando e deixando a sua possibilidade de otimização maior.

• Solucionar erros no HD/SSD: Verifica a integridade do disco rígido (HD) ou (SSD) e corrige erros encontrados.

• Verificar Erros na RAM: Ativa o mdsched (Diagnóstico de memória do Windows) , Serve para verificar se alguma das memórias está com algum problema .

• Reparador de Sistema: Executa a ferramenta de verificação de arquivos do sistema (SFC), reparando arquivos corrompidos.

Limpar Arquivos Temporários e HD: Permite a limpeza de arquivos desnecessários ou temporários no HD, liberando espaço e melhorando o desempenho do sistema.

Limpar o Cache da DNS: Executa comandos para limpar o cache DNS, corrigindo possíveis problemas de conexão de rede. Nota: Esta função não reconecta automaticamente sua internet em caso de queda.

Painel de Controle: Abre o Painel de Controle do Windows, permitindo a personalização das configurações do sistema. Nota: Utilize esta função apenas se tiver conhecimento técnico adequado.

Gerenciador de Tarefas: Abre o Gerenciador de Tarefas do Windows, permite monitorar o consumo de algum softwares também pode estar finalizando tarefas do software. Nota: Utilize esta função apenas se tiver conhecimento técnico adequado.

Iniciar o MRT: Inicia a Ferramenta de Remoção de Software Malicioso (MRT) da Microsoft, que atua como um antivírus básico. Nota: Esta ferramenta não substitui um antivírus completo.

Atualizador de Programas: Faz uma varredura completa no seu computador por buscas de programas desatualizados e logo em seguida atualiza todos os programas.

Resolvendo Problemas de Som: Executa uma linha de comandos com a função de recuperar ou solucionar problemas na conexão de áudio tanto na entrada quanto da saída.

Reinstalar Software Problemático: Executa um Power Shell que utiliza o Chocolatey que é um gerenciador de pacotes para Windows que simplifica a instalação, atualização e gerenciamento de softwares.

Deletar Pastas Corrompidas: Executa uma sequência de comandos em cadeia para excluir pastas fantasmas ou pastas que estão sendo bloqueadas por algum tipo de bug.Nota: Verifique com cuidado qual pasta você quer deletar.

Reparo Completo do Windows: Executa uma sequência de comandos para reparo completo do sistema, incluindo reparos de HD/SSD e integridade do sistema operacional.

O NiveBoost 1.1.0 oferece um menu com diversas opções para otimizar o sistemas Windows , projetado para realizar atualizações que tornam o sistema mais leve, rápido e ágil. Importante destacar que este script utiliza apenas funções nativas do Windows e não requer a instalação de programas adicionais.

Informação Sobre NiveBoost: Abrir o PDF com todas as funções e explicações técnicas sobre como usar o ScriptNive e NiveBoost independentemente da sua versão.

Crédito Do NiveBoost: Leva você para outro menu do ScriptNive, informando sobre o criador do script e os sites usados para criar as ferramentas que ajudaram no projeto.

Recomendações Técnicas: Mostrará o menu com algumas recomendações de uso do NiveBoost. (Resumo do que se pode estar fazendo para evitar problemas futuros.)

Retornar ao ScriptNive: Estará encerrando o script NiveBoost e retornará para o ScriptNive.

Desabilitar Alguns Serviços Do Windows: Desativa serviços do Windows que não são essenciais para o funcionamento diário do sistema, liberando recursos e melhorando o desempenho geral.

Desabilitar Tweaks De Tarefas Agendadas: Desativa tarefas agendadas que realizam ajustes e operações que podem consumir recursos desnecessários, permitindo que o sistema opere de maneira mais eficiente.

Desabilitar Alguns Softwares do Windows: Desativa aplicativos pré-instalados no Windows que muitas vezes não são utilizados, reduzindo o uso de memória e recursos do sistema.

Remover Telemetria e Coleta de Dados: Desativa a coleta de dados e telemetria do Windows, preservando a privacidade do usuário e liberando recursos que seriam utilizados para essas funções.

Remover Features Não Usadas: Desativa várias funcionalidades do Windows que não são frequentemente utilizadas, otimizando o desempenho do sistema.

Remover Animações Inúteis: Desativa animações visuais que são utilizadas apenas por estética. Tornando o sistema mais rápido ao custo de uma aparência menos atraente.

Desabilitar Busca Web Na Barra De Pesquisa: Desativa a função de pesquisa na web da barra de busca do Windows, acelerando as buscas locais e reduzindo poluição visual .

Desabilitar Escrita De Cache De Navegadores e Streaming:Desativa a escrita de cache de navegadores e serviços de streaming, liberando recursos de armazenamento e melhorando a performance do sistema.

Desabilitar Propagandas na Tela de Bloqueio: Remove as propagandas exibidas na tela de bloqueio do Windows, proporcionando uma experiência de usuário mais limpa e rápida.

Otimizar o Edge: Ajusta o navegador Edge, removendo funções desnecessárias para que ele não consuma tanta memória e processamento tanto em segundo plano quanto em uso padrão.

Acelerar Windows: Executa uma série de comandos que aceleram o tempo de inicialização do Windows, removem arquivos desnecessários e temporários, e otimizam o sistema para um desempenho mais eficiente. Nota: quem possui essa SSD nvme m2 , não é recomendada a ativação por que pode acabar ocasionando crash no Windows. Recomendado criar um ponto de restauração.

1. Criar um ponto de Restauração: Antes de utilizar os scripts é recomendado fazer um ponto de restauração.
2. Reiniciar após execução:: Após utilizar qualquer comando do script, é recomendado reiniciar o computador.
3. Evitar execuções excessivas: Não execute os comandos de forma excessiva para evitar possíveis problemas futuros no sistema.
4. Segurança dos comandos: Todos os comandos utilizados são certificados pela Microsoft e seguros para resolver problemas básicos de forma eficiente.
5. Segurança em primeiro lugar: Caso você não sinta confiável ou está com receio de ativar algum dos comandos recomendo contatar um técnico de computação. Caso queira me contatar eu vou estar deixando formas de contato no final do PDF.

Acesse esse PDF para evitar possíveis erros na hora da instalação : Link

Caso seja necessário pode me contatar , Através Das minhas redes sociais.

Este projeto foi desenvolvido por Ryan Vinicius Carvalho Pereira. Agradeço por explorar o ScriptNive e espero que você encontre soluções rápidas e eficazes para os problemas do seu sistema Windows.

Se você gostou do projeto ou tem alguma sugestão, sinta-se à vontade para contribuir ou entrar em contato.

Obrigado por visitar o ScriptNive !!

These are Matthew McCullough’s shell configuration dotfiles. The primary goal is to increase CLI productivity on Mac OSX, though many scripts run just fine on any POSIX implementation.

The focus is on Zshell support, but there are plenty of cross-platform scripts in here. There are a few bash-specific ones.

The contents of this repo have been partly invented from scratch, partly inspired by open source projects, and partly refactored from snippets from colleagues and friends. Many are attributed.

This project contains submodules. It is suggested that you clone this into your home directory.

cd ~
git clone --recurse-submodules https://github.com/matthewmccullough/dotfiles .dotfiles

There is a set up script that establishes the symlinks in your home directory. Run this once.

• For ZShell
  ~/.dotfiles/_setupdotfiles.zsh
• For Bash (needs some fixes)
  ~/.dotfiles/_setupdotfiles.bsh

NOTE: Some personal configuration of Matthew’s will remain after setup. These dotfiles are intended for your inspiration, forking, and for you to tweak to your specific needs.

Reminder-to-self: Some additional personalization lives in the ~/.config/ directory. Specifically, the ~/.config/gh/config.yml file for gh. It is not yet in scope for capture or copy, but some uers have shared their configuration in a Gist.

Contributions are always welcome in the form of pull requests with explanatory comments.

1. Loathing should be directed into pull requests that make it better.
2. Bugs with the setup should be put as GitHub issues.
3. Mehs should be directed to /dev/null
4. Praise should be directed to @matthewmccull on Twitter

Status: Closed

Our TomoX Testnet Bounty Program is an experimental and discretionary program that allows us to encourage and reward members of the TomoChain community for helping us find and address significant bugs in accordance with the rules set out below.

Any questions for bug report program, feel free to create an issue.

For the security issue, you can report it to our bug bounty program on WhiteHub platform: https://whitehub.net/programs/tomochain

Your mission: Report bugs.

The bonus is based on the technical severity of the reported vulnerabilities, ranging from 50 TOMO to 1000 TOMO

Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard).

Time estimation:

Review and Discussion: We will respond in 3 working days. The actual length of time from Response to Eligible Bug Confirmation depends on the complexity of the issue.

Issue Resolution: 10 working days

Bounty Rewarded: On the first working day of the following month

A bug or new feature report must follow the process to be considered for reward:

• Create an issue on TomoChain Github Bug Reports Repository: https://github.com/tomochain/bug-reports. Please include your TomoWallet address in the report.
• You should report the issue in as detailed as possible with reproducible steps (Please attach all supporting files (e.g. video, screenshots, configuration files, data files, output files, etc.). If the report is not detailed enough to reproduce the issue, the finder will not be eligible for rewards.
• If you propose a new feature, please explain why we need that feature and how it makes our products better.
• A proposal(s) to address or fix the issue is highly recommended. This could be a design proposal or include actual fix(es) to software code.
• Issues already submitted by another user or already known to the TomoChain team are not eligible for bounty rewards.
• Kindly note that any issue found and made public in any way forfeits the finder’s right to the bounty.
• Multiple bugs caused by one underlying issue will be awarded one bounty.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

TomoDEX:

• Site: https://dex.testnet.tomochain.com
• Source code: https://github.com/tomochain/tomox-sdk and https://github.com/tomochain/tomox-sdk-ui

TomoRelayer:

• Site: https://relayer.testnet.tomochain.com
• Source code: https://github.com/tomochain/tomorelayer

TomoX:

• Source code: https://github.com/tomochain/tomochain

• TomoDEX, TomoRelayer on Mobile browser.
• Translation

Please read our Medium blog post to have a quick understanding of the TomoX products: https://medium.com/tomochain/say-hello-to-tomox-public-testnet-and-launch-your-own-permissionless-dex-in-minutes-6d735ce557ba

The TomoX Testnet now is available, you can see the products by following the links below:

• TomoChain network stats: https://stats.testnet.tomochain.com
• TomoDex (a DEX’s based on TomoX protocol): https://dex.testnet.tomochain.com
• TomoRelayer (TomoX Governance DApp): https://relayer.testnet.tomochain.com

TomoX:

Follow this guide to know how to run a TomoX Relayer: https://docs.tomochain.com/masternode/tomox-sdk/

TomoDEX:

Follow this guide to know how to using TomoDEX: https://medium.com/tomochain/trading-with-tomodex-the-first-decentralized-exchange-on-tomox-3ec5b377023d

TomoRelayer:

Follow this guide to know to use TomoRelayer: https://medium.com/tomochain/launch-your-own-dex-with-tomorelayer-eb440a2d6a3d

Terms and Conditions:

TomoChain reserves the right to cancel or amend the Program and the Program rules at its own discretion.

Each participant is responsible for monitoring his/her Github account for notification or other communications related to this Program.

If a potential reward winner cannot be reached by TomoChain within ten (10) working days, that potential reward winner shall forfeit the prize. Rewards are made at the sole discretion of the TomoChain.

TomoChain’s core development team, employees and all other people paid by the TomoChain project, directly or indirectly, are not eligible for rewards.

For further technical information, please join our channels:

TomoX telegram Channel: https://t.me/TomoX

Docx rendering library

Demo – https://volodymyrbaydalka.github.io/docxjs/

Goal of this project is to render/convert DOCX document into HTML document with keeping HTML semantic as much as possible. That means library is limited by HTML capabilities (for example Google Docs renders *.docx document on canvas as an image).

npm install docx-preview

// renders document into specified element
renderAsync(
    document: Blob | ArrayBuffer | Uint8Array, // could be any type that supported by JSZip.loadAsync
    bodyContainer: HTMLElement, //element to render document content,
    styleContainer: HTMLElement, //element to render document styles, numbeings, fonts. If null, bodyContainer will be used.
    options: {
        className: string = "docx", //class name/prefix for default and document style classes
        inWrapper: boolean = true, //enables rendering of wrapper around document content
        hideWrapperOnPrint: boolean = false, //disable wrapper styles on print
        ignoreWidth: boolean = false, //disables rendering width of page
        ignoreHeight: boolean = false, //disables rendering height of page
        ignoreFonts: boolean = false, //disables fonts rendering
        breakPages: boolean = true, //enables page breaking on page breaks
        ignoreLastRenderedPageBreak: boolean = true, //disables page breaking on lastRenderedPageBreak elements
        experimental: boolean = false, //enables experimental features (tab stops calculation)
        trimXmlDeclaration: boolean = true, //if true, xml declaration will be removed from xml documents before parsing
        useBase64URL: boolean = false, //if true, images, fonts, etc. will be converted to base 64 URL, otherwise URL.createObjectURL is used
        renderChanges: false, //enables experimental rendering of document changes (inserions/deletions)
        renderHeaders: true, //enables headers rendering
        renderFooters: true, //enables footers rendering
        renderFootnotes: true, //enables footnotes rendering
        renderEndnotes: true, //enables endnotes rendering
        renderComments: false, //enables experimental comments rendering
        renderAltChunks: true, //enables altChunks (html parts) rendering
        debug: boolean = false, //enables additional logging
    }): Promise<WordDocument>

/// ==== experimental / internal API ===
// this API could be used to modify document before rendering
// renderAsync = parseAsync + renderDocument

// parse document and return internal document object
parseAsync(
    document: Blob | ArrayBuffer | Uint8Array,
    options: Options
): Promise<WordDocument>

// render internal document object into specified container
renderDocument(
    wordDocument: WordDocument,
    bodyContainer: HTMLElement,
    styleContainer: HTMLElement,
    options: Options
): Promise<void>

Thumbnails is added only for example and it’s not part of library. Library renders DOCX into HTML, so it can’t be efficiently used for thumbnails.

Table of contents is built using the TOC fields and there is no efficient way to get table of contents at this point, since fields is not supported yet (http://officeopenxml.com/WPtableOfContents.php)

Currently library does break pages:

• if user/manual page break <w:br w:type="page"/> is inserted – when user insert page break
• if application page break <w:lastRenderedPageBreak/> is inserted – could be inserted by editor application like MS word (ignoreLastRenderedPageBreak should be set to false)
• if page settings for paragraph is changed – ex: user change settings from portrait to landscape page

Realtime page breaking is not implemented because it’s requires re-calculation of sizes on each insertion and that could affect performance a lot.

If page breaking is crutual for you, I would recommend:

• try to insert manual break point as much as you could
• try use editors like MS Word, that inserts <w:lastRenderedPageBreak/> break points

NOTE: by default ignoreLastRenderedPageBreak is set to true. You may need to set it to false, to make library break by <w:lastRenderedPageBreak/> break points

So far I can’t come up with final approach of parsing documents and final structure of API. Only renderAsync function is stable and definition shouldn’t be changed in future. Inner implementation of parsing and rendering may be changed at any point of time.

Please do not include contents of ./dist folder in your PR’s. Otherwise I most likely will reject it due to stability and security concerns.

API para consultar los CP de México.

Depende de donde se vaya a desplegar el proyecto. Ya sea un servidor vps como Digital Ocean, AWS, entre otros. U otros servidores que ya esten preconfigurados como Heroku

Se tiene que tener instalado el CLI de heroku y desde ahi se manipula todo el servidor(es importante tener Git tambien). Es necesario usar una base de datos PostgreSQL que en este caso Heroku facilida la integración de la base de datos proporcionando así los datos de configuración. Aquí se tiene la facilidad de pasarle los datos confidentiales por medio de variables de entorno. Se tiene que organizar un archivo llamado Procfile con los comandos que el servidor va a correr. Aqui se integra unicorn para servir los archivos.

Al hacer push al repositorio de Heroku, este automaticamente detecta el lenguaje de programación y lo instala en el servidor, posteriormente, por medio de pip instala lo que encuentre en la archivo requirements.txt y al final ejecuta el archivo procfile donde el servidor se activa(es importante que para este punto, se haya cambiado la condiguración de modo de producción)

Aqui se tiene que considerar que se tiene una maquina (generalmente Unix) desde cero. Por lo que hay que configurar cada servicio por separado; como instalar las bases de datos que se vayan a utilizar, los lenguages de programación que se vayan a usar, Git, instalación de dependencias, etc. Para poder usar este servidor se tiene que establecer una comunicación por SSH a la ip (maquina) que nos proporcionan, por este medio es que podremos interactuar con el sistema mediante el uso de la consola.

Aqui se tiene que hacer un pull de los archivos que esten en el proyecto y para estos servidores, ademas de incluir Unicorn, se debe instalar un servidor web (en mi caso, yo conozco nginx), al cual se le agrega un archivo de comandos y servicios que tendrá este. Se configuran tanto los puertos internos como los externo de donde se haran las consultas de los clientes por medio del navegador y se cambia el proyecto con las configuraciones de producción.

Este es un archivo que facilita toda la construcción del contenedor de Docker, testing(he usado pytest) y la subida a producción. En este se debe incluir cada job. Estas instrucciones se llevarán a cabo cada vez que se haga un push al repositorio, por lo que aquí se automatizan estos procesos. Es un archivo .yml que como en docker-compose se tiene que indicar que servicios se realizarán y si dependen de otros para ejecutarse. En este caso yo lo he hecho con GitHub y aquí se introduce claves secretas o incluso entornos donde se almacena toda una serie de configuraciónes. Todas estas se utilizan para no dejar a la vista información sensible que pueda vulnerar la seguridad del proyecto.

Entonces, cada vez que se hace un push al repositorio, enseguida reconstruye el contenedor de la aplicación en Docker y la actualiza en el repositorio de DockerHub, después hace los testeos de funciones, esperando que todos los endpoints funcionen correctamente. Ya que pasaron estas dos instrucciones toma todos los datos necesarios del entorno para procesar la subida a producción y si todo esta bien, hace el despligue.

Small example how to key macsec with Nitrokey Storage or Pro2 model.

Instructions

Setting keys to Nitrokey

nk-macsec -p [user_pin] -s -i [interface] -f [peer-mac-address-file]

Getting keys to host

nk-macsec -p [user_pin] -g -i [interface]

You can generate shell script to bring up your macsec environment:

nk-macsec -p [user_pin] -g -i [interface] > macsec.sh

Included udev rule will run nk-macsec and macsec.sh to re-key and
setup macsec environment when Nitrokey is attached to USB port.

Install nitrokey & argon2 library and compile with:

$ make
$ sudo make install

Edit /opt/nk-macsec/rekey.sh and change pin-code, network interface
and uncomment macsec.sh line when macsec.sh file is generated succesfully
on Nitrokey insert.

Current udev values (/etc/udev/rules.d/90-nk-macsec.rules) are for
Nitrokey STORAGE. Change them if you plan to use PRO2 model.

• hidapi-devel

• libnitrokey-dev
• https://github.com/Nitrokey/libnitrokey

git clone --recursive https://github.com/Nitrokey/libnitrokey.git
# assuming current dir is ./libnitrokey/
mkdir -p build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. 
make -j2
sudo make install

• libghc-argon2-dev
• https://github.com/P-H-C/phc-winner-argon2

• https://github.com/imneme/pcg-c-basic
• http://www.pcg-random.org/

UVARC documentation and sample templates for K8S deployments.

The attached documentation covers the syntax and formatting for these typical deployments:

• Services – long-running, network-exposed pods such as web servers and APIs.
• Secrets – A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key.
• Jobs – short-lived, single-run pods such as a task or execution.
• Cron Jobs – recurring jobs set on a schedule.

The Service spec files explain the most about other available options for your pod, such as:

• Persistent Volume Claims (storage) needed to provide data or storage to your application.
• Secrets (encrypted keys, tokens, passwords, etc.) needed to run your application.
• Config Maps (ENV vars) needed to run your application in a given environment.
• Ingress to map your service to a domain name, with/without HTTPS.

If you would like to manage your own deployment(s), do the following:

1. Contact the RC DevOps team uvarc-devops@virignia.edu to create a NAMESPACE and kube/config file for you. This file will contain read-only credentials you will use below. The .kube/config file generated for you should be incorporated into any local .kube/config file you have for other environments (if any).
2. Create a clean, empty Git repository and copy these files into it.
3. Within the templates/ directory, create a new folder for each deployment. Populate that folder with the necessary files (with updated values for your deployment, service, namespace, etc.) from this documentation.
4. Work with the DevOps team to connect your Git repo with ArgoCD, our deployment management tool.

Download Lens, a Kubernetes GUI, and connect to our cluster (over UVA Anywhere or from Grounds). Using the Namespace selector
in the upper-right, choose your namespace and you will have observatility to any of your pods. From there you can view logs, shell into pods, and other
functions.

NOTE: Lens serves as a read-only tool. If you want to start, stop, or change a deployment, that must be done through your deployment code, where ArgoCD will ensure the state of your application conforms to its defined state in code.

Script to pull contract data from tzkt indexer posgres db, calculate statistics and push resulting json files to website dataset storage.

The resulting datasets are used by thestackreport.xyz dashboards to enable historic views over time of Tezos smart contract usage.

This codebase is made open source for the purpose of data transparency and to serve as example code.

• Daily contract calls per entrypoint
• Accounts calling contract per day (split by wallet & contract account)
• Transaction targets from contract per day
• Top callers of the contract
• Top targets by the contract

At the contract level, total numbers are stored directly in the document.
Full time series files are created as separate json/csv files and uploaded to the cloud storage layer.

Contract calls per day
Daily contract calls, split by entrypoint.

Usage per day

Accounts calling contract per day (split by wallet & contract account)

• Xtz volume to contract
  • from contract calls
  • from direct transactions
• Xtz volume through contract
  • from contract calls
  • from direct transactions (in case of a pass-through contract)
• Xtz volume from contract

Xtz volume to contract
Xtz volume towards contract can be further split into xtz volume sent towards contract through contract calls & ctz volume sent towards contract through direct xtz transactions.

Xtz volume through contract
Xtz volume through contract is the xtz volume from transactions that directly send through the xtz to another account within the same contract call transaction group.

Xtz volume from contract
xtz volume from contract is xtz volume that comes from the contract which was sent to the contract in an earlier contract call.

Xtz transactions are transactions where the native Tezos xtz token is being transferred from one account to another. An xtz amount can also be included in a smart contract call. Depending on the smart contract code this xtz amount is used or sent in other transactions or becomes part of the current account balance for the smart contract.

An example of a smart contract call which sends xtz to the contract is for example placing an offer on the objkt.com marketplace contract. This sends the offered xtz amount to the contract. Then upon accepting the offer by calling the fulfill_offer entrypoint, the xtz is transferred from the contract to the person accepting the offer.

For xtz being transferred to the contract through contract calls it is straightforward to attribute the xtz to a specific contract call as it is part of that contract call transaction.

When xtz is being transferred from the contract it is a bit less straightforward because the xtz transaction often becomes a separate transaction from the contract to one or multiple wallets.

In some cases multiple contract calls are generating xtz transactions within the same operation group. So it is not simply a matter of looking to the contract call transaction in the transaction group.

Data attributes used in transaction attribution

Ophash

The hash of the entire operation group. Used to query the mongodb.

Counter

Used within a contract to validate that each operation is sequenced in the correct order. Unique at the contract level.

https://www.opentezos.com/tezos-basics/operations

Sender ID & Target ID

Used to identify the contract from which the transaction is sent or which it is targeting.

I’m trying to build a robust analysis for xtz transfers generated by smart contracts.

Is it possible to explicitly link an xtz transfer to a contract call transaction based on on-chain (& RPC available) data?

What I’ve got so far is I can implicitly link them by combining xtz transfers within an operation group towards the original contract call. This works for basic contract calls when only the direct contract code is executed. But when the code within a contract calls on other contracts within the same operation group, those other contracts can also in turn generate more xtz transactions.

Another implicit link could be to look at the sender of the xtz transfer because it must come from the contract executing the code. But then there might still be multiple contract calls towards that contract.

For example in the following operation group there are two calls to ctez_to_tez on the cTEZ-TEZ Plenty Stable swap contract:

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/81][1]

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/103][2]

And two xtz transactions from the contract to the original sender:

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/89][3]

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/111][4]

In this case another assumption could be made that each transfer or xtz send transaction is executed before the next contract call code starts.
That would mean in the above call that the xtz transactions are actually triggered by the following calls to ctez_to_tez_callback:

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/87][5]

[https://tzkt.io/ooMhUwWAoefamMft7oknf6DidEMn433ZtAoMnjy4GkaSRoNaoDr/66548700/109][6]

In the case that there are more than one contract calls within an operation group.

Per contract call look at the nonce position in the operation group.

per xtz transaction determine the latest contract call to the contract that sent the transaction.

get call contract calls for the contract within the op group.

per xtz transaction coming from that contract within the op group:
Look for the highest contract call nonce value that is lower than the transaction nonce value itself.

GeoEngineer provides a Ruby DSL and command line tool (geo) to codify then plan and execute changes to cloud resources.

GeoEngineer’s goals/requirements/features are:

0. DSL based on Terraform: GeoEngineer uses Terraform to plan and execute changes, so the DSL to describe resources is similar to Terraform’s. GeoEngineer’s DSL also provides programming and object oriented features like inheritance, abstraction, branching and looping.
1. Development Workflow: GeoEngineer is built to be used within existing development workflows, e.g. branching, creating pull requests, code reviewing and merging. To simplify these workflows, GeoEngineer dynamically generates Terraform state files using cloud APIs and opinionated tagging.
2. Extensible Validation: Every team has their own standards when managing cloud resources e.g. naming patterns, tagging requirements, security rules. GeoEngineer resources can have custom validations added to ensure the resources conform to required standards.
3. Describe Existing Resources: Existing resources can be described with GeoEngineer without having to destroy and recreate them.
4. Principle of Least Astonishment: show the exact plan before execution; do nothing without confirmation; do not allow a plan to be executed with failing validations; by default do not allow deletions; show warnings and hints to make code better.
5. One File per Project: Managing dozens of projects with hundreds of files is difficult and error-prone, especially if a single project’s resources are described across many files. Projects are easier to manage when they are each described in one file.
6. Dependencies: resources have dependencies on other resources, projects have dependencies on other projects. Using Ruby’s require file that describe resources can be included and referenced without having to hard-code any values.

Instructions to install Terraform can be found here.

brew install terraform

Instructions to install Ruby can be found here.

rbenv install `cat .ruby-version`

Build the gem locally and then refer to it with geo on the command line.

bundle install
gem build geoengineer.gemspec
gem install geoengineer-version.gem
geo --help

Install and configure assume-role.

assume-role <account-id> <role>
./geo --help

GeoEngineer can use the folder structure where projects and environments are in the projects and environments directories respectively, however everything can also be defined in a single file, e.g. first_project.rb:

# First define the environment which is available with the variable `env`
# This is where project invariants are stored, e.g. subnets, vpc ...
environment("staging") {
  account_id  "1"
  subnet      "1"
  vpc_id      "1"
  allow_destroy true ## Defaults to false.  Set to true to support `geo destroy ...`
}

# Create the first_project to be in the `staging` environment
project = project('org', 'first_project') {
  environments 'staging'
}

# Define the security group for the ELB to allow HTTP
elb_sg = project.resource("aws_security_group", "allow_http") {
  name         "allow_http"
  description  "Allow All HTTP"
  vpc_id       env.vpc_id
  ingress {
      from_port    80
      to_port      80
      protocol     "tcp"
      cidr_blocks  ["0.0.0.0/0"]
  }
  tags {
    Name "allow_http"
  }
}

# Define the security group for EC2 to allow ingress from the ELB
ec2_sg = project.resource("aws_security_group", "allow_elb") {
  name         "allow_elb"
  description  "Allow ELB to 80"
  vpc_id       env.vpc_id
  ingress {
      from_port    8000
      to_port      8000
      protocol     "tcp"
      security_groups  [elb_sg]
  }
  tags {
    Name "allow_elb"
  }
}

# cloud_config to run webserver
user_data = %{
#cloud-config
runcmd:
  - docker run -d --name nginx -p 8000:80 nginx
}

# Create an EC2 instance to run nginx server
instance = project.resource("aws_instance", "web") {
  ami           "ami-1c94e10b" # COREOS AMI
  instance_type "t1.micro"
  subnet_id     env.subnet
  user_data     user_data
  tags {
    Name "ec2_instance"
  }
}

# Create the ELB connected to the instance
project.resource("aws_elb", "main-web-app") {
  name             "main-app-elb"
  security_groups  [elb_sg]
  subnets          [env.subnet]
  instances        [instance]
  listener {
    instance_port     8000
    instance_protocol "http"
    lb_port           80
    lb_protocol       "http"
  }
}

The GeoEngineer command line tool geo can:

1. Create a plan with geo plan -e staging first_project.rb
2. Execute the plan with geo apply -e staging first_project.rb
3. Create a graph with geo graph -e staging --quiet first_project.rb | dot -Tpng > graph.png && open graph.png
4. Status of Codified Resources with geo status first_project.rb -e staging
5. Query GPS Resource Graph with geo query "*:*:*:*:*"

There are more examples in the examples folder.

GeoEngineer’s DSL can be customized to your needs using validations, GPS and reusable methods on resources.

Below is an example which will add the validation to ensure that all listeners on all ELB’s must be HTTPS, for security reasons.

class GeoEngineer::Resources::AwsElb < GeoEngineer::Resource
  validate :validate_listeners_must_be_https

  def validate_listeners_must_be_https
    errors = []
    all_listener.select{ |i| i.lb_protocol != 'https' }.each do
      errors << "ELB must use https protocol #{for_resource}"
    end
    return errors
  end
end

GeoEngineer describes resources in the cloud domain, not your application domain. For example, security group ingress is the “cloud” way of defining “what can call your service”. The friction between these two domains makes communication with others (e.g. developers) difficult.

GPS is an abstraction that helps you describe your cloud in the language of your domain. GPS:

1. Uses Higher Level Vocabulary to build configurations.
2. Explicit Configurations means no tricks; What you see is what you get.
3. YAML and JSON Schema to strictly configure using known standards.
4. Extensible Configuration lets GPS express any domain.
5. Backwards Compatible: GPS is built to work with current GeoEngineer resources.

GPS files look like gps/org/first-project.yml:

<environment>:
  <configuration>:
    <node_type>:
      <node_name>:
        <attributes>:

The filename is used to define the project. The environment and configuration are used to group nodes. Each configuration has multiple nodes, defined under their types. You can define your own node types that can allow multiple attributes.

For example, the file ./gps/org/first-project.yml describes a node service named api with configuration staging in the development environment:

development:
  staging:
    service:
      api:
        ports: "80:80"

If you have multiple environments and wish something to be applied to all of them evenly, you can use _default as a special environment keyword. This will be applied to all known environments, unless they are already defined. For example, if you had a project that was deployed to all environments except one named internal, you could use the following example:

_default:
  common:
    service:
      api:
        ports: "80:80"
internal: {}

The service node type is defined to take a string of ports and build a Load balancer:

# Load Balancer Node
class GeoEngineer::GPS::Nodes::Service < GeoEngineer::GPS::Node
  # explicity define the exposed resources from this node
  define_resource "aws_elb", :elb

  # define the types of attributes using JSON schema
  def json_schema
    {
      "type":  "object",
      "additionalProperties" => false,
      "properties":  {
        "ports":  {
          "type":  "string",
          "default":  "80:80"
        }
      }
    }
  end

  # called by GPS when creating resources
  def create_resources(project)
    create_elb(project) # method created with `define_resource`
    setup_elb
  end

  def setup_elb
    # Set the values of the resource here
    elb.ports = attributes["ports"]
  end
end

To integrate with a project use:

project = gps.project("org", "first-project", env) do |nodes|
  # query for api filling in the default env, config, project...
  nodes.find(":::service:api")
end

# Find the service
# query syntax is `<project>:<environment>:<config>:<type>:<name>`
service = gps.find("org/first-project:development:staging:service:api")

# method to get the GeoEngineer resource ELB
service.elb

# method to get the terraform reference to the resource
service.elb_ref

# return all service nodes
gps.where("org/first-project:*:*:service:*").each do |node|
  node.elb.tags { ... }
end

Define methods to be used in your own resources, e.g. a custom method to security group to add a rule:

class GeoEngineer::Resources::AwsSecurityGroup < GeoEngineer::Resource
  # ...
  def all_egress_everywhere
    egress {
        from_port        0
        to_port          0
        protocol         "-1"
        cidr_blocks      ["0.0.0.0/0"]
    }
  end
  # ...
end

project.resource('aws_security_group', 'all_egress') {
  all_egress_everywhere # use the method to add egress
}

The best way to contribute is to add resources that exist in Terraform but are not yet described in GeoEngineer.

To define a resource:

0. checkout and fork/branch GeoEngineer
1. create a file ./lib/geoengineer/resources/<provider_type>/<resource_type>.rb
2. define a class class GeoEngineer::Resources::<ResourceType> < GeoEngineer::Resource
3. define _terraform_id, and potentially _geo_id and self._fetch_remote_resources method (more below).
4. write a test file for the resource that follows the style of other similar resources

A fundamental problem with codifying resources is matching the in code resource to the real remote resource. Terraform does this by maintaining an id in a state file which is matched to a remote resources attribute. This attribute is different per resource, e.g. for ELB’s it is their name, for security groups it is their group_name that is generated so cannot be codified.

Without a state file GeoEngineer uses API’s to match resources, this makes generated id‘s likes security groups difficult. For these generated ids GeoEngineer uses tags e.g. for ELB’s the GeoEngineer id is its name (just like Terraform) and for security groups it is their Name tag.

In a GeoEngineer resource the _terraform_id is the id used by Terraform and the _geo_id is GeoEngineer ID. By default a resources _geo_id is the same as the _terraform_id, so for most resources only the _terraform_id is required.

If _terraform_id is generated then the remote resource needed to be fetched via API and matched to the codified resource with _geo_id. This is done by implementing the self._fetch_remote_resources method to use the API and return a list of resources as an array of hashes each containing keys _terraform_id and _geo_id, then GeoEngineer will automatically match them.

For example, in aws_security_group‘s the resource is matched based on the Name tag, implements as:

class GeoEngineer::Resources::AwsSecurityGroup < GeoEngineer::Resource
  after :initialize, -> { _terraform_id -> { NullObject.maybe(remote_resource)._terraform_id } }
  after :initialize, -> { _geo_id -> { NullObject.maybe(tags)[:Name] } }

  def self._fetch_remote_resources(provider)
    AwsClients.ec2(provider)
      .describe_security_groups['security_groups']
      .map(&:to_h).map do |sg|
        sg[:name] = sg[:group_name]
        sg[:_terraform_id] = sg[:group_id]
        sg[:_geo_id] = sg[:tags] ? sg[:tags].select { |x| x[:key] == "Name" }.first[:value] : nil
        sg
    end
  end
end

Adding resources for a new provider requires creating a new subfolder and resources referencing the provider name in lib/geoengineer/resources/. If necessary, utility methods for the new provider client are stored at lib/geoengineer/utils/. Once the resources files are defined, no further setup is needed as provider information is pulled in from resource definitions in the project files being planned and applied.

Terraform does not validate a lot of attributes before they are sent to the cloud. This means that often plans will fail for reasons that could have been initially validated. When creating a resource think about what validations could be done to ensure a plan is successful.

For example, a security groups needs a Name tag, requires a name and description, and a more complicated example is that its cidr_blocks should be valid:

class GeoEngineer::Resources::AwsSecurityGroup < GeoEngineer::Resource
  # ...
  validate :validate_correct_cidr_blocks
  validate -> { validate_required_attributes([:name, :description]) }
  validate -> { validate_has_tag(:Name) }

  def validate_correct_cidr_blocks
    errors = []
    (self.all_ingress + self.all_egress).each do |in_eg|
      next unless in_eg.cidr_blocks
      in_eg.cidr_blocks.each do |cidr|
        begin
          NetAddr::IPv4Net.parse(cidr)
        rescue NetAddr::ValidationError
          errors << "Bad cidr block \"#{cidr}\" #{for_resource}"
        end
      end
    end
    errors
  end
  # ...
end

Terraform by default will attempt to sync its resources with the API so that its state file is up to date with the real world. Given that GeoEngineer uses Terraform in a different way this sometimes causes plans to list changes that have already happened.

To fix this issue a resource can override to_terraform_state method, e.g. aws_db_instance has issues with final_snapshot_identifier updating:

class GeoEngineer::Resources::AwsDbInstance < GeoEngineer::Resource
  # ...
  def to_terraform_state
    tfstate = super
    tfstate[:primary][:attributes] = {
      'final_snapshot_identifier' => final_snapshot_identifier,
    }
    tfstate
  end
  # ...
end

The core models in GeoEngineer are:

 +-------------+ 1
 | Environment +-----------+
 +-------------+           |
       | 1                 |
       |                   |
       v *                 v *
 +-----+-------+ 1  * +-------------+ 1  *  +-------------+
 | Project     +----->+ Resource    +------>+ SubResource |
 +-------------+      +-------------+       +-------------+

1. Environment contains many resources that may exist outside of a project, like VPCs or routing tables. Also every project defined to be in the environment, for example the test_www project is in staging but monorail is in staging and production environments.
2. Project contains many resources and services grouped together into a name.
3. Resource and SubResource are based off of how terraform models cloud resources. A Resource instance can have many SubResource instances, but a SubResource instance belongs to only one Resource instance, e.g. a load balancer resource may have a health_check sub-resource to only allow specific incoming ports.

All these models can have arbitrary attributes assigned to them either by directly assigning on the instance, or through passing a block to the constructor. For example:

resource = Resource.new('type','id') { |res|
  # CORRECT
  res.hello = 'hey'
  puts res.hello # 'hey'
  hello 'hey again' #
  puts res.hello # 'hey again'

  # INCORRECT way of assigning variables
  goodbye = 'nooo' # This assigns a local variable, not an attribute on the resource
  puts res.goodbye # nil
}

puts resource.hello # 'hey again'

resource.goodbye = 'see ya'
puts resource.goodbye # 'see ya'

Additionally, if the value is expensive to calculate or requires other attributes not yet assigned, an attribute can be assigned a Proc or lambda which will be calculated lazily:

resource = Resource.new('type','id')
resource.lazy_attr = -> { puts "CALCULATING THE VALUE"; 'value' }
# ...
puts resource.lazy_attr
#$ "CALCULATING THE VALUE"
#$ "value"

The top level class in GeoEngineer is the environment: it contains all projects, resources and services, and there should only ever be one initialized at a time.

An environment can mean many things to different people, e.g. an AWS account, an AWS region, or a specific AWS VPC. The only real constraint is that a resource has one instance per environment, e.g. a load balancer that is defined to be in staging and production environments, will have an instance in each.

The function environment is provided as a factory to build an environment:

environment = environment("environment_name") { |e|
  e.attr_1 = [1,2,3]
  attr_2 'value'
}
environment.attr_3 = "another value"

A project is a group of resources typically provisioned to deploy one code base. A project has an organization and name, to mimic the github username/organiztion and repository structure.

A project is defined like:

project = project('org', 'project_name') {
  environments 'staging', 'production'
}

This projects organization is org, its name project_name and will be provisioned in the staging and production environments. The org and name must be unique across all other projects.

The method project will automatically add the project to the instantiated environment object only if that environment’s name is in the list of environments, otherwise it is ignored.

Resources are defined to be similar to the terraform resource configuration. The main difference is to not use = as this will create a local ruby variable and not assign the value.

A Resource can be created with and environment or project object (this will add that resource to that object):

environment.resource('type', 'identifier') {
  name "resource_name"
  subresource {
    attribute "attribute"
  }
}

project.resource('type', 'identifier') {
  # ...
}

The type of a resource must be a valid terraform type, where AWS types are listed here. Some resources are not supported yet by GeoEngineer.

identifier is used by GeoEngineer and terraform to reference this resource must be unique, however it is not stored in the cloud so can be changed without affecting a plan.

A resource also has a ruby block sent to it that contains parameters and sub-resources. These values are defined by terraform so for reference to what values are required please refer to the terraform docs.