1) Instapaper

Tarayıcınızın araç çubuğuna yerleştireceğiniz bir düğmeyle, o anda okuyamadığınız ama sonradan okumak istediğiniz yazıları okuma listenize ekleyebilirsiniz. Üstelik bu yazıları Iphone, Ipad veya kindle gibi cihazlarda okuyabilirsiniz.

Ben bu problem için yer-imlerim arasında bir klasör oluşturmuştum. Bu çözüm kesinlikle daha kullanışlı.

Adres : http://www.instapaper.com

2) Readability

Bazen internette karşılaştığımız yazılar kullanılan stiller nedeniyle oldukça karışık olabiliyorlar. Örneğin www.hurriyet.com.tr gibi teoride haber sitesi olan yerlerde bir şeyler okumaya çalışırken epey zorlanıyoruz. Readability işte bu noktada yardımımıza koşuyor. Sık kullanılanlar çubuğunuza ekleyeceğiniz bir tuş ile tek tıkla o karmakarışık yazıyı alıp çok daha okunabilir bir hale sokuyor. Aşağıda bir karşılaştırma mevcut.

Adres : http://lab.arc90.com/experiments/readability/

Bill Amcayla çekilmiş eski bir resmim bu. Tabi daha o zamanlar yeterince(!) zengin değildi arkadaş.

Arada sırada işim gereği bu ruh haline giriyorum. Sanırım profesyonel iş yaşamımda, kişisel geliştirme alanımda olduğu gibi açık sistemlere geçmenin vakti geliyor yavaş yavaş.

• Agile (Çevik) Yazılım Geliştirme Süreçleri
• Agile Süreçler II : Genel Süreç İşleyişi
• Agile Süreçler III : Release Süreç İşleyişi

Notlar

• Agile’da bir kartın done olarak işaretlenebilmesi için tek koşul testlerden geçmesidir.
• Agile’da çok sık yapılan işlemlerin bir şekilde otomatize edilmesi (otomatik testler, çok sık yapılan işlemler için scriptler yazılması vs.) gereklidir.
• Hız tahmini yaparken son 3 iterasyonun ortalaması alınır.
  • (bu uygulama için burn down chart yapılmalı)

Agile Tasarım Yaklaşımları

• Sade bir tasarım olmalı : (önem sırasına göre)
  • Projedeki kodlar bütün otomatik testlerden geçmeli
  • Duplicate kod yazılmamalı (bunun için araçlar var)
  • Koda bakınca çok kolay bir şekilde anlaşılmalı (kod kendini dokümante etmeli).
  • Çözümün birden fazla class’a ve/veya çok fazla metoda bağlanmamış olması (minimum programlama elementi kullanılması, yani gereksiz patternlar gibi elementlerin kullanılmaması) gereklidir.

Agile Prensipleri

• İnsanların, bireylerin arasındaki iletişim süreçlerden daha önemlidir.
• Çalışan yazılım kapsamlı dökümantasyondan daha önemlidir.
• Müşteriyle işbirliği yapmak sözleşmelerden, şartnamelerden daha önemlidir.
• Proje başında bir plan yapmaktansa, bu planı proje süresine yayıp daha esnek bir süreç elde edilmelidir.

Story oluşturmada INVEST Kuralı :

I (Independet) : Storyler birbirinden bağımsız olmalı.

N (Negotiable): kendi başına bir anlam ifade etmeli, bağımlı olmamalı. İçersinde başka user storyler barındırmamalı.

V (Valuable): Mutlaka bir değer ifade etmeli.

E (Estimatable): Büyüklük verilebilir olmalı.

S (Small): Yeterince kısa ve küçük olmalı.

T (Testable): Test edilebilir olmalı.

Ekler

• Agile & Scrum Release Burndown Charts
• Kazanılmış Değer Yönetimi -3
• Agile Yazılım Geliştirme ve Scrum

• Agile (Çevik) Yazılım Geliştirme Süreçleri
• Agile Süreçler II : Genel Süreç İşleyişi

Release Süreci İşleyişi

Release planlaması yapıldıktan sonra;

• İterasyonlar : 1-2 haftada bir yapılan parçalara bölünmüş iş grupları. Genelde Çarşamba günleri başlayıp süresi ne kadar belirlenmişse (örneğin 1 hafta) o zamana kadar devam eden süreçler. İterasyonlar kendi içerisinde waterfall süreçler (analiz, tasarım, uygulama, test) içerirler.
• Kartlar öncelik sıralarına göre sıralanıp belirli iterasyonlara atanırlar. Kartlar:
  • M – must have
  • S – should have
  • C – could have
  • W – would have
  • Veya 1-5’e kadar öncelik sırasına da konulabilir.
• İterasyonlar planlanırken, iterasyon sürecinde hangi kartlar yapılacaksa ona konsantre olunur.
• Planlar yapılırken analist iterasyondan 2 hafta önce aday kartları detaylandırmaya başlar.
• Developer ise 1 hafta öncesinden, kart içerisinde yapılacak taskları (görevleri) belirler ve iterasyon planlama toplantısında diğerleriyle paylaşılır.
• İterasyona başlamadan iterasyon kick-off toplantısı yapılır.
  • Önce analist kartı anlatır, developer hazırladığı taskları açıklar.
  • Sorular cevaplanır vs.
  • Sonra tüm ekipten (developer, desginer, tester, vs) estimate tahmini (süre olarak) istenir. Çok uzun estimate’lere sahip tasklar break down yapılır (bölünür).
  • Son olarak ekip kartların ne kadarını yapabileceğini belirler ve bunlar ilgili iterasyona yazılır.
  • Burada estimate’ler belirlenirken testerlara ve developerlara ayrı sorulur ve ayrı yazılır. Ama sonradan birleştirilirler.
  • Eğer hangover (önceki iterasyondan kalan) kartlar varsa onlar öne alınır. Bir daha olmaması için önlemler alınır (storyler bölünebilir, ayarlamalar değiştirilebilir vs).
• Kartlar öncelik sırasına göre panodaki belirlenmiş yerlere (bag, development, test, done gibi) yapıştırılır.
• İterasyon değerlendirmeleri için daily stand-up meeting’lere (günde 15dk ayakta yapılan toplantılar) başlanır.
• Geliştirme aşamasında TDD prensipleri, %60 seviyesinde pair programming uygulanır.
• Her bir kart tester tarafından test edilmelidir.
• Bug’lar için production support ekibi kurulup (ekipten birisi veya birileri dönüşümlü olarak) sadece buglarla uğraşır.
• İterasyon bittikten sonra müşteriye (yoksa müşteri rolüne bürünecek herhangi bir kişiye – tercihen analist) demo yapılır. Buradan feedbackler alınır.
• Retrospective (iterasyonları değerlendirme toplantısı) yapılır.
  • Bu toplantıda herkese iterasyondaki kartlar dağıtılır ve insanlardan 15dk içerisinde iyi-kötü-çirkin buldukları şeylerin yazılması istenir. Burada iterasyon süresi daha iyi nasıl yapılabilir sorusuna cevap aranır.
  • Bir sonraki iterasyon için aksiyonlar alınır.

Ekler

• Çevik Geliştirmenin Planlamaya Bakışı -Teorik-
• Iterayon süresi
• Bir Solukta Kullanıcı Hikayeleri (User Stories)
• Çevik Süreçlerde Kestirim veya Tahimin
• Planlama Pokeri ve Takım Halinde Kestirim / Tahmin
• Şelale Modeli ( Waterfall Model )

• Agile (Çevik) Yazılım Geliştirme Süreçleri

Süreçler

• Velocity tahmini : En iyi ihtimalle şu kadar zamanda, en kötü ihtimalle şu kadar zamanda bu proje biter, tahmini.
• İterasyon ayarlamaları (bir iterasyon ne kadar sürecek vs)
• Mocking (prototipleme) yapılmalı. (prototyping lo-fi)
• Product Baglog’un hazırlanması :  story’lerin belirlenmesi.
• Release planı yapılmalı : Hangi feature’lar hangi release’de bitirilecek. İlk baştaki release’ler fonksiyonalite hedefli (mesela muhasebe paketi çıkacak gibi), sonraki release’ler bu fonksiyonalitelerin üzerine yeni özellikler ekleyen release’ler olmalı.

Ekler

• Extreme Programming
• Bir Bakışta İteratif Geliştirme
• UML ve Çevik (Agile) Modelleme
• Yazılım Mimarisi ve Çevik (Agile) Süreçler
• Bir bakışta CMMI ve Karacaoğlan
• Çevik Süreçler Zeki Olmayı Gerektiriyor mu?
• Çevik Geliştirme (Agile) Tam Türklere Göre (mi ?)

Bunların eğitim veya konu anlatımı değil, sadece notlar olduğunu aklımızdan çıkarmayalım lütfen

Yazı serisi kaç parçadan oluşacak bilmiyorum ama kısaca,

• Agile süreçlere giriş ve quick start aşaması
• Süreçler
• Notlar
• OOP Principles & Design Patterns and Refactoring
• Test Driven Development

konularına kısaca değinmek istiyorum. Hadi başlayalım o zaman…

Agile

• Think big, Act small
• Fail fast, improve learn

Agile’ın olayı sürecin kendini döngü içerisinde adım adım dinamik olarak ayarlamasıdır. Sık release’ler yaparak değişimlere kolay ayak uydurmak önemlidir. Tasarımın değişime, gelişime açık olup, hataları çabuk ortaya çıkması gereklidir. Agile’ın temelinde, bir feedback döngüsüne girip sonuçlara göre süreçlerin ayarlanması yatar.

Süreçler panolarda asılı kartlarda, kartların ayrıntıları wikilerde tutulur.

TDD ve OOP principles agile süreçlerde olmazsa olmaz bir tekniklerdir.  Bu tekniklerin bu kadar önemli olmasının nedeni, değişiklik maliyetinin (proje süreçlerinin her noktasında yapılacak değişiklikler) en aza indirilmesini sağlanmalarıdır.

DDD (domain driven design) gibi metodolojilerde kullanılabilir.

İlk aşamada satışçı projeyi satar, sonra quick start aşaması gelir.

Quick Start

Projenin başlangıcında 2-4 kişilik ekiplerle müşteriye gidilir. Bu ekipte,

• Tech lead
• Analyst
• Prototipleme uzmanı (hızlıca arayüz çıkartabilen bir kişi)

bulunur.

Project Deliverable list (İlk yapılacak şeyler):

• Projenin vizyonu : bu proje neden geliştiriliyor, kim kullanacak vs
• Ana story (özellik) listesi : Bu storyler INVEST presniplerine göre yazılır.
  • As a “Role”
  • I want “feature”
  • So that “benefit”
  • Stroy’ler kısa özelliklerdir. Daha büyüklerine epic denilir (Mesela, bir projede hem blog kısmı hem de cms kısmı olacak diyelim. Bu durumda blog özelliği epic, bunun içerisindeki comment ekleme, post gönderme gibi özellikler story olur). Storylerin olabildiğince bağımsız olması ve kısa yazılması gerekir.
  • Mimari vizyon : Tech lead konu bazında bir kaç story seçerek (belirsizlik nerelerde görülüyorsa) ona göre bir mimari vizyon hazırlar.
  • Release planı : Birtakım sorular sorularak (mesela featureların hepsi bitmesi gerekiyor mu, biraz sürede sarkma olsa önemli mi gibi) releaselerin nasıl olacağıyla ilgili planlama yapılır.

    • StoryID	As A	I want	So that	Estimate
      EBT-001	Admin	X	X	M

• Dokümantasyon wiki sisteminde yapılır. Geliştirme süresi başlamadıkça o story kesinlikle detaylandırılmaz. Geliştirme aşamasına gelinceye kadar (veya ihtiyaç oluşunca) o story sadece bir iki cümleyle açıklanır. Bu da agile’in waterfall süreçlerden en önemli farkıdır.
• Release planında, müşterinin isteklerine göre, hangi aralıklarla teslimler yapılacak ve teslim planı ne gibi sorulara cevap aranır. Agile’ın olayı sık sık release yapmaktır.
• Estimate tahminleri büyüklük tahminleri şeklinde olur (t-shirt sizeları, fibonacchi sayıları gibi dizilimler kullanılır. Mesela S,M,L,XL gibi). Daha sonra iterasyonlar içinde detaylı estimate yapılırken artık gün (0.5 ve katları) şeklinde estimate verilir. Eğer estimate verilmesinde bir sorun olan kart varsa onun için bir altyapı çalışması istenilebilir.
• Proje süresi hesaplanırken, estimateler verilirken, sizelara en iyi ve en kötü süreler verilir (mesela S bir iş, en iyi ihtimalle 0.5 en kötü ihtimalle 1.5 gün sürer gibi). Bu durumda proje süresinin en iyi ve en kötü tahmin süresi çıkartılır ve istenirse üzerine buffer konulabilir.
• Agile süreçlerde proje süreleride projenin diğer elementleri gibi dinamik şekildedir.
• Agile’ın sunduğu en önemli şey, deadline geldiğinde elinizde kesinlikle çalışan (her feature olmasa bile) kaliteli bir kod bulunmasıdır.

Ekler

• http://en.wikipedia.org/wiki/Agile_software_development
• http://en.wikipedia.org/wiki/Agile
• http://e-bergi.com/2008/Ekim/Cevik-Modelleme-ve-Cevik-Yazilim-Gelistirme
• Prime Teknoloji Agile’a Giriş Belgesi (pdf)
• http://www.minepla.net/2008/10/agilecevik-yazylym-gelithtirme/
• http://www.agileturkey.org/Index.aspx
• http://www.sulc3.com/model.html
• http://blog.emrahkahraman.com.tr/category/cevik-yazilim/

Web arayüzleri normal yazılım arayüzlerinden daha farklıdır. Sonuç olarak HTML ve yardakçıları (css, js) ile çalışmak çok farklı. Eğer bir web uygulaması geliştiriyorsanız Amerika’yı tekrar keşfetmemek için arayüz bileşenlerinin bir kısmını hazır kullanırsınız. Bunun, tasarım düzeni ve kullanışlılık olarak da avantajları olacaktır. Eğer tek bir framework kullanırsanız görünüş ve kullanım olarak ayrı telden çalmayan kontrollere sahip olursunuz.

Bu UI frameworklerinin çoğu aslında javascript kütüphaneleri. Tabii bu durum kontrolleri her türlü sunucu taraflı geliştirme ortamıyla kullanabilmemizi sağlıyor. Şimdi listemize bir göz atalım :

Cappuccino Web Framework

Mottosu Build Desktop Class Applications in Objective-J and JavaScript olan bu framework Objective-J ve Javascript ortamlarını destekliyor.  Dokümantasyonu daha çok referans tarzında hazırlanmış. Birkaç tanede tutorial mevcut. Arkasındaki komünite oldukça sağlam

Adres : http://www.cappuccino.org/ – demo

Lisans : Lisans olarak LGPL version 2.1 tercih edilmiş.

YUI Library

Yahoo’nun önceleri kendisi için geliştirmeye başladığı, sonraları açık kaynak kodlu olarak dağıtıma açtığı arayüz çatısı. En çok 2. ve 3. versiyonlar tercih ediliyor. Açıkçası gerek api gerekse de kontroller bana oldukça karmaşık geldi. Kendi içerisinde barındırdığı kontroller dışında arkasındaki komünite tarafından hazırlanan oldukça fazla kontrole ve araca sahip.

Adres : http://developer.yahoo.com/yui/

Lisans : BSD license

Google Web Toolkit

Google’ın kendi ürünlerini geliştirirken kullandığı arayüz kütüphanesi. Dahili ajax desteği, Java için direkt destek (eclipse plugini mevcut) ve mobil platform desteği (iphone ve android) avantajları.

Adres : http://code.google.com/intl/tr/webtoolkit/

Lisans : Apache License, Version 2.0

MochaUI

Mocha, Mootools kullanılarak yazılmış bir javascript uygulama arayüz kütüphanesi. Karışık olmayan güzel bir dökümantasyonu var. Kütüphane, özellikle layout uygulamaları için düşünülmüş ve oldukça başarılı.

Adres : http://mochaui.com/ demo

Lisans : MIT License

Ext JS

İlk bakışta sizi en çok etkileyecek framework bu. Javascript ve GWT için ayrı uygulamaları var. Çatı bir sürü bileşene sahip ve tek kelimeyle harika gözüküyorlar. Şu anda 3.1 sürümü mevcut. Daha önceki sürümlerinde JQuery gibi bir js kütüphanesine ihtiyaç duyuyorken, yeni versiyonunda ekip kendi kütüphanelerini geliştirmiş. Bunun dezavantajı, projenizde JQuery gibi bir kütüphane kullanıyorsanız ek olarak birde extjs_core kütüphanesini de kullanmanız gerekiyor. Yanlız burda şunu belirtmem gerek. 3.0 versiyonundan sonra kütüphanenin commercial sürümü eklenmiş. Ve bunun için komüniteyi kısıtlamışlar sanki. Yeni versiyonla ilgili neredeyse hiç dökümantasyon yok. Bu inanılmaz bir eksi. Dökümantasyon ve eğitimler ayrıca parayla satılıyor.

Adres : http://www.extjs.com/ demo

Lisans : GNU ve Commercial

jQuery UI

İnternette milyonlarcası bulunabilen Jquery bileşenleri gibi bileşenler içeren bir paket. Jquery ekibi tarafından geliştiriliyor. Henüz daha çok yeni olduğundan dolayı çok birşey beklememek lazım. Ama tema desteği gibi sunduğu özellikler oldukça güzel. Bence kesinlikle denemeye değer.

Adres : http://jqueryui.com/ demo

Lisans : MIT GPL

DHTML UI Toolkit

Yeni rastladığım bu kütüphane gerçekten çok başarılı. Gerek kullanım, gerek bileşen sayısı olarak şu ana kadarkiler arasında farklı bir yeri var. Kapsamlı dökümantasyon, kullanışlı bileşenler ve güzel görünüm artıları içerisinde sayılabilir. Bazı bileşenleri commercial lisansa sahip olsada genel manada oldukça başarılı bir set. Bence Ext JS’den daha başarılı bu konuda.

Adres : http://www.dhtmlx.com/index.shtml demo

Lisans : GPL – Commercial – Enterprise

Nitobi Complete UI

Nitobi, Asp, php, asp.net, java, javascript ve coldfusion’a destek veren bir arayüz kütüphanesi. Oldukça başarılı olan bu kütüphanenin dökümantasyon desteği çok iyi ve kullanımı da çok kolay. Kesinlikle bakmadan geçmemek lazım.

Adres : http://nitobi.wikidot.com/

Lisans : GNU – Commercial

Oyun AI Türleri

Çok farklı türlerde AI sistemleri ve bu sistemleri tamamlayan özel algoritmalar vardır. Yapay zekayı sadece oyun dünyasıyla sınırlandırsanız bile, çok sayıda seçenek ve bilgi kümesiyle karşılaşacaksınız. Bazı yapay zeka çözümleri, belirli oyun türleri üzerinde daha sık kullanılır. Farklı durumlara uygulanabilen çok sayıda farklı seçenek vardır. Oyunlarla ilgili yapay zeka algoritmaları  3 temel türe ayrılabilir;

1. Dolaşan AI (Roaming AI)
2. Davranışsal AI (Behavioral AI)
3. Satratejik AI (Strategic AI)

Bu 3 yapay zeka algoritması türünün, oyunlarda kullanılan yaklaşımları tümüyle kapsadığını düşünmeyin. Sadece anlaşılması ve kullanımı kolay, genel üç türü temsil ediyorlar.

Dolaşan AI

Dolaşan AI, oyun nesnelerinin hareketini modeller. Bu da oyun nesnelerinin sanal bir oyun dünyasında nasıl dolaşacaklarına karar vermesi anlamına gelir. Klasik arcade oyunu Galaga gibi sjoot-em-up uzay oyunları dolaşan AI’ye bir örnektir. Bu tür oyunlarda uzaylılar genelede oyuncunun peşinden giderler.

Temel olarak, bilgisayar kontrolündeki bir nesnenin, yolunu değiştirmek için bir karak vermesi gerektiğinde dolaşan AI kullanılır. Nesne, oyun içinde istenilen bir sonuca ulaşmak veya belirli bir hareket şeklini izlemek için yolunu değiştirebilir. Galaga örneğinde istenilen sonuç, oyuncunun gemisine çarpışmak ve ona zarar vermek için izlenecek yoldur.

Dolaşan AI’nin uygulanması oldukça kolaydır; başka bir nesnenin (oyuncunun gemisi) konumuna göre bir nesnenin (uzaylı) hızı veya konumu değiştirilir. Nesnenin gezinim hareketi, rastgele veya önceden belirkenmiş modellerden etkilenebilir. Üç farklı dolaşan AI türü vardır : Kovalama (chasing), kaçma (evading) ve şablonlu (patterned). Şimdi bu dolaşam AI türlerini daha detaylı inceleyelim.

Kovalama

Kovalama, bir oyun nesnesinin başka bir oyun nesnesi veya nesnelerini izleyip, onların arkasından gittiği türdür. Kovalama, bir uzaylının oyuncunun gemisini takip ettiği shoot-em-up oyunlarının çoğunda kullanılan bir yaklaşımdır. Oyuncunun gemisinin geçerli konumuna göre, uzaylının hızı veya konumu değiştirilerek uygulanır. Aşağıdaki örnek br uzaylı ve bir gemi içeren basit bir algoritmadır.

if (iXAlien && iXShip)
    iXAlien--;
else if (iXAlien && iXShip)
    iXAlien++;
if (iYAlien && iYShip)
    iYAlien--;
else if (iYAlien && iYShip)
    iXAlien++;

Gördüğünüz gibi uzaylının XY konumu (iXAlien ve iYAlien), geminin konumuna göre (iXShip ve iYShip) değiştiriliyor. Bu kodun tek potansiyel sorunu fazla iyi çalışıyor oluşudur. Uzaylı büyük bir azimle oyuncuya saldıracak ve ona kurtuluş şansı vermeyecektir. Bu kovalama algoritmasını düzeltmenin bir yolu eşitliğe biraz rastgelelik eklemek olabilir.

if ((rand() % 3) == 0) {
    if (iXAlien && iXShip)
        iXAlien--;
    else if (iXAlien && iXShip)
        iXAlien++;
}

if ((rand() % 3) == 0) {
    if (iYAlien && iYShip)
       iYAlien--;
    else if (iYAlien && iYShip)
       iXAlien++;
}

Bu kodda uzaylı 3′te 1 şansla oyuncuyu her yönde kovalar. Üçte bir şans fazla verimli görünmeyebilir ama unutmayın, uzaylı sadece oyuncuyu kovalamak için yolunu değiştirecektir. Akıllı bir oyuncu bunu farkedecek ve sıkça yönünü değiştirecektir.

Kaçma

Kaçma kovalamanın mantıksal tersidir. Bu türde, bir oyun nesnesi diğer nesne veya nesnelerden kaçmaya çalışır. Örnek;

if (iXAlien && iXShip)
    iXAlien++;
else if (iXAlien && iXShip)
    iXAlien--;
if (iYAlien && iYShip)
    iYAlien++;
else if (iYAlien && iYShip)
    iXAlien--;

Bu kodda temel olarak kovalama algoritmasının tersi kullanılır. Kovalamada olduğu gibi kaçmada da rastgelelik ile etki yumuşatılabilir. Bu klasik arcade oyunu Pac-Man’deki hayaletler için kullanılan koda benzer. Oyuncu güç hapı yuttuğu anda hayaletler ondan kaçmaya başlarlar.

Kaçma algoritmasının başka bir kullanımı da demolardır. Örneğin bir uzay oyununun demo kipini çalıştırdığınızda, bilgisayar kendi başına oynamaya başlar ve diğer nesnelerden kaçmaya başlar. Aslında normal bir oyuncuda uzaylılardan kaçmak için klavye tuşlarıyla kaçma algoritması kullanır.

Şablonlu Dolaşım

Şablonlu hareket, bir oyun nesnesi için önceden tanımlı bir hareketler kümesi kullanan dolaşan AI türüdür. Şablonlu harekete örnek olarak klasik Galaga oyunundaki uzaylılar verilebilir. Uzaylılar ekranda aşağı doğru inerlerken çeşitli akrobatik hareketler sergilerler. Şablonlar daireler, zigzaklar veya daha karmaşık hareketlerden meydana gelebilirler. Space Invaders oyunu şablonlu hareketlere daha basit bir örnektir; bir uzaylı sürüsü yavaşça ve düzenli olarak aşağı doğru iner.

Şablonlar genellikle şablonlu harekete ihtiyaç duyulduğunda bir nesneye uygulanan bir hız veya konum ötelemeleri (çarpanları) dizisinde depolanırlar:

int iZigZag[2][2] = { { 3, 2 }, { -3, 2 } };
iXAlien +=  iZigZag[iPatternStep][0];
iYAlien +=  iZigZag[iPatternStep][1];

Bu kod, oldukça basit dikey bir zikzak şablonunun nasıl uygulandığını gösteriyor. Tamsayı dizisi iZigZag, uzaylıya uygulanacak XY öteleme çiftlerini içeriyor. iPatternStep değişkeni, şablondaki geçerli adımı temsil eden bir tamsayıdır. Bu şablon uygulandığında uzaylı, oyun döngüsü başına 2 piksel hızında dikey yönde hareket ediyor ve oyun döngüsü başına 3 piksel hızla yatay zikzaklar çiziyor.

Bir sonraki yazıda Davranışsal AI’yi masaya yatıracağız.

Notlar tamamen basic terminology’i içermektedir. Konular kısaca şöyle;

- 3d rendering basics
- Basic Terminology (Vertex, Face, Normal etc.)
- World View Projection Matrices
- Viewing Frustum
- Quaternions
- Camera
- Basic Lighting
- Textures
- Vertex and Index Buffers
- Rendering Pipeline
- Depth Buffer

Bir oyun motoru kullanırken buradaki karmaşık matematiği kullanmayacaksınız. Çoğu işi sizin yerinize motor üstlenecek ama shader kullanırken kesinlikle bunlar işinize yarayacaktır.

Notlar tamamen matematikten ibaret, herahangi bir kod içermiyor.

Temel Tanımlamalar

Vertex : Uzayda bulunan bir nokta.

Face : En az 3 vertexten oluşan yüzey. Yüzeyler her zaman üçgenlerin birleşmesinden oluşurlar.

Normal : Bir yüzeye dik giden özel vektör. Birçok hesaplamada (özellikle ışık, kaplama ve fizik) kullanılıyor.

Vertex Buffer : Vertexlerin çizilmeden önce depolandıkları yer. Burada vertexlerden yüzey oluşturmanın 3 yolu vardır (TRIANGLE_LIST, TRIANGLE_STRIP ve DRAW_INDEXED).

World (Transformation) Matris : Uzaydaki nesnelerin Rotation, Scale ve Transformation bilgilerini tutan matristir.

View Matris (Camera Matris) : Kameranın pozisyon ve yön bilgilerinin saklandığı matris.

Projection Matris: Çerçeve bilgilerinin saklandığı matris.

Quaternion : Transformation bilgilerinin ifade edileceği (vektör bilgisi yerine) alternatif bir tür. Quaternion değeri bir karmaşık sayıdır ve oyun motoru kullanırken sıklıkla karşınıza çıkar.

Bunları daha uzun anlatmak isterdim ama yazarak anlatmak gerçekten zor. Ben bu notları sadece bir başlangıç olsun diye sunuyorum, sakın görünce bişey anlamazsanız korkmayın. İnternetten biraz araştırmayla daha fazla bilgi edinebilirsiniz. En azından nereden başlanacağı belli olsun. Yeni başlayanlar için aklımda daha farklı bir proje var, bakalım ne çıkacak

Notlar Note: There is a file embedded within this post, please visit this post to download the file.

Ben bu makalede Soa’nın çok teknik kısımlarına girmeden sadece anlamı üzerine duracağım.

Soa’nin avantajlarını şu şekilde sıralayabiliriz :

• Birçok uygulama aynı katmanları ayni servis üzerinden kullanabilir. Bu durumda bir revizyon yapmaniz gerektiğinde istemci uygulamalara dokunmadan tek bir servis üzerinden değişiklikleri yapabilirsiniz.
• Mesela desktop bir uygulama yazıyorsanız, uygulamanızın istemci tarafında sadece kabuk bir arayüz bulunacağindan (smart client olabilir), geliştirme işlemi soyutlaşmış olur.
• Farklı platformlarda geliştirilen uygulamalar için aynı altyapıyı kullanabilirsiniz. Örneğin, uygulamanızın hem web, hem windows, hem linux, hem mobile hem de mac sürümleri bulunuyorsa bile hepsinde aynı altyapıyı kullanabilirsiniz
• Uygulamanızın farklı katmanlarını farklı sunucularda barındırabilirsiniz. Bu size daha kolay yönetim ve performans getirecektir.
• Uygulamanız için uygulama geliştirme arayüzü (API) oluşturabilir, arkanızı yaslanıp yabancı uygulamaların sizinkine entegre olmasını keyifle izleyebilirsiniz.
• Cloud Computing konseptine uygun uygulamalar hazırlayabilirsiniz.

Peki Soa Nasıl Sağlanıyor?

Soa için web servislerini veya WCF gibi daha yeni teknolojileri kullanabilirsiniz.

XML Web Servisleri : Veri iletimi için oluşturulmuş xml yapılarının kullanıldığı yöntemdir. XML Web servislerinde eger yazdığınız servis karşı tarafta karşılığı bulunmayan bir veri türü kullanmıyorsa (örnegin datatable) yazılan metodlar dil bağımsız olur. Yani Java ile yazılan bir web servisi .Net ile çağırabilirsiniz. Web servisi yazmak Java veya .Net gibi platformlarda resmen çocuk oyuncağıdır (ayrıntılar için şuraya bakabilirsiniz).

API Uygulamaları : Tam olarak Soa içerisinde sayılmasalarda yinede bahsetmek gerek. Büyük çoğunluğu, GET metoduyla (QueryString) gönderilen parametreleri işleyerek geriye sonuçlar döndüren yapılardan oluşur (Örnek).

WCF (Windows Communication Foundation) : .Net uygulamaları için kullanılabilecek, web servislerinin geliştirilmiş halidir. En temel avantajı, servisi açmak için bir web sunucusu kullanmanız gerekmemesidir. Bunun yerine kendi uygulamalarınızdan da yayın yapabilirsiniz (ayrıntılar için şuraya bakabilirsiniz).

Web Uygulamalarında Soa

Web uygulamaları için soa ilk bakışta gereksiz gibi görünsede en az diğer uygulama türleri için olduğu kadar gereklidir. Web uygulamalarında sunucuların dağıtık yapıda olması (gerek veritabanı sunucuları için (linked server) gerekse uygulama sunucuları için) performans açısından elzem bir uygulamadır.

Örnegin Facebook gibi uygulamalar, dağıtık şekilde birçok veritabanı ve uygulama sunucusu kullanırlar.

Diğer bir örnek olarak banka servisleri verilebilir. Uygulamalarınızın banka entegrasyonu olmasını istiyorsanız ilgili bankaların web servislerini kullanmanız gerekir.

Son bir not olarak soa uygulamalarında state yönetimine dikkat etmenin öneminden bahsetmek istiyorum. Birden fazla servis kullanırken her bir servis için state durumunu (yani session durumunu) kontrol etmek gerekir. Bu servisler herhangi bir state bilgisi barındırmayacaklarından bu katmanlarda durum yönetimini sıkı yapmak gerekir. Yoksa çok büyük bir güvenlik açığı oluşturmuş olursunuz.

Kaynaklar

• SOA (Wikipedia)
• SOA Nedir Hoca?
• SOA ve Proje Analizi
• Web Services and Service-Oriented Architectures
• SOA Hakkında Herşey (Blog)