Kabul Kriterleri: Gherkin Formatı

Merhaba Arkadaşlar,

Bildiğiniz üzere user story'lerin temelde 3 bölümü vardır. Hikayenin tanımı - kabul kriterleri - bitimin tanımlanması. Şimdi Kabul Kriterleri kısmına bir alternatif oluşturan dil/model/format üzerinde duracağız: Gherkin Format/Language.

Malumunuz olduğu üzere, Kabul kriterleri müşterinin perspektifinden yapılır. Bunu en etkili kullanabileceğiniz formatlardan birisi de Gherkin yöntemidir. Kimilerine göre 3 kimilerine göre 5e ayrılır.

• Given
• When
• Then

Temelde bu 3leme üstüne kuruludur. Her bir adımda AND ile çoklayabilirsiniz. Bir de senaryoyu sayarsak, toplamda 5 yapar. Hatta daha da geliştirip daha fazla keyword kullanan da var. Evet, anlamsız gelen arkadaşlarım için adımları açıklayalım. :)

Given: description of the state of the system. Yani başlangıç durumudur. Senaryo için başlangıç noktası. 

When: customer or system action. Yani bir aksiyon alınması

Then: result of the action. When adımında alınan aksiyonun sonucu, çıktısı.

Hemen bir örnekle açıklayalım.

Örneğin ödeme sayfasında müşterilerin sorunsuzca ödeme yapabilmesi isteniyor olsun.

Given: Ödeme sayfasına girilmesi; müşterinin ödeme syafasında beklemesi

When: Müşteri ekrana, atıyorum, Krdi Kartı bilgilerini girmesi

Then: Sistemin müşteriye one-time-password(OTP) ile onay sms'i göndermesi.

Gördüğünüz gibi başarılı bir ödeme işleminde bir adımı, gayet düzenli ve anlaşılır bir şekilde kabul kriteri haline dönüştürebildik.

Görüşmek üzere.

Spotify Agile Organization - Spotify Çevik Organizasyonu

Merhaba Arkadaşlar,

Üzerinde mutabık olunamayan ama bazı firmalarca taklit edilen bir diğer Agile organizasyonu ise : Spotify Yapılanması. 

Önce kitabi kısmından bahsedelim, sonra neden itilaf oluşuyor kısaca ona değinelim.
Bir klasik haline gelen internetten resim alıntılama faslıyla başlayalım. :)

Spotify yapılanmasında da agile'daki gibi squad'lar ve bunların birer PO'su var. Tam olarak agile ritüellerini uygulamazlar. Scrum ya da kanban master'ları yoktur. Bir agile coach'a bağlıdırlar ve onunla çalışırlar.

Tribe denilen yapı, birbiriyle ilişkili olan birçok squad'ın bir araya gelmesiyle oluşan bir yapıdır. Yukarıdaki resimden de göreceğiniz üzere, bir tribe altında birçok squad ve her squad'ın da kendi Product Owner'ı vardır. Her tribe'ın da bir tribe leader'ı olmaktadır. Bir önceki yazımda bahsettiğim hiyerarşik bir yapı yok, Product Owner'lar arasında. Chief yok yani. PO'lar kendi aralarında işbirliği yaparlar. High-level bir roadmap üzerinde çalışırlar. Tribe'ın tüm PO'ları birlikte çalışır.

Chapter denen yapı ise, tribe altında, farklı squadlardan, benzer uzmanlığı bulunan kişilerin bilgi paylaşımı ve çözümler için oluşturdukları yapılardır. 

Guild'ler ise farklı tribe'lardan da katılanılan, daha genel, workshop veya atölye tarzında, isteyenin katılabidiği daha genel bir bilgi paylaşımıdır. Chapter'da örneğin arayüz geliştiricileri toplanmıştır. Guild ise tüm geliştiriciler gibi düşünebilirsiniz.

Gelelim bu yapıya yapılan itirazlara. :) Kurumların bu yapıya geçerek, sadece squad ya da direktörlük isimlerini değiştirerek, bu modeli uyguladığını sanmaları en büyük yanlışlardan birisi. Yani bu model size isimlerinizi değişitirip yola devam edin demiyor. 

Bir diğer sıkıntı da, bu model ya da yapılanma, Spotify firmasına göre yıllar içinde tecrübe edilen, denenen bir yapı. Bir modeli alayım, aynısını kullanayım çok başarılı bir yol olmaz. Bunu baz alıp firmalar kendilerine uyarlamadığı sürece, çok da başarılı olmayabilir. Örneğin, scrum master kullanıp da bu yapıyı deneyenler var. :)

Ve bu modelin arkasında Spotify'ın kendi organizasyonel ve kurum kültürü de var. Çalışanlara düşünmeleri eğlenmeleri için verilen zamanlar; hataların pişkince yüze vurulmasından ziyade, denemenin göstergesi olduğu inancı vs vs. Tüm bunları alt alta koyduktan sonra bu model daha anlamlı olacaktır.

Sonra görüşürüz.

Chief Product Owner

Merhaba Arkadaşlar,

Chief Product Owner nedir, ne değildir'i kısaca sizinle de paylaşmak istiyorum. Önce bir adım geri gidelim. Agile mantalitesinde, biliyorsunuz, bir product owner-scrum master-development team yer alır. 

Normalde product owner'lar, kitabi terimle anlatmak gerekirse, ürünün değerini arttıran ve bunu da dev team ile çalışarak yapan kişidir. 

Buraya kadar sorun yok. Soru tam olarak şu: " Tek bir Product Owner'ın başa çıkabileceğinden daha büyük bir ürün varsa ne olacak? ( what happens when the product ise too large for a single product owner?)

Bir diğer soru da şu: Tek bir ürün üzerinde çalışan birçok takım varsa ne olacak? ( what happens when you have dozens of teams working on a single project?)

Tam da böyle durumlara karşı, agile organizasyonel yapılanmasında bir kavram karşımıza çıkıyor: Chief Product Owner. 

Chief Product Owner, daha üst seviyeden kararlar alabilen, takım product ownerlarının kendisine bağlı olduğu ve bu takım product owner'larına yön veren kişidir.

Bu yapılanmadaki anahtar kelime HİYERARŞİ'dir (hierarchical organization). Burada ast-üst olayı var yani.  İnternetten yine hazır bir resme kondum; kendim çizmedim, onu paylaşayım sizlerle.

Yani daha üst seviye olaylara bakan, stratejik kararları veren, ürünün nereye gideceğini belirleyen ve hatta bunun için karar verici paydaşlarla görüşen kişidir. Takım PO'su gibi detaylarla ilgilenmez.

Sonra görüşürüz.

Çocuğumu Hangi Okula Göndermeliyim?

Merhaba Herkese,

Her zaman bilişim ile ilgili yazı yazamayabilirim. :) Benim gibi çocuğunu okula gönderme konusunda başlangıç noktasında olan, yön almak isteyen veya neler yaşandığını duymak isteyen arkadaşlarımız vardır diye yazmak istedim. Zira ben her yazılanı tek tek okudum. :)

Öncelikle ben ilkokul aradım. Aklınıza gelebilecek her şeyi okudum; size de tavsiye ederim: "okul seçerken nelere dikkat etmeliyim", "okul seçimindeki kriterler nelerdir", "doğru okulu nasıl bulmalıyım" vs vs. :)

Her şeyi dinleseniz de mutlaka potansiyel okullarınıza gidin sevgili arkadaşlarım. Bir defa okulu görün. Yerini, muhitini görmeniz iyi olacaktır. Herkesten duyacaksınız, ilkokul seçimi aslında öğretmen seçimidir. Yüzde yüz haklıdır da. Ancak kişisel görüşüm bununla sınırlandırmamak yönünde. Birçok okul gezdim. Hepsinde müdür ve müdür yardımcılarıyla görüştüm. Evet belki haddim değil, belki yanlış bir bakış açısıdır ama konuştuğum idarecilerden dolayı elediğim okullar oldu. İletişime açık olmamaları veyahut konuşmaları benim o okulları direkt elememe yol açtı. Bunun yanında bahçesi bile olmayan okullar türemiş; örneğin bu bile bir kriter olabilir. Salgın süreci olmasa, okul aile birlikleri aslında tek adresiniz olmalı. Okul aile birliğindekiler size okul nasıldır, hangi öğretmenler sevecen, hangileri çocuklar üstünde otorite deniyor vs her şeyi anlatıyorlar. Şanssızlıktır ki, bu süreçte bulmanız kolay değil. 

Okulların yan aktiviteleri/dersleri de önemli. İsteyene satranç isteyene halk oyunları gibi birçok ilave ders olması da önemli. Bunun için küçük bir maddi destek gerekebilir. Bunun dışında güvenlik, hemşire, temizlik gibi konular da kriterlerden sayılabilir. 

Yaşadıklarımı yazmak istedim; benim durumumdaki arkadaşlarımın işine yaraması dileğiyle. :)

İyi Geceler

Linux'ta Ortak Disk Sorunu ve Yama Çözüm

Merhaba Arkadaşlar,

Windows ya da Linux fark etmeksizin, uygulama makinalarınız ortak diskleri görüyordur. NFS ya da CIFS kullanıyor olabilirsiniz. Buradaki amaç, uygulamalarınızın ortak dosyaları görebilmesidir. Örneğin, sözleşme gibi önemli bir dosyayı bir uygulama sunucusundan ekrana bağlandığınızda görüp, diğerindeyken görememeniz kabul edilemez. Veyahut bir web siteniz vardır; bir kullanıcı arayüzden girip, siteye resim yüklemiştir. Bir başka kullanıcı başka bir makinaya düştüğünde o resimi göremezse, takdir edersiniz ki çok saçma olur. Ortak diskler bunun için vardır. Bunun da çok detayı vardır. IP bazlı, kablolu vs diye ama ona girmeyeceğim, asıl konum bu diskler değil zira.

Diyelim ki ortak diskte bir sorun var. Tabi ki storage ekibiniz hızlıca müdahale edecektir. :) Ancak storage ile uygulama farklı networktedir ve network sorunu vardır vs vs. Böyle durumlarda kısmet deyip beklemek kabul edilemez takdir edersiniz ki. =) Böyle durumlarda, uygulama üstünde ortak diski, herhangi bir uygulama sunucusu ile değiştirmeniz gerekiyor. Akabinde sunucuları sync etmelisiniz. Yani hangi sunucudan döküman, nesne yüklenirse yüklensin, hızlıca sizin belirlediğiniz, ortak disk olarak hizmet verecek uygulama sunucusuna bunları göndermeniz gerekecektir. Bunu da linux'taki rsync komutu ile yaparız. 

Örnek komut satırı:

rsync -avhz /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/uploads makina2:/gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/

Uploads altında ne varsa, ikinci makina altına atmış olacaksınız. Tüm uygulama sunucularınızda bu scripti çalıştırıp, shell olarak kurarsanız, düzenli olarak atmış olursunuz. 

Yazıyı bitirmeden de çok kısa rsync komutuna değineyim, daha önce kullanmamış arkadaşlarım için. Rsync komutu bu şekilde, dosya transferi, günlük delta backuplar, incremental backuplar gibi, farkları bulup, onları kopyalayan bir komuttur. 

rsync -parametreler kaynak hedef  şeklinde bir notasyonu vardır.

Yukarıdaki örneğimde kaynak: /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/uploads 

hedef: makina2:/gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/

Burada iki farklı makina yerine, aynı makina içinde yapsaydım, hedefte makina2'yi ayrıca belirtmeye gerek kalmazdı. Bu durumda hedef: /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/ olurdu.

Kullandığım parametreleri ise şöyle:

-a dosya veya diizne ait her şeyi arşivleyerek taşır(rol-izin-mtime gibi)

-v yaptığımız işlemin detayını ekranda, konsolda görmemizi sağlar.

-h bizim okuyabileceğmiz bir çıktı oluşturur(Human readable)

-z dosya ya da dizini sıkıştırarak alır.

Sonra görüşürüz.

Web Sitenizde Otomatik Restart Shell Scripti

Merhaba Arkadaşlar,

Web sitesi işlerinde çok temel seviye dedim ama sonuçta shell işlerinde o kadar da yeni değiliz. :)))
Başıma gelen bir olay ve nasıl bir ara çözüm uyguladığımı paylaşacağım. Elimdeki web sitesi çok temel seviyede olan, caching'i zayıf denebilecek, yüksek trafikleri kaldıramayacak basit bir mini site idi. Ancak bir şekilde web siteme aşırı yük geldi. :)

Eğer sizin de web sitelerinize fazladna yük geldiyse ve/veya web sitenize restart atmak isterseniz aşağıdaki gibi ilerleyebilirsiniz.

Öncelikle apache altında, executables'larınız her nerdeyse, altında bir sh dosyası oluşturmalısınız. Örneğin apache/exec altında olsun.

1. oto_restart.sh oluşturun.

2. İçine şunları yazın:

./stop-apache-WS    (sizin apacheyi kurarken apache stop scriptiniz her neyse, onu yazarsınız)

sleep 3                      (3 saniye bekle dedik, ki tüm processler kill olsun)

./start-apache-WS    (sizin apacheyi kurarken apache stop scriptiniz her neyse, onu yazarsınız)

3. chmod +x oto_restart.sh    (yetkilendirmenizi yaparsınız)

4. while [[ 0 -ne 1 ]]; do ./oto_restart.sh;   sleep 300; done  yazıp çalıştırabilirsiniz.

Bu sayede 300 saniyede bir oto_restart.sh çalışmış olacak. Yani 5 dakikada bir restart etmiş olacaksınız. Böylece site down olmayacaktır. Tabi bu işlemi yaparken db'nin durumunu da gözlemlemeniz iyi olacaktır.

Bu mantıkla web sitenizi de auto restart atabilirsiniz; herhangi bir apache platformunuzu da otomatik olarak restart edebilirsiniz. Genel mantık bu şekilde.

Sonra görüşürüz.

     

Web Sitenizin Internet Explorer Uyumluluğu

Selam Arkadaşlar,

Web sitelerinde benim gibi çok temel seviye bilgi sahibi olan arkadaşlarım ve ileride unutursam diye kendim için paylaşım yapmak istedim. :)

Şayet web sitenizin internet explorer ile açıldığında, bozuk olduğunu, kaydığını vs gördüyseniz, bu IE Uyumluluk için ufak bir ilave yapmanız gerektiğini söyler. Örneğin bazen çalıştığınız firmalar, kurumsal olarak eski Internet Explorer'ı policy üstünden makinalara yüklemiş olabilir. Bunu aşmak ve web sitenizin düzgün çalışması için:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

IE=edge ile, en son IE versiyonuyla uyumlu hale getiriyormuşuz. Bu satırı benim sitem php olduğundan, header.php altına attım. <head> etiketleri arasına koymanız gerekiyor.

İyi Akşamlar herkese.

Performance Monitor (PerfMon)

Merhaba Arkadaşlar

Geçen yazımda performance monitor ile ilgili yazıma gelen soruya istinadeni perfmon'un mantığına kısaca değineceğim. PerfMon özetle sunucunun perfomans verilerini toplayabildiğimiz, izleyebildiğimiz, loglatabildiğimiz bir uygulamadır. 

Performance Monitoring'te 3 seviye vardır:

1.Object

2.Counter

3.Instance

Örnekle açıklayalım: Processor bizim objectimiz(nesne) oluyor. İçinde bir sürü counter(sayaç) var. Örneğin ben Interrupt Time'ı seçtim. Counterımız Interrupt Time oldu yani. Altında da instance olarak herhangi bir processor'ı seçebiliriz. Bunlar da instance oluyor. 

Hep bu 3 seviye olmak zorunda değil. Örneğin memory objectimizi seçersek, altında available bytes counter'ını seçebiliriz. Göreceğiniz üzere, altında instance yok. 

Önceki yazımda Data Collector'u anlattığım için ona burada değinmiyorum. En temel anlatımı bu şekildedir. Bundan sonrasını kullanabilmek için tek tek objectleri ve counterları bilmek lazım ki, o da biraz tecrübeyle olacak iş. Ben de kendi kullandıklarımı ara ara paylaşmaya çalışacağım.

Şimdiden herkese iyi bayramlar.

Word'de İçindekiler Sayfası Oluşturmak

Merhaba Arkadaşlar,

Bu yazıda Microsoft Word'de İçindekiler sayfasının nasıl yapılacağına değineceğim. Eskiden manuel yapılırdı bu fihrist ya da sayfa indeksleri. Ancak uzunca bir süredir Word'de bu işlemi otomatik olarak yaptırabiliyoruz.

Öncelikle deneme için uzunca bir yazı gerekiyordu. Lorem Ipsum'dan ödünç aldım tabi ki. :)

30 paragraflık bir yazıyı word'ün içine koydum. Aralara Başlık 1 - Başlık 1.1 gibi başlıklar uydurdum.

Bu işteki en kritik bilgi, kendi başlıklarınızı Microsoft Word'e, başlık olarak tanıtmanız. Bunu yapmanın en kolay yolu da, Word'de Home dizinindeyken, Heading kullanmak. Başlıklarınızı Heading1 yapmalısınız. Örneğin başlığınızın da alt başlığı olacaksa, alt başlıklara da Heading2 diyeceksiniz. Alt başlığın da kendi alt başlıkları varsa, onlara da Heading3 diyeceksiniz; bu böyle gider.

Şimdi İçindekiler Sayfamızı yapalım. Boş bir sayfaya gidip: References (Başvurular) --> Table of Contents (İçindekiler Tablosu) seçilir. Ve oradan Automatic Table (otomatik tablo) 'dan birini seçersiniz. 

İçindekiler Sayfamız hazır. Burada atlanmaması gereken nokta, diyelim ki sayfalar değişti. Başka başlık geldi veya sayfada kaydırma oldu. İşlem çok basit. Ben şimdi sayfa 8in alt maddeleri ile 9'u biraz öteleyeceğim.(enter ile aşağıya atacağım).

Yapmanız gereken İçindekiler kısmına bir defa tıklayıp, Update Table demeniz. Tüm değişimi direkt tabloya yansıtır. Update table deyince, bir de soru sorar, sadece sayfa numaraları mı, tüm tablo mu diye. Sırf tablodaki sayfanın yeri değiştiyse, sadece sayfa numarası demeniz yeterlidir ama ben genelde tüm tabloyu seçmenizi öneririm. Ne değiştiyse, otomatik olarak gider bulur ve yansıtır.

Sonra görüşürüz.

IIS CPU Settings

Merhaba Arkadaşlar,

Bu yazımızda, IIS üzerindeki istediğiniz uygulamamız için Advanced Settings altındaki CPU sekmesini açıklayacağım. Burası önemli alanlardan birisi. O nedenle ayrı başlıkta paylaşmak istedim.

IIS'i açın. Application Pool'lara girip, hangi uygulamanın app pool'unu isterseniz onu seçin.

Sağ panelden Advanced Settings'e tıklayın. Artık birçok ayarı yapabileceğimiz panele geldiniz. Biz bu yazıda CPU kısmına değineceğiz.

Limit: Uygulamanız kendisine tahsis edilen CPU'nun ne kadarını kullansın demektir bu. Genelde 0 yazar. 0 yazdığınizda, cpu'yu limitleme demiş oluyorsunuz; yani tahsis edilenin tüm CPU'yu(%100) kullan diyorsunuz. Şimdi burayı her yerde okumuşsunuzdur ama bu alanın nasıl kullanabileceğini konuşalım. Diyelim ki, bir uygulamanız var ve cpu'su IISi aşağı indiriyor ve sürekli IISi ayağa kaldırmakla uğraşıyorsunuz. Eğer uygulamanıza cpu limiti koyarsanız, nispeten daha kontrol altında tutabilirsiniz. Ki normal şartlarda hiçbir uygulama %100e vurdurmamalıdır. Eğer böyle bir durum varsa, ya leak vardır ya da debug modda log açılmıştır veyahut farklı kod defecti vardır. 

Varsayalım ki %70 koymak istiyorsunuz. Bu limit aşıldığında ne yapılacağını belirleyebilirsiniz. Bunun için de sizi ikinci alana davet ediyorum(Limit Action)

Limit Action: Yukarıda bahsettiğim gibi, limiti koydunuz. Ve o limite gelindi. Bu durumda hangi aksiyonun alınmasının karar verilmesi gerekiyor.

a)No Action: En masumudur. Limit aşıldığında, hiçbir şey yapma demektir. :)

b)KillW3wp: Eski versiyon IISlerin vazgeçilmezidir. :) Diyelim cpu %70e geldi. App pool'u kill eder. Limit interval da kontrol ediyor o an. Bir sonraki limit interval kontrolüne kadar app pool öyle kalır.

c)Throttle: CPU limite geldi mi, peşinden gelen istekleri bekletir. Daha fazla cpu kullanamaz uygulamanız, cpu boş da olsa dolu da olsa.

d)ThrottleUnderLoad: Throotle gibi CPU'ya herhangi bir kısıt getirmez. Eğer CPU boş ve kullanabilir duurmdaysa, rahat bir şekilde CPU kullanırsınız. Ancak cpu limitine ulaşılırsa, CPUyu limitle kısıtlar. Yani adı gibi, sadece load altında throttle. :)

Limit Interval: İlk resimde 5 yazıyordu örneğin. 5 dakikada bir IIS'te cpu kontrolü yapılacak demektir. KillW3wp ile genelde kullanılır. Throttle ve ThrottleUnderLoad ile kullanılmaz. Kill edilen uygulamayı manuel start vermeniz iyi olacaktır. Yoksa 5 dakika dolana kadar IIS worker processi kill edilmiş şekilde durur. 

Processor Affinity Enabled: Diyelim ki 32 core cpu'unuz var. İlk 6 tanesini kullan, gerisini kullanma diyebilirsin, server sağlığını düşünüp. False derseniz, tüm cpunuzu kullanıma açarsınız. Bu durumda diğer iki değerin önemi yoktur. True derseniz, sizi aşağıya alalım. :)

Processor Affinity Mask: Hem bu arkadaşın hem de bir altındaki "64-bit option" olanın default(varsayılan) değeri 4294967295 'tir. İlk resimde bu nedenle o değeri görüyorsunuz. (2^32 -1 değeridir) Uygulama hangi processora bağlanıp çalışsın onu belirliyoruz. 1 dersek, ilgili IIS workerprocess'i birinci cpu'da çalışacaktır. Binary gösterimi: 00000000000000001  (2 üzeri 0)

2 dersek, ikinci processor'da çalışacaktır. Binary gösterimi: 00000000000000010 (2 üzeri1)

3 dersek, hem 1 hem de 2nci processorda çalıaşcaktır. Binary gösterimi: 00000000000000011 (2 üzeri 0 ve 2 üzeri 1'in toplamı)

Sonra görüşürüz.