Blog
Blog

In unserem Blog stellen wir Ihnen Themen vor, die unsere Belegschaft und das Unternehmen bewegen.

Unsere Belegschaft setzt sich aus einer Menge von Menschen zusammen, die bereits viele Erfahrungen in unterschiedlichsten Branchen und Aufgabenfeldern sammeln konnten. Bei unserer tĂ€glichen Zusammenarbeit wird natĂŒrlich auch diskutiert, voneinander gelernt, Entscheidungen getroffen, großartige Dinge geschaffen aber auch Fehler gemacht. In unserem Blog möchten wir Ihnen davon erzĂ€hlen.

Vor allem aber möchten wir mit Ihnen sprechen und Ihre Meinung zu unseren BeitrĂ€gen erfahren. Wir wĂŒrden uns sehr freuen, von Ihnen zu hören.



Programmiersprache Kotlin - Nicht nur im Android-Umfeld interessant

Kotlin ist eine relativ neue, statisch typisierte, JVM-Programmiersprache, die von JetBrains [1] entwickelt wird. Die Version 1.0 wurde Anfang 2016 veröffentlicht. Trotzdem ist Kotlin bereits seit lĂ€ngerem verfĂŒgbar und wurde auch vor diesem Release produktiv eingesetzt. Vor allem in der Android-Community hat Kotlin einige AnhĂ€nger gewinnen können und ist spĂ€testens seit der diesjĂ€hrigen Google Konferenz "I/O" in aller Munde, als man erklĂ€rte, dass Kotlin nun "offizielle Sprache fĂŒr Android" ist. Wir bei der Firma n-design sind stĂ€ndig gespannt, wenn es um neue Frameworks und Programmiersprachen geht, sodass auch diese Entwicklung mit Interesse verfolgt wird.

Warum ist Kotlin so interessant fĂŒr Android?

Der Grund ist relativ einfach, denn Kotlin kann zu Java 1.6 Bytecode kompiliert werden. Android unterstĂŒtzt in den meisten Versionen nicht das neuste JDK 1.8, wodurch Android-Entwickler auf moderne Java-Sprachfeatures wie Lambdas und Streams [2] verzichten mĂŒssen. Kotlin jedoch bietet diese Features, und viele weitere, natĂŒrlich ebenfalls an, obwohl lediglich Java 6 benötigt wird, um den kompilierten Code auszufĂŒhren. JetBrains' Idee beim Entwickeln der Sprache war, eine Alternative zu Java zu schaffen, die Probleme behebt, die ProduktivitĂ€t steigert und weiterhin mit Java-Code vollstĂ€ndig interagieren kann. Ich denke, dass jeder Java-Entwickler, der bereits mit JVM-Sprachen wie Groovy und Scala gearbeitet hat, weiß, dass Java oft sehr "geschwĂ€tzig" ist und viel Boilerplate-Code geschrieben werden muss, auch um simple Dinge zu bewerkstelligen. Kotlin setzt hier an und ermöglicht das Schreiben von deutlich kĂŒrzerem Sourcecode, wobei Scala erkennbar als Inspiration diente.

Weiterlesen...
 

Die Kurve kriegen -- Hacking the JVM for Enhanced Crypto

Die Kurve kriegen -- Hacking the JVM for Enhanced Crypto

Bei einem staatlich getriebenen Projekt wie der EinfĂŒhrung der elektronischen Gesundheitskarte steht die IT-Sicherheit an oberster Stelle. Dass aber die Anforderungen des Auftraggebers und der Zulassungsstelle ĂŒber das hinausgehen, was die von uns gewĂ€hlte Plattform fĂŒr unser embedded device in der Telematik-Infrastruktur von Haus aus liefern kann, ruft bei uns Entwicklern und Software-Ingenieuren gemischte GefĂŒhle hervor: Der Kitzel, etwas wirklich Neues zu schaffen, aber auch die Ahnung, dass man sich auf unbekanntem Gebiet ziemlich verirren kann.

So auch bei n-design, als die neuen Spezifikationen des Auftraggebers vorschrieben, dass TLS mit ECDHE Cipher-Suiten umgesetzt werden muss. ECDHE steht fĂŒr die SchlĂŒsselaushandlung nach Diffie-Hellman mit Verfahren ĂŒber elliptischen Kurven. GrundsĂ€tzlich ist das kein Problem, da Java schon seit einigen Jahren in diesem Bereich auch mit elliptischen Kurven umgehen kann. Außerdem ist es sehr zu begrĂŒĂŸen, dass diese modernen Verfahren Aufnahme in die Spezifikation finden. Sie bieten bei vergleichbarem Rechenaufwand ein deutlich höheres Sicherheitsniveau als die klassischen RSA-basierten Verfahren. Das ist fĂŒr die Entwicklung eines embedded GerĂ€ts auf der Basis eines Mobilprozessors ein Segen, da die zukĂŒnftig notwendigen SchlĂŒssellĂ€ngen mit der im Projekt gegebenen Hardware nicht gut zu berechnen wĂ€ren.

Weiterlesen...
 

Testautomatisierung mit der Test Workbench

Testgetriebene Entwicklung gehört bei n-design zum Alltag. Hierbei kommt die ĂŒbliche Toolchain bestehend aus JUnit, Maven (Surefire Plugin) und Jenkins zum Einsatz. Damit erreichen wir eine hohe Testabdeckung im Bereich der Komponententests und können eine großen Teil von Integrationstests umsetzen.

FĂŒr die DurchfĂŒhrung von Systemtests kommen zusĂ€tzlich unterschiedliche Werkzeuge, z.B. Selenium fĂŒr Web-GUI-Tests oder SOAP-UI fĂŒr WebServices, zum Einsatz. Diese eher lose Tool-Sammlung ist fĂŒr eine begrenzte Menge an explorativen Tests und seltene Deployments beherrschbar. Das wird allerdings schnell anders, wenn die Zahl der Tests steigt und diese hĂ€ufig oder regelmĂ€ĂŸig ausgefĂŒhrt werden sollen.

Im Rahmen der Entwicklung einer dezentralen Komponente der Telematikinfrastruktur der gematik, die wir bei n-design betreiben, mĂŒssen hohe Anforderungen an Systemtests erfĂŒllt werden, so dass wir dringend eine Lösung zur Testautomatisierung finden mussten.

Weiterlesen...
 

Dependency Injection - Theorie und Praxis am Beispiel von Google Guice

n-design ist OSGi -Verfechter der ersten Stunde. Dabei basiert die Überzeugung von dieser Technologie allerdings nicht auf der Technologie als solcher, sondern vielmehr auf OSGis Grundprinzipien, die zu einer strukturierten Architektur eines Softwaresystems durch Modularisierung und Serviceorientierung fĂŒhren. In einer solchen Architektur bildet Dependency Injection einen grundlegenden Baustein. Gilt es nun Technologien fĂŒr die Umsetzung neuer Projekte auszuwĂ€hlen, steht OSGi als bevorzugtes und beherrschtes Mittel im Vordergrund.

Was jedoch, wenn nun kein komplexes System, sondern lediglich ein einfaches Java-Programm, ein (kommandozeilenbasiertes) Tool oder ein strukturiertes Maven-Plugin umgesetzt werden soll? Hier scheint OSGi als Technologie sicherlich ĂŒberdimensioniert. Als leichtgewichtige Alternative konnten hier zuletzt gute Erfahrungen mit Google Guice gesammelt werden.

In diesem Blog-Beitrag soll das Thema Dependency Injection und die Design-Prinzipien, aus denen das Dependency Injection Pattern folgt, erlĂ€utert werden. Anschließend wird Google Guice als einfaches Framework zur Umsetzung von ModularitĂ€t und Dependency Injection vorgestellt.

Weiterlesen...
 

Entwicklung zertifizierter Software nach Common Criteria

Erfahrungsbericht „Vom Umbauprozess bis zur Evaluierung“

Die Entwicklung von Softwarekomponenten, die nach Common Criteria (CC) zertifiziert werden sollen, stellt ein Unternehmen vor große Herausforderungen. Mit dem Auftrag zur Entwicklung des Anwendungskonnektors fĂŒr die Telematikinfrastruktur im Gesundheitswesen mussten wir uns diesen Herausforderungen stellen. [Link zur Referenz „Zertifizierte Entwicklung]

Der Konnektor ist die dezentrale Zugangskomponente zur Telematikinfrastruktur.  Er muss vom Bundesamt fĂŒr Sicherheit in der Informationstechnik (BSI) nach Common Criteria im Level EAL3+ AVA VAN5 zertifiziert werden. Eine vom BSI anerkannte PrĂŒfstelle nimmt als sachverstĂ€ndige Stelle die PrĂŒfung und Bewertung (Evaluierung) des Konnektors vor. Sie stellt die technische Korrektheit und die inhaltliche VollstĂ€ndigkeit der PrĂŒfergebnisse sicher und stellt der Zertifizierungsstelle die vollstĂ€ndigen PrĂŒfergebnisse zur VerfĂŒgung.

Weiterlesen...
 

eHealth-Gesetz – Status quo

Im April dieses Jahres fĂŒhrte mich die diesjĂ€hrige Connecting Healthcare IT (conhIT) nach Berlin. Sie gilt als die fĂŒhrende Messe fĂŒr die Gesundheits-IT Europas. Die Messe, die bereits in die neunte Runde geht, stand unter dem Motto „Patient im Fokus – Innovative Healthcare IT“.

Wie diese technischen Innovationen in naher Zukunft auch einen Nutzen fĂŒr den Patienten herbeibringen sollen, beantwortete der Bundesminister fĂŒr Gesundheit, Hermann Gröhe, wĂ€hrend seiner Eröffnungsrede bei der conhIT mit dem verabschiedeten eHealth-Gesetz. im Folgenden möchte ich daher dieses eHealth-Gesetz  genauer betrachten, um einen Überblick ĂŒber die Thematik und deren aktuellen Stand zu schaffen.

Weiterlesen...
 


Seite 1 von 5