Mari kita mulai reli off-road dan kecerobohan Java EE! Wawancara dengan Sebastian Dashner, Komisaris EE Jakarta

Hari ini di studio virtual kami adalah Sebastian Dashner. Singkatnya, siapa ini:

• Pimpin Advokat Pengembang Java di IBM;
• Banyak laporan dan video menarik di YouTube ;
• Penulis Aplikasi Modern Java EE ,
• Anggota Proses Komunitas Java: kelompok ahli JAX-RS, JSON-P, Config;
• Pengganti dalam banyak proyek sumber terbuka, termasuk semua yang terkait dengan Java EE / Jakarta EE / MicroProfile.

Dalam wawancara ini kita akan berbicara tentang topik-topik berikut:

Wawancara, seperti biasa, oleh Evgeny Trifonov ( phillenium ), dan Oleg Chirukhin ( olegchir ) dari Grup JUG.ru.

Eugene: Mari kita mulai dengan masalah non-teknis. Di Twitter Anda, saya melihat foto Anda di Novosibirsk dengan kaus JAVA. Apa kesan Anda tentang perjalanan ini?

Sebastian: Senang Anda mengenali fotonya, saya punya kaus ini bersama Joker 2017. Saya pasti ingat konferensi JBreak. Saya tidak akan pernah membayangkan bahwa saya akan pergi ke sudut yang jauh dari Siberia - saya pikir dari lingkaran teman-teman saya, saya adalah salah satu dari sedikit orang yang telah ada di sana. Selain itu, sehari sebelum konferensi, saya merayakan ulang tahun saya, dan kami pergi mengendarai mobil salju, setelah itu kami duduk di pemandian dan makan kebab. Secara umum, ada banyak kenangan yang menyenangkan. Alam di sekitar Novosibirsk sangat indah. Dan fakta bahwa, jika Anda menghitung Krasnoyarsk dan Tomsk, untuk seribu kilometer di sekitar Anda, tidak ada kota besar lainnya, sangat mengesankan.

Eugene: Anda adalah Java Developer Advocate di IBM. Ini bukan posisi yang sangat umum - Advokat Pengembang lain yang saya tahu cenderung mempromosikan produk perusahaan mereka. Apa tanggung jawab Anda yang sebenarnya di IBM? Apakah Anda mencoba memaksimalkan distribusi dan penggunaan Java secara efisien dalam setiap cara yang memungkinkan?

Sebastian: Ya, ini adalah deskripsi yang cukup akurat tentang apa yang saya lakukan. Saya harus menambahkan bahwa di tempat pertama saya dalam kepentingan tidak begitu banyak perusahaan atau produk, tetapi para pengembang. Saya berusaha untuk memfasilitasi pekerjaan mereka dan mengajarkan berbagai hal terkait Java Enterprise. Saya membagikan pengetahuan saya di blog, podcast, seminar, dan konferensi. Saya tidak menjual produk tertentu, melainkan saya menjual teknologinya secara keseluruhan.

Eugene: Anda adalah pendukung besar open source, tetapi bekerja untuk IBM, yang bagi kebanyakan orang tidak terkait dengan open source. Pada saat yang sama, saya tahu bahwa IBM kadang-kadang mengambil bagian yang agak aktif dalam banyak proyek sumber terbuka, misalnya, di OpenJ9. Bagaimana kaitan IBM dengan open source?

Sebastian: Anda dengan benar mencatat bahwa banyak yang sering meremehkan partisipasi IBM dalam proyek sumber terbuka - saya sendiri tidak tahu tentang hal ini sampai saya mulai bekerja di perusahaan ini. Sebagai contoh, IBM melakukan banyak pekerjaan di Cloud Native dan di Java dan merupakan salah satu kontributor utama untuk Kubernetes dan Istio. Akses ke sumber OpenJ9 dibuka oleh Eclipse Foundation, yang, pada gilirannya, diciptakan oleh IBM. Perusahaan juga berkontribusi pada pengembangan teknologi tanpa server, seperti Apache OpenWhisk. Secara umum, programmer IBM sangat berpikiran terbuka - hampir semua yang dilakukan di perusahaan ini memiliki aspek open-source atau versi terbuka. Sejauh ini, orang benar-benar tidak cukup akrab dengan upaya IBM dalam arah ini, dan pekerjaan saya sebagai Advokat Pengembang adalah, antara lain, untuk memberi informasi kepada komunitas.

Oleg: Saya baru-baru ini membaca di Twitter bahwa Anda melakukan perjalanan sepeda motor JUG khusus di Jepang dengan Steve Chin. JUG di sepeda motor, whaaaat? Bisakah Anda menguraikan ini?

Sebastian: Perjalanan yang luar biasa. Steve Chin dan saya telah bepergian dengan sepeda motor beberapa kali, dan setiap kali kami mencoba menggabungkan ini dengan pidato di konferensi dan dalam kelompok pengguna. Beberapa perjalanan seperti itu di Jerman, dan tiga di Jepang. Pada pandangan pertama, sepertinya kita melakukan ini hanya untuk bersenang-senang - dan, tentu saja, kita tidak dapat menyangkal bahwa kita bersenang-senang dalam perjalanan ini. Tapi dari sudut pandang yang murni praktis, sepeda motor adalah bentuk transportasi yang sangat nyaman untuk Jepang atau Eropa Tengah, karena ada kota-kota dengan kelompok pengguna dan komunitas TI yang berjarak hanya seratus atau dua kilometer, dan Anda dapat menghindari kemacetan lalu lintas pada sepeda motor. Dalam setiap perjalanan ini, kami mencoba untuk bertemu dengan jumlah maksimal orang dan membagikan pengetahuan kami kepada mereka.

Oleg: Kamu sering bepergian dan bahkan pergi ke Rusia, meskipun tidak mudah untuk mendapatkan visa kami. Ada pendapat bahwa Pengembang Advokat bukan pekerjaan serius. Seolah-olah Anda bepergian ke seluruh dunia, bersenang-senang di konferensi - apa saja, hanya untuk tidak menulis kode. Apakah Anda pikir Anda memiliki kerja keras yang nyata? Sepertinya terbang setiap hari harus melelahkan.

Sebastian: Saya pikir kedua sudut pandang itu sedikit benar. Saya suka pekerjaan saya, tetapi itu jauh dari selalu sederhana. Satu tidak mengganggu yang lain. Memang, perjalanan bisa melelahkan, terutama jika Anda tidak beristirahat tepat setelah beraktivitas, tetapi berbicara di konferensi atau mengatur seminar. Dan tepat setelah konferensi Anda perlu naik pesawat lagi, jadi sepanjang hari sibuk. Di sisi lain, jika kegiatan ini tidak dilakukan, maka atap akan dengan cepat berubah dari ritme seperti itu, dan seseorang akan terbakar begitu saja. Secara umum, jika saya berhasil mengajari orang sesuatu dan mengadakan seminar yang sukses dalam sehari, maka kelelahan pun menjadi menyenangkan.

Eugene: Sejauh yang saya tahu, pekerjaan ini membutuhkan banyak upaya agar tetap up to date dengan teknologi terbaru di lapangan. Karena beban kerja tambahan untuk Pengembang Advokat, ini lebih sulit daripada bagi mereka yang terus-menerus memprogram. Saya tahu bahwa Anda secara teratur menulis kode untuk EE Jakarta, jadi Anda jelas belum melepaskan diri dari teknologi. Apakah sulit untuk menjadi Advokat Pengembang dan sekaligus pengembang?

Sebastian: Ya, tentu saja, untuk pekerjaan saya, sangat penting untuk tetap menjadi seorang programmer, jika tidak Anda akan kehilangan kontak dengan kenyataan. Untuk berbicara tentang teknologi secara kompeten, Anda perlu pengalaman terus-menerus bekerja dengannya. Dan waktu pemrograman benar-benar jauh lebih sedikit karena konferensi. Selain itu, Anda harus benar-benar terpesona oleh sisi teknis hal-hal dan Anda akan siap untuk menghabiskan malam dan akhir pekan untuk itu. Secara umum, keseimbangan tertentu diperlukan antara kedua sisi kegiatan.

Oleg: Mari kita beralih ke masalah teknis. Ada epigraf di halaman pertama blog Anda:

TI harus sederhana dan produktif.
IT harus menyelesaikan masalah, bukan membuat masalah.
Saya percaya bahwa IT adalah peluang, bukan faktor biaya.

Menurut Anda, apa faktor terpenting yang menentukan produktivitas pengembang Java? Apakah ada tips tentang cara menjadi lebih produktif, hack seumur hidup, nishtyaki teknis spesifik, dan utilitas seperti jcmd atau sdkman, apa saja?

Sebastian: Ya, ada banyak program seperti itu. Adapun kesederhanaan, kita berbicara tentang perlunya berusaha untuk menyingkirkan kompleksitas yang berlebihan baik dalam alat yang kami kembangkan dan dalam implementasi di mana kami menggunakan alat ini. Seringkali, pengembang tertarik oleh kompleksitas dalam dirinya sendiri, semakin banyak fitur ditambahkan ke produk semata-mata karena minat olahraga. Anda selalu perlu bertanya pada diri sendiri: apakah dunia akan menjadi lebih baik dari fitur ini? Apakah akan membantu menyelesaikan masalah? Apakah ini akan membawa kita lebih dekat untuk menyelesaikan produk?

Jika kita berbicara tentang produktivitas pengembang sendiri, saya benar-benar dapat merekomendasikan sumber daya untuk ini. Google nama saya dan frasa "produktivitas pengembang." Saya merekam kursus video, yang diposting di Youtube , dan di sana saya memberikan saran hanya tentang topik ini. Ini berbicara tentang menggunakan baris perintah, tombol pintas, dan cara menggunakan keyboard. Poin umumnya adalah bagaimana melakukan lebih banyak pekerjaan dalam waktu yang lebih singkat. Dan jika Anda mulai mempelajari topik ini, maka proses otomatisasi dan optimalisasi pekerjaan akan tertunda. Anda akan menjadi lebih banyak waktu untuk memikirkan solusi untuk masalah dan kurang - bodohnya mengetuk tombol. Secara umum, kinerja pemrograman adalah topik yang sangat dekat dengan saya.

Oleg: Sejauh yang saya mengerti, Anda adalah pengemis di MicroProfile, dan karena itu Anda dapat mengetahui segala sesuatu yang berkaitan dengannya. Tolong beri tahu kami apa yang terjadi di sekitar Jawa EE dan Jakarta? Saya membaca sedikit tentang itu, tetapi bagi saya, sebagai orang dari dunia Musim Semi, semua ini terlalu membingungkan.

Sebastian: Seperti yang Anda ketahui, Jakarta EE adalah penerus Java EE, yang sekarang sedang ditransfer ke Eclipse Foundation. Ini adalah proses yang agak rumit, dan belum selesai, sehingga pengembang belum dapat menggunakan EE Jakarta. Namun, fondasinya masih berdasarkan standar Java EE, titik awalnya adalah Java EE 8. Tentu saja, di masa depan, EE Jakarta akan terus berkembang dengan cara yang sama seperti Java EE berevolusi melalui JCP (Java Community Process). Ini berarti bahwa komunitas dari beberapa perusahaan, perusahaan dan pengembang individu akan bersama-sama mengembangkan standar untuk versi perusahaan baru Java.

Karena perubahan dalam Java EE ini, MicroProfile muncul. Itu dibuat oleh beberapa vendor yang menjalankan server Java EE. Tujuannya di sini adalah untuk memastikan perkembangan teknologi yang lebih cepat, tidak terlalu terikat pada standar yang ketat. Tampaknya sangat menarik bagi saya bahwa MicroProfile sedang mencoba untuk menebus kekurangan Java EE sehubungan dengan microservices cloud-asli modern. Misalnya, Java EE belum memiliki sistem untuk konfigurasi injeksi, toleransi kesalahan, pemantauan, segala macam OpenTracing, dan sejenisnya. MicroProfile memberi Anda akses ke semua hal ini, jadi Anda tidak perlu menerapkan semuanya sendiri. Selain itu, dalam hampir semua kasus, kompatibilitas dengan Java EE dihormati. Standar Java EE (seperti JAX-RS dan CDI), yang sudah dikenal oleh sebagian besar pengembang JavaEE, dijadikan dasar. Karena itu, ketika saya menemukan toleransi kesalahan dalam aplikasi Java EE saya, misalnya, saya tidak menulis semua ini secara manual, tetapi mengintegrasikan MicroProfile dengan aplikasi saya. Kedua ekosistem ini berbaur dengan sangat baik. Untuk banyak aplikasi, seperti Open Liberty atau Payara, runtimes mendukung MicroProfile dan Java EE. Semua yang masih harus dilakukan dalam hal ini adalah memasukkan fitur-fitur tertentu dalam runtime, dan kemudian menambahkan proyek-proyek MicroProfile yang diperlukan ke aplikasi Java EE. Sementara kami menunggu transisi akhir Java EE ke Eclipse Foundation, Anda dapat menggunakan solusi ini.

Oleg: Apakah menurut Anda MicroProfile harus menjadi bagian dari Jakarta?

Sebastian: Ini pertanyaan yang bagus, dan belum ada keputusan akhir untuk itu. Secara pribadi, saya pikir MicroProfile berfungsi paling baik sebagai semacam inkubator untuk Jakarta EE. Standar baru pertama kali ditambahkan ke MicroProfile (seperti yang dilakukan dengan OpenTracing atau konfigurasi injeksi), dan kemudian kita melihat bagaimana sistem berperilaku dalam produksi. Ketika dia mencapai kedewasaan, elemen-elemen dirinya yang telah membuktikan diri untuk menjadi standar penuh. Dengan demikian, kita menyingkirkan beberapa ketidakpastian, karena kita sudah tahu apakah sistem bekerja dengan baik dalam produksi atau tidak.

Oleg: Karena kita berbicara tentang standar, saya melihat Proses Spesifikasi Eclipse, itu adalah googlodok besar, yang sangat sulit untuk dipahami. Dokumen dengan spesifikasi rancangan EE Jakarta tampak seperti kusut. Bisakah Anda membantu bola ini untuk melepas lelah? Misalnya, bagaimana hal ini berbeda dari Proses Komunitas Java?

Sebastian: Eclipse Foundation adalah organisasi sumber terbuka. Saat ini, kami sedang mencoba untuk menentukan bentuk dari proses-proses tersebut sesuai dengan yang akan dikembangkan EE Jakarta di masa depan. Anda menyebutkan JCP - jadi, saya sepenuhnya setuju dengan pendapat bahwa standar untuk Jakarta EE harus dimodelkan pada JCP. Saya percaya bahwa model ini menunjukkan dirinya dengan sangat baik. Harus diingat bahwa tidak ada perusahaan yang memonopoli pengembangan standar untuk EE Jakarta. Beberapa perusahaan dengan hak yang kurang lebih sama berpartisipasi dalam proses ini, sehingga ia tidak akan terjebak dalam pengembangan jika salah satu dari mereka tidak dapat berpartisipasi di dalamnya lagi. Saya pikir ini adalah keuntungan penting, karena teknologi ini sangat penting, dan lebih aman untuk dikembangkan di komunitas terbuka.

Oleg: Teknologi canggih semacam itu perlu diuji pada sesuatu. Apakah Anda menggunakan Kit Kompatibilitas Teknologi untuk Jawa dan Jakarta? Atau apakah Anda memiliki ruang tes sendiri?

Sebastian: Ini juga topik yang sangat penting. Di JCP, semua TCK ini biasanya memiliki sumber tertutup. Ini adalah keuntungan yang cukup meragukan. Di satu sisi, spesifikasi dapat memberikan tes yang menunjukkan apakah beberapa implementasi valid atau tidak. Tetapi pengembang biasa tidak tahu persis apa yang diuji di sana di dalam, apa cakupan tes ini, dll. Sekarang TCK telah menjadi sumber terbuka. Semua perusahaan dan pengembang sekarang dapat berpartisipasi dalam pengembangan dan peningkatan mereka. Jika ternyata produk perusahaan tidak berfungsi seperti yang disebutkan dalam spesifikasi, maka Anda tidak hanya dapat menunjukkan ini kepada perusahaan, tetapi juga meninggalkan permintaan di TCK itu sendiri. Atau bahkan lebih baik, Anda dapat mengirim beberapa permintaan tarik dan meningkatkan TCK itu sendiri. Jadi, Anda meningkatkan tidak hanya perangkat lunak satu pemasok, tetapi seluruh ekosistem.

Oleg: Ada produk lain yang memiliki kata "Profil" dalam namanya: IBM WebSphere Liberty Profile. Karena Anda bekerja di IBM, dapatkah Anda memberi tahu kami apa itu dan apa perbedaan dari Open Liberty?

Sebastian: WebSphere Liberty Profile adalah versi komersial dari Open Liberty. Ini adalah server aplikasi Java EE yang untuknya IBM menyediakan dukungan komersial. Saya bisa saja salah, tetapi, menurut saya, Open Liberty menjadi open source satu setengah tahun yang lalu. Berkat ini, pengembang perusahaan sekarang memiliki server aplikasi yang bebas dan teruji produksi. Jika suatu perusahaan membutuhkan dukungan komersial atau beberapa fitur komersial, ia dapat menggunakan Profil Liberty WebSphere. Ini tahun 2019, dan saya percaya bahwa sekarang setiap perusahaan harus menyediakan versi open source dari produknya sehingga pengembang memiliki kesempatan untuk mencoba produk secara gratis. OpenSource sangat penting, dan saya senang bahwa IBM sekarang memiliki beberapa opsi untuk WebSphere Liberty Server sebelumnya.

Oleg: Saya dengar ada tertulis di atas OSGi. Bisakah Anda memberi tahu kami lebih lanjut tentang bagaimana pengaturannya di dalam?

Sebastian: Saya pribadi tidak mengembangkan Open Liberty, tetapi sejauh yang saya tahu, itu benar-benar ada di bawah OSGi. Sangat menarik bahwa di sana Anda dapat dengan mudah mengkonfigurasi fitur mana yang akan disertakan. Jika Anda hanya ingin menggunakan MicroProfile, yang hanya mencakup sejumlah kecil standar Java EE, maka Anda dapat mengonfigurasi sistem yang sesuai. Atau Anda dapat membuatnya sehingga Anda memiliki aplikasi Java EE lengkap. Karena kenyataan bahwa hanya apa yang benar-benar dibutuhkan yang termasuk dalam instance berjalan, waktu startup yang optimal dan konsumsi sumber daya minimal tercapai.

Oleg: Apakah konfigurasi dan penggunaan Profil Liberty berbeda dari Profil Lengkap? Apakah alat yang sama digunakan dalam kedua kasus?

Sebastian: Tidak ada perbedaan signifikan dalam penggunaan. Mengenai pilihan fitur, kedua server dapat dikonfigurasi secara sama. Jika Anda memiliki aplikasi Java EE atau MicroProfile, setup akan sama untuk kedua jenis.

Oleg: Perusahaan telah menggunakan Profil Lengkap untuk waktu yang lama. Bagaimana dibenarkan penggunaan Profil Liberty di organisasi besar?

Sebastian: Benar-benar dibenarkan. Sekalipun perusahaan membeli dukungan komersial, ini tidak berarti harus menggunakan Profil Lengkap, cukup masuk akal untuk menggunakan versi yang lebih ringan. Jika produk korporasi didasarkan pada layanan mikro modern dan runtime ringan, maka mungkin lebih baik bagi mereka untuk memilih WebSphere Liberty dan mengkonfigurasinya sehingga berfungsi, katakanlah, hanya dengan MicroProfile. Untungnya, dukungan komersial dan fitur komersial tidak ada hubungannya dengan dunia lama WebSphere, sehingga runtime itu sendiri sangat ringan dan kompak, dimulai dengan sangat cepat dan dapat digunakan dalam hitungan detik. Jadi jika Anda memiliki aplikasi berbasis Java EE modern, Anda dapat mengkonfigurasi fitur-fitur Anda sesuai dan hanya menyertakan standar-standar yang benar-benar dibutuhkan. Terlepas dari apakah Anda menggunakan fitur komersial, Anda masih memiliki akses ke runtime yang cepat dan modern ini.

Oleg: Pada bulan Oktober, Oracle merilis Helidon, kerangka kerja layanan mikro yang ringan di Jawa. Sejauh yang saya tahu, itu tidak menggunakan server aplikasi yang ada, itu dibangun di atas set perpustakaan sendiri. Bersama-sama mereka menyediakan dasar untuk membangun layanan microser - fitur untuk konfigurasi, pengaturan keamanan, meningkatkan server web, dan sebagainya. Di atas sistem ini, MicroProfile bahkan diterapkan. Saya mendapat kesan bahwa pengembang Helidon berpikir bahwa Java EE memiliki terlalu banyak warisan dan perlu dibuang dan ditulis ulang. Apa yang Anda pikirkan tentang ini?

Sebastian: Helidon adalah proyek yang sangat menarik. Tapi jujur ​​saja, sepertinya naif bagi saya untuk berpikir bahwa Java EE perlu ditulis ulang sepenuhnya. Memang, sebagian besar aplikasi tidak memerlukan Java EE secara keseluruhan. Sebagai aturan, seperangkat fitur / standar khusus diperlukan, paling sering digunakan dalam aplikasi perusahaan. Misalnya, MicroProfile reguler belum menyediakan JPA atau skrip kompleks untuk multithreading. Ini memerlukan setidaknya beberapa komponen Java EE. Secara umum, saya sekarang melihat proses membuat aplikasi dengan cara ini. Berdasarkan komponen paling penting dan modern dari Java EE, misalnya, CDI, JPA, JAX-RS, JTA dan seterusnya, kami memilih serangkaian standar yang kami butuhkan, sementara mengabaikan banyak hal yang diwariskan yang ada di Java EE. Berdasarkan pilihan ini, kami menggunakan runtime yang mendukung semua fitur ini. Jika kami melakukan sesuatu yang terkait dengan layanan microser-cloud asli, maka kami menambahkan standar MicroProfile, misalnya, toleransi kesalahan. Tetapi runtime seperti Helidon tidak mendukung fitur yang hanya dimiliki oleh Java EE, dan sementara itu, multithreading atau JPA adalah fitur yang, menurut pengalaman saya, sangat diperlukan. Saya lebih suka runtime yang mendukung Java EE / Jakarta EE dan Microprofile, dan pada saat yang sama memberikan kesempatan untuk memilih fitur yang diperlukan untuk aplikasi tertentu. Misalnya, jika Anda membutuhkan kegigihan dan memiliki basis data, Anda dapat mengaktifkan JPA. Secara umum, Anda akan memiliki set fitur yang sangat mirip dengan MicroProfile, tetapi sesuatu dari Java EE juga akan diperlukan. Jenis runtime ini adalah Open Liberty, Payara, WildFly, dan sebagainya.

Oleg: Setahu saya, salah satu fitur paling menarik yang akan diterapkan di Jakarta dalam waktu dekat adalah dukungan untuk teknologi cloud modern. Bagaimana dengan Java dalam wadah sekarang? Sejauh yang saya ingat, beberapa tahun yang lalu pada pelacak bug OpenJDK ada beberapa bug yang terkait dengan kompatibilitas, ukuran tumpukan, sinyal dan sebagainya. Apakah mungkin menggunakan Java dalam wadah sekarang, pada 2019?

Sebastian: Ya, tentu saja. Alasan sebagian besar masalah yang terkait dengan ini bukan Java itu sendiri, tetapi cara Linux bekerja dengan wadah. Seringkali wadah tidak tahu tentang berbagai pembatasan sumber daya yang dapat ditetapkan. Dalam versi terbaru, masalah ini telah diatasi. Sekarang Anda cukup menjalankan Java dalam wadah, dan opsi ini akan diaktifkan secara default. Dan jika Anda meminta ukuran memori dalam sistem atau ukuran tumpukan default, nilai-nilai ini akan ditentukan dengan benar. Java EE bekerja sangat baik dalam wadah Docker dan, secara umum, terintegrasi dengan baik dengan teknologi cloud-asli.

Oleg: Bagaimana dengan infrastruktur? Apakah Anda menggunakan sesuatu seperti Kubernetes atau Istio?

Sebastian: Ya, cukup aktif. Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..

: Java EE Kubernetes ? API ?

: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .

: Java ?

: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .

: JPoint « Java Enterprise». ?

: , enterprise-, . — - ; — . Java EE-, , , , .

JPoint. , — . Java-, — .

: . (, «» ). Linux, : ?

: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .

: !

, 5-6 , JPoint «Bulletproof Java Enterprise applications for the hard production life» . Simon Ritter, Kohsuke Kawaguchi, . .
.