Haydi ufak bir bootcamp projesi yapalım
Düşünsene; mezun olmuşsun ya da yazılım öğrenmiş / öğrendiğini düşünüyorsun, online bir iki kurs bitirmişsin ve çevrendeki tüm şirketler seni işe almak için hazır bekliyor diye düşünüyorsun. Keşke böyle olsaydı ama aslında, Türkiye’de bilgisayar mühendisliği bölümünden ( tanıdığım en iyi yazılımcılardan birçoğu bu bölümlerden mezun değildi ) sadece bir yılda 10000 yeni mezun çıktığı ve bu yeni mezunlar arasından nasıl sıyrılmamız gerektiğini çok da bilmiyoruz belki de. Evet şirketlerin bir kısmı okul/ortalama konusuna baksa da, bence daha doğru olan değerlendirme, kişilerin o görüşmeye gelmeden önce yaptıkları.
Bu bağlamda yeni mezun ya da bu sektörde iş arayan biri olarak, hatta comfort zone’dan çıkmak isteyenler için, 2–3 yıldır farklı kişilerle deneme şansı bulduğum bir ‘Deneme Projesi’ fikrinden bahsetmek istiyorum. Mini bir bootcamp projesi olarak da düşünülebilir. Baştan sona basit bir projeyi, bir cloud provider üzerinde görebileceğimiz, bizi gerçek dünyaya hazırlayacak, belki de yarın bir gün aklına gelen bir fikri canlıya almak için gerekli araçları daha önceden öğretecek bir proje. Bu projede herhangi bir süre v.b. kısıtlaması yok, amaç deneyimlemek sadece.
Hazırsanız projeye başlayalım.
Faz 1: Bir proje seçelim
Bir şirkette çalışıyor olalım ve sistemimizdeki kullanıcı bilgilerini kaydeden ve onlara email adreslerini doğrulamak için mail atan bir sistemimiz olsun. Mikroservis mimarisinde, bu servis diğer sistemlerden ayrı olacaktır ve biz de bu sistemi tamamen ayrı bir şekilde yönetiyor olalım.
Başka herhangi bir proje de seçebiliriz bu arada, amaç projede zor kısım olan, altyapısal işleri ve süreçleri çözmek olduğu için, gerçek dünyaya daha yakın proje önerilerimi en aşağı yazacağım.
Faz 2: Time to Code…
Bu fazın amacı basit bir kod yazıp, onu deploy edilebilecek bir hale getirmek olsun. Öncelikle bir dil seçip, ben golang, kotlin ya da Java öneriyorum, bir tane basit uygulama yazacağız. Dil çok fark etmez bence ama ben golang tercih ederdim. Uygulamanın amacı, gönderdiğimiz text bilgisini alıp, büyük harf olarak dönen bir uygulama olacak. Basit bir rest istegi yaptığımızda, sadece büyük harfe çevirme işlemi yapsın, o kadar yani. Burada amaç basit bir uygulamayı ayağa kaldırmak. Bu basit uygulamayı daha sonra dockerize edelim.
Faz 3: Time to deploy
Bir cloud provider seçip, oraya bu imajımızı deploy edelim. Çok basit gibi görünen bu cümlenin altında aslında biraz kan, biraz ter ve biraz da gözyaşı yatıyor olabilir. Ben bu madde için şöyle yapardım:
- AWS seçerdim, freetier’den de faydalanırdım
- Hemen alarm kurardım, billing alarm’dan bulabilirsiniz. İstenmeyen ücretler ödemeyelim :(
- İmajı Amazon ECR’da host ederdim.
- Deployu da ECS’e yapardım.
Bu üstteki yöntemi ben hiç denemedim ama bir sonraki deneme projesinde deneyeceğim. İsteyen EC2'ya github ya da jenkins ya da başka bir cloud provider’da başka bir şekilde yapabilir, burada herhangi bir zorlama yok. Amaç bir imajı otomatik bir şekilde deploy etmek. AWS Beanstalk da olur mesela vb. v.b. Buradaki kritik kelime ‘otomatik’. Manuel olmaması lazım hiçbir işlemin. Bir butona basarak, kodun derlenip, paketlenip, hazırlanıp, deploy olması lazım. Manuel müdahale hiç ama hiç olmamalı.
Faz 4: Test?
Bu adımda artık yavaş yavaş test konusuna girmeye başlayalım. Daha ortada kod yok farkındayım, sadece verdiğimiz text’i büyük harfle geri donen bir API yazdık belki ama olsun. Şimdiki hedef olarak bu kodun hem unit hem de integration testlerini yazıp, bir önceki maddede hazırladığımız pipeline’a bu süreçleri de dahil edelim. Daha sonra pipeline’da kod kalitesi için bir tool da entegre edelim. Belli bir coverage ve/veya başka bir metrike göre kodun her zaman stabil olduğuna emin olsun bu adım. Jenkins, AWS codebuild, codedeploy ile bunlari yapabilir, deneyebiliriz. Tekrar belirtmek isterim, burada önemli olan ne kullanıldığı değil, amacın ne olduğunu anlamak ve onu deneyimlemek önemli.
Faz 5: Hadi dışarıya açalım
Sırada bu sistemi dışarıya ufak ufak açmak var. AWS kullanıyorsak mesela Route 53 üzerinden bir domain’i bu uygulamaya yönlendirebiliriz. Bu sayede public bir api’miz olur aslında. Sahip olduğumuz domain’den bir istek yaptığımızda, bu yazdığımız api’ye ulaşabiliyorsak bu adımı başardık diyebiliriz. Tekrar ve tekrar hatırlatmakta fayda var, bu 4 cümlede anlatılan kısım bile 1–2 haftayı alabilir, hiç panik olmak yok.
Faz 6: Gerçek uygulamamızı yazalım
AWS kullanıyorsak, freetier bir veritabanı seçip, DynamoDB de olur, MySQL da, bu adımda artık sorumluluğumuzda olan projeyi kodlamaya başlayalım. Büyük harfe çeviren o basit API’mizi alıp, kodlarını temizleyip, basit CRUD işlemleri ile kullanıcıları yöneten bir API’ye çevirelim. Aldığı istekleri DB’ye kaydetsin, verilen ID’ye göre silsin, güncellesin ya da DB’den getirsin mesela. Tüm bunları yaparken de, end to end testlerini yazarak yaptığımızı, küçük commit ve deploy’lar ile ilerlediğimiz, yapabiliyorsak TDD deneyimlediğimizi umuyorum. Her bir commit’te, testlerimizin tam olduğundan, kod kalitesini v.b. bozmadığımızdan emin olarak, otomatik bir şekilde deploy edelim.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Burada durup, bir özet geçelim isterseniz; bu adıma geldiğimizde DB’ye kayıt atabilen, onu okuyup, silebilen, güncelleyebilen; dışarıya açık bir API’miz var. Tüm testlerini yazdık, deployment’larını otomatik bir şekilde AWS’ye ( ya da X bir platform’a ) yaptık. Kod kalitesine dikkat ediyoruz, yoksa deploy çıkmıyor, testlerimiz var bizi koruyan. En önemlisi de, canlıda API’mız var. Buraya kadar gelebildiysek, çok güzel bir şey başardığımızı unutmayalım.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Faz 7: Ve son…
Proje hedefinde, bir kullanıcıyı kaydettikten sonra; eposta onayı için bir mail atacaktık hatırlarsanız. Bu mail atma işlemini async yapmayı deneyelim. Kullanıcıyı DB’ye kaydettikten sonra, bir MQ’ya mesaj atalım ve başka bir API’den burayı dinleyip; bir doğrulama kodu yaratıp, bu kodu sadece belirli bir süre için sistemde geçerli halde tutup, bu maili kullanıcının adresine atma işlemlerini gerçekleştiren bir API yazalım. Tasarım olarak, bu onay kodu ve onay linkini yaratacak, TTL’li bir şekilde tutacak business logic aslında ilk yazdığımız API’nin değil. Adına ‘user-verification-API’ diyebileceğimiz API’nin sorumluluğu aslında. AWS kullanıyorsak, user-API diyebileceğimiz ilk API bir kullanıcı kaydolduğunda, SQS’e bir event bırakır, bu event’i yeni yazdığımız user-verification-API dinler, 5 dakikalık bir TTL ile AWS Elasticache üzerinden Redis’te tutacağımız bir key generate ederiz ve bu key ile oluşturduğumuz mail’i AWS SES ile göndeririz.
Burada seçilen cloud provider AWS olduğu için, oradaki servisleri kullandık ama istediğimiz başka şekillerde de bu sistemi kurabilirdik. Buradaki amaç, asenkron iletişim, herhangi bir MQ ile send/receive işlemlerini yapmak, yeni yazdığımız ‘user-verification-api’ yi de TDD, Test coverage, clean code v.b. düşünerek, otomatik bir sekilde deploy etmek olmalı. Bu yaptığımız basit yapı sayesinde de, iki farklı API ve business için farklı veritabanları kullanabildik.
Daha önce de dediğim gibi, bu tip basit bir proje farklı platformlarda çok daha hızlı, basit, temiz v.b. yapılabilirdi ama amaç hem production’a basit bir sistem çıkarmak, bunu host etmek, ci-cd süreçlerine biraz girmek, test yazmak v.b. olarak düşünebiliriz. Bir iş görüşmesine gitmeden once bunları yaparsanız ve kodlarını, config’leri v.b. açık olarak mesela github’da tutarsanız, sizi iş görüşmesine çağıran bir şirket bunlara bakacaktır ( hatta sizi buradan bulacaktır 😅), aradan sıyrılma ihtimaliniz artacaktır, iş görüşmesinde bunu nasıl yaptığınızı anlattığınızda bazı kısımları yapamamış olsanız dahi, kazandığınız o tecrübe çok degerli olacaktır.
Bitirirken…
Çok uzun olmayan bir yazı gibi gözükse de, bu işlemleri yapmanın, hele ki ilk defa yapıyorsanız, uzun süreceğini düşünüyorum. Başta da yazdığım gibi, zaman v.b. baskısı olmadan, gerekirse birkaç aya yayacak sekilde planlı ve düzenli çalışma ile bitirilebilir bence. Herhangi bir soru, öneri, düzeltme ya da daha iyi bir yol öneriniz olursa lütfen herhangi bir platformdan geri bildirimlerinizi gönderin. Bunları yaparken ya da yaptıktan sonra eğer beraber çalışma şansımız olursa çok sevinirim.
Proje Önerileri
- Belirli bir websitesinde, belirli bir arama kriterine göre arama yapılmış olan url’i belli periyotlarla kontrol edip, yeni bir ilan v.b. gelirse, kullanıcıya haberdar etmek üzerine kurulu. Beşiktaş bölesinde, aradığım kriterlerde yeni bir ilan var mı alarmı gibi.
- Belli aralıklarla bir ürünün fiyatı düştü mü diye, belli bir ya da bir kaç siteyi kontrol eden bir sistem. Kullanıcılar bu ürünler ile ilgili fiyat bilgilerini otomatik olarak mail yoluyla alırlar mesela.
- Belli aralıklarla https://dolarrekorkirdimi.com/ sitesine bakıp, rekor kırdığı an, kullanıcıya bir mail atan sistem de olabilir.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Not1 : Bu yazı özellikle Türkiye’de gördüğüm bir sıkıntı üzerine, yeni mezun arkadaşlarımızın ya da sektöre atılmak isteyen kişilerin, kendilerini sektöre hazırlamaları ve iş görüşmelerinde öne çıkabilmelerine yardımcı olmak için Türkçe yazıldı, sadece yeni mezun arkadaşlar için değil, comfort zone’dan çıkmak isteyen herkes deneyebilir.
Not2 : AWS ve sunduğu servisler, iyi oldugum bir konu değil. Yukarıda AWS tarafında şöyle yapardım, böyle olsa akardı dediğim çoğu şeyin çalışmama ve yanlış olma ihtimali yüksek ama bence sorun değil. Daha iyisi, kolayı kesin vardır. AWS Gateway’lerle, Lambda’larl bu sistemi yapmak, Localstack ile farklı bir şekilde test etmek, GCP’de AliBaba Cloud’da, DigitalOcean’da çok daha iyisi temizi ve kolayı kesin yapılabiliyordur. NoCode bir platformla bile yapılabilir hatta. Buradaki her şeyi kabul etmek yerine, neden sorusunu sorup, acaba daha iyisi var mıdır diye sorgulamak lazım her zaman.
