<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>python on </title>
    <link>https://mesuutt.com/categories/python/</link>
    <description>Recent content in python on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>tr-tr</language>
    <lastBuildDate>Sun, 05 May 2019 22:59:25 +0300</lastBuildDate>
    
	<atom:link href="https://mesuutt.com/categories/python/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Django select_for_update</title>
      <link>https://mesuutt.com/2019/05/django-select-for-update/</link>
      <pubDate>Sun, 05 May 2019 22:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2019/05/django-select-for-update/</guid>
      <description>select_for_update queryset&amp;rsquo;de donen rowlar uzerinde ayni anda birden fazla update/delete querysi calismasini engeller.
Asagidaki kodu inceledigimizde ayni anda ayni bayi(Dealer)&amp;lsquo;in bakiyesi guncellenmesini engelliyoruz. Bu acilan DB transactioni bitene kadar ikinci request Dealer&amp;lsquo;in cekildigi satirda bekler.
@transaction.atomic def post(self, request, **kwargs): d = Dealer.objects.select_for_update().get(pk=self.kwargs[&#39;pk&#39;]) d.balance -= 100 d.save() ...  select_for_update kullanmadigimiz durumda ayni anda ayni bayi icin bu query calistiginda(bayinin bakiyesinin 1000 oldugunu varsayarsak) ayni anda calistiklari icin islem sonucunda bakiye 800 kalmasi gerekirken 900 kalacaktir.</description>
    </item>
    
    <item>
      <title>Django Coalesce ile sorgularda default value</title>
      <link>https://mesuutt.com/2019/02/django-coalesce-kullanimi/</link>
      <pubDate>Fri, 01 Feb 2019 22:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2019/02/django-coalesce-kullanimi/</guid>
      <description>Annotation ve aggregation yaparken calistirilan sorgu sonucunda DB&amp;rsquo;den herhangi bir kayit donmez ise sonuc olarak None doner. Biz bu donen degeri uzerinde sayisal bir islem yapmak istedigimizda hata aliriz.
total_price = Product.objects.filter(category_id=1).aggregate( total_price=Sum(&#39;price&#39;) )[&#39;total_price&#39;] mytotal += total_price // TypeError: unsupported operand type(s) for +: &#39;int&#39; and &#39;NoneType&#39;  Sorgudan deger donmedigi durumda None yerine 0 donmesini istersek Coalesce kullanabiliriz.
from django.db.models.functions import Coalesce total = Product.objects.filter(category_id=1).aggregate( total_price=Coalesce(Sum(&#39;price&#39;), 0) )[&#39;total_price&#39;]  Mesela iki fieldi F ile toplama yapiyorsak ve fieldin birinin sonucu None donerse toplama da yapamaz.</description>
    </item>
    
    <item>
      <title>Django annotation ve aggregation</title>
      <link>https://mesuutt.com/2018/09/django-annotate-aggregate/</link>
      <pubDate>Thu, 20 Sep 2018 22:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2018/09/django-annotate-aggregate/</guid>
      <description>Django&amp;rsquo;da annotate ve aggregate kullanarak, veritabanı tablosundaki satırların toplamı, ortalaması gibi, birden çok satırdan veya ilgili diğer tablolardaki değerler üzerinden database seviyesinde hesaplama yapıp tek sorguda sonucu alabiliriz.
Aşağıdaki gibi Flat ve FlatDebit adında iki modelimiz olduğunu varsayalım. Yazıyı bu modeller üzerinden örnekler vererek anlatmaya çalışacağım.
class Flat(models.Model): name = models.CharField(max_length=30) class FlatDebit(models.Model): flat = models.ForeignKey(&#39;myapp.Flat&#39;, related_name=&#39;flat_debits&#39;) amount = models.DecimalField(decimal_places=2, max_digits=9)  Aggregation Aggregate result olarak tek satır veri döndürür.</description>
    </item>
    
    <item>
      <title>Django&#39;da select_related ve prefetch_related kullanımı</title>
      <link>https://mesuutt.com/2018/08/django-select-related-ve-prefetch-related-kullanimi/</link>
      <pubDate>Fri, 31 Aug 2018 14:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2018/08/django-select-related-ve-prefetch-related-kullanimi/</guid>
      <description>Bir proje geliştirirken dikkat ettiğimiz konulardan birtanesi de kuşkusuz sistemin olabildiğince performanslı çalışmasını sağlamaktır.
Performansı artırmanın birden fazla yöntemi olduğu gibi bir yöntemi de ihtiyacımız olan veriyi DB&amp;rsquo;den olabildiğince az sorgu ile çekmektir. [1]
Şu şekilde modellerimiz olduğunu varsayalım.
class Category(models.Model): name = models.CharField(max_length=30) class Product(models.Model): name = models.CharField(max_length=100) category = models.ForeignKey(Category, related_name=&#39;products&#39;)  Şimdi ise bu modeller üzerinden hangi kod nekadar db sorgusu attığını ve nasıl daha optimize edebiliriz göstermeye çalışacağım.</description>
    </item>
    
    <item>
      <title>Celery notları</title>
      <link>https://mesuutt.com/2018/07/celery-notlari/</link>
      <pubDate>Fri, 20 Jul 2018 22:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2018/07/celery-notlari/</guid>
      <description>task_acks_late  Suan çalışan bir task varken herhangi bir sebepten ötürü(restart vs) celery worker kapanırsa ne olacak?
 Celery&amp;rsquo;de default olarak bir task işleme alındığı anda kuyruktan çıkartılır. Eğer task bitmeden celery worker kapanırsa task kuyruktan çıkartıldığı için worker tekrar çalıştırıldığında task tekrardan işleme alınmayacaktır.
Celery workerlarda çalışan kod worker restartlanmadığı sürece değişmez. Bu yüzden her deployment yaptığımızda celery workerları kapatıp açmamız gerekir. Fakat deployment yaptığımız anda çalışan bir task varsa celery workeri kapattığımız an task yarıda kalacaktır ve celery workeri tekrar başlattığımızda task tekrar işleme alınmayacaktır çünkü yukarıda da belirttiğim gibi default olarak celery taskı işleme aldığı an kuyruktan çıkartır.</description>
    </item>
    
    <item>
      <title>Django best practiceler</title>
      <link>https://mesuutt.com/2018/05/django-best-practices/</link>
      <pubDate>Sat, 19 May 2018 00:00:00 +0000</pubDate>
      
      <guid>https://mesuutt.com/2018/05/django-best-practices/</guid>
      <description>Configler  Django environ kullanılmalı. Her ortam için ayrı requirements dosyası olmalı(prod, staging, dev) Her ortam için ayrı settings dosyası olmalı.  Modeller  Birtane BaseModel yapıp, bütün modelleri bu modelden extend etmek lazım. Bu sayede butun modelleri etkileyecek bir degisiklik yapmak istedigimizde sadece olusturdugumuz base modelde degisiklik yapmamiz yeterli olacaktir. Mesela butun objelerimizin olusturulma ve en son update edilme tarihlerini tutmak istiyoruz. Bunun icin butun modellere field eklemek yerine sadece base modele gerekli fieldlari eklememiz yeterli olacaktir.</description>
    </item>
    
    <item>
      <title>Django data migrationlar</title>
      <link>https://mesuutt.com/2017/09/django-custom-migrationlar/</link>
      <pubDate>Sat, 09 Sep 2017 14:59:25 +0300</pubDate>
      
      <guid>https://mesuutt.com/2017/09/django-custom-migrationlar/</guid>
      <description>Django migrationlar Django&amp;rsquo;nun beni kendine hayran bırakan özelliklerinden biri olduğunu çok rahat söyleyebilirim. Bir satır bile SQL yazmadan database tablolarında değişikliklik yapabiliyorum. Henüz DB migrationlarını Django kadar zahmetsiz ve temiz yöneten herhangi bir dille yazılmış bir framework göremedim. Cansın Django :)
Bazı zamanlar oluyorki modellerde yaptığımız değişikliklerden ötürü bir migration oluşturduğumuzda bu migrationa yeni eklemeler yapmamız veyada bu migrationdan ötürü eski data üzerinde işlemler yapmamız gerekebiliyor.
Şimdi örnek bir senaryo üzerinden custom migration nasıl yazılır ondan bahsetmeye çalışacağım.</description>
    </item>
    
    <item>
      <title>Python&#39;da pdb ile debugging</title>
      <link>https://mesuutt.com/2017/03/python-pdb-ile-debugging/</link>
      <pubDate>Sat, 18 Mar 2017 10:13:48 +0300</pubDate>
      
      <guid>https://mesuutt.com/2017/03/python-pdb-ile-debugging/</guid>
      <description>Yazdigimiz kodun beklenenden farkli bir davranis sergilediginde kodun nasil calistigini incelemek istedigimizde kuskusuz debuggerlar en cok isimize yarayan aractirlardir.
Bu yazimda Python ile yazdigimiz kodlari pdb ile nasil debug edebilecegimizi ve pdb komutlarindan bahsedecegim.
Python standart kutuphanesiyle beraber pdb debuggeri kurulu gelir. Debug etmek istediginiz satira import pdb; pdb.set_trace() ile breakpoint koyup kodu calistirdigimizda o satira geldiginde interaktif bir shell acilir ve bu shellden kodumuzu debug edebiliriz.
ipdb ipdb pdb&amp;rsquo;nin sundugu butun ozelliklere ek olarak IPython&amp;rsquo;un sundugu kod tamamlama, kod renklendirme, magic fonksiyonlar gibi bircok ek ozellik sunar.</description>
    </item>
    
    <item>
      <title>Django Migrationlar ve Takım Çalışması</title>
      <link>https://mesuutt.com/2017/02/django-migrationlar/</link>
      <pubDate>Sat, 18 Feb 2017 11:43:17 +0300</pubDate>
      
      <guid>https://mesuutt.com/2017/02/django-migrationlar/</guid>
      <description>Bir proje uzerinde calisan birden fazla kisi oldugunda takim uyelerinin olusturdugu migrationlarinin cakismasi kacinilmaz olabiliyor. Bu yazimda bu problemi ve nasil cozdugumuzu dilim dondugunce anlatmaya calisacagim.
Mesela Erdem arkadasimla ayni proje uzerinde calisiyoruz. Erdem calistigi branch&amp;rsquo;de Profile isimli bir model olusturdu, daha sonra migration dosyasini olusturdu(migration dosyasinin isminin 0011 oldugunu varsayalim) ve developa(ortak branch) merge etti diyelim. Sonrada ben Erdem&amp;rsquo;in develop brancindeki degisiklikleri kendi branchime merge edip, Profile modeline yeni bir field ekledim diyelim.</description>
    </item>
    
    <item>
      <title>Django ve browser cache invalidation</title>
      <link>https://mesuutt.com/2016/12/django-ve-browser-cache-invalidation/</link>
      <pubDate>Sun, 25 Dec 2016 17:09:35 +0300</pubDate>
      
      <guid>https://mesuutt.com/2016/12/django-ve-browser-cache-invalidation/</guid>
      <description>Onceki yazimda HTTP caching mekanizmasinin nasil calistigindan birazcik deginmistim. Bu yazimda ise asagidaki sorunu nasil cozdugumu anlatmaya calisacagim.
 Hem statik dosyalarimizin client-side&amp;rsquo;da en uzun sure cachelenebilmesini, hemde statik dosyalarimizda degisiklik olunca clientlarin dosyanin yeni veriyonunu indirmelerini nasil saglayabiliriz?
 Ben bu sorunun cevabini Django uzerinden anlatacagim ama siz hangi programlama dili/framework kullaniyorsaniz onda da ayni sekil yapabilirsiniz.
Sunucumuzda style.css adinda bir css dosyamiz oldugu varsayalim. Biz bu dosyanin kullanicinin tarayicisinin cachinde maximum sure durmasini, dosyamizin degismesi durumunda da tarayicinin dosyamizin yeni versiyonunu indirmesini ve kullanmasini su sekilde sagalayabiliriz:</description>
    </item>
    
    <item>
      <title>Docker ile Örnek Django Uygulaması</title>
      <link>https://mesuutt.com/2016/07/docker-nginx-ve-django-ile-ornek-uygulama/</link>
      <pubDate>Thu, 21 Jul 2016 03:14:15 +0300</pubDate>
      
      <guid>https://mesuutt.com/2016/07/docker-nginx-ve-django-ile-ornek-uygulama/</guid>
      <description>Bu yazimda sizlerle docker ile ayni fiziksel makina uzerinde calisan bir django uygulamasi alt yapisi nasil hazirlanir onu paylasacagim. Bu alt yapi ile birlikte gerektiginde sisteme ilave uzerinde django uygulamamizin calistigi containerlar ekleyip sitemizin performansini {artira/koruya}bilecegiz.
Sistemin yapisi su sekilde olacak:
 Nginx gelen trafigi django containerlar arasinda dagitacak. Nginx olusturulan mystatic isimli volume uzerinden static dosyalari sunacak. Django containerlar DB containeri ile haberlesecek. Django containerlar mystatic isimli volume uzerindeki dizinlere erisebilecek.</description>
    </item>
    
  </channel>
</rss>