Category Archives: Kitaplar

Javascript Kaynak Kitaplar

Dün mail ile bir arkadaş Javascript için önerebileceğim kitapları sormuştu. Bende Javascript öğrenirken kullandığım kaynakları aşağıya yazayım başkaları içinde belki faydalı olabilir diye düşündüm. Bana en çok yararlı olan kaynaklar :

İlk kitap Yahoo’da front-end engineer olarak çalışan Nicholas C. Zakas tarafından yazılmış oldukça iyi bir Javascript kitabı. Kitapta Javascript dili,Object Oriented Javascript,DOM,BOM,Ajax,XML.. gibi neredeyle genel olarak birçok konuya değinmiş. Kitabın sonundaki Best Practices kısmını oldukça beğendiğimi söyleyebilirim. Kitabı daha çok referans kitabı olarak kullanıyorum.

ikinci kitap JSON mucidi yine bir Yahoo çalışanı olan Javascript dünyasının efsanesi Douglas Crockford tarafından yazılmış sadece Javascript dilini anlatan bir kitap. Kitap yaklaşık olarak 200 sayfa civarında kısa olduğuna bakmayın birçok bölüm tekrar okumayı gerektiriyor.

Diğer kitap ise bir Twitter çalışanı olan blog’unuda severek takip ettiğim Dustin Diaz tarafından yazılmış. Klasik anlamda Design Pattern’ların Javascript dilinde nasıl kullanılacağını güzel örneklerle anlatmış.  Bu kitabın örneklerini oldukça sevdiğimi söyleyebilirim.

Bunun dışında Yahoo’nun YUI Theater kısmında bulunan videoları şiddetle tavsiye ederim. Özellikle bu sayfada bulunan Douglas Crockford’un Javascript JavaScript Programming Language ve Advanced Javascript serilerini mutkala izleyin. Umarım kitaplar ve videolar yararlı olur…

Ship It:Bölüm 3

Pratik Proje Teknikleri

Bu bölümün ilk girişinde neden bazı projelerin kaliteli,başarılı olupda erken bittiğini ama bazı projelerin kalitesiz başarısız ya da geç kaldığını sorarak başlıyor.Bunu sebebini iletişim ve işbirliği olduğunundan bahsediyor.Benimde düşündüğüm şeyleri burada da tekrarlamış kitap. Tutkulu hevesli, işbirliği halinde iyi iletişim kuran bir takım projenin başarısı için en önemli faktörlerdendir. Takım olabilmek içinde tabiki en önemli faktörlerden biri iyi iletişim ve işbirliği içinde olmak . Bu noktada kitapta aşağıdaki gibi vurucu bir söz yazılmış.

Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.

Evet söz çok hoşuma gitti.İyi işbirliği,iletişim projenin başarılı olacağını garanti etmez fakat kötü iletişişim,işbirliği her zaman projenin başarız olacağını garanti eder.Bu bölümde aşağıdaki gibi takım olarak işbirliğini arttıracak teknikler üzerinde duruluyor.

Yapılacaklar Listesinden Çalışın

Bu bölümde aslında uzunca yapılacaklar listesinden(to-do list) bahsediliyor.Yapılacaklar listesini proje olarak kişisel olarak tutmanın genel gidişatı yolunda tutmak için önemli olduğunu söylüyor. Kendim kişisel olarakda sürekli yapılacaklar listesi tutuyorum. Hatta şuanda çok sevdiğim rememberthemilk sitesini tavsiye edebilirim. Web üzerinde oldukça pratik yapılacaklar listeleri oluşturup,bunlara öncelik atayıp yayınlayabiliyorsunuz. Tabi bunu illa bir yazılım yoluyla yapmak zorunda değilsiniz. En güzel kayıt aracı hala bence defter kalem ikilisi. Mesela daha önceki çalıştığım firmada bunu proje içinde uygulardık. Öncelikle müşterinin isteklerine göre haftalık yapılacaklar listesi oluşturup herkes için bunu yayımlanırdı. Ardından proje yöneticimiz ile birlikte bunlara öncelik atardık ve önceliği en yüksek olan özellikleri geliştirmeye başlardık. Önceliği yüksek olan öğeler bitmeden düşük öncelikli öğelere geçmezdik. Bu şekilde önüimüzdeki işleri rahatça takip edebilirdik.Ayrıca müşteride şuanda hangi özellikler var, ve projenin genel gidişatını kolaylıkla öğrenebiliyordu. Liste dediğimiz şey çok abartlama gerek yok kısaca aşağıdaki gibi diyebiliriz.

    Visual Earth entegrasyonu yapılacak(Öncelik 1) Zoom out seçeneği eklenecek(Öncelik 2) NAnt bile build scripti yazılacak(Öncelik 3) Geliştirme makinası Ubuntu üzerine taşınacak(Öncelik 3)

Gördüğünüz gibi liste kısaca yukarıdaki gibi yapıya sahip.Kitapta listelerin sahip olması gereken temel özelliklerini sıralayarak açıklamış. Liste aşağıdaki özelliklere sahip olmalıdır.

    Herkes tarafından ulaşılabilir(Listeyi gizledikten sonra bir faydası yok) Önceliklendirilmiş(Yukarıda bahsettik) Zaman tahmini yapılmış(Projede tahmin sürelerinin geliştirilmesi için yapılaraklara zaman tahmini eklenmesi ) Canlı(Bir defa yaz kenara at değil, sürekli gelişen değişen) Ölçeklenebilir(“Performansı arttır” gibi bir öğe yerine “login ekranında giriş 5 saniyeden kısa olmalıdır”.) Hedef kitlesi belirli(Takımın yapılacaklar listesi ya da kişisel yapılacaklar listesi)

Teknik Lider

Bu kısımda projede bulunması gereken takım lideri,teknik lider gibi kişilerin rollerinden ve neler yapması gerektiğinden bahsediyor.Öncelikle teknik bilgisi yetersiz bir proje yöneticisiyle çalıştınız mı bilmiyorum fakat ben acı şekilde bunu tecrübe ettim. Böyle biriyle çalışmanın en büyük problemlerinden biri sizin geliştirdiğiniz yazılımın sorunlarından , teknik detayından çok fazla haberdar olmadığı için çoğu zaman gerçekçi olmayan planlar çıkarabiliyorlar. Onun için yeni bir özellik desteği eklemek 1 günü alabiliyor fakat işin içinde In Hohe und Art kann sich ein spielautomaten online Bonus allerdings von Casino zu Casino erheblich unterscheiden. olan siz oradaki problemi biliyorsunuz ve bunun bu sürede çıkarılamayacağını söyleyince muhtemelen şöyle bir cevap alıyorsunuz; “A tablosuna yeni bir alan ekleyelim bu problemi çözecektir” :) Bu arada konu ile alakalı değil fakat söylemeden geçemiycem, DB oriented insanlarla ya da proje yöneticisiyle çalışmanın en ilginç bulduğum yanlarından biride her problemin çözümünü bir tablo ile ya da tabloya bir alan eklemeyle çözmeleridir :). Tabi proje yöneticiniz yazılım hakkında çok iyi olan biriside olabilir. Fakat bu da problemi çözmeyecektir. Çünkü takım içinde olmadığı için sizin kod içindeki problemlerinizi bilmediği için aynı problemler devam edecektir. Bu yüzden kitaba kesinlikle katılıyorum.Proje içerisinde Takım Lideri ya da Teknik Lider bulunması gerekiyor. Böylelikle takımın problemlerini bilip onlara daha uygun çözümler ve daha uygun planlar çıkarabilir. Teknik Lider neler yapar kitapta şu şekilde belirtmiş.

    Müşterinin belirttiği önceliklerle takımın çalışmasının örtüşmesini sağlar Takımın çalışmasının üst yönetime ya da proje yöneticisine düzgün olarak sunar. Teknik konuları teknik olmayan insanlara iletir. Projede Teknik olmayan konuları takıma bildirir. Takım üyelerine yön çizer Projenin özellik listesini düzenler. Yapılacak özellikleri takım ile birlikte önceliklendirir Takımın dış etkenlerden rahatsız olmamasını sağlar

Hergün İşbirliği ve İletişim İçinde Olun

Bu kısımda takım olmanın en önemli unsurlarından olan iletişimden bahsetmiş. İletişimi arttırmak için özellikle günlük toplantıları anlatmış. Öncelikle neden iletişimi arttırmalıyız ona değilenim. Aynı problemleri tekrar çözmemek için,tekerleği tekrar icat etmemek için iletişim gerçekten önemli.İletişim; Takımda herkesin birbirinin yaptığı iş hakkında fikir sahibi olması, o işin başka kişiler tarafından yapıldıysa bilgilerinin paylaşılması, karşılaşılan hataların paylaşılması ve bu hatalar ile daha önceden karşılaşanların bilgilerini paylaşarak probleme daha hızlı çözüm üretmesini sağlar. Özellikle daha az bilgili takım elemanlarının bu konularda daha fazla bilgi ve tecrübeye sahip geliştiricilerden faydalanarak problemlere nasıl çözüm bulacağını anlaması ve takım olarak gelişmeyi arttırır. Ayrıca hergün takımın durumunu görerek projenin yolundan çıkmamasında önemli rol oynar.

Burda iletişimi sağlamak için kitap Scrum,XP gibi yöntemlerde kullanılan günlük toplantı yöntemini tavsiye ediyor. Ayakta toplantıların bir toplantı havasından çıkıp günlük bir aktivite olması için herzaman aynı yerde aynı saatte yapılmasını tavsiye ediyor. Burada toplantı deyince benim aklıma bitmek bilmeyen haftalık ya da aylık şirket toplantıları geliyor. Daha önceden bu tarz toplantılarda çok bulunmuştum açıkçası herkesin benim gibi bitsede kurtulsak modunda olduğunu görebiliyordum. Çünkü toplantı belli bir süre sonra gereksiz uzayıp çıkmaza giriyordu.Bazen kişiler arasındaki tartışmalara dönüşüyordu.Bu yüzden günlük ayakta toplantılar bu bakımdan oldukça verimli.Toplantının süresi 15 dakikayı geçemiyor. Herkes dün neler yapmış bugün neler yapacak onları anlatıyor. Ayrıca karşılaştığı problemler varsa onlardan bahsediyor. Bu şekilde problem ile daha önce karşılaşmış ya da çözümünü bilen biri toplantıdan sonra takım arkadaşına yardım ederek problemi daha hızlı çözmesini sağlıyor.Toplantıda tabi yaptığı işi anlatırken geliştirici işimin yarısını bitirdim diye yuvarlak cümlelerle değil dün login ekranını yaptım bugün şunları yapacağım diye daha açıklayıcı cümleler ile belirtiyor.

Kodunuzu Gözden Geçirin

Klasik adıyla Code Review. Sizinde başınıza mutlaka gelmiştir. Bir takımın içinde, diğer takım öğeleri tarafından yazılan kodun size tamamen yabancı hiçbirşey ifade etmediği durumlarla karşılaşmıştırsınız. Tabi bende karşılaştım. Başkasının yazdığı koda dokunmadığınız sürece problem yok fakat diğer takım arkadaşınızın başka bir projeye geçmesi, tatile çıkması, işten ayrılması vb.. gibi durumlarda kaçınılmaz son olarak kodu değiştirmek zorunda kaldığınızda asıl problem o zaman başlıyor demektir. Daha önce hiç görmediğiniz kod ile karşı karşılayısınız ne yapacaksınız kodun ne testi var, ne düzgün bir yapısı,okunaklı değil vs..İşte bu tarz problemlerle takım olarak çok fazla karşılaşmamak için kitap ve ben klasik adıyla Code Review yapmanızı şiddetle öneriyoruz :)

Yazılım geliştiren bir takımın bence iletişimi ve bilgiyi arttırma konusunda en efektif yöntemlerden biri. Ayrıca hataların bulunması ve problemlere daha çabuk çözüm bulunması için oldukça faydalı. Aslında çok basit bir işlem olmasına rağmen çoğu geliştirici ekibinde neden hala uygulanmıyor bir türlü anlamış değilim. Mantık çok basit geliştirdiğiniz bir özelliğin kodunu versiyon kontrol sistemine check in etmeden önce kodunuzu gözden geçirecek bir ya da birkaç takım üyesi bulun. Kodunuza bakıp fikirlerini söylesinler iyileştirme ya da hatalı bir özellik varsa bildirsinler ve ardından kodunuzu versiyon kontrol sistemine gönderin. Bu kadar basit. Ayrıca kodunuzu başka bir takım arkadaşınızla gözden geçirdiğinizde çözemediğiniz bir problem varsa ona anlatırken farklı bir perspektifle baktığınız için kafanızda büyük ihtimalle çözümü bulacaksınız.Buna Rubber Ducking deniyor.

Ayrıca tecrübeli elemanların acemi elemanlara kodları gözden geçirirken bilgi aktarması çok kolay.Özellikle Object Oriented,Design Patterns,Refactoring konularında bilgili deneyimli geliştiriciler kod gözden geçirmeleri sırasında bu bilgilerini takım üyelerine problemlemler üzerinde anlatıp takımın gelişmesine de katlı sağlarlar.Ayrıca gözden geçirme sırasında kodunuz karşıdaki tarafından anlaşılamıyorsa bu kodunuzu basitleştirmeniz gerektiğinin işaretidir.

Kod Değiştiği Zaman Uyarı Gönder

Bu kısımda versiyon kontrol sistemi gibi kodun herhangi bir yeri değiştiğinde gerekli kişilere uyarı mesajları halinde bunun bildirilmesini tavsiye ediyor.Özellikle kimin ne yaptığını izlemek için efektir bir yöntem olduğunu söylüyor.Bu konuda hiç tecrübem olmadığı için yorum yapamıyorum

Özet Liste

Yapılacaklar Listesi:

Herkes tarafından izlenebilir
Önceliklendirilmiş
Zaman tahmini yapılmış
Sürekli değişen

Teknik Lider:

Projenin özellik listesini yönetir
Developerların yaptığı işleri ve güncel durumlarını kontrol eder
Yapılacak özelliklere öncelik atamada yardımcı olur
Takımı dış etkilerden izole eder.

Günlük Toplantılar

Kısa tutulmalılar
Konular belirgin olmalı
Problemleri anlatın toplantıda çözmeye çalışmayın

Kod Gözden Geçirmeleri:

Küçük miktarda sık sık kodu gözden geçirin
Gözden geçiren sayısı bir ya da iki kişi olsun
Gözden geçirme yapılmadan kodu yayınlamayın

Code change notifications:

EMail ile değişiklikleri bildirin
Değiştirenin adını bildirin
Değişikliğin amacını yazın

Bedava E-Book , Foundations of Programming

Blogunu ve yazı serisini severek takip ettiğim Karl Seguin Foundations of Programming altında daha önceden yazdığı serilerini e-book formatında angelscamp.org toplamış. Kitapta gerçekten çok faydalı bilgiler bulacağınıza emin olabilirsiniz. Özellikle, OOP,DDD,TDD,.NET hakkında çok güzel bilgileri vermiş. Kitabı yukarıdaki linkten indirip okuyabilirsiniz.

Ship It: Bölüm 2

Tools and Infrastructure

Kitap ikinci bölümün ilk başında güzel bir hikaye anlatmış. Hikayede iki arkadaşın ev yapma hikayesi anlatılıyor. Kısaca isimleri değiştirerek bende anlatayım. Mehmet ve Cihat(kim acaba :) ) adında iki arkadaş aynı anda ev yapmaya başlıyorlar. Mehmet çekicini ve tornavidasını alarak hemen evi yapmaya başlıyor. Fakat Cihat iş için kompresör ,çivi çakma makinası.. gibi işini çok kolaylaştıracak modern araçları alıyor ve bunları öğrenmeye başlıyor. Tabi Mehmet’in evi yavaş yavaş ortaya çıkarken Cihat daha araçları öğrenmeyle uğraşıyor. Cihat araçları kullanmayı öğrendikten sonra onların verdiği avantajla çok hızlı bir şekilde evini bitirip Mehmet’i geçiyor.Cihat Mehmet evini yapmakla uğraşırken o araçları öğrenmeyle kaybettiği vaktini kolayca geri kazanıyor. Tabi bundan sonraki yaptıkları evlerde Cihat doğal olarak öğrenmiş olduğu araçları kullanarak çok hızlı sağlam evler yaparken Mehmet hala eski tekniklerle Cihat’a yetişmeye uğraşıyor.

Sizinde anladığınız gibi yazar yukarıdaki hikayeden yola çıkarak yazılım araçların ve altyapısının geliştirme için eski ilkel yöntemlere göre nasıl avantaj sağladığını,nasıl hızlı ve kaliteli ürünler ortaya çıkardığını anlatıyor.

Develop In A Sandbox

Bu kısımda özellikle yazılım geliştiricilerin dış etkilerden izole edilmiş bir ortamda çalışmalarını gerektiğini anlatıyor.Özellikle Versiyon Kontrol Sistemi ile herkesin kendi bilgisayarlarında diğerlerini etkilemeyecek şekilde çalışmaları gektiğini,her yazılımcının bilgisayarında diğerlerini etkilememek için Veritabanı,Web servisleri.. gibi yazılımların kurulu olması gerektiğini anlatıyor. Eğer geliştiriciler veritabanı lisansları gibi konular yüzünden tek veritabanı üzerinde çalışıyorlarsa bunun riskinide göze almaları gerektiğini söylüyor.

Manage Assets

Bu kısımda yazılımcının en değerli varlığının sadece kod ya da diğer dosyalar olduğunu bununda en iyi şekilde yönetmesi gerektiğini anlatıyor.Bunun versiyon kontrol sistemi ile sağlandığını ve faydalarını anlatıyor.Özellikle yazılım geliştirmek için tüm gerekli kütüphaneler grafik dosyaları xml dosyaları kısacası geliştirme ortamında kullanılan herşeyin Versiyon kontrol sisteminde olması gerektiğini anlatıyor.

Bunu daha önceden tecrübe ettiğim için iyi biliyorum. Herşeyi Versiyon kontrol sistemine atmadığınız zaman kodu sistemden çektiğinizde sürekli eksik dosyalar eksik kütüphaneler… ile uğraşmak zorunda kalıyorsunuz. Özellikle aklınızda bulunsun geliştirme ortamınızda kullanacağınız herşeyi ama herşeyi Versiyon kontrol sistemine atın.

Script Your Build

Bu bölümde geliştirdiğiniz programın çalışabilir hale getirmek için el ile yaptığınız adımları otomatik build scriptlerini kullanarak yapmanızı öneriyor. Özellikle çoğu kullanıcının Build denince kullandığı IDE nin build işlemi aklına geliyor. Fakat burada tamamen IDE den bağımsız o olmadan komut satırından çalıştırılacak bir komut,yada bir buton ile (ant build,make all.. gibi) yazılımın çalıştırılabilir bir sürümünün çıkarılma işlemini otomatikleştirmeyi anlatıyor.Yazarda benim yaşadığım aynı tecrübeleri kitaba aktarmış.

IDE kullanılarak yapılan Build işlemini anlatmış.IDE ile yapılan build işlemini hepiniz bilirsiniz. Önce kodu derleriz ardından başka bi dizine kopyalarız ardından biryerden bazı kütüphaneleri unutmuş oluruz onları kopyalarız. O dizinden çalıştırıp problem olmadığından emin oluruz… diye devam eden bir süreç. Otomatik build script ile sadece tek tuşla bunların hepsini yapmayı sağlayabiliriz. Kendim bizzat acısını çekerek otomatik build işlemine geçtiğimde daha önceden bu eziyeti neden çekiyormuşum kendime hayret etmiştim.

Burada yazarın en önemli vurgusu şu. Herhangi bir makina yazılımı hatasız build edebilmelidir. IDE ile build işlemi yapıldığında en çok karşılaşılan hatalardan biri build işlemini yapan developer ın makinasında çalışıp diğer makinalarda çalışmamasıdır(It works on my machine). Sebebide gelende developer makinasında olan kütüpane ayar gibi şeylerin diğer makinalarda olmaması eksik olması bu işlemlerin en ile yapılması hatanın asıl sebebidir malesef.Otomatik build scriptleri ile bunun önüne kolaylıkla geçebilirsiniz.

Build Automaticly

Bu kısımda otomatik build scriptlerinin bir sonraki adımı olan sürüm otomasyonu ve sürekli bütünleştirmeden(Continuous Integration) bahsediyor. Continuous Integration’ın temel felsefesi ayrı bir build server’da versiyon kontrol sistemindeki her kod değişikliğinden sonra bütün build işleminin tekrar yapılması ardından sonuçlarının çeşitli şekillerde geliştiricilere kullanıcılara sunulmasıdır. Bunun sağladığı en büyük fayda farklı makinalarda geliştirililen yazılımın entegre edilmesi sırasında bir sürü hata ortaya çıkması ve bu işlemin uzun süre almadı. Continuous Integration ile sürekli entegrasyon yapıldığı için hatalar anında yakalanabiliyor. Böylelikle geliştiriciler hatalı bir commit sonucunun build işleminde probleme yol açtığını kodu gönderdikten hemen sonra anlayabiliyor. Ayrıca bu sisteme testlerinde çalıştırılmasını eklediğinizde hataların ne kadar azaldığını düşünün.

Burada Continuous Integration aracı olarak meşhur open source CruiseControl’dan bahsetmiş. Bu kategoride birçok araç bulabilirsiniz ama unutmayın araçlar önemli değil önemli olan yapılış şekli herhangi bir aracıda kullanabilirsiniz.

Track Issues

Bu kısımda geliştirdiğiniz yazılım için hataların isteklerin takibi için Issue Trackler sisteminin bulunmasının önemini anlatıyor.Bu sistemde hatanın içeriği tüm detaylarıyla sisteme kayıt ediliyor.  Yazarın dediği Biz yazılım geliştiriciler unutkan insanlarız o yüzden yapmamız düzeltmemiz gereken önemli bug ve istekleri bu tarz bir sistemle veritabanında tutmazsak birgün mutlaka unutacağız. Ayrıca bununla alakalı yaşadığı bir anıyı anlatıyor. Müşterinin yapılmasını istediği önemli bir özellik yapılmayınca müşteri doğal olarak pek memnun olmuyor. Bu özelliği yapması gereken yazılımcı ise böyle bir istediğin gelmediğini söylüyor.Bu  Bir gün ofiste kağıda yazılı çok önemli unutma notunda o özelliğin açıklamasını yerde buluyorlar. Buda bu tarz bir sistemin gerekliliğini anlatıyor.

Bu tarz bir sistem sayesinde ayrıca yazılımcı neleri yapması gerektiğini sürekli görebiliyor. Yazılımda neler eksik hangi hatalar mevcut sürekli şeffaf izlenilebilir bir yapıda olduğu için önünüzü çok daha kolay görebiliyorsunuz.

Track Features

Bu kısımda da hataların izlenildiği gibi yazılıma eklenmesi gereken özelliklerin ya da özellik isteklerininde bu tarz bir sistemde tutulması gerektiğini anlatıyor. Gelen isteklerin önceliklerinin,sürelerinin belirlenip sisteme kayıt edilmesi önünüzde bir yapılacaklar listesi oluşturup sizin önünüzü görmenizi sağlıyor.

Use a Testing Harness

Evet en sevdiğim kısıma geldik.  Yazarın benimleaynı fikirleri paylaştığı için çok memnunum :). Bu kısımda test yazmanın faydaları ve en önemlisi bunun otomatik olarak yapılmasının önemi anlatılıyor. El ile yapılan testler çok zaman aldığı ve hataya daha açık oldukları için zamanda faydadan çok zarar getirmeye başlarlar. Bu yüzden iyi bir test otomasyon sistemi(JUnit,NUnit,EasyMock….)otomatikleştirilmesi anlatılıyor. Çeşitli test türlerinden de ayrıca bahsetmiş. Unit Test,Integration Test,Smoke Test,Functional Test, Acceptance Test leri kısaca anlatmış.

On Choosing Tools

Burada geliştirdiğimiz yazılımda araçların seçiminin önemi anlatılmış. Dikkat edin araçları kendiniz yazın demiyor :) Genelde yazılım dünyasına yeni atılanların en büyük heveslerinden biride herşeyi kendilerinin yazmak istemeleridir(itiraf ediyorum benimde öyleydi). Başkasının yazdığı aracı mümkünse kullanmayayım kendim baştan yazayım tarzı bir felsefe vardır. Burada bu bakımdan araçları ve  araçların seçiminin önemini anlatmış.Özellikle sizi illa kendisini kullanmaya zorlayan araçları kullanırken iki kere düşünmenizi tavsiye etmiş.Bencede tamamen haklı.

When Not to Experiment

Bu kısımda da araçları seçerken dikkatli olmamızı ve bunları sırf havalı yeni teknolojileri öğrenmek için değil gerçekten işe yaradığının kanıtlanıp ondan sonra kullanılmasını tavsiye ediyor.

Kitabın ikinci kısmı bu şekilde. Gördüğünüz gibi kısa kısa bahsettim aslında herbiri kendi başlığı altında ayrı bir kitap oluşturucak kadar detaylı konular. Genel başlıkları ile en iyi pratikleri vermeye çalışmış.Dikkat ederseniz zaten yukarıdaki yöntemler modern yazılım geliştirme tekniklerinin bel kemiğini oluşturuyor. Bu bakımdan başarılı bir proje için herkesin bu maddeleri gözden geçirmesi bence iyi olur. Bu arada kitabı bitireli baya oldu ama vakit ayırıp ancak yazabildim. Gerçekten çok güzel bir kitap.Sıraca 3. bölüm var onuda fırsat bulduğum vakit yazacağım….

Ship it! A Practical Guide to Successful Software Projects

prj

Hafta başında çok sevdiğim Pragmatic Programmer serisinden Ship It kitabını okumaya başladım. Bölüm bölüm okuduğum faydalı şeyleri burada sizlerle paylaşmaya çalışacağım.

Kitabın birinci bölümünde yol haritası niteliğinde bilgiler verilmiş. Özellikle Agile pratikler açısından iyi bir giriş olmuş. Özellikle bölümün başındaki güzel söz çok hoşuma gitti.

We are what we repeatedly do.
Excellence, then, is not an act, but a
habit.

See product Again would drive generic viagra sildenafil will find pinker I sildenafil citrate 100mg fall product it. Probably turns http://www.mordellgardens.com/saha/viagra-sales.html peptides works t my vermontvocals.org “here” After hair hair everyday viagra dose goprorestoration.com I great no cheap cialis generic brighten wipes eyecolor the teddyromano.com best cialis prices years actually hopes http://augustasapartments.com/qhio/cialis-free-sample and blame on http://www.teddyromano.com/free-cialis/ you it. Redder shave viagra india IT? Well-known expensive http://www.mordellgardens.com/saha/generic-viagra-sildenafil.html with and never use online pharmacy comb It’s spray cost cialis on Heck taper, it creativetours-morocco.com pharmacy and love this I.

Aristotle

 

 

Ayrıca kitapta yer alan faydalı pratiklerin posterini hemen internetten indirip masaüstü arka planına koydum.Burayada sizler için yerleştireyim.Posterde gerçekten yazılım geliştirmede çok önemli olan anahtar pratikler verilmiş. Özellikle Agile pratiklerin çoğunu aşağıdaki resimde görebilirsiniz.Sizi posterle başbaşa bırakıyorum. Ben kitabı okumaya kaçar :) ….

keyPractices

Practices of an Agile Developer Working in The Real World

pad Bu aralar yolda gidip gelirken Practices of an Agile Developer Working in The Real World kitabını okuyorum. Oldukça eğlenceli ve bir o kadar yararlı bir kitap. Bir yazılımcı için Agile development felsefesi genel olarak anlatıyor. Kitap kısa ve öz yaklaşık 200 sayfa civarı ve anlatılan konular genel olarak yazılım geliştirme sürecinde kodlamadan müşteri ilişkilerine ,takım içi iletişimden, günlük yapılan birçok işleme kadar oldukça pratik bilgiler anlatıyor. En çok hoşuma giden tarafıda şeytan-melek diyalogları örnek olarak şöyle bir diyalog vardı;

Şeytan : Kodu gerçekten anlamana gerek yok zaten çalışıyora benziyor. Sadece küçük bir takla attırılmaya ihtiyacı var. Bir iki satır kod ekle muhtemelen çalışacaktır

Melek : Kodun temiz sade anlaşılabilir tutmak için uğraş.

Gerçekten içimizdeki şeytanın sesine kulak vermişler. :)

 

Programın içinde bütün bölümlerde bu

tarz şeytanın vesveselerine karşı gerçekten yapmamız gereken meleğin tavsiyeleri yer alıyor. Kitabı oldukça eğlenceli buldum herkese tavsiye ediyorum.

Son olarakta şeytana uymayalım uyanları uyaralım diyorum :)

Test-Driven Development: A Practical Guide

TDDPracticalTest Driven Development’a yeni baştan sağlam bir başlangıç yapmak için kitap okumaya karar verdim. Test-Driven Development: A Practical Guide TDD temellerini örnek bir proje üzerinde adım adım ilerleyerek öğretiyor. Proje ufak bir film yöneticisi, Java ve Swing kullanılarak yapılıyor. Genelde pratiğe yönelik kitapları okumayı sevdiğim için şuanda kadar oldukça iyi gidiyor. Yeni başlayanlara tavsiye ederim.

Kitabı bitireli oldukça zaman olmuş ama bu yorumu sonradan bu yazıya eklemek istedim.TDD geçmişim yaklaşık 2 seneye geliyor.

Bu kitaptan sonra birçok kitap,makale,ve yazıdan faydalandım ama hala bu kitabı benim için en önemli kaynaklardan biri olarak görüyorum. Test Driven Development hakkında gerçekten bu kitaptan çok faydalandım.Özellikle pratik bakımından küçükte olsa bir projeji baştan sona geliştirmesi TDD’nin projede nasıl işlediğini görmem açısından oldukça iyi olmuştu.

Kitabın içinde Unit testing,Mock objects,GUI testing,Refactoring.. birçok konuda oldukça faydalı bilgiler veriliyor. En sonunda da TDD ile yazılan kodun kalitesi metrikler ile ölçülüp gözden geçiriliyor. Özellikle GUI testing gibi uğraştırıcı bir konuda kitaptan oldukça faydalanmıştım. Herkese tekrar mutlaka okumasını tavsiye ediyorum.