Bitcoin Üzerine Birkaç Not

Herkese selamlar,

Son günlerde oldukça konuşulan bir konu oldu Bitcoin. Silkroad olayında adını oldukça duyduğumuz bir konu, bir olgu oldu Bitcoin. Çok seven early adopterlar da var, bütün gücüyle karşı çıkan statükocular(heeey! sonunda ben de entel bir kelime kullandım) da. Ben de sizlere bir kaç izlenimimi aktarmak isterim. Merkez bankası olmayan bir para birimini ilerleyen günlerde de sıkça konuşacağımızı düşünüyorum.

Evet, Bitcoin’in ilk göze çarpan özelliği merkezi bir para birimi olmaması. Ne demek bu? Bu, Bitcoin’in hiç bir kuruluş,maden vs ile desteklenmediği demek. Yani kimse Bitcoin’ın stabil kalacağını garanti etmiyor veya arkasına belirli bir miktar altın veya başka az bulunan bir maden eklemiyor. Bu Bitcoin’in hem en çok övülen özelliği hem de en çok saldırı altında kaldığı noktalarından birisi. Yalnız şu unutulmasın ki, bankacılık sistemi hayata geçtikten çok sonra merkez bankaları kurulmuştur. Ve de bilenler bilir, ne hileler ve ne kumpaslar kullanılarak! Amaç, bir ülkenin kendi halinde olan para birimini, kontrol edecek bir yapı oluşturmak! E zaten merkez bankası olmadan varolabilmişse ekonomiler, neden tekrar varolamasınlar?

Bitcoin’i eleştirenlerin unuttuğu noktalardan biri de serbest piyasa mekanikleri. Bitcoin’in fiyatı değişkenlik gösterebiliyormuş! Bu yüzden güvenilir değilmiş! Bu parayı kim kontrol ediyormuş? Unutulan en temel noktalardan biri paranın da satın alınabilen bir meta olduğudur. E durum böyleyken, her şey için serbest piyasayı savunan kalantorlar, neden paranın kendisinin serbest fiyatını savunmazlar? Borsadaki hisselerin değerlerinin bir gün içinde ne kadar değişebildiğini farkedersek, Bitcoin’in fiyatının değişmesine de fazla şaşırmamak gerek. Sonuçta güven verdiği sürece fiyatı artar, güvensizlik yarattığında da düşer, bu kadar basit. He siz serbest piyasaya karşısınızdır, orası ayrı.

Hükümetlerin en çok sinirlendiği noktalardan biri de Bitcoin’in takip edilmesi zor bir para birimi olduğu. Bu yüzden teröristlerin, suç organizasyonlarının yaptığı işlemleri kontrol edemeyeceklerini iddia ediyorlar. Teröristlerin hareketlerini sadece para transferleri üzerinden kontrol edebiliyorlarsa zaten vay hallerine. Diğer yandan şaka gibi bir olay, Forbes’a göre FBI piyasadaki Bitcoin’lerin %1.5’unu kontrol ediyor. Buna rağmen Bitcoin’in anonimliği ise tamamen sizin özgürlüğünüz anlamına geliyor. Tabii ki her işlemde tek bir adres kullanırsanız. Arada işlemi doğrulayan bir Bitcoin madencisi dışında kimse olmaması kimsenin sizi izleyemediği anlamına gelmekte. Peki nedir bu Bitcoin madencisi?

Burası açıkçası benim de en az bildiğim kısımlardan. Henüz inceleme şansım olmasa da Bitcoin yazılımı en azından açık kaynak. Fakat çalıştırmanız için özel bir donanıma ihtiyacınız var. En azından sağlam bir GPU’nuz olmalı. Bitcoinler 50’şerlik paketler halinde dolaşıma açıldığından basit bir bilgisayarla bu Bitcoinlerin sizden çıkması ihtimali düşük oluyor. Burada yapılan şey esasında basit algoritma çözümleri, fakat hepsini tek bir işlemciyle yapmaya kalktığınızda sorun yaşayabilirsiniz. Diğer yandan bu sorunu çözmek adına Bitcoin maden havuzları oluşturulmuş. Bu gibi oluşumlarla insanlar işlemci güçlerini birleştirerek kazanılan Bitcoin’den kendilerine düşen küçük payları alabiliyorlar. Bu ve bunun gibi teknikler aslında sistemin güvenilirliğini de artırıyor, çünkü madenciler aynı zamanda işlemleri kriptografik olarak da onaylıyorlar. Bunun karşılığında da para kazanıyorlar. Bir nevi İsmet İnönü’nün namusluların cesurluğu ilkesine benziyor. (Burada da bir cehape zihniyeti söz konusu yani : p)

Neyse uzun lafın kısası, oldukça enteresan bir dijital para birimimiz olmuşa benziyor. Bu konuda daha çok bilgi edindikçe gerek bu yazının güncellemeleri gerek de yeni yazılarla sizleri bilgilendiriyor olacağım.

Görüşmek üzere.

QCON 2013

Herkese merhaba,

Bu sene çalıştığım şirket tarafından QCON 2013’ü izlemek üzere Londra’ya gönderildim, dönüşte izlenimlerimizi bir blog yazısı olarak aktarmamız istendi, bu amaçla aşağıdaki yazıyı kaleme aldım, umarım beğenirsiniz.

What happened at QCON 2013 London?

This year I was one of the two engineers that my company sent to attend to QCON London. We tried to split as we encounter interesting presentations that seem useful to us and our company’s main line of work. Below you will find the main summary and the trending topics of the event.

One of the main line of topics was Best Practices in Web Development, we have seen so many things that we feel in our guts when we are developing but yet did not find its way into our practice somehow. Most prominent examples were anti-patterns like sessions and cookies, usage of javascript and css, semantic html and web sockets. Session usage being an anti-pattern was the most important aspect of those talks. Now I am really convinced that sessions must only be used in development mode, then must be switched to something else, like databases or memory cache structures in the software life cycle.

 

Another interesting aspect of the conference was the real world scenarios. Those were the cases where big companies or big projects encounter problems that can take companies/projects down. It was a very useful series, we have seen NOSQL products in action. Also we have seen a trend where people are migrating to JVM and started to use functional languages like Scala and Clojure.

 

Agile Practices was another interesting topic in the series. Everyone knows that they must be followed, but none follows them well in Turkey. Especially Pair Programming, Retrospection and Iterative Development models are practices which every development team that calls itself agile must follow. Companies that calls themselves agile and customer-driven must also follow these, at least as guidelines.

Key Notes were very successful in my opinion. Barbara Liskov’s entry to conference was really refreshing about where the software came from and where it must go. Damian Conway was a real presentation expert and inspired a lot of people. His main theme was also a very important one that programming languages determine the way you think, therefore more powerful and abstract languages make your thinking more powerful. By the way I must add that he wrote a Latin interpreter just for the sake of the presentation!! There was also a key note called 8 Lines of Code that changed my view of Spring frameworks. It was very inspiring and challenging.

REST was also a very important topic at the conference. Because everyone talks about how they do their API’s in REST, but no one actually does it right. I know that because I was not doing it right. We get the chance to learn the powers of REST and after this conference, will try to use it at every opportunity. I also inspected that the simplicity of REST does not mean it is easy.

Last but maybe the most important topic of the conference was NOSQL technologies. A lot of NOSQL companies were sponsors of the conference so it is logical to see so many presentations. But the numbers and the use cases shows us that this technology is here to stay. And it is powerful. And it is useful. And the beauty is, everyone can break their own motherships to use new technologies piece by piece. The challenge and the beauty lies in this situation.

As for the summary, QCON really showed us great trends and useful presentations. Many of the presentations were also a lot of fun so we did not dose of sleep in any of the presentations : ). Every competing software company needs to follow this conference every year if it wants to stay competitive and succeed.

 

Spring Web Serviceleri ve Spring Namespace Handler not found hatasi

Gençler selam,

Uzun aradan sonra bir kaç cümle yazayım dedim, baktım ki evvelden iki madde not almışım bunlardan bahsedeyim diye. Yeri gelmişken sizlere de aktarayım.

Spring süper bir framework, kabulümüzdür. Fakat arada sırada kullanıcıya yardımı dokunmayan hata mesajları da verebiliyor, sonucunda da çokca vakit kaybedebiliyoruz. Ben geçenlerde benzer bir vakit kaybı yaşadım, sizlerle de paylaşayım da mümkün olduğu kadar siz aynı vakti kaybetmeyin.

Spring Namespace Handler not found diye bir hatası var, bu genelde aynı spring jarinin farklı versiyonlar üzerinden birden fazla şekilde uygulamaya katmaktan oluyor, keşke Spring kendisi bunu bize söyleyebilseydi. : )

Ayrica jax-ws spring eklentisini kullanmaya gerek yok, springin SimpleJaxWsServiceExporter sınıfı inanılmaz kullanışlı. Tek sıkıntısı, bu exporter web servisinizi ayri bir port üzerinden sunuyor. Bu durumda aynı uygulama içinden web servisi de sunmak imkansız hale geliyor, denediğinizde orada zaten bir uygulama olduğu hatasını alıyorsunuz.

Herkese iyi geliştirmeler.

Bir kaç düşünce

Uzun süredir yazamıyorum arkadaşlar, herkeslerden özür dilerim. Ama bu rehavetin tek sorumlusu ben değilim, çok sıcak geçen yaz, yoğun iş temposu vs beni yazmaktan alıkoydu. Eylülü de yazısız geçirmeyeyim dedim ve son projemde kodlama yaparken aklıma daha önceki okumalarımdan gelen fikirleri sizlerle paylaşayım istedim.

Başlıyoruz:

Eğer yazdığınız kod, üzeride comment satırları olmadan anlaşılmıyorsa, o kod sizin başınıza çok belalar açabilir. Eğer ki yazdığınız kodun bir “hack” olduğunu düşünüyorsanız bunun iyi bir hack mi yoksa kötü bir hack mi olduğuna karar verin. Eğer kötü bir hackse düzeltmeniz gereken şeyler olabilir.

Başka bir nokta, eğer yazdığınız bir metoda isim vermekte zorlanıyorsanız, bu metodun ne iş yaptığına tekrar bir bakın derim. Büyük ihtimalle içeride birden çok iş yapıldığını göreceksiniz. Bu durumda metodunuzu daha küçük parçalara bölmeyi düşünebilirsiniz. Bu sayede metodun karmaşıklık seviyesini de düşürebilirsiniz. Açıkçası benim beynim küçük karmaşıklık seviyelerinde daha rahat yolculuk ediyor, adeta akıp gidiyor : p.

Son olarak, eğer sınıf tasarımını yaptıktan sonra kodlama esnasında, sınıflarınızın isimlerini hatırlayamıyorsanız, o zaman o tasarımı hemen bir gözden geçirin. Yada yeni bir metod yazmanız gerektiğinde bu metodu alacak sorumluluğun hangi sınıfta olması gerektiğini kestiremiyorsanız, tasarıma yeni bir arkadaş daha eklenme vakti gelmiş olabilir.

Havaların soğumasıyla beraber yazılarımızın ve okumalarımızın ısınması dileğiyle, herkese iyi günler!

IOS – tablo yapılarına “daha çok göster” alanı eklenmesi

Herkese merhaba,

Başlıktan da gördüğünüz gibi bu aralar boş vakitlerimde ; ) IOS development takılıyorum. Geçenlerde de bir tableview kasıyordum ki, zor bir problemle karşılaştım : sayfalama. Bir şekilde çözmeyi başarınca, bunu diğer arkadaşlarla da paylaşayım, hem bana da sonradan hatırlatma olur diye sizler için not düşüyorum.

İlk olarak bu fazladan eklenecek table view cell için bir xib dosyası hazırlıyorsunuz. Bu dosyaya artık button mu eklersiniz label mı yapıştırırsınız orası sizin bileceğiniz iş. Hücrenize fonksiyonalite de ekleyecekseniz, UITableViewCell den türemiş bir subclass da yazmanızı öneririm.

Hazırladığınız görselin identifierını bir kenara not edin ve ondan sonra tableview u handle edeceğiniz sınıfın uygulama dosyasına gelin. Burada bildiğiniz gibi tablonuzda kaç satırınız var ve bu satırlar için hangi hücreleri kullanacaksınızı belirlediğiniz iki metodunuz var. İşte bu metodlarda bazı değişiklikler yapacağız.

İlk olarak eleman sayımızı belirlediğimiz metodumuzu aşağıdakine benzer şekilde güncelleyebiliriz :


- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{

if ( isJsonData == YES ){

return [postData count] + 1;

}

else {

//TODO we will put a loading sign here afterwards

return 1;

}

}

Burada gördüğünüz gibi elimizdeki eleman sayısından bir fazla yer aldık. E bunu da demin hazırladığımız xib dosyasındaki cell ile kullanacağız. O kısımda da şöyle bir hareket yapıyoruz :


- (UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{

...

if ( isJsonData == YES ) { //normal operation

...

}

else {

UITableViewCell* cellLoadMore = [tableView dequeueReusableCellWithIdentifier:loadMoreIdentifier];

if ( cellLoadMore == nil ) {

NSArray* nib = [ [ NSBundle mainBundle ] loadNibNamed:@"loadMoreCell" owner:self options:nil ];

cellLoadMore = [ nib objectAtIndex:0 ];

}

return cellLoadMore;

}

...

}

İşte bu şekilde artık tablomuzun sonunda daha fazla satır getirmemiz için bağıran bir table cellimiz oldu. Table cell için özel olarak bir xib dosyası hazırladık, üzerine de bunu kenar koşul oluştuğu anda kullandık.

Bu doldurma tuşuna basınca ne olacağını da bir sonraki seferde konuşuruz artık.

İyi çalışmalar

Hiç bir pencereyi kırık bırakma!!

Amerika’da yapılan bir araştırmada bir binanın şehrin orta yerinde nasıl çürümeye başladığı araştırılmış. Hani şu filmlerde olur ya etrafında herşey normal görünürken içinde evsizlerin yada ne yaptığı belirsiz insanların yaşadığı uğursuz binalar, işte bu binalar nasıl oluyor da bu hale geliyor araştırılmış arkadaş.

Araştırmada çıkan sonuçlardan biri, binanın genel durumuyla ilgili. Eğer ki bina sürekli titiz bir bakım içerisindeyse, uzun yıllar sağlıklı olarak ayakta kalabiliyor. Mesela arada sırada her binanın camları kırılır, bu camları siz inatla tamir ettiğiniz sürece binanın sınıfı ve canlılığı olduğu gibi kalmaya devam eder. Ama eğer bir kırık camı bir kaç günden uzun süre tamir etmezseniz, diğerleri de o pencereye bakarak bu binanın terk edilmeye başladığını düşünürler ve başka camları kırmaya başlar millet. Bir süre sonra da binadaki hasar öyle bir boyuta gelmiştir ki eskiden binanın sakini olanlar da tamir etmeye üşenir ve binadan taşınırlar, onların yerine de artık ne idüğü belirsiz tipler yerleşmeye başlar.

Bu olayı enteresan bir biçimde yazılım projelerinde de benzetme olarak kullanıyorlar. Örneğin güzel bir proje hazırladınız ve üretim seviyesine getirdiniz. Bu aşamadan sonra yazılım canlı bir süreç olduğundan (gene güzel bir benzetme), bu organizmanın üzerinde değişiklikler olmaya devam ediyor. İşte burada dikkatli olmak gerekiyor ve hiç bir pencereyi kırık bırakmamak gerekiyor.

Örneğin kullanılmayan bir değişken mi gördünüz, hemen kaldırın gitsin. Uzun bir kod blokunun yorumlanarak silindiğini mi fark ettiniz? Silin gitsin, versiyon kontrol araçları ne güne duruyor? Bir kod parçasının iki-üç yerde kopyala yapıştır kullanıldığını mı gördünüz? Hemen onu bir metod haline getirin ve metod çağrısı olarak kullanın. Kodunuz üzerinde bu şekilde titiz davrandığınız zaman, projedeki diğer çalışanlar ve özellikle yeni katılanlar da bu dikkati, özeni göstermeye kendilerini zorunlu hissedeceklerdir. Bu sayede binanız asla terkedilmeyecek ve şanıyla birlikte yaşlanmaya devam edebilecektir.

İyi çalışmalar!

Mobil Uygulamalar ve Titanium Gerçeği

Phonegap ile ilgili daha önce bir giriş yazısı yayımlamıştım. O yazımda mobil uygulama geliştirme çatılarının birden fazla mobil platformda iyi sonuçlar verebileceğini ve denemeye değer olduğunu yazmıştım. Açıkçası Phonegap i değil ama Titanium u gerçek bir uygulama ile denedim ve izlenimlerimi sizlerle paylaşmak zorundayım.

  1. Titanium Javascript ile kendi kütüphanelerini kullandırarak size yazılım geliştirtiyor. Bunu da hem Android in hem de IOS un karışık çatılarını ezberlemeyelim diye yapıyorlar. Burada dikkat edilmesi gereken bir nokta var ki, Android i de IOS u da böyle güzel ve kullanışlı yapan şey bu karmaşık yazılım çatıları. Yani demek istediğim şey şu ki, bu adamlar keyfiyetten bu çatıları karmaşık hale getirmiyorlar, gereksinimleri karşıladıkları zaman uygulama çatısı kendiliğinden karmaşık bir hale gelmiş oluyor. Ama Titanium burada ne yapıyor, bu adamların özenerek ürettikleri bu karmaşık çatıları, tek bir çatı altına almaya çalışıyorlar, yani denkleme bir problem daha katıyorlar, ve çözümü iyice karmaşıklaştırıyorlar yada tam aksine basitleştirmek için sistemleri budamak zorunda kalıyorlar.
  2. Bu mobil çatı aynı zamanda Java ve Objective-C öğrenmek zorunda kalmayalım diye hazırlanıyor. Diğer yandan burada bizim Javascript kullanmamız gerekiyor. Bu dili bir çok web geliştiricisinin bildiğini düşününce gerçekten mantıklı bir sonuç değil mi? İşte kazın ayağı öyle değil ne yazık ki: Bir çok web geliştiricisi Javascript i sadece basit Jquery metodlarını çağırabilmek için kullanır, yani esasında kullandıkları şey web metodları olan bir C dilidir. Diğer yandan her ne kadar ciddiye alınmasa da Javascript çok ciddi bir dildir. Hatta ana akım olmayı başarmış en yakın Lisp özellikli dildir. Bu da ne demek, öyle herkes Javascript bilmiyor demek(şahsen ben adeta bilmiyorum). Bayağı bir özelliği var demek (ki kötü özellikleri de var ve adeta bunları öğrenmemek gerek, hatta sırf bunun üzerine yazılmış kitaplar bile var.). Dolayısıyla amatör bir şekilde tüm uygulamayı Javascript te yazarsan işlerin çığrından çıkma ihtimali yüksektir. Önce function scope nedir, global namespace nedir bilmek gerekir.
  3. Bu adamlar bu kadar güzel özelliği beleşe veriyorlar biliyor musunuz? E peki nasıl para kazanıyor bu amcalar? Şimdilerde marketplace uygulaması başlattılar. İlk maddede bahsettiğim budanmış sisteme bu sefer o budanan nesneleri satıyorlar. E peki daha önce ne yapıyorlardı? Sonuçta ortada ne olduğu belli olmayan bir uygulama çatısı mevcut. Kullanmak istiyorsan nasıl çalıştığını bilmek zorundasın, e dökümantasyon da olmadığına göre gelip bu amcalardan eğitim alacaksın ve sertifikanla beraber yazılım geliştirmeye devam edeceksin. Yani sonuç, dökümantasyona güvenme! Çünkü adamlar bilerek ve isteyerek çok az dökümantasyon yayınlıyorlar, projeye baslamana yetecek kadar ama biterecek kadar değil!
  4. Hata varsa ne yapacaksınız? Sonuçta bu Titaniumu yazan amcalar da insan ve onlar da hata yapabiliyorlar. Tamam kabul ediyorum google ve apple daki elemanlar da insan onlar da hata yapabilirler. Ama burada dikkat edilmesi gereken elemanların böyle bir durumda tepki hızları olacaktır. Forumlardan siz de görebilirsiniz, bir hata herhangi bir uygulama çatısında kesin olarak belirlendikten ne kadar süre sonra çözülmüş. Titanium forumlarında ise bir ıssızlık, bir umursamama kol geziyor. Projenizde güvendiğiniz çatının hatası yüzünden müşteriye geç kalınca ne demeyi düşünüyorsunuz?
  5. Diğer yandan bu adamlar bu işi bırakırlarsa ne olacak? Bu projeye bundan sonra kim bakacak? Google ve Apple ın daha uzun süreler buralarda olacağı kesin(batacaklarsa veya bırakacaklarsa da çok önceden kokusu çıkar ve siz önleminizi alabilirsiniz) ama ya yarın Apple Titanium u satın alırsa ne yapacaksınız? Siz müşterilerinize destek vermeye devam edeceksiniz ama adamlar çatıya gerekli değişiklikleri yapmayabilirler. Misal Facebook satın aldığı start-up şirketleri kapatıp, elemanlarına şirket bünyesinde görev veriyor. Titanium a da bu olursa ne olacak? Mesela yanlış bilmiyorsam PhoneGap i Adobe satın aldı. Ee ne olacak şimdi? Onlara ne söyleceksiniz bu durumda? Kullandığınız uygulama geliştirme çatısının piyasa desteğinin bittiğini mi söyleceksiniz? Bu projenin kendi evanjelist programcıları var mı? Lisp gibi yıllarca kendi kendini devam ettirebilecek mi?
Sonuç olarak tabii ki ortak bir çatı fikri her zaman mantıklı geliyor, ama teknoloji ve fikir dünyası böyle yürümüyor. Eğer bu adamların taktiği işe yarıyor olsaydı şu anda herkes en fazla C++ ile işini halledebiliyor olacaktı. Monarşi de dünyanın tek yönetim sistemi falan olurdu heralde : ). Böylelikle diyebiliriz ki, Titanium gibi projeler şimdilik daha orta ve küçük ölçekli projelerde tercih edilmeliler, daha ciddi işlerde teknolojinin kendi çatısı kullanılmalı.
Herkese iyi çalışmalar, iyi kodlamalar.

İz Mermileri ve Yazılım Projeleri

Herkese merhaba,

Andrew Hunt ve David Thomas’ın ibretlik çalışması The Pragmatic Programmer kitabında enfes bir bölüm okudum geçenlerde. Bu bölümün en azından Türkçe yorumunu sizlerle paylaşmam gerektiğini düşünüyorum.

Askerlikte, gece çatışmaları ayrı bir önem taşır çünkü genelde hedefinizi işler son raddeye gelinceye kadar göremezsiniz. Çatışma çıktığında işler karışır ve özellikle makinalı tüfek kullanan tim elemanlarının azami dikkat etmesi gereken bir kaç dakika yaşanır. Makinalı tüfek erinin, ateş etmeye başlamadan önce karşı tarafın ateşinin en azından yönünü tespit etmesi gerekir ki kendi elemanlarını vurmasın. Peki bu nasıl yapılır, ses ve iz mermileri ile yapılır. Sesin geldiği yöne bakarsınız ve sonra iz mermilerinin çıktığı yere hedef alırsınız.

Fakat burada Hazır Ol, Nişan Al ve Ateş! emrinden farklı olaylar gelişir. Karanlıkta nişan alabilmeniz çok uzun sürer bir kere, tüfeğin gezinden baktığınızda zaten karanlık olan dünya iyice karanlıklaşır ve herşey görünmez olur. Bu yüzden burada sırayı değiştirmek gerekir, Hazır Ol, Ateş Et, Nişan Al ve Tekrar Ateş Et! emrini uygularsınız. İz mermileri her 10 yada 20 mermide bir fosfor taşıyan mermilerdir ve tüfekten çıktığı andan itibaren arkasında iz bırakarak hedefe ilerler. Siz de bu iz mermileri sayesinde nereyi vurduğunuzu bilir ve gerekirse nişanınızı ona göre yeniden düzenlersiniz. Ve eninde sonunda hedefi vurursunuz, tabii o sizi daha önce vurmadıysa :). Bu arada denizci olarak askerlik yaptım, bunları da sadece teorik olarak dinledim komutanlarımdan :).

Yazılım projelerinde de benzer bir yaklaşım uygulayabiliriz(hayat fazla derecede askerliğe benziyor ya ona da ayrıca bitiyorum 🙂 ). Diyelim ki yeni bir projeye başlıyorsunuz. Ve ilk deneyeceğiniz işler olacak. Bu durumda, herşeyi baştan tasarlayıp, inciğine kadar detaylandırıp, uzun uğraşlardan sonra tasarımın tamamını ortaya koyabilirsiniz. Bu en temel yazılım mühendisliği çalışma şeklidir ve herkesin aklına ilk bu çözüm gelir.

Fakat bu kadar tasarımda ya hata yaptıysanız? Başa dönmeniz için yeterli vaktiniz kaldı mı? Takımın morali ne durumda? Hali hazırda müşterileriniz varsa onlara ne söyleyeceksiniz? Patronunuza da açıklama yapmanız gerektiğini unutmayın. Sonuç olarak bayağı bir stresse gireceğiniz kesin gibi görünüyor :). Peki bunun yerine ne yapabilirdik?

Bunun yerine, bizi zorlayacak sistemin tek başına çalışabilecek en küçük iskeletini ortaya çıkarabilirdik. Bakın burada prototiplerden bahsetmiyorum çünkü prototip kodlar kullanılmaz, atılır. Burada sistemin en küçük ve basit mimarisinin çıkarılmasından söz ediyorum. Diyelim ki akıllı bir telefondan uzaktaki bir sunucuya bağlanıp, çalışanlarınıza işler atayıp, onlara e-posta yoluyla haber verebilen ve geri besleme alabilen bir çözüm hazırlamanız gerekiyor. Burada ilk olarak, akıllı telefondan uzak sunucuya bağlanıp, oradaki veritabanına veri girip, sonuç olarak boş bir mail gönderen bir iskelet yazılım hazırlamalısınız. Görebileceğiniz gibi bu bir prototip değil, esas sisteminizin en temel parçasını çıkarmış oluyorsunuz. Bunun üzerine diğer akıllı telefonları desteklemeyi, iş tipleri girmeyi, değişik mail adreslerine zamanlı olarak mail atmayı, alınan cevabı işlemeyi de yapabilirsiniz.

Yani sistemin en temel halini en çabuk şekilde hazırlarsanız, projeniz büyük ihtimalle başarıya ulaşacaktır.

Sistemin diğer özelliklerini uygulamayı da kolaylıkla yaparsınız çünkü elinizde en basit işlemin hazır örneği bulunmaktadır. Kolaylıkla yaparsınız çünkü moraller yüksektir, her adımda hedefe yaklaşırsınız.

Aynı izli mermiler gibi…

Use Case, kullanım senaryolarına giriş

Herkese merhaba,

Biliyorum konularda dağınık gidiyorum ama arada aklıma anlatmam gerektiğini düşündüğüm şeyler geldiğinde sırayı sapıtıyorum. Normalde bu seferki yazımda geçen ingilizce olarak yayımladığım özet design patterns yazısını türkçeye çevirecektim ama konu gene değişti.. Ve bugünkü konum kullanım senaryoları olarak türkçeye çevrilmiş olan use case mantığı.

Yazılım dünyasında kullanıcı gereksinimleri diye bir kavram var ilgilenen arkadaşların bildiği gibi. Bu kullanıcı gereksinimleri başlamanız gereken projenizde, sonuçta oluşacak yazılımın sahip olması gereken özellikleri madde madde sıralayan bir belgedir. Her madde, yazılımınızda kesinlikle olması gereken bir özelliği işaret eder çoğu zaman.

Kullanıcı gereksinimlerinin bizim için kötü yanı, oldukça resmi bir dille yazılmış olmalarıdır. Örnek olarak :

Kullanıcı, ekranda gördüğü içeriğin yerini dilediğince değiştirebilmelidir.

Bu dil hem resmi hem de yoruma aşırı açık bir belirtmedir. Siz bu gereksinim ile ilgili olarak müşterinizle yada proje müdürünüzle anlaştığınızı zannedersiniz ve kodlamaya başlarsınız. Belli bir süre sonra projeniz bittiğinde, ve sevinçle sonuçları müdürünüze açtığınızda, iki taraf da farklı ruh hallerine bürünür. İlk olarak müdürünüz bu özelliği nasıl test edeceğini bilmiyor olacaktır büyük ihtimalle. (En iyi proje müdürleri eski yazılımcılardır!!!) İkincisi ve daha önemlisi, siz sürükle bırak için haftalarınızı harcamışken, müdürünüz sizden sürükle bırak değil de mesela bir yönetim ekranında menülerin yerlerinin değiştirilmesini istediğini söyleyebilir. Bu durum da tam bir kabus olsa da, günümüz projelerinin çokca başına gelen bir beladır. Peki biz bu durum için ne yapabiliriz?

Bu şekilde yoruma açık cümleler kullanırsak birşey yapamayız. Çünkü bu tarz cümleler müşterilerin ve pointy haired boss ların çok sevdiği cümlelerdir ve hemen anlaştığınızı görerek şaşırırsınız. Aslında böyle olmaması gerekiyor, uzun tartışmalar yaşanmalı ve istenenin net olarak belgelenmesi sağlanmalıdır.

Bunun için, kullanım senaryosu denilen teknik kullanılabilir. Use Case olarak literatüre geçmiş bu kavram İsveçli bilgisayar bilimcisi Ivar Jacobson tarafından ortaya atılmıştır. Kullanım senaryolarında gereksinimler bir sıra ile sistemde yapılacak işler tasvir edilerek belirtilir. Örnek vermek gerekirse:

  1. Kullanıcı sisteme giriş yapar.
  2. Yönetim menüsüne tıklayarak yönetim ekranını açar.
  3. Yönetim ekranında, kutuların yerlerini değiştirme listesinden kutuya yer seçer.
  4. İstediği tüm kutuların düzenlenmesi bitene kadar 3. adımda kalır.
  5. İşlem bitince save düğmesine basarak, düzeni saklar.

Bu şekilde yazılan senaryo hakkında netlik ortadadır. Her taraf tam olarak anlayana kadar üzerinde çalışılabilir.

Kullanım senaryoları özellikle Unified Process denilen birleşik proses yazılım geliştirme tekniğinde yoğun olarak kullanılmaktadır. Özellikle sistemin geliştirilmesi bittiğinde resmi süreçlerde kabul testleri olarak da kullanılabilir. Hatta büyük ihtimalle test yazmak bile zorunda kalmazsınız çünkü adım adım ne yapmanız gerektiği zaten kullanım senaryolarında yazılıdır.

Bunlardan daha da önemli olan özelliği, sistemin bu şekilde tasviri sayesinde, elimizde sınıf olması ihtimal dahilinde olan kavramlar ortaya çıkar ve bu da nesneye yönelimli tasarım açısından bize büyük bir avantaj sağlar. İlk olarak isimleri ve isim tamlamalarını ayırırsınız. Bunlar bir liste halinde tutulur. Örneğin :

  • Kullanıcı
  • sistem
  • giriş
  • yönetim menüsü
  • yönetim ekranı
  • kutu
  • yer değiştirme listesi
  • işlem
  • save düğmesi
  • düzen

Bu isim ve isim tamlamalarının bir kısmı anlamsız olacaktır. Aynı anlama gelenler, yapılan işle alakası olmayanlar ve önemsiz varlıkları temsil edenler silinir. Önemsiz varlıkları temsil edenlerden daha büyük varlıklara ait olanlar, o fiziksel sınıfın özellikleri olabilirler. En son olarak da bu cümlelerdeki fiiller, isimlerin (yani fiziksel sınıfların) aralarındaki ilişkileri belirler. Bir sonraki yazımda bunun daha detaylı bir örneğini vereceğim. Şimdilik herkese iyi çalışmalar.

Design Patterns, An introduction

Today I would like to relate to a little research i have done on my
daily job. These abstracts will provide a path for us on the road
to further investigate these patterns. Also a turkish version of
this work will be published too.
	Recommended GOF Patterns

	1 - Abstract Factory
	    	     Abstract factory creates factories that produces
		     different classes. For example if we need a factory
		     that either creates win buttons or osx buttons, we
		     need a factory to create these factories.
		     Here we need to define what factory is by the way :
		     if we have more than one adapters for example,
		     we need to know which one to create in a given
		     situation, but if we give this responsibility to
		     any class in the system, we improve the dependency
		     of each object to another, so we need another class
		     to handle this responsibility. This class is the
		     factory class.
	2 - Factory Method
	    	     This pattern is used to put the creation method
		     to the class which will use the created object
	3 - Singleton
		     Singleton pattern is used to create the factory itself
		     . To implement a singleton pattern you have to define
		     the constructor as private and create a static method
		     for the class that cannot be overridden. This static
		     method will return an object of the class.
	4 - Adapter
	    	     Main function is to change the interface of a class to
		     match other classes, for example, there may be more
		     than one outside class that does the same operation
		     for our system but we don't want to change the inner
		     classes according to the outer class that we use
		     so we create adapters for each class and provide the
		     same interface to our inner classes, so the inner
		     classes dont have to know which class they are dealing with.
	5 - Composite
		     Sometimes an object should not know about the way a
		     method works. For example an object may work with a
		     single other object to accomplish some task and some
		     other time the same object may require to work with
		     multiple objects to do the same task. If the
		     implementor object knew about the objects it works,
		     this reduces low-coupling and flexibility. In order
		     to overcome this problem we use composite pattern.
		     A class is constructed with same interface as the
		     other classes, and the multiple objects work in that
		     class, so all other objects dont know anything about
		     the sub objects that does the work.
	6 - Facade
		     This pattern is used to hide complexity of a system
		     (either inside or outside) from other parts of the
		     system. For example you want to hide business logic
		     from representation logic because the representation
		     can change any time but business logic is more stable.
		     So a facade class is constructed to centralize the
		     operations done on a complex subsystem.
	7 - Observer
		     This pattern is used when a change of state in a
		     class requires the attention of many other classes.
		     If we write a function for every class about the
		     change, we have a highly coupled class system and
		     it will be very hard to make a change in the class
		     that does the changes.
		     So in Observer pattern as a solution to this problem
		     an interface is created, and the classes that want
		     to learn about the change, implements this interface.

	8 - Strategy
		     Over time an object may require different kinds of ways
		     to do the same operation. This can be examplified by a
		     a discount method, some conditions require different
		     discount methods, and some other conditions require
		     different methods. In order to cope with the complexity
		     this problem presents, we use the strategy pattern. In
		     strategy pattern, a method is abstracted using an
		     interface. Then different strategies are implemented
		     using this interface. As a result, implementor class
		     knows nothing of the strategy class, it just uses the
		     specified interface.