Herkese selamlar. Görmeyeli forumda birkaç değişiklik olmuş hatta kapanma tehlikesi geçirmiş fakat hayatta kalmayı başarmış yazbel… Kapanmamasına çok sevindim açıkçası. Forumun müdavimleri bilir, sık sık gelir iş görüşmelerimi burada paylaşırdım. Sevgili @aib ilk attığım mülakat postunu silmem üzerine özel mesajla ulaşıp geleceğin yazılımcılarına faydalı olabileceğini düşündüğünü, geri yükleyip yüklemeyeceğimi sorduğundan bu yana girdiğim tüm mülakatları paylaştım. Bu son mülakat postum sanırım. 2 ay önce hayal ettiğim işi aldım (en azından bu şirkette javascript yazmak zorunda değilim). Kısaca mülakattan bahsedecek olursam magic methodlar soruldu, __init__, __new__, __enter__, __exit__ gibi methodlar. ayrıca daha önce de karşılaştığım context manager nedir sorusu soruldu. önceki soruyla bağlantılıydı bu. __enter__ ve __exit__ fonksiyonlarıyla alakalı. bunlar dışında aklımda kalan acid prensipleri nedir gibi bir soru soruldu. bildiğim kadarıyla cevapladım. Django'da view fonksiyonunda kullanılan "request" parametresi tam olarak ne yapar? sorusu soruldu. soru yetersiz geldiğinden sorunun eksik olduğunu düşündüğümü söyledim (öncesinde gunicorn, wsgi vs. üzerine konuştuk ancak tatmin olmadı) ve mülakatı yapan arkadaş direkt olarak sonraki soruya geçti. Web scrapingle uğraştığımı bildikleri için web scraping'de aynı anda 100 url'e istek atmak istesen ne yaparsın gibi bir soru soruldu, ben de asenkron bir http kütüphanesiyle 100 url’e asenkron bir şekilde istek atacağımı söyledim. evirdi çevirdi ancak konuyu threading’e getiremedi. konuyu threading’e getirmeye çalıştığını biliyordum ama asenkron yazılması gerektiği konusunda zorlamak istedim. nasılsa onlarca iş görüşmesinden başarısız ayrılmıştım bundan da başarısız ayrılsam +1 başarısız iş görüşmesi olurdu ve hayatıma devam ederdim. her neyse en son kendim “siz konuyu threading’e getirmek istiyorsanız direkt threading konu başlığı üzerinden konuşabiliriz” şeklinde bir şey söyledim ve threading hakkında birkaç şey sordu. Python mülakatlarında sorulan klasik GIL nedir sorusunu sordu mesela. Biraz GIL üzerinden konuştuk, daha sonra basit OOP konuları konuşuldu. Ertesi gün olumlu dönüş aldım ve birkaç gün içerisinde de işe başladım.
Bu iş görüşmesinden birkaç hafta önce kendim bir projeye başlamış hatta kendime 2 ortak bulmuştum. Ben backend’i yazacaktım, diğer 2 arkadaş ise front’a bakacak, logolar ve butonlar tasarlayacaklardı. Projeyi epey geliştirdik ve proje çok çok küçük de olsa bize gaz verecek bir yatırım aldı. Projenin hâlâ yeterli olmadığını ve geliştirilmesi gerektiğini düşündüğümden canlıya çıkmadık fakat geliştirmelere devam ediyoruz. Umarım burada o projenin büyüdüğünü, acil yazbelci python developer aradığımızı duyurma fırsatım da olur.
Burada iyisiyle kötüsüyle bana yardımcı olan herkese çok teşekkür ederim. Seviliyorsunuz <3
Hayal ettigin isi almana sevindim! Tebrikler ve mutluluklar
Tabi bu demek ki, mulakat sorularini paylasma isi artik baskasina dusuyor. Sirada kim var?
Bu arada adettendir, icerige yorum yapayim. Context manager guzel bir konu. Daha yaygin (ve kotu) isminin RAII (Resource Acquisition Is Initialization, kotu oldugunu soylemistim) oldugunu da yazalim buraya, bulunsun.
Async’e gelince, ben 100 thread icin yapmazdim. 1000, hatta belki 10,000 thread icin de yapmayabilirdim. Veya soyle diyelim: Thread’lerin overhead’inin fazlalastigi, hatta kaynaklarin yetmedigi noktaya gelene kadar async virusunu koda bulastirmamak lazim.
(Niye virus? Cunku su aralar populer olan stackless coroutine implementasyonlari fonksiyonlari ikiye ayiriyor ve async cagirmasi gereken fonksiyon async’e donusup boyle boyle butun codebase’e yayiliyor.)
Thread’lerin (preemptive multitasking) duzgun call stack’lere sahip olmalari ve akisa (fazla) dikkat etmeden dumduz yazilmalari gibi avantajlari var. Zaten bu yuzden teknoloji ve kaynaklar izin verir vermez buna gectik. Kaynaklarin yetmedigi noktada cooperative multitasking’e donmemiz ya son derece dogal ya da ironik, daha cozemedim.
Ama Python’da olmasini anlayamiyorum. Gideyim rationale’ini okuyayim bari.
Çok teşekkür ederim hocam. Sizden ve diğer kıdemli abilerimden çok şey öğrendim. Sizlerin katkısı büyük…
Her zaman daha iyisi vardır diyelim. Bazen eğlencesine başvurular atıyorum. Belki “eğlencesine” girdiğim başka mülakatları paylaşırım.
RAII hakkında sizinle daha önce konuşmuştuk ve böyle bir terimin varlığını ilk sizden öğrenmiştim. RAII araştırmak biraz daha arkasındaki mantığı anlamamı kolaylaştırdı aslında.
İlginçtir ki sektörde sözüne çok güvendiğim 4 kişinin 2si asenkron yazılmalı, 2si asenkrona gerekmedikçe bulaşılmamalı diyor. Aralarındaki teorik farkları biliyorum fakat teknik farklılıkları bilmediğimden benim bir yorumum bulunmuyor açıkçası. Haddime değil diyorum kısaca. .
Teknige girmeye gerek yok. Cok basit bir fark var: Thread rutinleri “duz” yaziliyor, stack’siz coroutine’ler (async) bulasici async ve kontrol verme noktalarinda await ile yaziliyor. Yani thread kodu yazmak daha basit.
O zaman buyuk bir kaybi olmadigi surece thread+duz rutin kullanmak daha mantikli.
Sektordeki bir suru insanin yeni ve populer seyleri tercih etme aliskanligi var; teknolojilerin getirileri ve goturuleri bilinmediginde kotu bir aliskanliga donusebiliyor. Orn. dedicated admin takimi bulunmayan herhangi bir projede Kubernetes, PoC’si cikmamis projeye mikroservis mimarisiyle girmek, thread ve OS context switch overhead’lerini olcmeden async I/O kodu yazmak.
Tabi bu tercihleri herhangi bir yonde yapmanin diger sebepleri de olabilir, ama isi komplike hale getiren seylere gozu kapali “evet” diyen insanlardan korkarim ben :).
@makesamba mülakattaki başarından dolayı tebrik ediyorum. Yeni işinin hakkında hayırlı olmasını temenni ediyorum.
Bir seyler öğrenme gayreti ile yazılarınızı okudum. Bu sıralar flutter/Dart ile hobi amaçlı uğraşıyorum. Maksat mobil tarafta da deneyimim olsun istiyorum.
Flutter/Dart’da Future ifadesi ile async olarak tanımlanan bir çok fonksiyon kullanıyoruz. Daha sonra await, then gibi ifadelerle bu fonksiyon/metotlardan faydalanmış oluyoruz. İnternetten bitirdiğim flutter eğitiminde eğitmen, özellikle bir mobil uygulama ilk açılışta bir db ye bağlanıp veri çekip ekranda listelenecek ise uzun sürebilecek bu görevde uygulamanın donmadan açılması için asenkron programlamanın önemini vurguladı. Bu yaklaşımda uygulama açılırken arka planda veriler db den çekilip işlem tamamlandığında ekranda gösteriliyor. Böylece uygulama açılması için verilerin inmesini beklemiyor. Dart’taki Future yapısı gelecekte tamamlanacak bir işin garantisini veriyor. Gelecekte tamamlanacak bu iş gerçekleşene kadar diğer metotlarınız onu beklemeden çalışabiliyor.
Üni.'de Java üzerinde threadları işlediğimizde aynı anda birden fazla metodun çalıştırılabildigini, hatta bu metotların hangi oranda çalıştırılabileceğini (öyle hatırlıyorum yanlış olabilir) görüp demiştik.
Bu iki yöntem birbirlerinin alternatifi mı yoksa farklı işler için mı kullanılıyor? Şimdi siz konuşunca kafamda bı analiz yaptım. Mobil uygulama örneği için uygulama açılırken widgetleri çizen metotların çalışması, bir yandan da db den veri çekilmesi gerekiyor. Bu threatla da yapılabilir belki ama asenkron kelimesinden ben işlerin aynı anda olmayacağı, farklı zamanlarda birbirinden bağımsız ilerleyen işler oldugunu anlıyorum.
Arkadaşa mülakatta soru soran kişi aynı anda istek gönderilecek demiş sanırım anahtar kelime bu. Aynı anda demesi senkron bir yapıyı ifade ediyor gibi.
Öğrenmek için yazdım, konu konuyu açıyor. Yanlış ifade etmiş olabilirim. Teşekkürler
Flutter ile uygulama geliştirirken kullandığın dart dili olay örgüsü gereğince asenkron programlamayı desteklemektedir. Dart dilindeki temel yapı olan event loop async await anahtar kelimeleri ile asenkron programlamayı sağlar. Gelecekta yapılaca bir future nesnesinin yapılmasını await ile bekletir ve işlem tamamlandıktan sonra bir sonraki işleme geçer.
Event Loop olayına gelirsek dart, js gibi programlama dilleri bu şekilde çalışır. Uygulama çalıştığında event yani olaylar gerçekleşir. Bu olaylar veri çekme, dosya işlemleri gibi zamana dahalı işler olabilir. Event loopta bu olayları alıp bir kuyruğa ekler. Sırayla bu kuyruktaki işlemler gerçekleşir ve bir işlem bitmeden sonrakine geçmez. Asenkron işlem bittikten sonra callback fonksiyonu çalışır ve bir olay yani event bitmiş olur. Bu olayların tümünün sürekli döngü içerisinde çalışma olayı da event loop olarak geçer.
Event loop tek ana thread üzerinden işlemleri gerçekleştirir. Çoklu iş parçacıkları varmış gibi görünebilir ancak tek iş parçacığı üzerinden çalışır bu sayede olayların sıralı olması düzeni oluşturur. Birbirini takip eden ve bağımlı işlemlerin sıra ile çalışması sağlanır. Düzen oluşturur.
Multithread çalışmak ise birden fazla iş parçacığı ile çalışmaktır. Dart dilinde de istersen flutter yazarken multi threading kullanabilirsin.
Örneğin seçtiğin resmi tek seferde siyah beyaz yapan, çözünlürğü artıran, çözünürlüğü düşüren, rengi tersine çeviren ve bunun gibi aynı resim üzerinde bir çok işlem yapan bir program düşün. Resmi seçtiğinde butona basınca tüm sonuçları tek seferde istiyorsun. Bu senaryoda event loop kullanırsan:
1- resmi alırsın
2- resmi siyah beyaz yapar kaydedersin
3- resmin çözünürlüğünü artırıp kaydedersin
4- çözünürlüğü düşürüp kaydedersin
5- rengi tersine cevirir kaydedersin
6- sonuçları gösterirsin
Her bir işlemin çalıştığı süre boyunca ivmesi sabit 10 mb bellek tükettiğini ve işlemin 10 saniye sürdüğünü varsayarsak event loop ile 6 işlem için 60 saniye boyunca 10 mb sabit bellek tüketilirek işlemi tamamlar. Multithread olunca ise 2 3 4 5 maddeleri için yeni thread açıp hepsini aynı anda yapabilirsin. resim gelir ve daha sonra aynı resim üzerinde 4 farklı thread ile işlemler tamamlanır. Bu sayede 1. işlem 10 saniye boyunca 10mb bellek tüketir. 2 3 4 5 işlemleri 10 saniye boyunca 40 mb işlem tüketir. 6. işlem ise yine 10 saniye boyunca 10 mb bellek tüketir. Toplamda 30 saniye sürer işlem ancak 10-20 saniye arası fazladan 30 mb bellek kullanır.
Yani senaryolarına göre eğer cihaz kapasitesi yüksek ve hızlı bir şekilde yoğun bellek tüketen işlem yapıyorsan -ki çekirdekte burda önemlidir- multithread de kullanabilirsin. Ancak kullanıcı beklesin cihazı çok yormak istemem dersen de async await iş görecektir.
Yapay zeka ile ilgili işlemler yaparken multithreading kullanıyorum örneğin ancak flutter ile uğraşırken daha önce hiç multithread kullanma gereksinimi duymadım.
Ayni anda iki is yapma eszamanlilik. Yukarida “async” dedigimiz, stack’siz coroutine’ler ile yapilan cooperative multitasking. Terimleri aciklayan bir sozluk yapmistim, ise yarayabilir. Kafa da karistirabilir.
Routine’ler (duz fonksiyon) + OS thread’leri ile yapilan preemptive multitasking ile karsilastiriyoruz.
“Eszamanli programlama” daha dogru bir isim olabilir. Stackless coroutine’ler (async+await) bir cozum, ama multithreading de. Hatta I/O rutinlerini arkada calistirip sonuclarini poll etmek (asynchronous I/O; tek thread, duz kod) da bir yontem.
Konustugumuz her sey eszamanli is yapma cozumu. Duz multithreading’in guzelligi her thread’in kodunu dumduz bir sekilde yazmamiz. Stackful coroutine’ler de boyle.
Stackless’lar (async+await) daha verimli calisabilme (veya kolay implement edilebilme) ugruna kod yazimini zorlastiriyorlar. Rust ve C++ gibi zero overhead amaclayan diller disinda neden kullanildiklarini anlamiyorum.
Future’lar da eszamanli kodu kolay yazmayi saglayan bir yapi. Uzerine dusunmeden soyluyorum: Arkaplanda her turlu eszamanlilik cozumunu kullanabilirler. Kullanim estetigi acisindan turlu problemleri var, ama en azindan async+await’te olan “Future dondurmeyen fonksiyonda Future kullanamazsin” problemi yok.
Bu arada coroutine’leri birden fazla OS thread’i uzerinde (yani potansiyel paralel olarak) calistirmak da mumkun. Multithreading’in avantajlari ve dezavantajlari ile birlikte geliyor.
Tek OS thread’i uzerinde calistiran scheduler’lara “event loop” denebiliyor (JS). Fakat mesela duz tek thread uzerinden asynchronous I/O yapip sonucu poll eden kod da event loop. Win32’de her seyi ana pencerenin queue’suna mesaj olarak alan WindowProc da.
Çok teşekkür ederim. Darısı tüm forumdaşlarımın başına.
ben djangoyu pek kullanan hatta seven biri değilim. Çoğunlukla FastAPI kullandım şimdiye kadar. Bana daha çok kurcalanabilir geliyor, django biraz bir şeylere zorluyor gibi geliyor.
FastAPI’dan en büyük farkı çok kolay olması. FastAPI’da kendiniz authentication yazmanız gerekiyor, migrationlar biraz can sıkabiliyor vs. ama Djangoda bu problemler olmuyor. Her şey içerisinde zaten var, yoksa da basit bi googlelamayla ihtiyacınız olan şeyi buluyorsunuz. hatta ilk işim olan history tutma olayı buna güzel bir referans olabilr. Database’de yapılan herhangi bir değişikliğin kim tarafından yapıldığını, nasıl bir değişiklik yapıldığını görmek istiyorlardı. Bunun için django-simple-history paketini kullandım. FastAPI olsa oturup baştan yazardım muhtemelen. bu biraz iyi biraz kötü aslında. kişiyi çok körelten bir şey ama üşengeçler için harika bir nimet.
Django’yu bence en iyi kendi reklam metni anlatıyor. The web framework for perfectionists with deadlines
