Biz Bunları Gist’lerimizde Anlattık! – PostgreSQL

Geliştirici olarak bir projeden/işyerinden ayrılırken “bu projeye çok emek verdi(m)(k), bazı kısımlar şahane, lazım olur günün birinde, zipleyeyim de atayım kenarda dursun” hissiyatı çoğumuzda olur. Ben ise şu iki sebeple bunu yapmaya gerek görmüyorum:

  1. Geçmiş deneyimlerimiz ile yeni çevrede öğrenilen yeni bilgileri harmanlayarak daha iyilerini yazabileceğimize inanıyorum
  2. Geçmiş deneyimlerimi unutmamak için blog ve Gist yazıyorum

(Ayrıca projeyi o şekilde başka yerlere kopyalamak yasal olarak da sıkıntılı olsa gerek.)

github-gist

Gist yazmak da blog yazmak gibi, ama ağırlıklı olarak kod parçaları -hatta çoğu zaman dosyalar- içermekte. Bir baktım 2015’ten bu yana Gist karalıyormuşum. Bazıları public, bazıları private, bazıları blog tarzında uzunca (onları buraya taşısam daha iyi olacak), bazıları bir kaç kelime açıklama ardından bir kaç dosyadan oluşmakta. Her gün işim düşmese de 1-2 ayda bir işim düşüyor oradaki notlarıma.

Bu sabah production ortamındaki bir durumu çözmeye çalışırken öğrendiğim bir yöntem için yeni bir Gist yazınca, ben neden Gist yazıyorum diye tekrardan bir düşünüp yazıya dökmek istedim. Gist PostgreSQL üzerineydi. Geriye dönüp bakınca farkettim, 1 yıl içinde PostgreSQL ile alakalı faydalı olduğunu düşündüğüm 5 adet Gist yazmışım. Günün birinde sizlere de faydalı olması dileğiyle, buyrunuz…

ALTER TABLE ve başka pahalı sorguların çok daha hızlı çalışması için:

Tabloyu kilitlemeden INDEX ekleyip çıkarmak için:

“Biz Bunları Gist’lerimizde Anlattık! – PostgreSQL” öğesini okumaya devam et

Reklamlar

Başı-Boş Satırlar – IntelliJ ile Bahar Temizliği – Bölüm 2

Geçenlerde IntelliJ’de tek bir hamlede tüm Java kodumuzun biçimsel düzenini sağlamanın yöntemine göz atmıştık: Kodunuza İyi Bakın – IntelliJ ile Bahar Temizliği

Şimdi ise Java kodumuzdaki tüm gereksiz boş satırları silmenin yolarına göz atacağız. Birinci bölümdeki yöntemi uyguladıktan sonra “Edit > Find > Replace in Path…” özelliğini uygun regexler ile kullanarak şunlardan kurtulabiliriz:

Kodun herhangi bir yerinde yer alan ard arda iki boş satırdan…

Text to find:
\n\n\n

Replace with:
\n\n

Metot gövdesi başlangıcındaki boş satırdan…

Text to find:
\) \{\n\n

Replace with:
\) \{\n

Metot gövdesi sonundaki boş satırdan…

Text to find:
;\n\n    }

Replace with:
;\n    }

Kodunuza İyi Bakın – IntelliJ ile Bahar Temizliği

Java derleyicisi kodunuzu biçimsel olarak nasıl düzenlediğinize karışmaz, kodunuzun derlenebilmesi için Java söz dizim kurallarına uymanız yeterlidir. Ancak kodunuzun okunabilir olması için kodunuzun biçimlendirmesine (format) dikkat etmeniz gerekir. Özellikle birden fazla kişinin çalıştığı büyük/orta ölçekli projelerde okunabilir kod eşittir bakımı yapılabilir kod denebilir.

Elbette kodun biçimsel düzeni okunabilir/anlaşılabilir kodun tek ön koşulu değil, yine de özenli olma yolunda iyi bir başlangıç olacaktır. (Yeri gelmişken okunabilir/anlaşılabilir kod yazmak üzerine müthiş tavsiyelerde bulunan şu kitaba göz atmanızı şiddetle tavsiye ederim: Clean Code: A Handbook of Agile Software Craftsmanship. Ya da şu yazı dizisine bir bakın derim: Clean Code’dan Notlar: Bölüm 1 — Temiz Kod Derken?)

Özellikle birden fazla kişinin çalıştığı projelerde zaman zaman acele yetişmesi gereken işlerden, kafa dağınıklığından yada basitçe kişisel ihmalden kaynaklı olarak -kodun hacminin de büyümesiyle- kodun biçimsel düzeni bozulmaya başlar. İşte burada bu bozuklukları topluca düzenlemede kullanabileceğiniz basit bir yöntemden bahsedeceğim. Favori Java editörüm olan IntelliJ IDEA‘da şu iki adımla tüm *.java dosyalarımızı topluca düzene sokmamız mümkün:

Adım 1: Tüm Java sınıflarımızı barındıran “src” dizinine (başka türde dosyalar da içerebilir elbette) sağ tıklayıp “Reformat Code” seçeneği seçilir:

reformat-them-all-step-1

Adım 2: Açılan “Reformat Code” penceresinde aşağıdaki seçenekler uygulanıp “Run” denilerek, tüm *.java dosyalarımızın düzenlenmesi yanında kullanılmayan ‘import’ deyimlerinden de arındırılması sağlanır:

reformat-them-all-step-2

“Mobil Oyun Geliştirme Stratejileri” Sunumundan Notlar

Yaklaşık bir yıl önce katıldığım “Mobil Oyun Geliştirme Stratejileri” başlıklı sunumda bir hayli not almış, notlarımı bazı arkadaşlarımla paylaşmış ve güzel geri dönüşler almıştım. Geçenlerde notlarıma göz attarken -biraz daha düzenleyerek- buradan da paylaşmamın yerinde olacağını düşündüm:

  • Konuşmacı: Sertaç Pıçakçı
  • Mobil vs. Tablet: Tablet oyunlarının geliri daha azmış. Ama önce tablet sürümünü çıkarıp, UX’i, oyun mekaniklerini vb. iyileştirip sonra mobil (akıllı telefon) versiyonunu çıkartıyorlarmış.
  • En büyük mobil oyun pazarı Asya-Pasifik’miş. Ve bu pazarda “casual” (“ev hanımlarının bile oynayabildiği” diye tanımladı) oyunlardan ziyade daha çok vurdulu kırdılı oyunlar seviliyormuş.
  • Çinli oyun firmalarında “retention” (bağlılık) “monetization”dan (gelir yaratma) daha önemli.
  • Oyuncular arası iletişim ve sosyal medya entegrasyonları çok önemli. “Bir oyun ‘oyun’ olmaktan çok sosyal mecra aslında” diyor. Sosyal mekanizmaların üstüne oyunu inşa ediyorlarmış. Voice chat (sesli mesajlaşma) dahi varmış bazı oyunlarda. Batıda bunun tam tersi yapılıyormuş; önce oyun sonra sosyal mekanizmalar.
  • Uygulama marketlerinde üst sıralarda yer alan bir oyun ayda 80 Milyon $‘dan fazla kazanıyormuş. Örneğin Clash of Clans:
    clash-of-clans-logo
  • Genel kabul görmüş gelir modeli: F2P. Onun dışında “premium” (oyunu yüklerken para ödediğin) ve “advertisement” (reklam) gibi gelir modelleri var.
  • F2P oyunlarda oyuncu kitlesinin ortalama %0.1-%0.3’lük kısmı bolca para harcıyormuş. Ve bu kitle gelirin %70-%80’ini sağlıyormuş.
  • Çinli firmaların “retention”a verdiği öneme çarpıcı bir örnek: Bolca para harcayan oyuncularla oyun moderatörleri arkadaş olup (tabii moderatör olduğunu hissettirmeden) oyuncunun doğru şekilde para harcaması için yönlendirmelerde bulunuyor ve böylece oyuncunun oyundan soğumamasını sağlamaya çalışıyorlarmış.

““Mobil Oyun Geliştirme Stratejileri” Sunumundan Notlar” öğesini okumaya devam et

Erik Meijer’e Göre “Reactive” Olmak

Erik Meijer “Reactive” denildiğinde şu yan etkileri (side effects) ele alacak şekilde tasarlanmış arabirimler kullanarak programlama yapılmasının anlaşılması gerektiğini vurguluyor:

  • Değerin “null” olup olmama durumu (Optional)
  • İstisna/hata durumları (Exception)
  • Gecikmeler (Latency)

Redis Sertifikasyonu

Redis açık kaynak bir veri yapısı saklama çözümüdür/sunucusudur. “In-memory”dir, hızlıdır, ölçeklenebilir… kısaca candır.

redis-white

Dahili olarak List, Set, Hash, Sorted Set gibi veri yapılarını destekler, bunların üzerinde işlem yapabileceğiniz fonksiyonlar sunar. Pek çok dil için istemci kütüphanesi mevcuttur. Örneğin Java için Jedis tercih edilebilir. Jedis metot isimlerini Redis’teki fonksiyon isimleriyle benzer olacak şekilde belirlediği için, terminalden Redis istemcisinde veri yapılarını ve fonksiyonları biraz kurcaladıktan sonra hızlıca Java uygulamanızda kullanmaya başlayabilirsiniz.

Redis’in resmi dokümantasyonunu oldukça beğeniyorum: http://redis.io/documentation. Ancak benim gibi önce genel konsptlerden bahseden webiner ya da çevrimiçi video kurslarla başlamayı seviyorsanız sizleri “Redis Sertifikasyonu” öğesini okumaya devam et