Da ich seit letztem Sommer mehr oder weniger Vollzeit an [Neotoma](https://neotoma.io) (ehemals Asheville) arbeite, hatte ich zum ersten Mal die Gelegenheit, mich wirklich mit Open-Source-Software zu beschäftigen.

Ich freue mich, sagen zu können, dass ich zusätzlich zur Arbeit an öffentlich verfügbaren Repositorys speziell für Neotoma einige Repositorys erstellt habe, die hoffentlich als Module für andere Node.js-Apps im Allgemeinen nützlich sind:

- [Park Ranger](https://github.com/markmhx/park-ranger): Ein Manager für umgebungsspezifische Abhängigkeiten wie Umgebungsvariablen, Konfigurationsdateien und SSL-Zertifikatsdateien.

  Es wird „Park Ranger“ genannt, weil ein Computerprogramm immer in einer bestimmten Umgebung ausgeführt wird, die oft durch sein Gerät oder eine bestimmte, innerhalb dieses Geräts ausgewählte Umgebung neben anderen möglichen Umgebungen bestimmt wird. Und an wen wenden Sie sich, wenn Sie die Natur genießen und Fragen dazu haben? Genau, ein Parkwächter.

  Grundsätzlich habe ich in meinen Repositorys immer wieder denselben Dienstprogrammcode neu geschrieben, um umgebungsbedingte Unterschiede zu bewältigen, hauptsächlich zwischen meiner lokalen Entwicklungsmaschine und dem Bereitstellungshost. Deshalb habe ich alles in dieses Modul umgestaltet, um Codeverbesserungen und Wartung in Zukunft zu beschleunigen. Mein Ausgangspunkt war [dotenv](https://github.com/motdotla/dotenv), aber mir wurde schnell klar, dass es für meine Bedürfnisse zu einfach war.

- [Hoist](https://github.com/markmhx/grunt-hoist): Eine Reihe von Grunt-Aufgaben zum Bereitstellen von Node.js-Apps auf Hosts und zum Ausführen zugehöriger Remote-Prozeduren.

  Ähnlich wie bei meiner Erfahrung mit Park Ranger habe ich festgestellt, dass ich geringfügige Variationen derselben Bereitstellungsroutinen in allen Repositorys neu geschrieben habe (z. B. Dateien rsyncen, „npm install“ ausführen und den Remote-Server neu starten). Deshalb habe ich diese Reihe von Aufgaben erstellt (die sich automatisch als NPM-Skripte für übergeordnete Projekte zur Verfügung stellen), um die Art und Weise zu standardisieren, wie ich damit umgehe. Sie vereinfachen auch meinen Ansatz zur kontinuierlichen Entwicklung erheblich, selbst wenn ich nebenbei neue Mikrodienste einrichte oder schnelle Änderungen an lokalen Abhängigkeiten vornehme.

- [Proxy](https://github.com/neotoma/proxy): Ein Proxyserver für HTTP- und HTTPS-Anfragen.

  Als ich begann, frühe Versionen von Neotoma für geschlossene Tests zu hosten, brauchte ich eine einfache Möglichkeit, verschiedene Server zu unterstützen, die auf demselben Host über Protokolle (HTTP vs. HTTPS), Ports und Subdomains laufen. Beispielsweise stellt derselbe Host, der HTTP verwendet, um die Landingpage für Neotoma bereitzustellen, auch HTTPS-Anfragen an die zugrunde liegende API und sowohl HTTP- als auch HTTPS-Anfragen an die tatsächliche Neotoma-Webanwendung bereit, die zu Testzwecken auf einer Subdomain ausgeführt wird.

  Obwohl dieses Repository der Neotoma-Organisation untersteht, kann es von jedem genutzt werden, der dasselbe für seine Hosts tun möchte, auf denen mehrere Server laufen.

Es gibt eine Reihe anderer öffentlicher Repositories in der Entwicklung, die einen direkteren Bezug zu Neotoma haben und die ich hier nicht auflisten werde, die aber auf der [Neotoma GitHub-Organisation](https://github.com/neotoma) zu finden sind. Obwohl ich noch nicht aktiv nach Beiträgen gesucht habe, sind alle oben aufgeführten Repositories und in dieser Organisation offen für Pull-Anfragen, falls Sie Änderungen vornehmen möchten!