Podcasts about programmteile

In einer neuen Folge des Digital Insurance Podcast spreche ich mit Christian Macht, dem CEO der ELEMENT Insurance AG über die Vorteile junger Unternehmen und der besonderen Arbeitskultur bei ELEMENT. ELEMENT ist ein vergleichsweise junges Versicherungsunternehmen. Sie entwickeln, so Christian Macht, White-Label-Versicherungsprodukte auf Basis neuester Technologien, wie cloud-nativem Arbeiten und der Verwendung moderner Schnittstellen. Es habe zudem den Vorteil, sich der ständigen Aufbereitung von Legacy-Systemen entledigen zu können. Dabei gehe es nicht primär um den Einsatz bahnbrechend neuer Technologien: Das, was gerade als State of the Art gilt, reicht vollkommen aus, so Christian. Cloud, Microservice und API würden bereits viele Arbeitsprozesse erleichtern. Da sich die Philosophie, was den Einsatz moderner Programmteile wie API angeht, alleine in den letzten paar Jahren fundamental verändert habe, sei deren Verwendung praktisch unausweichlich. Gerade in einer Versicherung, wo ein Großteil der Wertschöpfung inhouse stattfände, mache das einen großen Unterschied und sei deutlich günstiger, als auf externe Anbieter angewiesen zu sein. Bei der Frage, welchen Verwendungszweck BiPRO und REST-API haben, werden wir uns ganz nicht einig. So gibt es zum Beispiel Maklerversicherer, die alles auf BiPRO setzen, sagt Christian. Um mit diesen eine Zusammenarbeit zu ermöglichen, brauche es entsprechende Schnittstellen. Ein Ansatz, der für einzelne Bereiche funktioniere, habe auch seine Daseinsberechtigung. Darin, dass die Mitarbeiter das höchste Gut einer Versicherung darstellen, sind wir uns hingegen einig. Umso wichtiger sei es, meine ich, die Besten ins eigene Unternehmen zu holen. Das ergänzt Christian mit dem Hinweis, es gehe auch darum die höchst unterschiedlichen Mitarbeitertypen miteinander zu verbinden und sprachliche sowie kulturelle Barrieren abzubauen. Kooperation und Flexibilität seien gerade bei einem Unternehmen wie ELEMENT von unschätzbarem Wert. Während in alteingesessenen Konzernen der individuelle Eigennutz häufig über dem Unternehmenswohl stehe, gebe es bei ELEMENT eine Kultur der Rücksichtnahme und des Vertrauens. Harte Arbeit und gute Ideen sollen belohnt werden. Christian selbst sei hier das beste Beispiel: Leute, die nun im Rang unter ihm stünden, haben ihn ursprünglich eingestellt. In einer gewachsenen Unternehmensstruktur sei das schwieriger, wo so etwas als Abstieg verstanden würde. Bei ELEMENT werde diese Flexibilität hingegen von den Mitarbeitern mitgetragen und als Stärke des Unternehmens angesehen. Doch auch ELEMENT steht früher oder später vor den Herausforderungen, die jene etablierten Konzerne bereits haben, meine ich. Dies ist vor allem eine Frage des richtigen Managements, entgegnet Christian. Jeden Tag baue man schließlich ein Stück weit Legacy auf - ob im technologischen oder personellen Bereich. Der richtige Umgang damit sei entscheidend. Zudem hätten große Unternehmen auch Vorteile, wie etablierte Infrastrukturen zum Beispiel im Recruiting-Bereich. Links in dieser Ausgabe Zum LinkedIn-Profil von Christian Macht Über diesen Podcast Folgt uns auf LinkedIn für mehr Podcast-Updates Zur Podcast-Website Wir suchen immer nach neuen und spannenden Gesprächspartnern. Meldet euch bei uns.

​Gab es früher 1-2 grosse Updates der SAP-Systeme pro Jahr, so werden moderne SAP-Landschaften 1-2-mal pro Woche aktualisiert. Um das zu leisten benötigt man Erfahrung, gute Werkzeuge zum Testen und Ausliefern dieser Programmteile und einen Kulturwandel hin zu DevOps. Hierüber spreche ich heute mit Thomas Bruggner, Managing Director EMEA und mit Achim Töper, Senior DevOps Solution Specialist, von Basis Technologies Germany GmbH.

Ein verrücktes Jahr: Es war WWDC Keynote und wir sprechen erst am dritten Tag danach über das neue iOS. Dabei sind die Änderungen derartig gering, dass selbst das neue iPadOS in die gleiche Folge gepasst hat. Was einst gemeinsam begann, trennt sich im zweiten Jahr immer mehr. Vor der WWDC stellte ich in diesem Podcast schon mir selbst die Frage, ob die beiden Betriebssysteme künftig weiter gemeinsam oder getrennt entwickelt werden. Meiner Meinung nach habe ich die Frage bereits erhalten: Getrennt. Einige Funktionen finden wir zwar auf beiden Systemen wieder, sie sind häufig aber stark unterschiedlich implementiert. Das sorgte nach der WWDC durchaus für Kritik. Widgets für Alle - nur wo? Neu sind unter anderem die Widgets - es ist nur eine von vielen Funktionen, die wir eigentlich bereits von Android kennen. Die Widgets sind auch der Auslöser einiger hämischer Kommentare. Auf iOS können sie direkt auf dem Homescreen platziert, bei iPadOS nur in der Seitenleiste. AppClips und mehr Generell wurde der Homescreen auf beiden Geräten leicht überarbeitet und die Steuerung allgemein angepasst. Es gibt weniger bildschirmfüllende Überblendungen. Neu sind auch die App Clips, so können kleine Programmteile auch ohne Installation einer App ausgeführt werden. Der Newton ist wieder da Dafür erhält das iPad Scribble, Eingaben mit dem Apple Pencil werden direkt in Maschinenschrift, oder Formen, übersetzt. ----- Wenn euch dieser Podcast gefallen hat, würden wir uns freuen, wenn ihr Apfeltalk unterstützen würdet. Einerseits könnt ihr uns auf iTunes bewerten – damit erhöht sich die Sichtbarkeit dieses Podcasts – oder uns andererseits auf Steady unterstützen. Förderer auf Steady erhalten die Apfeltalk SE sowie die Film und Serien Folgen immer bereits am Sonntag, alle anderen Hörer am Freitag. Außerdem sind alle Folgen werbefrei und ihr bekommt Zugriff auf unsere wöchentliche News-Zusammenfassung. Empfehlt uns auch gerne euren Freunden!

Heute dreht sich alles um das Thema: „Was ist eigentlich eine API?”   Der Begriff API stammt aus dem Englischen und ist die Kurzform von „Application-Programming-Interface". Frei ins Deutsche übersetzt bedeutet das, so viel wie „Schnittstelle zur Anwendungsprogrammierung“. Allerdings wird die API umgangssprachlich meistens als Programmierschnittstelle bezeichnet und ist für das moderne Programmieren unerlässlich. Generell dienen Programmierschnittstellen zur Kommunikation, zum Austausch sowie zur Weiterverarbeitung von Daten und Inhalten zwischen verschiedenen Geräten, Programmen, Websites oder Anbietern. So ermöglichen APIs zum Beispiel die Fernsteuerung der heimischen Heizung, indem sie die Temperaturwerte, die von einem Thermostat gemessenen wurden, über eine Cloud zum Smartphone des Endverbrauchers übermitteln. Im Gegensatz zu einer Benutzerschnittstelle kommunizieren die Anwendungen direkt miteinander und nicht der Menschen mit einem System. Mal angenommen ein Internetnutzer bestellt einen Fernseher im Webshop. Dann kommuniziert er nur über die Weboberfläche des Onlineshops. Das Shopsystem selbst kann über die Programmierschnittstelle die Kundenbonität erfragen, die Zahlung per Kreditkarte oder Paypal veranlassen, bei einer Versicherung eine Garantieverlängerung abschließen und einen Spediteur beauftragen. In anderen Unternehmensprozessen gewährleisten Programmierschnittstellen beispielsweise den Austausch sowie die Weiterverarbeitung von Daten und Inhalten zwischen Customer Relationship Management (CRM), Dokumentenmanagementsystem (DMS) und Enterprise-Resource-Planning (ERP) über die Cloud. Aber wie funktioniert die API nun genau? Die Programmierschnittstelle dient wie bereits erwähnt dazu, Soft- und Hardwarekomponenten wie Anwendungen, Festplatten oder Benutzeroberflächen zu verbinden, sprich mit einer API können zwei Anwendungen, die voneinander unabhängig sind, problemlos interagieren und Inhalte, Ressourcen und Daten austauschen. Die Übergabe von Daten und Befehlen erfolgt dabei strukturiert nach einer zuvor definierten Syntax*. Hierzu werden einzelne Programmteile, die spezifische Funktionen erfüllen, vom Rest des Programmes abgekapselt. Die Module kommunizieren untereinander lediglich über die festgelegte API. Dort werden ausschließlich die Daten übergeben, die für den weiteren Programmablauf benötigt werden. Die API definiert dabei, in welcher Form Daten vom Anwendungsmodul entgegengenommen und wieder zurückgegeben werden. Der eigentliche Programmablauf innerhalb des Moduls ist für die API unwichtig. Im Gegensatz zu einer Binärschnittstelle, kurz ABI, findet in der API die Programmanbindung rein auf der Quelltext-Ebene statt. Zur Bereitstellung einer API gehört meist eine ausführliche elektronische oder aber eine papiergebundene Dokumentation, in der die einzelnen Schnittstellenfunktionen, der genauen Syntax und die möglichen Parameter aufgeführt sind.     Grundsätzlich können Programmierschnittstellen in verschiedene Typen unterteilt werden: funktionsorientierte APIs, dateiorientierte APIs, objektorientierte APIs, protokollorientierte APIs und die RESTful-API-Schnittstelle. Funktionsorientierte APIs: Die funktionsorientierten Programmierschnittstellen reagieren nur auf Funktionen, wahlweise mit oder ohne Rückgabewert. Auf den Aufruf einer Funktion folgt die Ausgabe eines Referenzwertes (Handle). Dieser Wert dient zum Aufruf weiterer Funktionen, sind alle Funktionen verfügbar, wird das Handle geschlossen. Dateiorientierte APIs: Die dateiorientierten Programmierschnittstellen werden über die Befehle open, read, write und close angesprochen. Gesendete Daten werden mit write geschrieben, sollen Daten empfangen werden, sind diese mit dem read-Kommando einzulesen. Objektorientierte APIs: Die objektorientierten Programmierschnittstelle adressieren definierte Schnittstellen-Pointer, was diesem Schnittstellentyp gegenüber funktionsorientierten Schnittstellen eine erhöhte Flexibilität verleiht. Oft wird mit den Daten auch eine Typ- oder Klassen-Bibliothek übergeben. Protokollorientierte APIs: Die protokollorientierten Programmierschnittstellen befinden sich in keinerlei Abhängigkeit von Betriebssystem oder Hardware, allerdings ist das Übergabeprotokoll stets neu zu implementieren. Um diesen Vorgang zu erleichtern, werden protokollorientierte Schnittstellen im Regelfall von interface- oder funktionsorientierten Schnittstellen gekapselt. RESTful-API-Schnittstelle: Die RESTful-API-Schnittstelle stellt einen Sonderfall dar. Hierbei handelt es sich um eine Schnittstelle für Anfragen im HTTP-Format, der Datenzugriff erfolgt über GET-, PUT-, POST- und DELETE-Befehle. Programmierschnittstellen sind mittlerweile in vielen Bereichen unterschiedlichster Softwareanwendungen vorzufinden. Im Web-Umfeld kommen APIs häufig bei Online-Shops und Content-Management-Systemen zum Einsatz. Es können dadurch unterschiedliche Bezahldienstleister, Online-Marktplätze, Shop-Bewertungssysteme oder Versanddienstleister und weitere Services mit wenig Aufwand standardisiert an die verschiedenen Systeme angebunden werden. Beispielsweise existieren APIs zu Services wie: Wikipedia, Google Maps, Facebook, Twitter, PayPal, DHL etc. Bevor wir nun zum Ende unseres heutigen Podcasts kommen, möchte ich auf die Frage eingehen: Welche Vorteile ergeben sich nun durch die Verwendung von Programmierschnittstellen?   Einer der vielen Vorteile ist es, die Entwicklung von Software zu vereinfachen, indem komplizierte und zeitaufwendige Aufgaben automatisiert werden. Das bedeutet, dass bestimmte Aufgaben, die mehrere Stunden in Anspruch nehmen, nun in wenigen Sekunden durchgeführt werden können. Zudem sind die angebundenen Programme weniger fehleranfällig und leichter wartbar, da modulare Programmcodes verwendet werden. Arbeiten einzelne Funktionen fehlerhaft, müssen lediglich die betroffenen Module und die an der API übergebenen Daten genauer geprüft werden.   Ein weiterer Vorteil, dass sich aus einer sauber dokumentierten Programmierschnittstelle ergibt, ist die Möglichkeit der Auslagerung von Programmierarbeiten. Die Entwicklung einzelner Teilbereiche einer Software kann dank der Programmierschnittstelle mit geringem Aufwand an eine externe Softwareunternehmen oder freie Entwickler übertragen werden.   Zudem können Drittanbieter selbst Funktionen für das System entwickeln. Dadurch steigert sich die Attraktivität und Flexibilität des Gesamtprodukts und es ergeben sich klare Wettbewerbsvorteile. Allerdings gibt es neben den genannten Vorteilen auch Nachteile: Um andere Anwendungen, Festplatten oder Benutzeroberflächen individuell anbinden zu können, braucht man Programmierkenntnisse. Hat man also keinen Entwickler im Unternehmen, muss man jemanden extern beauftragen. Außerdem benötigt das Entwickeln einer Anbindung Zeit. Kontakt: Ingo Lücker, ingo.luecker@itleague.de

In dieser Folge des IT Manager Podcasts dreht sich alles um das Thema: „Was ist eigentlich eine Sandboxanalyse?“ Sie wollen selbst mal in einem Interview dabei sein? Oder eine Episode unterstützen? Dann schreiben Sie uns gerne eine E-Mail: ingo.luecker@itleague.de Zunächst aber einmal vorweg zum Begriff Sandbox. Eine Sandbox ist nämlich ein isolierter Bereich eines Systems, indem getroffene Maßnahmen keine Auswirkungen auf die Umgebung haben. Sinnbildlich kann ein Programmierer also - wie ein Kind im Sandkasten – in der Sandbox verschiedenste Möglichkeiten testen, ohne das gesamte System in Mitleidenschaft zu ziehen, wenn ein Versuch fehlschlägt. Ein großer Vorteil ist es also Verfahren im Voraus testen zu können, bevor sie dann im regulären Tagesbetrieb fehlerfrei funktionieren müssen. Ein weiterer, bedeutender Vorteil einer Sandbox ist es, dass Malware zwar die eine Box betreffen kann, nicht aber von dort aus auf das ganze System übergreifen kann, wie es ja zumeist bei Attacken versucht wird. Für Sandboxen gibt es ganz verschiedene Anbieter, wie beispielsweise die FortiSandbox von Fortinet. Es gibt aber auch Open Source Versionen, die völlig kostenlos genutzt und getestet werden können. Sollten Sie dahingehend gerne einmal Ihre Fähigkeiten als Programmierer testen wollen gibt es bei heise.de praktische Tipps und „Baupläne“ für Einsteiger. Die Funktionsweise einer Sandbox ist dann wie folgt: Mithilfe von Programmen wie FAUmachine oder Klik können die Boxen erzeugt werden. Bei sogenannten virtuellen Maschinen kann man mit Java Virtual Machine beispielsweise innerhalb eines bestehenden Systems noch weitere virtuelle einbauen. Mithilfe von Applikationen können dann diese Sandboxen im Programmcode eingebunden werden. Damit keiner auf die Sandboxen zugreifen kann, nutzt man SecurityManager und den sogenannten ClassLoader. Mit der Anwendung Solaris Zones können bis zu 8.190 Zonen erstellt werden, die alle zum Testen genutzt werden können und eine reale Systemstruktur simulieren können. Die Zonen untereinander sind nicht gekoppelt und greifen daher nicht auf den Prozess der jeweils Anderen zu. Dadurch lassen sich gesonderte Fälle simulieren. Durch die VMware Server stehen mehrere Workstations und Server zur Verfügung, die wie eine Virtuelle Maschine genutzt werden können. Die entstehende Rechneroberfläche ist sehr einfach zu konfigurieren und jeder mögliche Bedrohungs-Fall lässt sich dabei simulieren. Unsere Ursprungsfrage, was ist eine Sandboxanalyse lässt sich nun vor diesem Hintergrundwissen gut beantworten. Durch die Vorteile einer Sandbox, können dort problemlos ganze Systeme getestet werden und im Hinblick auf potentielle Schadware, besteht die Möglichkeit diese zunächst in den gesicherten Bereichen auf ihr Risiko zu testen. Die FortiSandbox geht beispielsweise der immer größer werdenden Bedrohung durch Cyber Kriminalität und der damit einhergehenden Datenschutzverletzung entgegen, indem mit einer Sandbox-Methode eine Sicherheitsarchitektur geschaffen wird, in der sämtliche Bedrohungen separat geprüft werden und dann natürlich mit gekoppelten anderen Anwendungen gemeldet beziehungsweise eliminiert werden. Ein weiteres bekanntes Anwendungsbeispiel ist Chrome. Dort werden potenziell unsichere Programmteile kontinuierlich in unabhängigen Sandbox-Prozessen getestet.

Es kommt immer wieder vor, dass auf hochauflösenden Monitoren unter Windows bestimmte Programme oder Programmteile nicht korrekt oder verzerrt dargestellt werden. Teilweise sind nur Schriften verändert, manchmal lässt sich das Programm aber durch die fehlerhafte Auflösung nicht korrekt bedienen. In diesem kurzen Video seht ihr, wie man dies unter Windows 10 einstellen kann.

Was Radio heute Kindern und Jugendlichen bieten kann Mein selbsternannter Stammgast und ich fahren in den schönen Kanton Aargau. Unterwegs leeren wir unsere Hirnmasse darüber aus, was Radio heute den Kindern und Jugendlichen noch bieten kann – oder könnte. Was gehört eurer Meinung nach unbedingt in ein modernes Radioprogramm für Kinder? Ideen für innovative Programmteile, […]

Ziel dieser Arbeit war es ein neuartiges optisches Meßsystem zu testen und für eine klinische Verschleißanalyse von Kompositinlays (Visio Gem® Fa Espe®) einzusetzen. Im Rahmen einer ausführlichen Literaturstudie entstand eine detaillierte Übersicht über die verschiedenen Verfahren für In-vivo-Verschleißanalysen. Auf die Vor- und Nachteile der einzelnen Meßsysteme wird eingegangen. Bei dem eingesetzten 3D Meßsystem handelt es sich um einen Lichtschnittsensor, der nach dem Triangulationsverfahren arbeitet. Ein Laserstrahl wird als Lichtlinie auf das Messobjekt abgebildet. Mit einem CCD-Chip wird diese Linie erfasst. Der seitliche Versatz der Linie beinhaltet in Abhängigkeit vom Triangulationswinkel die Höheninformation. Zu Beginn existierte nur ein Prototyp des optischen 3D-Sensors. Durch größere Umbauten und durch Automatisierung wurde der Sensor bis zur Serienreife weiterentwickelt. Die Überlagerung der zu vermessenden Bilder erfolgt referenzpunktfrei mittels einer eigens entwickelten Matching-Software. Die Probenbefestigung im Prototyp des Sensors stellte ein erhebliches Problem dar, weil zur Vermessung die unterschiedlichsten Formen und Größen positioniert werden mussten. Zur Datenerhebung standen Einzelzahn, Quadranten- und ganze Kiefer- Modelle an. Die ersten Sensoren besaßen obendrein nur eine Kamera-Optik-Einheit. Alle Abtastungen, die Verschattungen aufwiesen, mussten daher von zwei Seiten aufgenommen werden, um abschattungsfreie Okklusalflächen generieren zu können. Daher wurde ein geeigneter Objektträger mit einem Aufsatz, der um 180° umzusetzen ist, entwickelt. Der industriell gefertigte Träger kann alle Objektgrößen (Einzelzahn-, Quadranten-, Kiefer- Modelle) aufnehmen. Testreihen zur Qualitätssicherung deckten einige Probleme der Software auf. Durch Korrektur einiger Parameter bzw. Implementierung neuer Programmteile in die Auswertungssoftware konnten diese beseitigt werden. Aus der Validierung des Gesamtsystems konnten die folgenden technischen Daten für den 3D-Laserscanner ermittelt werden: Auflösung in der x-Achse (seitlich; CCD-Chip) 25 µm Auflösung in der y-Achse (längs der Abtastrichtung; Schrittmotor) > 2 µm Auflösung in der z-Achse (Höhe) 5 µm Messzeit :40 ms/Linie (512 Messpunkte) 5.000 – 10.000 Oberflächenpunkte / sec. Tiefenmessbereich 15 mm Reproduziergenauigkeit 1 µm +/- 1 Gesamtgenauigkeit 10 µm +/- 3 Der Prototyp konnte durch die Weiterentwicklung (ab Sensor 2) für die Erhebung größerer Datenmengen eingesetzt werden. Durch die Verbesserung der Software bzw. die Entwicklung eines eigenen „matching“-Programms (match 3d) durch Gloger (1993) (KUNZELMANN 1998; S. 30-35) kann die Auswertung der gewonnenen Daten schnell und komfortabel erfolgen. Erstmals wurde der Laser-Scanner für die Auswertung klinischer Daten verwendet. Die Auswertung des Verschleißes von Kompositinlays aus Visio Gem® erfolgte an Gipsmodellen (New Fuji Rock®). Für die Untersuchung standen 32 Zähne bzw. Inlays zur Verfügung, 14 Prämolaren und 18 Molaren. Die durchschnittliche Verweildauer betrug 48,8 Monate, bei den Prämolaren allein 47,4 Monate und bei den Molaren allein 49,8 Monate. Bei 13 Zähnen war eine Ausmessung der Inlaygrösse möglich. Sie betrug im Durchschnitt 45% der sichtbaren Fläche, bei den Prämolaren 51%, bei den Molaren 39%. Die Bilddaten wurden in zwei Gruppen ausgewertet. Zum einen die Gesamtgruppe aus 32 Zähnen, zum anderen eine Auswahl der besten, bestehend aus sechs Molaren und 3 Prämolaren. Der Mittelwert der Standardabweichungen betrug 158 [µm] (Gruppe2: 88 [µm]). Genauer: Prämolaren 110 [µm] (Gruppe2: 85 [µm]), Molaren 196 [µm] (Gruppe2: 91 [µm]). Die Anforderungen der ADA (1989) für Seitenzahnfüllungen der Klasse II erfüllen die Visio Gem®-Inlays nicht.