Rename folder

development/100-architecture.md

@@ -0,0 +1,152 @@
+# SOLID
+
+## SRP	- Tek Sorumluluk Prensibi (Single responsibility principle)
+
+Bir sınıfın tek bir sorumluluğu olmalıdır. Örneğin aşağıdaki `User` sınıfında kullanıcının yaratılması, silinmesi, 
+kayıttan sonra email atılması, login logout olması gibi çok fazla sorumluluk vardır.
+
+```ruby
+
+class User
+  attr_accessor :username, :password, :email
+
+  def create username, password, email
+    # Kodlar
+  end
+
+  def delete username
+    # Kodlar
+  end
+
+  def send_register_email email
+    # Kodlar
+  end
+
+  def login email, password
+    # Kodlar
+  end
+
+  def logout email
+    # Kodlar
+  end
+
+end
+```
+
+Daha doğru bir yaklaşım emaili Email sınıfının, login logout işlemlerini Session sınıfının, hatta kullanıcının kaydedilip,
+silinmesi işlemlerine DAO sınıfının bakması gerekmektedir. Eğer bir sınıfın birden fazla sorumluluğu olursa o sınıfın ileride
+modifiye edilmesi yüksek bir olasılıktır ki buda açık kapalı prensibine aykırıdır.
+
+
+```ruby
+class User
+  attr_accessor :username, :password, :email
+end
+```
+
+
+```ruby
+class UserDao
+  def create username, password, email
+    # Kodlar
+  end
+
+  def delete username
+    # Kodlar
+  end
+end
+```
+
+
+```ruby
+class SendEmail
+  def send_register_email user
+    # Kodlar
+  end
+end
+```
+
+
+```ruby
+class Session
+  def login user, password
+    # Kodlar
+  end
+
+  def logout user
+    # Kodlar
+  end
+end
+```
+
+## OCP	- Açık Kapalı Prensibi (Open/closed principle)
+
+Ivar Jacobson söyle demiştir. "Her program görev süresince değişikliğe uğrar. Bu ilk sürümden ötesi düşünülen 
+programların yazılımında göz önünde bulundurulmalıdır." Yani mutlaka ama mutlaka yazılımınız ileride gelen yeni 
+istekleri karşılabilecek kapasitede olmalıdır. Sektörde müşterilerine yazılımları satıp yeni istekler gelince 
+köşe bucak kaçan bir sürü yazılım firması vardır.
+
+Bu prensibe göre programlar geliştirilmeye açık ama değiştirilmeye kapalı olmalıdır. Yani yeni bir istek geldiğinde
+eski yazdığınız kodları değiştirmemeli yeni kodlar yazarak müşterinin yeni isteklerini karşılamalısınız. Kodlar
+değişeme kapalı, geliştirilmeye açık olmalıdır. 
+
+Basit bir örnek verelim. Müşterimiz bize AVEA ve Turkcell'den SMS atan bir program istedi diyelim. 
+
+```ruby
+class Sms
+  send_sms number, msg
+    if number is turkcell
+      # Turkcell'den SMS gönder
+    elsif number is avea
+      # Avea'dan SMS gönder
+    end
+  end
+end
+```
+
+Yukarıda kod tam bir beladır. İleride müşteriniz Vodofan'dan bir kampanya alırsanız. Yukarıda ki kodu switch'e çevirmeniz
+gerekecektir. Yani eski yazdığınız kodu değiştirmeniz gerekecektir. Bunun yerine aşağıdaki kod daha kalitelidir.
+
+```ruby
+# Kadu yazalım
+
+```
+
+## LSP	- Liskov substitution principle
+## ISP	- Interface segregation principle
+## DIP	- Dependency inversion principle
+
+# Design patterns
+
+http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
+
+## Oluşturucu
+
+### Factory
+### Abstract Factory
+### Singleton
+### Builder
+### Prototype
+
+## Yapısal
+
+### Adapter
+### Bridge
+### Facede
+### Composite
+### Decorator
+### Proxy
+### Flyweight
+
+## Davranışsal
+
+### Command
+### Iterator
+### Memento
+### State
+### Observer
+### Strategy
+### Chain of responsibility
+### Mediator
+### Visitor
+### Template Method

development/1000-newbie.md

@@ -0,0 +1,33 @@
+# Çıraklar için kaynaklar
+
+## Try Ruby
+
+İnteraktif bir şekilde Ruby programlama dilini öğretiyor.
+
+* http://tryruby.org
+
+## Try Github
+
+İnteraktif bir şekilde Git ve Github öğretiyor.
+
+* http://try.github.com
+
+## Try JQuery
+
+* http://www.codeschool.com/courses/try-jquery
+
+## *nix kurulumu
+
+Ruby programlama dilini Windows üzerinde geliştirmeniz zordur. Bunun yerine Linux veya Mac tercih ediniz. Firmada bizler ya Ubunyu ya da Mac kullanıyoruz.
+
+## Lynda Ruby Essential Training
+
+* 7 saatlik Ruby 1.9 eğitim seti
+* http://www.lynda.com/Ruby-tutorials/essential-training/47905-2.html
+
+## Lynda Ruby on Rails 3 Essential Training
+
+* 12 saatlik Rails eğitim seti
+* http://www.lynda.com/Ruby-on-Rails-3-tutorials/essential-training/55960-2.html
+
+

development/200-agile-project-management.md

@@ -0,0 +1,67 @@
+# Çevik Süreçler
+
+Proje yönetimi için çevik süreçler kullanılır.
+
+* [Çevik Manifesto](http://agilemanifesto.org/iso/tr/)
+* [Çevik İlkeler](http://agilemanifesto.org/iso/tr/principles.html)
+* [Kanban](http://kanban.lab2023.com) için huboard programını kullanıyoruz.
+* Sürüm kontrolü için [semver](http://semver.org/) kullanıyoruz.
+
+# Semantik Versiyonlama
+
+lab2023 olarak www.semver.org adresinde ki standartlara göre versiyonlama yapıyoruz. Bu reponun Türkçesini https://github.com/lab2023/semver/blob/tr_translation/locales/semver.tr.md adresinde bulabilirsiniz.
+
+**Kurallar**
+
+* X.Y.Z şeklinde ifade edilecen bir versiyonlama da X -> Major, Y -> Minor, Z -> Patchi ifade eder.
+* Z -> Uygulamaya yapılan hotfix ve typo düzeltmelerinden de yapılır. Yani uygulamaya yeni bir özellik eklemediyseniz, belli bir yerdeki bir hatayı veya yazıyı değiştirdiyseniz Z sayısı değişir.
+* Y -> Uygulamaya eklenen yeni özellikler, iyileştirmeler sonucunda değişir. Y deki değişiklikler eski kullanıcıları eklemez. Y de ki değişiklikler **GERİYE UYUMLU**dur.
+* X -> Uygulamada yapılan büyük değişikliklerdir. Örneğin yapının komple değişmesi, teknolojinin değişmesi gibi gibi. X de yapılan bir değişiklik **GERİYE UYUMLULUĞU** desteklemez.
+* Bir uygulama 0.1.0 versiyonu ile başlar. 
+* Bir uygulama product olunca 1.0.0 olmalıdır. 
+* Eğer X = 0 ise o uygulama stable değildir. Yani her an her şeyi değişebilir. Hala develop aşamasındadır.
+* Her uygulmanın versiyonunu gösteren bir API si olmalıdır. Yani kullancılar, diğer developerlar mutlaka hangi sürümü kullandıklarını bilmelidir! **Bu programcının birinci ve en önemli görevidir.**
+* Versiyonlamada [0-9A-Za-z-] ifadelerini kullanabilirsiniz.
+* 1.0.0-alpha.1 gibi prepatchleri kullanmanızı biz lab2023 olarak önermiyoruz. Hayat zaten yeterince karışık!
+
+## Github ve Etiketler
+
+lab2023 projelerinde github'da 4 adet etiket açılır.
+
+* Bug 
+* Enhancement
+* Question
+* Future
+
+**Bug**
+
+Hata bildirimleri için kullanılır.
+
+**Enhancement**
+
+Programdaki bir özelliği veya arayüzü iyileştirmek için kullanılır.
+
+**Question**
+
+Soru sormak, öneride bulunmak veya tartışmak için kullanılır.
+
+**Future**
+
+Proje süresince müşterinin aklına gelen ancak anlaşmadığımız gelecekte yapılması planlanan işlerdir. Bunlar yapılmaz ancak fikirler unutulmasın diye future etiketi ile etiketlenir.
+
+NOT: 
+
+1. wontfix, dublicate, invalid gibi etiketler kullanılmaz. 
+2. Eğer yeni iş istek varsa buna etiket yapılmaz. 
+
+# Üretkenlik
+
+Bu bölümde geliştiricilerin üretkenliğini artırmaya yönelik kurallar vardır.
+
+* Gelişticiler ile toplantılar günde bir alınır. Bu toplantılar günlük 5 dakikayı geçemez.
+* Geliştiricilere işler iteratif olarak haftalık verilir.
+* Geliştirici aynı anda iki projeye de çalışmaz. Bir proje bitmeden başka projeye geçemez.
+* Mümkün olduğunca iki geliştirici bir projede çalışır.
+* Geliştiriciler sorularını mail grubunda sorarlar. Böylece sorular kayıt altına alınır. Aynı sorular iki defa sorulmaz.
+* İletişim aracı olarak sırasıyla 1. mail, 2. gtalk, 3. cep telefonu tercih edilir. Böylece geliştiriciler bir birlerini rahatsız etmez.
+* lab2023 geliştiricilerine donanım, lisans vb unsurları alması için kredi verir, bu konuda maddi olarak destekler.

development/250-git-github-gitflow.md

@@ -0,0 +1,136 @@
+# Git, Github, Git flow
+
+## Git
+
+## Github
+
+## Git Flow
+
+Git-flow [Vincent Driessen](http://nvie.com/) tarafından etkili dallanma (branching) yapmak için geliştirilmiştir.
+
+Aşağıdaki dökümanlarda git-flow'un basit kullanımı anlatılmıştır. Daha detaylı kullanım için kaynakçada ki makale ve videoları izleyebilirsiniz.
+
+### Temel İpuçları
+
+* git-flow mükemmel bir komut satırı yardıma ve çıktısına sahiptir. Lütfen okuyun!
+* [Sourcetree](http://www.sourcetreeapp.com/) ürünü git-flow için gui sağlıyor. Eğer komut satırı ile aranız yoksa değerlendirebilirsiniz.
+
+### Kurulum
+
+Kurulum esnasında git-flow dal (branch), yayım (release), etiket (tag) ön ekleri ile ilgili size sorular sorar. Bunların hepsini boş bırakırak enter tuşuna başıyoruz.
+
+**OSX**
+
+`brew install git-flow`
+
+**Linux**
+
+`apt-get install git-flow`
+
+**Windows**
+
+Şaka yapıyorsunuz... *nix çekirdekli bir makine kullanın.
+
+### Başlayalım
+
+Havuza (repository) git-flow'un kurulması için  `git flow init` kodu koşuyoruz. Unutmayın git-flow için sizin önceden git havuzunuz olmalıdır.
+
+### Özellikler (Features)
+
+* Yeni gelen release için geliştiricilerin eklediği yeni özellikler için
+* Sadece mevcut develop havuzuna uygulanır.
+
+#### Yeni özellik ekleme
+
+* Diyelim ki size yeni bir görev verildi programa yeni bir özellik ekleyeceksiniz. O zaman develop dalından 
+
+`git flow feature start NEW_FEATURE` 
+
+kodunu çalıştıracaksınız. Bu kod size develop branchtan türemiş yeni bir dal varecektir.
+
+#### Yeni özelliğin bitirilmesi
+
+Yeni özelliği bitirilmesi
+
+* NEW_FEATURE dalını develop dalına birleştirir (merge)
+* NEW_FEATURE dalını kaldırır
+* Varsayılan dalı develop yapar
+
+`git flow feature finish NEW_FEATURE`
+
+#### Yeni özelliği yayınlama
+
+Eğer bu yeni özelliği birden fazla developer ile geliştiriyorsanız uzak sunucuyada göndermeniz gerekmektedir. Eğer sadece siz kodluyorsanız yapmayınız.
+
+`git flow feature publish NEW_FEATURE`
+
+#### Yayınlanmış bir özelliği alma
+
+Eğer bir geliştiricinin yayınladığı özelliği almanız gerekiyorsa
+
+`git flow feature pull NEW_FEATURE`
+
+yapmalısınız.
+
+### Yayım (release) yapma
+
+* Yeni ürünüzün producta hazırlamanızı sağlar.
+* Bu yapı ile ürünlerinize hotfix imkanı gelir ve yayım olunca otomatik etiketlenir.
+
+#### Yayıma başlama
+
+Yeni bir yayıma başlamak için git-flow'un `release` kodunu kullanırız. 
+
+`git flow release start RELEASE` 
+
+Örneğin `git flow release start 0.1.0` gibi
+
+Eğer aynı özellik gibi yayımıda yayınlamak isterseniz 
+
+`git flow release publish RELEASE` 
+
+yapmanız gerekmektedir.
+
+#### Yayımı bitirme
+
+Bir yayımın bitmesi git-flow için büyük bir iştir. Aşağıdakileri yapar.
+
+* release dalını master dalına birleştirir (merge)
+* master dalını etiketler (tag)
+* release dalını develop dalı ile birleştirir
+* ilgili release dalını siler
+
+### Düzeltmeler (Hotfixes)
+
+* Kullanılmakta olan bir uygulamada beklenmeyen hatalar oluşabilir. Bunların hızlı bir şekilde düzenlenmesi gerekmektedir.
+* Bu düzelmeler yeni bir versiyon ile tekrer sunucuya gönderilmelidir.
+
+#### Düzenlemeye başlama
+
+`git flow hotfix start VERSION`
+
+#### Düzenlemeyi bitirme
+
+`git flow hotfix finish VERSION` 
+
+### Komutlar
+
+* git flow init
+* git flow feature start NEW_FEATURE
+* git flow feature finish NEW_FEATURE
+* git flow feature publish NEW_FEATURE
+* git flow feature pull NEW_FEATURE
+* git flow release start RELEASE
+* git flow release publish RELEASE
+* git flow release finish RELEASE
+* git flow hotfix start VERSION
+* git flow hotfix finish VERSION
+
+**Kaynaklar**
+
+* https://github.com/nvie/gitflow
+* http://nvie.com/posts/a-successful-git-branching-model/
+* http://danielkummer.github.com/git-flow-cheatsheet/
+* http://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow
+* http://vimeo.com/16018419
+* http://vimeo.com/37408017