Ethereum Private POA (Proof-of-Authority) Network Kurmak

Blockchain üzerinde kurumsal uygulamalar oluşturmak için en çok kullanılan Blockchain teknolojilerinden birisi olarak Ethereum karşımıza çıkıyor. Çok kullanılmasının en önemli nedenleri programlanabilir olması, hem data hemde para’yı (Value) tutabilmesidir. 

Tek bir Ethereum adresinde ayrı ayrı birimlerden ör: USD,TL,EUR gibi düşünülebilir para tutulabiliyor, bu ise operasyonların tek bir adres üzerinden yapılabilmesinden dolayı önemli bir esneklik sağlıyor. Yani size para gönderecek birisinin adresinizi ve hangi birimden para göndereceğini bilmesi yeterli oluyor.

Kurumsal uygulamalarda Ethereum network’ü kurmak için dikkat edilmesi gereken en önemli husus consensus mekanizmasının doğru kurulmasıdır. Consensus türkçeye çevirirsek fikir birliği mekanizması demektir. Yani oluşturulan blokların nasıl oluşturulacağının ve zincire kabul edilebilmesinin şartlarının ne olacağının kararının verilmesidir.

Enerji sarfiyatının minimuma indirilmesi için consensus mekanizmasının doğru seçilmesi gerekmektedir. Private network tarafında kullanılan consensus mekanizması Proof-of-Authority olarak kurulmalıdır. Ethereum engine olarak Clique engine kullanılmalıdır.

Private network olarak adlandırılan bu networkler genellikle bir kurum tarafından kullanılmak için veya birden fazla kurumun aralarında kullanmak için kurdukları network’tür. Dışarıdan müdahelelere kapatılması veya sınırlandırılması gerekmektedir.

Proof-of-Authority mekanizmasında Bloklar  miner(madenci)  olarak çalışan düğüm tarafından oluşturuluyor. Networkü ayağa kaldırırken(genesis.json içerisinde) blokların Chain'e (zincire) eklenebilmesi için birden fazla node(düğüm) tarafından onaylanmasını isteyebilirsiniz.  Bu düğümlere sealer deniyor. Yani imzalayan mühürleyen anlamında. Bu mühürler olmadan blok ethererum zincirine eklenmiyor. Örnek vermek gerekirse bir kişi A bankasından işlem yapıyor ve işlemin gerçekleşmesi içinde B bankasının onayı gerekiyor. A bankasını ve B bankasını network'te sealer olarak tanımlarsanız A bankası bloğu oluşturup yollasa bile B bankası onaylamadan işlem gerçekleşmiş sayılmaz. Doğal olarak B bankası onaylayınca ilgili işlem gerçekleşir. Hatta araya birde merkez bakası gibi bir mekanizma koyup merkez bankası onaylamadan işlem  gerçekleşmez derseniz merkez bankasını da sealer olarak tanımlamalısınız.  Gördüğünüz gibi işlemler onaycılar mekanizmasından geçtikten sonra zincire ekleniyor ve gerçekleşiyor. İşin güzel tarafı bütün bunlar gerçekleşirken çok karmaşık yapıların mimarilerin içinde boğulmanıza gerek kalmıyor. Sadece bir düğümü ayağa kaldırmak ve network'e dahil etmek yeterli oluyor.

Ben kurulum yaparken resmi Ethereum implementasyonlarından Go dili ile geliştirilen Go Ethereum implementasyonunu kullandım. Go Ethereum kurulumunu https://ethereum.github.io/go-ethereum/install/ adresinden takip edebilirsiniz. 

Private network kurmak için öncelikle genesis.json dosyasını oluşturmalısınız. genesis.json dosyası düğümler ilk ayağa kalkarken ihtiyaçları olan configurasyonu vermeniz içindir. 

Genesis.json dosyasını oluşturmak için puppeth kullanabilirsiniz.  Github üzerinden puppeth https://github.com/puppeth/go-ethereum kodunu indirip build ederseniz puppeth için çalıştırılabilir dosya oluşmuş olacaktır.

Ben MACOS üzerinde çalıştığım için komutları ve kurulumları MACOS'a göre yaptım. Linux kurulumlarıda aşağı yukarı aynı şekilde yapılıyor belki windows üzerinde ufak farklılıklar olabilir. 

https://github.com/puppeth/go-ethereum  indirdiğim kodu build edip bin klasöründe ihtiyacım olan dosyaların oluştuğunu gördüm. Burada dikkat etmeniz gereken birkaç noktayı söyleyeceğim. Go implementasyonunu indirdiğim için build yaparken Go engine'e ihtiyacınız olacaktır. Öncesinde

brew install go

komutu terminalde çalıştırarak go kurulumu yapmanızı öneririm. problem çıkarsa sudo ile denemenizi öneririm.

Ben yıllarca windows üzerinde çalıştığım için MACOS üzerinde bunları yaparken biraz zorlanıyorum eğer linux üzerinde  çalışıyorsanız  bunlar sizin için çocuk oyuncağı olacaktır.

terminal üzerinde  go ethereum/build/bin klasöründe puppeth'i run ediyorum.

L52850MAC:~ osmansonmez$ cd go-ethereum/build/bin

L52850MAC:bin osmansonmez$ puppeth

Network name'i girip devam ediyorum. İsim olarak newgenesis veriyorum.

2. seçenek ile devam ediyorum.

1. seçenek ile devam ediyorum.

2. seçenek ile yani proof-of-authority seçeneği ile devam ediyorum.

ve kalan sorulara  devam ediyorum. ilk soru blok üretme süresi ne kadar olacak yani kaç saniyede bir blok üretilecek ben 5 saniye olarak veriyorum. 2. soru ise hangi hesaplar sealer olacak. Yani A bankası ve B bankasının public key'leri yani adreslerini burada gireceğiz. bunun için 2 tane ethereum adresi oluşturmamız gerekiyor. 

Adres oluşturmak için ethereum go'nun geth komutunu kullanacağız. Bunun için yeni bir terminal açmamız lazım. Terminalde geth komutları ile 2 adet ethereum hesabı oluşturacağız.

Ethereum hesabı oluşturmak için kullanacağımız komut geth account new komutudur.
komutu terminalde yazdığımızda bize hesap için şifre sormaktadır.  şifreyi girdikten sonra bize hesabı oluşturmaktadır.

ikinci adreside aynı şekilde oluşturalım ve bunları puppeth'a girelim.
Adres 1 :df6cc60abfdfdef40be53c75962b666a9febd3ef
Adres 2 :29e97a93c40d91a6cc86a03668bebecc3b989494

Tekrar puppeth ekranına dönelim.

puppeth üzerinden iki adet hesabı sealer yaptık aynı zamanda bu iki hesaba sabit olarak bir miktar ethereum yüklemesini söyledik.

Devam eden sorular başka prefunded hesaplar olacak mı bu soruya no yanıtını verdim ve benden network Id 'yi istedi. NetworkId olarak 1881' i verdim.  NetworkId değeri aynı network'e dahil olmak isteyen node'lar için önemli bir değerdir.

Daha sonra Manage existing genesis ve Export genesis configuration seçenekleri ile devam edilirse
puppeth içerisinde yer alan default klasöründe newgenesis.json dosyasının oluştuğunu göreceksiniz ve içeriği aşağıdaki gibi olacaktır.

{

  "config": {

    "chainId": 1881,

    "homesteadBlock": 1,

    "eip150Block": 2,

    "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",

    "eip155Block": 3,

    "eip158Block": 3,

    "byzantiumBlock": 4,

    "constantinopleBlock": 5,

    "clique": {

      "period": 5,

      "epoch": 30000

    }

  },

  "nonce": "0x0",

  "timestamp": "0x5c8e4466",

  "extraData": "0x000000000000000000000000000000000000000000000000000000000000000029e97a93c40d91a6cc86a03668bebecc3b989494df6cc60abfdfdef40be53c75962b666a9febd3ef0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",

  "gasLimit": "0x47b760",

  "difficulty": "0x1",

  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",

  "coinbase": "0x0000000000000000000000000000000000000000",

  "alloc": {

    "29e97a93c40d91a6cc86a03668bebecc3b989494": {

      "balance": "0x200000000000000000000000000000000000000000000000000000000000000"

    },

    "df6cc60abfdfdef40be53c75962b666a9febd3ef": {

      "balance": "0x200000000000000000000000000000000000000000000000000000000000000"

    }

  },

  "number": "0x0",

  "gasUsed": "0x0",

  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"

}

newgenesis.json dosyasını oluşturduk. Aslında işin en büyük kısmını tamamladık sayılır. Artık 2 node'lu network'ü ayağa kaldırmak kaldı. Ben tamamını localde ayağa kaldıracağım. Dilerseniz kubernetes, docker veya openshift ortamında da ayağa kaldırabilirsiniz. Ben çok uzatmamak adına ilk etapta local'de ayağa kaldıracağım.

Öncelikle boot node ayağa kaldıracağım. Boot node nedir?

Boot node network'te bulunan node'ların birbirlerini bulabilmeleri için ayakta olan kayıt nodu'dur.

Herhangi bir transaction veya miner rolü yoktur. Esasında olay ayağa kalkan herhangi bir node'un  boot node'a ben burdayın diye haber vermesidir.

Yeni bir terminal açıp boot node'u ayağa kaldıralım.

komutlar : 

1- bootnode -genkey boot.key

2- bootnode -nodekey boot.key -verbosity 9 -addr :30304

Komutları yazdıktan sonra  localde 30304 portundan boot node ayağa kalkmış olacaktır. 

bootnode bilgisini  diğer node'larla paylaşmak için enode adress bilgisini oluşturmamız gerekiyor.

enode bilgisi aşağıdaki gibi bir bilgi olmalıdır.

"enode://<your node public key>@<your node public ip>:30304"

node public key bilgisini aşağıdaki gibi oluşturmalıyız.

boot.key dosyasını vererek aşağıdaki komutu çalıştıralım.

bootnode -nodekey boot.key -writeaddress

komutu çalıştırınca bize yeni bir public key oluşturacaktır.

b19a42e8bf96953a0e365fbfbea7fba8aab55a057c086d12bd8584115e6e8b66e9a98d739e021eba2fb4b6f3eb451ffeef1287950cd596a80c88fbddc26ea6dc

yani boot node adresimiz:

enode://b19a42e8bf96953a0e365fbfbea7fba8aab55a057c086d12bd8584115e6e8b66e9a98d739e021eba2fb4b6f3eb451ffeef1287950cd596a80c88fbddc26ea6dc@127.0.0.1:30304

şeklinde olacaktır.

Şimdi Node'ları ayağa kaldıralım. Bunun için iki adet farklı klasöre ihtiyacımız olacaktır.

Node1 ve Node2 olarak 2 adet klasör açalım.

ilk komutumuz ilk node'u  yani Node1'i başlayacan konuma getirmek olacaktır. Burada daha önce oluşturduğumuz newgenesis.json dosyası gerekli olacaktır.

newgenesis.json dosyasını node1 ve node2 klasörlerine kopyalayalım. 

yeni bir terminal açalım ve node1 ve node2'yi ayarlayalım.

komut1 : geth --datadir node1/ init node1/newgenesis.json

komut2:  geth --datadir node2/ init node2/newgenesis.json

Komutları çalıştırınca node1 ve node2 klasörlerinde geth, keystore gibi klasörlerin oluştuğunu göreceksinizdir.

şimdi node'ları ayağa kaldırma zamanı:)

Hatırlıyorsanız 2 node'u  sealer olarak oluşturacaktık ve ilk başta newgenesis.json dosyasını oluştururken 2 adet ethereum hesabı oluşturmuştuk. Hesapları oluştururken 

şifre vermiştik. Şimdi node'ları ayağa kaldırırken bu hesapların bilgileri ve şifresi gerekiyor. Sebebi ise node transaction'u onaylarken vereceğimiz hesap ile onaylayacak. Yani mühürleyecek.

Hatırlıyorsanız hesapları geth komutu  ile oluşturmuştuk. hesaplar oluşunca geth'in kurulduğu ethereum klasöründe  bulunan keystore  klasöründe hesapların bilgilerinin hesap ismiyle bir dosyada tutulduğunu göreceksinizdir. 

29e97a93c40d91a6cc86a03668bebecc3b989494 hesabının keystore dosyasını node1/keystore altına,

df6cc60abfdfdef40be53c75962b666a9febd3ef hesabının keystore dosyasını node2/keystore altına kopyalayalım.

node1/ ve node2/ altında bu hesapların şifrelerini tutmak için password.txt isimli bir dosya oluşturalım ve ilgili hesabın şifresini bu dosyaya yazalım.

Node1'i ayağa kaldırmak için komutu oluşturalım.

geth --networkid 1881 --datadir "node1/" --bootnodes 'enode://b19a42e8bf96953a0e365fbfbea7fba8aab55a057c086d12bd8584115e6e8b66e9a98d739e021eba2fb4b6f3eb451ffeef1287950cd596a80c88fbddc26ea6dc@127.0.0.1:30304  --port  30305 --ipcdisable --syncmode full --rpc --rpcaddr 0.0.0.0 --rpccorsdomain "*" --rpcport 8546 --unlock 29e97a93c40d91a6cc86a03668bebecc3b989494 --password node1/password.txt --mine  --keystore 'node1/keystore' console

komutu çalıştırınca node1 ayağa kalkar fakat herhangi bir mine işlemi yapmadığını ve blok oluşturmadığını göreceksinizdir.  Sebebi ise bütün sealer node'ların ayakta olmamasıdır.

ikinci sealer node yani node2'yi ayağa kaldıralım.

geth --networkid 1881 --datadir "node2/" --bootnodes 'enode://b19a42e8bf96953a0e365fbfbea7fba8aab55a057c086d12bd8584115e6e8b66e9a98d739e021eba2fb4b6f3eb451ffeef1287950cd596a80c88fbddc26ea6dc@127.0.0.1:30304'  --port  30306 --ipcdisable --syncmode full --rpc --rpcaddr 0.0.0.0 --rpccorsdomain "*" --rpcport 8547 --unlock df6cc60abfdfdef40be53c75962b666a9febd3ef --password node2/password.txt --mine  --keystore 'node2/keystore' console

İki adet sealer node ayağa kaldırdık. İsterseniz bir tanede transaction node ayağa kaldıralım. Yani mine işlemi yapmasın.

geth --networkid 1881 --datadir "node3/" --bootnodes 'enode://b19a42e8bf96953a0e365fbfbea7fba8aab55a057c086d12bd8584115e6e8b66e9a98d739e021eba2fb4b6f3eb451ffeef1287950cd596a80c88fbddc26ea6dc@127.0.0.1:30304'  --port  30307 --ipcdisable --syncmode full --rpc --rpcaddr 0.0.0.0 --rpccorsdomain "*" --rpcport 8548 --unlock console


2 adet miner bir adet transaction node ile  networkümüzü kurmuş bulunuyoruz.

Networkü kurarken ufak tefek problemlerle karşılaşmış olabilirsiniz ama yinede yılmadan çalıştırmaya çalışınız bir problem yaşarsanız lütfen sonmezosman@gmail adresine istediğiniz zaman mail atabilirsiniz.

.Net Core, MACOS ve JetBrains Rider

Bildiğimiz gibi .NET Core ile birlikte .NET ile kod geliştirmek işletim sistemi  bağımsız hale geldi. Durum böyle olunca yazdığımız kodları Linux ve MACOS ortamında çalıştırmak .NET geliştiricileri için büyük bir avantaj haline geldi.

.NET Core maceramız nasıl başladı ilk olarak oradan başlayayım. .Net 4.5.2 ile geliştirdiğimiz bir projemizi microservis olarak yazmaya karar verdik. .NET framework ile devam etmek yerine .NET Core ile yazıp yazamayacağımızı araştırdık. Projenin 3. parti dll bağımlılığı vardı ve firma .NET CORE versiyonunu çıkarmamıştı. 2019 'da çıkaracağız diye cevap döndüler. Mecburen .NET 4.6.1 ile geliştirmeye başladık. Microservisleri ise mecburen Service Fabric ile çalıştırmayı planladık. Üzülerek söylüyorum ki Microsoft firmasının geliştirdiği .NET framework'un sadece windows ortamında çalışmasından dolayı microservis projemizi mecburen yine microsoftun sunduğu platformda koşturmak durumundaydık. Openshift windows desteğini henüz sağlamamıştı (2019 başında cıkacak demişlerdi).  Projenin ilk sürümünü .NET 4.6.1 ile çıkardıktan sonra ekip olarak bu kadar platform bağımlı olmak çok da içimize sinmedi.  Madem böyle bir proje yapıyoruz, microservis ve container yapısı bizim içinde yeni ve güzel bir tecrübe oluyor platform bağımlılığından bir şekilde kurtulup yazdığımız kodları istediğimiz ortamda  çalıştırıp denemeliyiz diye düşündük. İşe ilk olarak 3. parti kullandığımız dll'leri decompile yapıp .NET standart projesine dönüştürmeye çalışmakla başladık. İlk başta kuşkuluyduk fakat decompile işlemlerini başarılı bir şekilde yaptıktan sonra ve .NET Standart projelerini oluşturunca, bütün projeyi .NET CORE ile yeniden yazmaya cesaretimiz arttı. Decompile işlemlerinde .NET framework ortamında olup .NET Core ortamında olmayan kütüphaneler olabiliyor bunların denklerini (open source kütüphaneler) bulmalısınız veya yöntem değişikliğine gitmek zorunda kalabilirsiniz. Microservis projemizi .NET Core ile geliştirmeye başladık. Ekipteki herkes .NET Core'da  yeni olmasına rağmen büyük bir iştahla bir çok konuyu araştırıp en iyisini yapmaya çalıştık.  Projenin ilk çıktılarını Openshift  platformunda Redhat Linux ile çalıştırdık. Windows'ta kodladık Linux ortamında çalıştırdık. İşletim sistemi bağımsızlığı gerçekten güzel birşeymiş. .NET CORE geliştiricilerine teşekkürler. Tabii işletim sistemi bağımsızlığı gelince geliştirme işini de  diğer  işletim sistemlerinde de denemeye karar verdik. İlk olarak MACOS ile başladık.  MACOS ortamına da oldukça yabancıydık.  Windowsa alışınca MACOS ve Linux biraz korkutucu geliyor.  Bazılarınızın ne gerek var dediğini duyar gibiyim ama  bende şimdiye kadar bu kadar windows  bağımlısı kaldığım için  bir developer olarak kendimden utanıyorum diyorum. Birçok platforma hakim olmamız gerektiğini şuan rahatlıkla söyleyebiliyorum. 

MACOS ortamında .NET Core ile geliştirme yapmak için visual studio for mac, visual studio code veya JET Brains Rider kullanabilirsiniz.  Bir kaç arkadaşım Jet Brains Rider kullanmam gerektiğini visual studio for mac'in windows'ta bulunan visual studio ile aynı olmadığını söyledi. Daha az özelliği olduğundan bahsettiler. Visual Studio Code'u zaten çoğunuz biliyordur, kullanım amacı biraz daha farklı bir react projesini visual studio code ile geliştirmek güzel olabiliyor, özellikle javascript geliştiriceleri çok fazla rahatlık intellisense aramıyor ama .NET geliştiricileri alıştıkları Visual Studio özelliklerini arıyor. Visual Studio Code'un Visual Studio rahatlığına ulaşması biraz zaman alacaktır. Seçenek olarak geriye JetBrains Rider kaldı. Yalnız Jet Brains Rider'ın ücretsiz sürümünü direkt olarak edinemiyorsunuz. Resharper'ı birçoğunuz duymuştur. Resharper ürününü üreten firma aynı zamanda Rider'ı üretiyor. Zaten elimizde Resharper lisansı vardı.  Üzerine  bir miktar daha ödeme yaparak yaklaşık 150$ gibi bir miktar. Rider'ı denemeye karar verdik. Daha sonra baktığımda Rider'ın öğrenciler, öğretmenler, startuplar ve  geliştirici toplulukları için ücretsiz veya indirimli olduğunu gördüm. 

Rider'ı https://www.jetbrains.com/rider/download/download-thanks.html adresinden indirip kullanmaya başlayabilirsiniz. sadece MACOS ortamında değil windows ortamında da kullanabilirsiniz. 

Rider'ı kullanmaya başlayıp keşfettikçe hoşunuza gideceğini düşünüyorum. Her tarafında farklı bir özellik var. Visual Studio'da olan Rider'da olmayan birşeye rastlamadım. Rider'da fazlası var diyebilirim. Visual Studio'da olmayan ve Rider'da karşılaştığım en önemli ve hoşuma gider özellik ise kullandığınız her kütüphaneyi decompile yapıp debug yapmanızı sağlaması. .NET Core ile birlikte kullandığınız kütüphanelerin çoğunun open source ve  neredeyse çok az dökümantasyona sahip olduğunu düşünürsek kendi kodunuzu debug esnasında kullandığınız kütüphaneleri de debug yapıp neler yaptıklarını görmek ve anlamak hoşunuza gidecektir. 

Visual Studio'da görmediğim Rider ile gelen özelliklerden ilki 3. parti kütüphaneleri on the fly  decompile ve debug özelliği idi.

Diğer bir özellik ise kendi içinde gelen bir  REST Client'ı olması. Bildiğiniz bir nevi Postman'i adamlar Rider'ın içine eklemişler. REST  Api'lerinizi ayağa kaldırdıktan sonra buradan  request atabilirsiniz.

Yine alt menülerde
TODO : TODO' larınızı tek bir ekrandan görebilirsiniz.

Package yönetimi ekranı. Bizde nuget.org ve nexus üzerinden paketlerimizi yönetiyoruz.

Version Control : Biz Git  kullanıyoruz. Rider'ın gerçektende çok güzel bir Git yönetim ekranı var. Branch üzerinde yaptığımız bütün değişiklikleri buradan yönetebiliyoruz.  Aynı zamanda yaptığımız değişikliğin local ve remote branch arasındaki farkı anında gösteriyor.  Git'i komut ekranından yönetmek istemeyen ve görsel bir ekran isteyenler için bire bir.

Unittest, Terminal ve TeamCity gibi menülerde alt menüde listelenmiş durumda. Rider'ın alt menüsü bir çok ihtiyacınızı karşılayacak düzeyde ve yeterlilikte.

Tabii henüz bende 1 haftadır MACOS ortamında Rider üzerinde geliştirme yapıyorum. Muhtemelen henüz yüzde 10 özelliğini keşfetmişimdir ama bu haliyle bile Visual Studio eksikliğini aramadım fazlası var eksiği yok diyebiliyorum.

Bizim Core Framework solution da 20 adet proje olmasına rağmen açılış ve build hızı da gayet iyi.

Projeler sol tarafta listeleniyor. Biliyorsunuz eğer Visual Studio'yu özelleştirmediyseniz solution explorer  default sağdadır. Burada ise default olarak solda açılıyor. Solution yapısıda biraz Visual Studio Code gibi. Direkt klasör yapısını görüyorsunuz. Hem solution hem klasör yapısını aynı anda görmekde hoşunuza gidebilir. Özellikle bu tarz editör kullanmış olanlar alışmak için zorluk çekmeyecektir.













MACOS ortamında veya Linux ortamında kodunuzu build etmek ve çalıştırmanın  bir diğer faydasıda windows ortamında çalışan bazı kodların burada çalışmadığını veya farklı şekilde yazılması gerektiğini anlamanız oluyor. Mesela Server IP adresini aldığımız kodun MACOS ortamında çalışmadığını görmem iyi oldu. Her platformda çalışacak şekilde değiştirdim.

Yazıyı çok da uzun tutmak istemiyorum. Rider üzerinde çalıştıkça tecrübelerimi paylaşmak ve siz değerli yazılımcı arkadaşlarıma faydalı olmak istiyorum. Umarım yararlı olmuşumdur. Umarım benim gibi yıllarca windows ortamında çalışan ve diğer işletim sistemi ve platformları tecrübe etmek isteyen arkadaşlarıma  cesaret verebilmişimdir. Rider beni çok şaşırttı. Gerçekten geliştiren ekibi tebrik ediyorum. Teşekkürler.

Büyüme ve Agile Yöntemler İlişkisi

         Son zamanlarda  domain isimleriyle ilgili bir çalışma içerisindeyken çok ilginç bulgularla karşılaştım ve bunları sizinle de paylaşmak istedim. İçerisinde tech geçen bir domain ismi almak istedim. Yaptığım araştırmalarda içeriğinde tech geçen bütün domain isimlerinin alındığını gördüm. Benim için ilginç olan ise neredeyse baktığım bütün isimlerin 1991- 1998 arası alınmış olmasıydı. İçerisinde tech  geçen bütün isimleri bu tarihlerde almışlardı. İşin en ilginci ise agiletech.com isimli bir domain isminide aynı yıllarda alınmış olmasıydı. flytech.com, techline.com, coretech.com vs... Siteleri incelediğimde bu sitelerin içlerinin boş olmadığını incelediklerimin tamamının bir teknoloji şirketini temsil ettiğini gördüm. Daha biz internetin 'İ' sini görmediğimiz zamanlarda bu adamlar internete girmişler, hepside domain ismi almış, internet sitesi kurmuş ve büyümeye devam etmişler. Aslında bir çoğu 80'ler de kurulmuş firmalar. İnternet ile birlikte kendilerini dünyaya açmışlar ve daha da büyümüşler. Bu esnada yine amerika menşeli  agile ve scrum ile ilgili danışmanlık sitelerinin bı yıllarda kurulduğunu görüyorum.  Bunların tesadüf olmadığını düşünüyorum. Bence büyüme ile agile yöntemler arasında doğrusal bir bağlantı var. Firmalar büyüdükçe, çalışanların sayısı arttıkça, ekipler kalabalıklaştıkça bunları yönetmek, projeleri bu ekipler içerisinde koordine etmekte zorlaştı. Bu esnada agile yöntemler bu problemler için bir çözüm yöntemi olmaya başladı. Bu devasa hantal yapıların idare edilebilmesi ve devamlılığın sağlanması için kendi kendini yöneten ekipler, hızlı karar alan ve hızlı hareket eden ekipler gerekliydi. Tam da bu esnada agile yöntemler imdada yetişti.  Küçük firmalar bu hızı zaten kendi yapıları itibariyle sağlıyordu ama büyük firmaların hızlı olması geleneksel yöntemlerle mümkün değildi.

 

     90'lar da internetinde gelmesiyle birlikte firmalar daha da büyümeye başladı. Özellikle amerikan menşeli firmalar bütün dünyaya hizmet vermeye başlamaları ile birlikte çok daha büyüdü ve verimlilik anlamında ciddi sıkıntılarına en büyük çözüm alternatifi de agile yöntemlerdi. Bundan dolayı 90'lı yıllarda agile danışmanlık hizmeti veren amerikan menşeli firmaların internet sitelerinin olması anlamlı geliyor. Aslında olması gereken olmuş. Peki ülkemizde bu dönüşümün 2010'lu yıllara kalmasının sebebi nedir?



    Bunu da  anlamak artık zor gelmiyor. Bizde ki firmalar maalesef hiç bir zaman amerikan menşeli firmalar kadar büyüyemedi. 1981'de Microsoft'un 1000(bin) çalışanı olduğunu duyduğumda çok şaşırmıştım. Şuan belkide dünya çapında 100 binlere ulaşmıştır ama o günlere göre 1000 çalışan çok yüksek bir rakam. Buna şaşırmama neden olan ise 2010'lara geldiğimizde ülkemizin en büyük teknoloji gruplarında bile bu kadar çalışan olmamasıydı. Demek ki  bizim agile yöntemlere geçmemizin zamanı ancak 2010'larda gelmişti. 2005'ten sonra ülkemizde teknoloji çalışanı ciddi manada artış göstermeye başlamış ve büyük firmaların, holdinglerin, bankaların teknoloji birimleri  100-200 çalışandan 400-500 hatta bazı büyük bankalara 1000 kişiye yaklaşmıştır. Birçok ürün kurum içinde geliştirilmeye başlanmıştır. Bu büyüklük firmaların proje yönetimlerini ve iş verimliliklerini ciddi anlamda düşürmeye başlamıştır. Tam bu sırada ülkemizde de agile yöntemler popüler olmaya başlamış, agile yöntemlerle ilgili danışmanlık hizmetleri çok daha kurumsal bir yapıya dönüşmüştür. Amerikanın 30-40 yıl gerisinden de olsa bizim sorunlarımıza da benzer yöntemler çözüm olmaya başlamıştır. Agile yöntemler artık büyük firmalar için bir deneme yöntemi değil, zorunluluk olmaya doğru gidecektir, gitmek zorundadır. Aksi takdirde bu büyüklüğü başka türlü hareket ettirmenin çaresi maalesef yok gibi.

Teşekkürler.
Osman Sönmez.

YAZILIMDA FAST FOOD SCRUM

Baştan söyleyeyim yanlışım varsa düzeltin lütfen. 1.5 seneden fazladır projelerimizi scrum metedolojisi kullanarak yapıyoruz ama ben hala scrum'un faydasını anlamış değilim. Scrum ile ilgili ilk bilgileri edindiğimde faydalı bir şey olduğunu düşünmüştüm. Japonlar kullanmışsa iyidir demiştim. Her ithal ettiğimiz şeyi amacına uygun kullanmadığımız gibi galiba bunu da amacına uygun kullanmıyoruz. Scrum'ın ülkemizde veya kendi kullandığımız projelerde uygulanış biçimini Fast Food satan yerlere benzetiyorum. Kısa zamanda çok iş:). Biri yağı döksün, aynı anda biri ocağın altını yaksın, aynı anda biri köfteleri hazırlasın, aynı anda biri siparişleri alsın,aynı anda  biri patatesleri kızartsın, biri ekmekleri hazırlasın, biri patatesleri paketlesin, biri köfteleri paketlesin vs... herkes koşturuyor, çünkü müşteri buraya geldiğinde 5 dakika içerisinde yemeğini almak istiyor. 5 dakikada bütün bunların hazır olması gerekiyor. 6 dakika  olmaz deniyor, mutlaka 5. dakikada bu müşteriye verilecek. Müşteri memnun mu eh... evet, yemeğini almış mutlu:) Kalite mi? çok da önemli değil biz müşteriye hızlı bir şekilde yemek vereceğiz demişiz. Mutfaktakiler mi? çok yorulmuşlar ve şunu anlamışlar ve öğrenmişler; biz bu şekilde hizmet vereceksek malzemenin önceden  hazır olması gerekiyor, ne yapalım biz geceden malzemeleri hazırlayalım veya bir yere hazırlatalım. hızlı pişmesi içinde yarı pişmiş olsun. müşteri farklı birşey talep ederse ne yapacağız?.
5 dakikada hünkar beğendi yapacak halimiz yok. Elimizdeki malzeme bu. Yeni birşey yapmak için zaman olması gerekiyor. Mutfaktakiler çok yoruluyor, bir ürün çıkıyor ama kalitesi ve geliştirebilirliği tartışılır,müşteri memnun gibi ama yeni bir şey isterse tecrübeli adam yok, çünkü herkes hızlı köfte üzerine uzmanlaşmış, başka bir şeye vakit verilmemiş. Evet biz scrum yapmaya başlarken, geleneksel yemekleri bırakmış fast food yapmaya başlamışız. Çünkü bize sunulan ve istenen şey tam olarak bu.  Niye scrum yapıyoruz?. Şelale yönteminde işler çok yavaş, bitmiyor, isterleri toplamak çok uzun vs.. kaygılarla scrum yapıyoruz. Aynı iş scrumda daha çabuk oluyor diyorlar. Hemde mesai yapmadan oluyor diyorlar. mesai yapmama olayına inanmıyorum çünkü fazla fazla  yapıyoruz. aynı iş oluyor mu? oluyor gibi ama aslında akçaabat  köfte yapmamız beklenirken, biz daha hızlı pişmesi için aynı görünümde başka bir köfte yaptık, daha az lezzetli ama görünümü aynı akçaabat. Evet şimdiye kadar gördüğüm bu. Aslında bize anlatılan Scrum, Akçaabat köfte yap ama kaliteden ödün verme, organizasyona değer ver ve devamlı geliştir değilmiydi. Problemlere hemen müdahele et ve süreçleri geliştir değilmiydi. Development açısından baktığımda daha içler acısı bir durum görüyorum. Development takımlarına daha çok iş düştüğünü görüyorum. Scrumda analiz var ama dökümantasyon pek yok diyorlar. Dökümante etmek zaman alırmış:). Developer soru sorar bu konuda analiz dökümanı var mı şunu ne yapacaktık acaba; cevap: ara sor veya yüz yüze sor, tam olarak ne istiyorsunuz: ara sor veya yüz yüze konuş, mailleş ve bir sürü  mailden ne yapılacağını çıkar,bol bol ben sana söylemiştim hatırlamıyormusun diyalogları. Scrum yapmak için biyonik developer olmak gerekiyor. Hafızaya al ve bir daha unutmamak üzere kaydet. Çünkü scrumda şelale yöntemindeki gibi döküman yazılmaz, öyle öğrendik biz. İşimizede geliyor aslında:) Biz  söyledik developer yapsın işte. İsterler pat diye geliyor ya 7.sprint geliyor biz şöyle bir ekran istiyoruz deniyor. uçsun kaçsın. Biz bunu yaparız ama biraz araştıralım. 2 haftada bitmesi lazım:) Jquery.UI diye bir şey varmış onunla yaparız herhalde. Başlıyoruz yapmaya, yaptık yaptık iyi birşeylerde çıktı Allah Allah ie8 de çalışmıyormuş bu. Tüh yaparız da dedik. Nerden bileceksin ie8'de çalışmadığını. ie8 müşteri için olmazsa olmaz deniyor. bir o kadar da ie8 için uğraş. Gece gündüz yetiştirmeye çalış. Keşke buna benzer bir şey isteyeceklerini çok daha önce söyleselerdi, yada bir analist bunu çok önceden sorgulasa mıydı?. Bütün scrum böyle geçiyor, bitiyor. Sonunda şunu söylüyoruz biz ya Scrum'da birşeyleri yanlış yapıyoruz, Ya Scrum yanlış yada bizde bir sorun var. Scrum bizi çok yoran, çok daha kısa sürede aynı işi yapmaya çalıştığımız, düzensiz ve dökümansız çalıştığımız ve en önemlisi çok dağınık bir kodlama yapılan bir ortama doğru götürüyor gibi. Bu şekilde yapılan çalışmaların uzun vadede özellikle development takımlarının gelişimine ciddi negatif etkisi olacağını düşünüyorum. Birilerinin scrum yapılırken  gerekli arge faaliyetleri ve development gelişimi için nelerin yapılması gerektiğini, Scrum içerisine bir yere koyması gerekir diye düşünüyorum.