lombak şehidi

gRPC server yazacagiz ve serverimizin cok guclu (o da ne demekse) olmasini istiyoruz. Bu yuzden, bir sekilde gelen requestleri paralel olarak isleyebilen bir yapiya ihtiyacimiz var. Python threading malum, CPU intensif isler icin uygun degil cunku GIL sebebiyle ayni anda birden fazla Python kodu calistirilamiyor. Dolayisi ile mevzubahis CPU gerektiren islemler ise, Python threading aslinda tek thread gibi davraniyor.  Bu durumda official ornege bakabiliriz. Tamam Python threading'de GIL engeli var ama multi-process yapar isek boyle bir engel yok. Ne de olsa her bir process kendi GIL'ine sahip olacak. Ama burada da yuku processlere nasil dagitaracagimiz problemi akillara geliyor.  Port Sharing Resmi ornekte, yuk dagitma islemini butun process'leri ayni porta bind ederek saglamislar. Bu sayede yuk TCP katmaninda, isletim sisteminin Kernel seviyesinde yapilmis oluyor. Port uzerine gelen istekler, TCP katmani tarafindan bu portu dinleyen processlere bir round-robin yapisi sekli

Cok fazla yuk altina girecek olan bir gRPC server isletiyoruz diyelim. Server'i de Python ile yazdigimizi dusunelim.  - Ne gini kisitlamalar yasayacagiz? - Serveri horizontal olarak scale etmek icin ne gini seceneklerimiz var? - Bir de gRPC server local'de calisip, diger desktop uygulamalarina hizmet veriyor ise isler nasil degisir?  Gelin bu kullanim alani uzerinden biraz beyin cimnastigi yapalim. 1. Network Load Balancing Server-side RPC, HTTP 2.0 uzerinde calisan bir iletisim protokolu oldugu icin, HTTP2.0 destekleyen standart load balancerleri kullanabiliriz. En populer secenekler ngix ve envoy proxy olarak gosterilebilir.  Yalniz burada temel bir problemimiz var. gRPC sessionlari sticky bir yapidadir. Yani bir client bir servere bir kere baglanir  ve uzun bir sure boyunca bagli kalir. Request ve response'lar bur mevcut baglanti uzerinden gerceklesmis olur. Bu sayede her request/response icin tekrardan baglanti kurmaya (ve dolayisi ile TCP handshake yapmaya) gerek kalma

Bu multithreading isini cok karistirdilar.  Thread ve Process Thread ve Process, birbirinden bagimsiz olarak calisabilen (teorik olarak) kod parcaciklaridir.  Aradaki fark, ayni program tarafindan olusturulan threadler ayni hafiza alanina erisebilir. Buna karsilik process kendi basina bagimsiz bir program olarak dusunulebilir, Kendine ait hafiza alani vardir.  Bu da demek oluyor ki, thread'ler kendi aralarinda haberlesebilmek icin ekstra bir efora ihtiyac duymazken, process'leri birbiri ile konusturabilmek icin ekstra birseler (gRPC?) yapmak gerekir. Yukarida ayni program tarafindan olusturulan threadler derken bile, aslinda buradaki program, bir process 'tir. Her process primary thread olarak adlandirilan en azindan 1 adet thread'e sahiptir. (Single threaded tabirini hatirlayalim).  Peki neden birden fazla thread'e ihtiyac duyalim?  Kullanici acisindan, birden fazla process'in ayni anda calistirilbilmesi demek, ayni anda birden fazla uygulamayi calistirabilme

Heap  Heap, binary tree'nin ozel bir formudur Complete binary tree ozelligi vardir. (Leaf node'lar arasinda en fazla 1 level fark olabilir) Heap property: her bir node, kendi child node'larindan daha buyuk olmalidir. Max-heap, bir array seklinde de implemente edilebilir. Bu durumda i. node'un child node'lari sirasi ile 2i + 1 ve 2i + 2 olacaktir. Insertion: O(log n) Max element look-up: O(1)  Deletion of the max element: O(log n) Ayni zamanda Priority Queue adi da verilmektedir. Cunku max elemani kopardigimizda, siradaki eleman ondan sonra gelen en buyuk eleman olacaktir. Yani Queue gibi davransa da, elemanlarin oncelik sirasi vardir. Max-heap yaninda min-heap yapisi da bulunur ki, tamamen ayni ozelliklere sahip olup, max eleman icin degil de min eleman icin calisir. Eger sadece en buyuk veya en kucuk elemanla ilgileniyorsak, hizli look-up, arama ve silme islemleri onemli degil ise heap kullanmak iyi bir cozumdur. En buyuk veya kucuk k elemanin bulunmasi gibi probl

15. Reconstruct A Binary Tree From Preorder Traversal With Marks Array seklinde preorder traversali verilmis olan binary tree'yi yeniden olusturunuz. Bos olan child node'lar None ile gosterilmis.  Ornek: [1, None, 2]  Root node:1 , left child: None, right child: 2  Cozum Preorder traversal verildiginden, root degerini bulmak icin ilk elemana bakmamiz yeterli. Daha sonraki elemanlar, sol subtree'ye ait olacaktir. Ama problem su ki, sol subtree'nin ne zaman bitip de sag subtree'nin basladigini bilemiyoruz. Ama recursive olarak gidersek, her bir adimda root'u biliyor olacagiz. Daha sonra da, array uzerinde nerede oldugumuzu belirten bir index kullanarak, yolumuzu bulabiliriz. def reconstruct_preorder(preorder):     # recursive olarak binary tree'yi olusturacak metodumuz     # ayni zamanda verilen subtree'nin eleman sayisini da dondurmeli ki     # ornegin sol subtree'nin nerede bittigini bilebilelim      def rec(arr, start_index):          # preorder'

12. Reconstruct A Binary Tree From Traversal Data Pre-order ve pre-order node dizilimleri iki liste halinde verilmis olan bir binary tree'yi tekrar olusturunuz. ( leetcode ) Cozum Elimizde neler var once ona bir bakalim.  1. Preorder traversal'de ilk eleman her zaman tree'nin root node'u olacaktir. Bu durumda root node'u biliyoruz. 2. Inorder traversal icerisinde, root node'a kadar olan kisim left subtree'dir. Root node'dan sonraki kisim ise right subtree'dir.  3. Inorder traversal bilgisi kullanarak, left subtree'de kac tane node oldugunu hesaplayabiliriz. Yapmamiz gereken, root'un indexini bulmek. Left subtree'de kac tane node oldugunu bulur isek, preorder traversalda root'tan baslayarak o kadar node gidersek, sag subtree'ye ulasmis oluruz. Ornekte yesil kutucuk olarak gorulebilir.  Bu ilk uc adimi izledigimizde, verilen bir binary tree icin root, left subtree icin inorder ve preorder traversal degerleri ve de right subtree icin