Matt Raible iyi bilinen bir Java ve JavaScript eğitimcisidir. birkaç kitap sektördeki kredisine ve geniş deneyimine borçludur. o şu anda Okta’da geliştirici savunucusugüvenliğe odaklandığı yer ve bir üye teknoloji danışma kurulu nın-nin JHipsterönde gelen bir Java ve JavaScript geliştirme platformudur.
JHipster, esas olarak, reaktif ön uçlar kullanan tam yığın uygulamaların geliştirilmesini kolaylaştıran gelişmiş bir oluşturma aracıdır. Arka uçta Spring Boot kullanır, ön uçta React, Vue, Angular ve diğer JS çerçevelerini destekler ve hem JPA tabanlı ilişkisel veri depoları hem de MongoDB ve Cassandra gibi NoSQL veri depoları için iskele içerir. JHipster ile ilgili adım adım buradan okuyabilirsiniz.
Raible ile JHipster, Java, JavaScript, güvenlik, monolitler ve mikro hizmetler, bulut altyapısı ve daha fazlası hakkında sohbet etme şansım oldu.
Matt RaibleMatt Raible
Matthew Tyson: İnsanların sonsuza kadar kodlamayı öğrenmelerine yardımcı oluyorsunuz. Yıllar boyunca pek çok Java evangelizmi yaptınız. Şimdi biraz JavaScript ve JavaScript çerçeveleri hakkında konuşuyorsunuz. Sizi JS’ye daha fazla bakmaya ne getirdi?
Matt Raible: JavaScript benim ilk aşkımdı. İlk dili HTML olan programcılardan biriyim. 92’de. Kısa bir süre sonra JavaScript ve CSS öğrendim ve web siteleri oluşturmaya başladım. ’99’a kadar Java öğrenmeye başlamadım.
İlkbahar ve arka uç geliştirme harika olsa da, bu benim gerçek aşkım değildi. Bu her zaman UI olmuştur. 2007-2008 civarında UI geliştirmeye geri döndüm ve 2016 yılına kadar birkaç müşteri için “UI Mimarı”ydım.
2016’da sabahları JS yaparak CA için çalışıyordum ve öğleden sonra Java yapan Stormpath ile başka bir sözleşmem vardı. Stormpath beni tam zamanlı bir Java geliştiricisi olarak işe almaya çalıştı ve onlara “Hayır, gerçekten her zaman Java yapmak istemiyorum” dedim. Müzakerelerimiz birkaç ay durdu. Sonra bir “rüya işi” mektubu yazdım ve onlara gönderdim. Bu, bir savunucu olmayı (blog gönderileri, konuşma vb.) hem Java hem de JavaScript.
agresif: Java ve JavaScript’in birleşimi olarak ilgi alanlarınızın mükemmel bir birleşimi gibi görünen JHipster’ın teknoloji panosundasınız. Bu projeye nasıl dahil olduğunuzu ve bunun heyecan verici tarafını anlatır mısınız?
Raible: 2014 yazında tesadüfen rastladım. İşleri kolaylaştıran bir çerçeve kullanarak Python ile hızlı bir API ve UI prototipi oluşturan bir müşteri için çalışıyordum (hangisini unuttum). Aynısını Java’da yapabileceğimi düşündüm, JHipster’ı buldum ve benzer bir prototipi 24 saatten kısa sürede teslim ettim. Etkilendim! Ve ilk izlenimler kalıcıdır.
O noktada kariyerimin çoğunda bağımsız bir danışmandım ve pazarlamanın önemli olduğunu biliyordum. Sık sık konferanslarda konuşmak için seyahat ediyordum ama kitap yazmanın da bir güç olduğunu biliyordum. Bu yüzden InfoQ ile şunları yazmak hakkında konuştum. JHipster Mini Kitap ve yardım etmeyi kabul ettiler.
Kitabı yazma ve kitap için örnek uygulama oluşturma sürecinde hatalar buldum ve sorunları girdim. Bazılarını kendim çözebildim ve PR’lar gönderdim. Birkaç ay boyunca bunu yaptıktan sonra, projede taahhütte bulunmaya davet edildim.
Sonra bir JHipster konuşması başlatmak için eski moda bir Java geliştiricisi gibi giyinme ve konuşma ilerledikçe yavaş yavaş bir Java yenilikçisine dönüşme fikri aklıma geldi. ilk ben yaptım Nisan 2015’te Denver JUG. O konuşmadaki en iyi performansım 2015 yılında Devoxx Belçika.
Stormpath’a ve daha sonra Okta’ya katıldığımda, etkili bir geliştirici savunucusu olmanın en iyi yollarından birinin şirketin ürününü JHipster’a entegre etmek olduğuna karar verdim. Sonra JHipster hakkında yazmaya ve konuşmaya devam edebilir ve aynı zamanda şirketin ürününü gösterebilirdim. Oldukça iyi çalıştı ve şimdi Okta, JHipster’ın platin sponsoru! Ayda 2500 $ katkıda bulunuyoruz.
agresif: Biliyorsunuz JHipster’a bakarken, kullanıma hazır auth desteğini gördüm ve “Oh, şükürler olsun” diye düşündüm. Bir geliştirici olarak yetkilendirmeden nefret ediyorum, burada olduğu gibi tekrar tekrar aynı şeyi yapıyorum …
JHipster’daki auth desteği ve Auth0/Okta ile nasıl bütünleştiği hakkında biraz ayrıntılı konuşmak ister misiniz?
Raible: Yetkilendirmeyi JHipster’a ilk entegre etmeye başladığımda, oluşturduğum Stormpath modülü aracılığıylaydı. Stormpath o sırada yerleşik bir kurulum kullandığından, entegrasyon çoğunlukla Stormpath SDK’larının eklenmesini içeriyordu. Bu konuda daha fazlasını okuyabilirsiniz burada.
Ardından Okta, Şubat 2017’de Stormpath’i satın aldı. Ağustos 2017’de Stormpath API’sini kapattığımız için bu modül artık kullanışlı değildi. Eylül 2017’de JHipster’ın OAuth uygulamasını yeniden düzenlemeye başladım. Bu çabanın çoğunu aşağıdaki blog gönderisinde okuyabilirsiniz: JHipster ile OpenID Connect Desteğini Kullanın.
JHipster’ın OAuth uygulaması, Spring Security’den bir yetkilendirme sunucusu kullanmayı ve istemci kimliğini ve sırrını istemci tarafı koduna koymayı içeriyordu. Bu bir Kocaman güvenlik deliği. Bir ay boyunca, her şeyi sunucu tarafında olacak şekilde yeniden düzenledik ve istemcide asla jeton saklamadık. Beş yıl sonra, hala bunun iyi bir karar olduğunu düşünüyorum.
agresif: Burada bir Node.js bağlamından Auth0’ı vurmaktan biraz bahsedeceğim. Güvenliği daha az külfetli ve daha geliştirici dostu hale getirme konusunda uzun bir yol kat ettiğimizi hissediyorum. Alanın hareket ettiği eğilimler veya yönler olarak ne görüyorsunuz?
Raable: Katılıyorum, ama bence gitmemiz gereken bir yol var.
Güvenliği test etmekle karşılaştırmayı seviyorum. Çoğu geliştirici, test etmeleri gerektiğini bilir ve test kapsamını göstermek için birçok araç vardır. Çoğu IDE, sınıfların test kapsamını gösterme desteğine bile sahiptir. Güvenlik alanında, geliştiricilere güvenlik sorunlarını belirtmek için IDE eklentileri kadar fazla bir şey yoktur. Yine de işlerin düzeldiğini düşünüyorum. Snyk’in bir IntelliJ eklentisi güvenlik açıklarını düzeltmek için. Yapabilirsin OWASP Maven ile kontrol ediyorve GitHub’ın Dependabot’u oldukça kaygandır.
Gördüğüm büyük bir sorun, geliştiricilerin (veya müşterilerinin) OIDC yerine SAML’yi uygulamak istemesi. Arkadaşım Joël Franusic’ten alıntı yapmak gerekirse, “SOAP DİNLENMEKTİR, SAML da OIDC’ye aittir.” SOAP API’lerini uygulayan pek çok insan görmüyorum, öyleyse neden insanlar hala SAML’yi uyguluyor? Bunun geliştiricilerin hatası olduğunu düşünmüyorum, ancak yanlış bilgilendirilmiş karar vericiler.
Geliştirici dostu olma konusunda, ilk tanıştığımda Trish, 2010 yılında güvenlik sektöründe satış elemanıydı. Onunla Kansas City’de bir siber güvenlik konferansına gittim. Beni bilgi güvenliği arkadaşlarından bazılarıyla tanıştırdı. Ne yaptığımı sorduklarında “Ben bir geliştiriciyim” dedim. İlk yanıtlardan biri, “Bahse girerim senin bokunu kırabilirim” oldu. Bu benim için endişe vericiydi.
“Hey, daha yeni tanıştık ve sen şimdiden bana hakaret mi ediyorsun?” diye düşündüm. O andan itibaren, güvenliği geliştiriciler için daha kolay hale getirmek için güvenlikle ilgili daha fazla görüşme yapmaya başladım. Geçmişte Java geliştiricilerine, JSF kullanarak onları görmezden gelmek yerine web teknolojilerini benimsemelerine yardımcı olmak için JavaScript ve web teknolojilerini açıklayan benzer konuşmalar yaptım. [Java Server Faces].
agresif: Evet. Görünüşe göre, bilgisayar korsanlığına odaklanarak çok zaman harcarsanız, bir şeyleri kırabilirsiniz ve yapmazsanız, bunu yapanlara karşı savunmasızsınız.
Son zamanlarda ortaya çıkan Spring Native/JHipster şeylerini sorabilir miyim? Oradaki ana paket servis nedir?
Raible: Ana paket, JHipster Native’i entegre ederseniz, JHipster + Spring Boot uygulamanızı saniyeler yerine milisaniyeler içinde başlatmanızdır.
Micronaut ve Quarkus için de planlarımız var. Yerleşik yerel desteğe sahipler, ancak JHipster ile çalışmalarını sağlamak için biraz çalışmamız gerekiyor.
NestJS ve .NET Core için de planlar var, ancak herhangi bir yerel desteğe sahip değiller.
JHipster Native (ve Spring Native) muhtemelen yalnızca geçici olacaktır çünkü Spring Boot 3 varsayılan olarak yerel olmayı planlamaktadır. Buna yükselttiğimizde (yayınlanması 2022’nin sonunda planlanıyor), artık JHipster Native’e ihtiyacımız olmayacak. Tabii ki, Spring Boot 2.x tabanlı mevcut uygulamalar yine de buna ihtiyaç duyacaktır.
agresif: Ayrıca altyapı hakkında da epeyce yazdınız—mikro hizmetler, Kubernet’ler, vb. İşlerin nereye gittiğine dair fikriniz nedir? İlginç trendler veya gelişmeler var mı?
Raible: Severim Kelsey Hightower’ın nasıl hakkında 2020 yazı monolitler gelecek. Mikro hizmetleri oluşturan her şeyi öğrenmek, özgeçmişlerini oluşturmak ve en yeni “modern” teknolojileri kullanmak istedikleri için geliştiricilerin mikro hizmetlere çok fazla ilgi gösterdiğini düşünüyorum. Ancak, benim görüşüme göre, bir monolitin gayet iyi çalışacağı birçok zaman vardır. Monolitlerin bozulduğu yer, üzerinde çalışan bir ton insan olduğunda ve insanları ölçeklendirmeniz ve başkalarını beklemeden hızlı bir şekilde kod gönderme yeteneğinizin olması gerektiğidir.
Mikro hizmetler genellikle aşağıdakiler tarafından engellenir: Conway Yasası kuruluşunuzun fikirler üretebilen, bunları teslim edebilen ve bağımsız olarak sürdürebilen ürün ekipleri oluşturma yeteneğine sahip olması gerekir. Kuruluşunuz bunu başkalarına güvenmeden yapma yeteneğine sahipse, mikro hizmetleri benimsemenin sizin için iyi sonuç verme şansı yüksektir.
Bir monoliti ölçeklendirmek genellikle bir sorun değildir, insanları ölçeklendirir. 2007-2008’de LinkedIn’de çalıştığımda, monolitleri vardı ve gayet iyi performans gösterdi. Ancak, yalnızca Perşembe günleri konuşlandırıldılar ve bu hız için bir sorundu. Sonunda mikro hizmetleri teknoloji ölçeklendirme sorunları nedeniyle değil, insan ölçeklendirme sorunları nedeniyle benimsediler.
İşlerin nereye gittiğine dair iyi bir fikrim yok, ancak Kubernetes’in işleri yürütmek için çok sayıda düşük seviyeli YAML gerektirdiğine inanıyorum. Bir şeyleri yapılandırmanın daha iyi bir yolu olduğunu düşünmeden edemiyorum. İdeal olarak, ezberlemesi kolay bir tür sözdizimi olurdu. Ya da belki sonunda sizin için tüm YAML’yi oluşturabilecek JHipster gibi bir şey olacaktır.
agresif: Süper ilginç. İnsanları ölçeklendirmenin nasıl bir darboğaz olduğunu açar mısınız? Ne anlama geldiğini biraz daha açıklar mısınız?
Raible: Bugünlerde tüm şirketler teknoloji şirketleri ve geliştiricileri olma ihtimali var. Şirket ne kadar büyükse, o kadar fazla geliştiriciye sahip olma veya dış kaynak kullanma eğilimi gösterir. Hepsi aynı proje üzerinde çalışıyorlarsa (diğer bir deyişle monolit) ve saatte binlerce satır kod işliyorlarsa, mutlaka çakışmalar olacaktır. Serbest bırakıldığında birleşme kabusuna dönüşüyor. Ancak, binlerce geliştiriciniz varsa ve yüzlerce mikro hizmet üzerinde çalışan 10’dan az ekip varsa, çakışma olma olasılığı daha düşüktür. Ayrıca, mikro hizmetlerle bağımsız olarak dağıtabilmeli ve ekipler arasındaki bağımlılıkları en aza indirebilmelisiniz.
Komik ilgili hikaye: İlk duyduğumda James Valisi web şirketlerinin nasıl büyüdüğünden bahsedin, Java mağazalarına dönüş. Bir zamanlar bunun, Java’nın daha iyi bir dil olması ve statik yazmanın ölçeklenebilirliği kolaylaştırması nedeniyle olduğunu düşünmüştüm. James’in konuşmalarından birini şahsen dinledikten sonra, Java’nın en büyük geliştirici ekosistemine sahip olması nedeniyle daha fazlasını öğrendim. İşinizi ölçeklendirmek için aynı anda yüzlerce geliştiriciyi işe almaya çalıştığınızda, işe alınması en kolay olanlardan biridir.
agresif: Bu harika bir şey! Tamam, bitirmek için son bir soru. Bir şeylere biraz geriye bakacak kadar uzun süredir etrafta olan bir geliştirici (kendim gibi) olarak kodlama hayatı hakkında herhangi bir düşünceniz olup olmadığını merak ediyorum.
Raible: Muhteşemden başka bir şey olmadı! okula gittim DU [University of Denver] e-posta için Pine’ı kullandığımızda ve Lynx benim ilk tarayıcımdı. SlipKnot ve ardından Netscape 1.0 ile internetin görsel hale geldiğini görmek inanılmazdı. Struts 1.0’ı piyasaya sürüldükten hemen sonra kullanmaya başladım, sevdim ve topluluğuna yoğun bir şekilde dahil oldum. Karşılaştığım sorunlara birçok yeni arkadaş ve çözümlerle ödüllendirildim. Sonra blog yazmaya geldi, AppFuse, Spring, Spring hakkındaki kitabım, konuşma (esinlenen bruce snyder), JavaScript rönesansı ve kullanıcı arayüzü geliştirmeye geri dalışım.
Yolculuk boyunca en çok keyif aldığım şey, yol boyunca açık kaynak topluluğunda edindiğim arkadaşlar oldu. Bir konferansa gittiğinizde ve neredeyse 20 yıldır tanıdığınız biriyle takılmaya veya hack’lemeye başladığınızda, bu gerçekten özeldir. 2002’den beri uzaktan çalışma yeteneğim de gerçek bir nimet oldu. İnternetin iyi olduğu her yerden çalışma özgürlüğüne sahip olmayı seviyorum!
agresif: Teşekkürler Matt, seni yakalamak harikaydı!
Raible: Seninle sohbet etmek eğlenceliydi!
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3663677/oktas-matt-raible-how-i-became-a-java-hipster.html#tk.rss_all