Die Programmiersprache Rust eignet sich gut für die Umsetzung von Cross-Plattformprojekten. Der erste Teil der Artikelserie hat die grundlegenden Konzepte einer langlebigen Cross-Plattform-Architektur vorgestellt: Ein herausgelöster Core in Rust bildet das Fundament für nachhaltige Apps. Die Implementierung eines einfachen MVVM-Patterns mit ViewModel, Actions und State zeigte eine einfache konkrete Umsetzung dieses Ansatzes. Wie sich die Architektur verfeinern lässt, zeigt sich, wenn man sie um Validierungen erweitert.

Cross-Plattform mit Crux

Das in Rust geschriebene Framework Crux für die plattformübergreifende Entwicklung implementiert die im ersten Artikelteil vorgestellten Konzepte. Was Aktion hieß, nennt Crux Event. Der Zustand(State) heißt Model. Durch den ähnlichen Namen ist die Grenze zum ViewModel leider nicht mehr ganz so deutlich. Das ViewModel heißt nämlich auch bei Crux ViewModel. Umso wichtiger ist es, die Abgrenzung bei der Umsetzung im Hinterkopf zu behalten.

Zudem bringt Crux mit Effect und Command noch weitere wichtige Konzepte mit.

Ein Effect bildet einen Seiteneffekt der hexagonalen Architektur ab. In diesem Kontext sind Seiteneffekte gleichbedeutend mit Plattformspezifika und dem Rendern des User Interface (UI). Dabei ist ein Effect keine Einbahnstraße. Durch ein Command lässt es sich mit einem Event verknüpfen, sodass der verarbeitete Effekt beantwortet und die Antwort in der App auf ein weiteres Event angewendet werden kann. Auf diese Art lässt sich der Zugriff auf das jeweilige Dateisystem und auf native APIs abstrahieren und umsetzen.

Crux definiert außerdem die Begriffe App, Core und Shell.

• Die App ist das zentrale Trait und ein Pendant zum Core aus Teil 1
• Core umhüllt die App und sorgt dafür, dass ein Event in die App hinein- und nur eine Liste von Effect oder das ViewModel aus der App hinausgeht
• Shell bezeichnetet den Konsumenten des Cores (bepackt mit der App), wie eine native App auf Basis von Swift, Kotlin oder C#

Beispiel: E-Mail-App

Das zuvor in Teil 1 implementierte Beispiel wird erneut aufgegriffen und auf Crux übertragen. Als Erstes die einfachen Typen (Listing 1):

Listing 1: Crux: Event/Model/ViewModel-Definitionen

#[derive(Deserialize, Serialize)]
pub enum Event {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

#[derive(Default)]
pub struct Model {
    name: String,
    email: String,
}

#[derive(Deserialize, Serialize)]
pub struct ViewModel {
    pub name: String,
    pub email: String,
}

Hierbei gibt es keine Überraschungen. Actions werden zu Event (Einzahl), State wird zu Model und das ViewModel bleibt bestehen.

Als Nächstes die neuen Typen (Listing 2):

Listing 2: Crux: Effect-Enum und App-Struct

#[effect]
pub enum Effect {
    Render(RenderOperation),
}

#[derive(Default)]
pub struct EmailApp;

Das Enum Effect definiert alle möglichen Kommunikationen aus dem Core hinaus. Das Struct EmailApp bleibt leer. Es implementiert im nächsten Schritt das Trait App von Crux.

Die Implementierung von App ist in drei Blöcke (siehe Kommentare in Listing 3) unterteilt.

Listing 3: Crux: App-Trait-Implementierung

impl App for EmailApp {
    // 1
    type Event = Event;
    type Model = Model;
    type ViewModel = ViewModel;
    type Capabilities = (); // deprecated
    type Effect = Effect;

    // 2
    fn update(
        &self,
        event: Self::Event,
        model: &mut Self::Model,
        _caps: &Self::Capabilities,
    ) -> Command<:effect self::event=""> {
        match event {
            Event::ChangeEmail(email) => {
                model.email = email.clone();
            }
            Event::ChangeName(name) => {
                model.name = name.clone();
            }
            Event::ApplyChanges => {}
        }
        render()
    }

    // 3
    fn view(&self, model: &Self::Model) -> Self::ViewModel {
        ViewModel {
            name: model.name.clone(),
            email: model.email.clone(),
        }
    }
}

Der erste Block legt die grundlegenden assoziierten Typen fest, die App vorsieht. Diese Typen sind aus Listing 1 und 2 bekannt. Der Typ Capabilities ist ein Relikt und gilt als veraltet (deprecated). Dieses Konzept wurde vor der Einführung von Command genutzt. Daher ist es lediglich aus Gründen der Rückwärtskompatibilität vorhanden und lässt sich ignorieren.

Die update-Methode nimmt eingehende Events entgegen und passt daraufhin den Zustand (Model) an. Änderungen am Namen oder der E-Mail-Adresse werden auch hier direkt im Model gespeichert. Nach der Verarbeitung eines Events wird ein Render– Effect ausgelöst. Dieser kann in der Shell aufgegriffen, das ViewModel angefragt und das Re-Rendering angestoßen werden.

Die view-Methode in Abschnitt 3 bietet die Schnittstelle, um das ViewModel zu erstellen. Wie zuvor erzeugt das ViewModel das aktuelle Model (Zustand) und bereitet die relevanten Informationen für die UI so auf, dass die Benutzeroberfläche sie direkt anzeigen kann.

App im Core einwickeln

Um die App zu verwenden, gilt es diese im Core zu umhüllen (zu wrappen):

let core: Arc> = Arc::new(Core::new());

Dieser Core-Instanz lässt sich ein Event übergeben und die zurückkommenden Effekte können verarbeitet werden (Listing 4).

Listing 4: Crux: Effect-Verarbeitung

let effects: Vec =
    core.process_event(ChangeEmail("marcel.koch@example.org".into()));

for effect in effects {
  match effect {
    Effect::Render(_) => {
      let view_model = core.view();
      
      assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

process_event nimmt das Event entgegen und gibt eine Liste von Effekten zurück. Das Beispiel behandelt nur eine Art von Effect: Render. Es wird geprüft, ob das ViewModel die eben übergebene E-Mail-Adresse enthält.

Ist das UI verbunden, tritt es bei jeder Änderung der E-Mail-Adresse auf.

Core in Bridge wrappen

Geht es nicht um einen reinen Aufruf innerhalb von Rust, ist die Integration in andere Technologien abhängig von Serialisierung. Diese Aufgabe übernimmt auf der Rust-Seite die Bridge. Ein einfacher Einsatz sähe in Rust wie folgt aus:

Listing 5: Crux: Bridge-Integration

let serialized = 
    bincode::serialize(&ChangeEmail("marcel.koch@example.org".into())).unwrap();

let effects: Vec = bridge.process_event(&serialized).unwrap();

let effects: Vec> =
bincode::deserialize(effects.as_slice()).unwrap();

for request in effects {
  let effect = request.effect;
  
  match effect {
    EffectFfi::Render(_) => {
    let view_model = bridge.view().unwrap();
    let view_model: ViewModel =
    bincode::deserialize(&view_model).unwrap();
    
    assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

Es ist der gleiche Ablauf wie zuvor mit dem reinen Core. Die einzigen Unterschiede sind die Serialisierung des Events und die Deserialisierung der Effekte und des ViewModel. Diese Serialisierungen werden in einem realistischen Einsatz in den jeweiligen Fremdtechnologien (.NET, Swift etc.) durchgeführt. Diese Umsetzung zeigt der nächste Teil dieser Artikelserie.

Neue Sicherheitsmaßnahmen von SpaceX haben offenbar dazu geführt, dass massenhaft Starlink-Antennen ausfallen, die vom russischen Militär an der Front im Ukraine-Krieg benutzt werden. Das berichtet unter anderem der Kyiv Independent unter Berufung auf Beiträge in sozialen Netzwerken. Ein ukrainischer Experte für die elektronische Kriegsführung hat bereits erklärt, „der Feind hat an den Fronten kein Problem, es handelt sich um eine Katastrophe“. Zwar hätten auch andere ukrainische Quellen berichtet, dass russische Truppen offenbar weitgehend von der Kommunikation abgeschnitten wurden, die dürften aber nun nach Alternativen suchen. Gleichzeitig hätten ukrainische Militärs eingestanden, dass russische Angriffe durch die Maßnahme nicht gestoppt, sondern höchstens verlangsamt wurden.

Seit Mittwoch vom Satelliteninternet abgeschnitten

Auch wenn die ganze Tragweite der Maßnahmen damit nicht absehbar ist, machten die Berichte deutlich, wie schnell es der Ukraine dank SpaceX gelungen ist, dem russischen Militär eine zentrale Technik zu nehmen. Erst vor gut einer Woche hat der ukrainische Verteidigungsminister Mychajlo Fedorow darauf aufmerksam gemacht, dass Russland Angriffsdrohnen mit Starlink-Antennen ausgestattet hat, um sie aus der Ferne zu steuern. Da war bereits von Lösungsvorschlägen die Rede und auch wenn Elon Musk da unflätig auf Kritik reagiert hat, war sein Unternehmen danach nicht untätig. Anfang der Woche hieß es dann, dass erste Gegenmaßnahmen Wirkung gezeigt hätten. Wie groß der Erfolg war, kann man aber erst jetzt abschätzen.

Die wichtigste Maßnahme dürfte dabei eine Beschränkung von Starlink auf autorisierte Antennen sein, Nutzer und Nutzerinnen in der Ukraine müssen sich inzwischen verifizieren. Dem russischen Militär ist dieser Weg versperrt und mit der Blockade nicht autorisierter Antennen funktionieren die nicht mehr. Wie viele Antennen davon betroffen sind, ist unklar, es wird aber deutlich, dass Russland die Technik nicht nur für die Fernsteuerung von Drohnen benutzt hat. Laut einer Quelle der Nachrichtenagentur Reuters haben die Antennen am Mittwochabend ihren Dienst eingestellt, etwa zu dieser Zeit hat Lauren Dreyer von SpaceX die Anleitung der ukrainischen Regierung zur Registrierung auf X geteilt.

Die Entwicklung macht einmal mehr deutlich, welchen enormen strategischen Wert das Satelliteninternet in dem blutigen Krieg längst hat. Starlink hat in der Ukraine längst einen großen Teil der Kommunikationsinfrastruktur ersetzt, die durch die Kämpfe zerstört wurde. Nicht nur die Truppen des Landes sind auf das Funktionieren der Technik angewiesen, sondern auch Krankenhäuser, Schulen und andere Einrichtungen kommunizieren darüber. Insgesamt hat die Ukraine mehr als 50.000 der nötigen Antennen erhalten, der Großteil wurde von Polen gestellt. Zwischenzeitlich hatte Elon Musk Zweifel an seiner Zuverlässigkeit gestreut, aber das ist längst überwunden.

(mho)

Beim Aufbau von IT-Infrastrukturen führen kurze Entwicklungszyklen zu einem hohen Automatisierungsbedarf. Das quelloffene Tool OpenTofu ermöglicht Entwickler- und Operations-Teams, ihre gesamte IT-Infrastruktur mithilfe von deklarativem Code zu definieren, bereitzustellen und zu verwalten. Dabei ist es unerheblich, ob es sich um Infrastrukturen in der Cloud, im eigenen Rechenzentrum oder in hybriden Umgebungen handelt.

OpenTofu ist ein Fork von Terraform und bis zur Version 1.5.7 vollständig kompatibel, sodass Sie bestehende Umgebungen mit wenig Aufwand migrieren können.

Ressourcen mit wiederverwendbarem Code verwalten

Im iX-Workshop OpenTofu Fundamentals: Infrastructure as Code aufbauen und verwalten lernen Sie, wie sich IT-Infrastrukturen mit OpenTofu als Code abbilden lassen. Dabei arbeiten Sie mit der HCL-basierten Syntax von HashiCorp, dem Entwickler des Ursprungsprojekts Terraform.

Aufbauend darauf üben Sie, IT-Infrastrukturen mit OpenTofu automatisiert bereitzustellen, anzupassen und zu verwalten. Sie erfahren, wie sich Ressourcen zur Beschreibung von Infrastruktur-Objekten wie virtuellen Maschinen, Netzwerken oder Storage erstellen und bereitstellen lassen und wie diese zu Modulen zusammengefasst werden, um sie gemeinsam zu nutzen.

In praktischen Übungen erstellen, verändern und bauen Sie eigene IT-Umgebungen wieder ab. So lernen Sie den Umgang mit wiederverwendbarem Code und trainieren, wie Sie Zustände dauerhaft speichern, sowie Variablen und Outputs sinnvoll nutzen können. Abschließend erfahren Sie, wie sich OpenTofu mithilfe von Providern erweitern und mit Schnittstellen, Cloud- und SaaS-Diensten verknüpfen lässt.

Dieser Workshop richtet sich an erfahrene Linux-Administratoren, die die IT-Infrastruktur ihres Unternehmens mit OpenTofu einrichten und verwalten wollen.

An zwei Tagen führt Carl Camurça mit langjähriger Erfahrung als Trainer durch die Inhalte des Workshops. Er ist Linux Consultant bei B1 Systems und auf Automatisierung, effektive Administration und Konfigurationsmangement spezialisiert. Für einen intensiven Austausch und ausreichend Zeit für Diskussion und Fragen ist die Teilnehmerzahl maximal 12 Personen begrenzt.

(ilk)