Sık söylediğim laflardan biri şudur : "If you can automate it, automate it". DRY (kendini tekrarlamamak/do not repeat yourself) sadece kod yazma sırasında değil bence hayatın her noktasında önemli bir şey. Özetle eğer bir şeyi otomatiğe bağlama şansın varsa hemen şimdi bunu yap. İlk internet sitemi yayınladığımda hayat çok farklıydı siteyi en ufak bir değişiklik için FTP ile her seferinde güncellemek ve tek kişilik CMS sistemi olmak rezil bir deneyimdi. İlk blog sistemimi yazdığımda da bazı şeyler fark ettim blog yazmaya başlamam ne kadar çetrefilli ise o kadar az blog yazıyordum, yani sistemin kendi limitleri veya gereksinimleri blog yazmamı engelliyordu.

Bu sadece teknik veya vakit ile ilgili bir sorun değil bu psikolojik bir sorun. İnsan doğası sıkıcı işleri sevmiyor ve rutin işler insana sıkıcı geliyor. Bir geliştirici olarak kendinizi bir rutin içerisinde bulursanız gidişatta bir hata var demektir. Belki Ruby On Rails' ın çıkışı veya binlerce framework' ün tetikleyicisi de budur.

Yazılım geliştirirken gerekli otomasyonu yapıyor musunuz?

• Veritabanında değişiklik yaptıktan sonra ORM' de kodların belirmesi için kaç tuşa basman gerekli?
• Yazılıma yeni bir eklenti eklendiğinde Unit Test' ler otomatik olarak çalışıyor mu?
• Aynı kodu tekrar ve tekrar yazıyor musun?
• Koddaki değişiklikten yazılım paketinin internette yayınlanması arasında kaç tane manuel işlem var?

Daha önceden büyük resmi görebilmek ile ilgili bir yazı yazmıştım, yazılım geliştirirken ve başka işler yaparken de büyük resmi görebilmek lazım.

• Sisteminizde otomatiğe bağlayabileceğiniz şeylerin listesini çıkartın
• Listedeki her başlık için "Otomatiğe bağlamak ne kadar sürer?", "Otomatik olmadığında hata oranı nedir?", "Bu işlemin ne kadar sıklıkla yapılması gerekiyor?" sorularını kendinize sorun ve cevaplarını düşünün. Otomasyona harcayacağınız vakit kendini 1 haftada amorti ediyor olabilir ya da hata çıkma oranından dolayı potansiyel bir hata da otomasyona harcayacağınız vakit kadar hatayı düzeltmeye ya da tespit etmeye vakit harcayacak olabilirsiniz.

Eğer programcı değilseniz hala hayatınızda otomatiğe bağlayabileceğiniz şeyler var:

• Faturalarınızı, kiranızı vs. otomatik olarak ödeyin
• İnternette okuduğunuz yazılara siz gitmeyin RSS okuyucu kullanın onları size gelsin
• Bilgisayarınızdaki rutin işlemleri otomatiğe bağlayın

Bunların hepsini otomatiğe bağladıktan sonra, para kazanmayı da otomatiğe bağlayınca Kuala Lumpur' da sahilde uzanıp otomatiğe bağladığınız her şeyi unutabilir ve belki de hayatın tadını çıkartabilirsiniz…

I've got a routine of extracting downloaded video files, appending subtitles where required and moving them to the server that my PS3 connects, so I can watch it on my TV. This process involves about 3 steps, 1-2 minutes waiting, worse I have to be in front of the computer (second floor) to do these.

This weekend I decided to put an end to my misery and developed a small application which watches a folder and carries out defined rules based on the created/renamed files in the folder. After about 2-3 hours of hacking I end up with Psycho Folder. Just modify the Rules.xml, define your own rules and let it do the job for you. After I saw it on action and really liked it and spent another couple of hours for polishing.

It's written .NET Framework 2.0, get the source code or get the installer to give it a try. Report a bug or request a feature.

Diyelim ki bir uygulama için raporlama fonksiyonu geliştiriyorsunuz. Bu raporların CVS ve HTML formatını desteklemeleri gerekiyor. Bu durumda iki seçeneğiniz var:

• İki fonksiyon yazmak
  • Rapor datasını alıp CSV çıktı üreten bir fonksiyon,
  • Rapor datasını alıp HTML çıktı üreten bir fonksiyon.
• Bir raporlama sistemi yazmak;
  • CSV ve HTML için iki şablon tasarlanır,
  • Raporlama sistemine Rapor Datası verilir,
  • Raporlama sistemine Rapor Şablonu verilir,
  • Raporlama sistemi bu iki bilgiyi birleştirip raporları oluşturur,
  • Bu altyapı kullanıcıdan gizlenir içeride kullanılır. Gerekirse gelişmiş kullanıcılarda bu rapor sistemini kullanarak daha sonradan yeni rapor tipleri üretebilirler. Mesela XML rapor alabilirler.

Birinci yolun avantajları ve dezavantajları:

• Hızlı bir şekilde sonuca ulaşmak, kodun çok daha basit olması.

İkinci Yolun Avantajları

• Prezantasyon ile datanın temiz şekilde ayrılmış olması,
• Daha sonradan yeni bir rapor formatı gerektiğinde tekrar kod yazmaya gerek olmaması,
• Daha sonradan bu fonksiyonun kullanıcılara açılabilmesi.

Şimdi geniş ölçekte farklı yolları seçen yazılımları görelim:

• Internet Explorer
  Birinci yolu seçen yazılımlardan.
• Firefox
  İkinci yolu seçen yazılımlardan. Firefox bir onlarca fonksiyonu XUL Framework' ü üzerine inşa etti. Dolayısla aynı raporlama sistemi gibi XUL sistemini yazdılar. Daha sonradan geniş bir API ile onu desteklediler ve aynı herhangi biri Firefox için eklenti (addon) yazarmış gibi Firefox' un iç sistemini geliştirdiler. Daha sonrada bunu kullanıcıya açtılar. Açılan API çok güçlüydü çünkü geliştiriler XUL ile bir şeyler geliştirirken API yüzünden tıkandıklarında API' ı geliştirdiler dolayısıyla tüm sistem çok daha güçlü bir hal aldı.

Benzer örneklerden gidersek Macromedia' nın hemen hemen tüm ürünleri de aynı şekilde geliştirilmiştir. Ana motor JavaScript + Macromedia' nın güçlü API larını destekler. Aynı XUL gibi JavaScript ve bu API' lar birleştirilerek extension' lar yazılabilir. Eğer Dreamweaver, Flash gibi yazılımların altyapılarını incelerseniz ana sistemden sonraki hemen hemen tüm yazılımın JavaScript ile yazılmış olduğunu görebilirsiniz. Yani bu kodları değiştirerek aslında tüm yazılım arabirimlerine kadar değiştirebilir ya da yeni fonksiyonalite ekleyebilirsiniz.

Burada bence unutulmaması gereken şey geliştirilen yazılımın boyutudur. Yani Macromedia ya da Firefox bu tip bir framework' ü destekleyebilir ama küçük bir takım için bu seçim büyük bir yanlış olabilir. Ama raporlama sistemi küçük olduğundan tek kişi olarak çalışan bir geliştirici bile raporlama sistemini özel bir çözüm yerine bu şekilde genel bir çözüm olarak geliştirebilir.

Benim naçizane fikrim iyi programcılar her zaman ikinci genel çözümü yapmak ister, ancak hayatın gerçekleri işin yönünü değiştirebilir.

Her ne kadar TDD ve Unit Testing' i bir boyutta uygulasam da yazılım geliştirirken XP (extreme programming) ya da benzer bir metodolojiyi sıkı sıkıya takip etmiyorum. Her konuda yaptığım gibi açık fikirli olup, değişik yaklaşımları analiz edip, haklarında bilgi toparlayıp kendi durumuma göre kendi hybrid modelimi kullanmaya çalıştırıyorum. Bu aralar özellikle yazılım geliştirme ile çok iç içeyim ve bunun sonucunda Unit Testing, TDD ve Functional Testing konularında denemeler yapıp en iyi birleşimi bulmaya, işimi en iyi görecek çözüme ulaşmaya çalışıyorum.

Devam etmeden Functional Testing ile Unit Testing' e ve aralarındaki farklara bakalım.

Unit Testing

• Sistemin en küçük birimlerini test etmektir,
• Hızlıdırlar,
• İzolasyon kritiktir ve hiç bir testin diğer testleri ya bir dış kaynağın çalışan testleri etkilememesi gerekir. Bu amacı yerine getirmek için bir web server ya da file system erişimde, ya da diğer herhangi bir class ile konuşma noktasında Mocking devreye girer,
• Kodda hata oluştuğunda kesin olarak hatanın nerede oluştuğunu saptamak çok kolaydır. (Çünkü sistemin en küçük birimlerini test ediyoruz),
• Yüksek Code Coverage almaya uygundur,
• Genelde koddaki her değişiklikten sonra çalıştırılır. Bu sayede kodda gözü kapalı değişiklik yapabilir ve bir sorun varsa anında farkına varabilirsiniz. Bunun anlamı sorun çok daha büyümeden ya da tasarımın içerisine girmeden sorunu çözmek demektir.

Functional Testing (Automated)

• Sistemin parçalarını ya da sistemin bütün olarak işleyişini otomatik şekilde test etmektir,
• Daha gerçekçi testler ortaya çıkmasını sağlar,
• Yavaştırlar (izolasyonun az olması bunun ana nedenidir),
• Kodun bir yerinde hata oluşması testlerin büyük bir kısmını geçersiz hale getirebilir,
• Kodda hata oluştuğunda nokta atışı hatayı bulmak pek basit olmayabilir,
• Bazı testler Unit Testing' e göre çok daha hızlı yazılabilir, çünkü çok daha az test yapmak gerekir. Mesela bir class' ın private method' ları vs. test edilmez. Class' ın geneli beklendiği gibi çalışması yeterlidir,
• Code Coverage' i yükseltmek zor olabilir çünkü her durumu geniş perspektiften simule etmek mümkün olmayabilir ya da gereğinden çok efor gerektirebilir,
• Yavaşlığından dolayı ve coverage azlığından dolayı her kod değişikliğinden ya da yeni koddan sonra çalıştırılmaya pek uygun değildir.

Functional Testing' i Unit Testing ile birlikte kullanmak popüler kullanımlardan biri, bu sayede en ince detayda ve tam bir bütün olarak kodun beklenildiği gibi çalıştığı otomatik olarak kontrol edilebilir.

Genel olarak insanların TDD (önce test, sonra kod) ya da klasik Unit Testing yapmamalarının nedeni testleri yazmanın getirdiği ekstra külfet. Özellikle Türkiye gibi agresif, kısa deadline' lı projeler ile dolup taşan yerlerde yazılımcılara Unit Testing önermek küfürmüş gibi algılanıyor. Açıkçası kimse gerçek bir getirisi olmayan bir şey için ekstra vakit ayırmak istemez ama bu işin gerçek ve gözle görülür bir getirisi var (kanıtlanmış mı? Hem evet hem hayır! o başka bir yazı konusu).

Hybrid Model
Eğer...

• Yazılımınınız çok kritik bir iş yapmıyorsa, (örnek: Ayda cirit atacak robot kontrolü, Nükleer füze tetikleyicisi, Merkez Bankasının para-girdi çıktı düzenleyicisi, Britney Spears' a hava durumuna göre ayakkabı önermeciliği )
• Geniş bir takıma ve uzun, rahat geliştirme planına sahip değilseniz,
• Az koyup çok almak istiyorsanız...

bu model sizin işinizi görebilir. Pareto Prensibini bilirsiniz, hani şu 80/20 kuralı. Bir süredir bu mantığa dayanarak Functional Testing ile ve aralarda Unit Testing desteği ile bir proje geliştiriyorum ve otomatik testlerden alacağım faydanın %80' ini %20 efor ile aldığıma inanıyorum.

• Private method vs. leri test etmiyorum,
• Çok az mock objesi kullanıyorum,
• Aşırı izolasyon yapmıyorum,
• Küçük detayların harici uzun soluklu functional testlere odaklanıyorum,
• Hata çıkarma olasılığı çok olan, kritik olan kod kısımlarını Unit Testing ile destekliyorum.

Bu modelin en ciddi sorunlarından biri kodun highly coupled (Law of Demeter) olmasına izin veriyor. Tabii ki bunu düzeltmek geliştirici olarak sizin elinizde ama TDD odaklı bir geliştirmede highly coupled class' lar bulmanız pek mümkün olmayacaktır. Açıkçası highly/tightly coupled olmayan kod yazmak gerçekten zor bir iş.

Bu benim yaklaşımım şu ana kadar benim için istediğim kıvamda çalıştığını söyleyebilirim. Eğer şimdiye kadar hiç yapmadıysanız bu şekilde hafif bir başlangıç yapabilir ve biraz tadını çıkartabilirsiniz.
Farklı deneyimleri duymak da hoşuma gider. Özellikle Unit Testing yapıp mutlu olanlar ya da yapmayı deneyip verim alamayanlar gibi.

Üç sene kadar önce silahını tanı başlıklı bir yazı yazmıştım. Dün Visual Studio ile biraz vakit harcayıp istediğim hale getirdim, Visual Studio konusunda bilmeniz gereken bazı temel şeyler var:

• Visual Studio' nun Express Edition' ları tamamen ücretsiz, Yalnız bu Express Edition' lar aşadağıdaki gibi bazen çok önemli olabilecek şeyleri desteklemiyor:

  Class Designer
  FxCop Entegrasyonu
  Gelişmiş Debug Seçenekleri (özellikle condition dayalı breakpoint' lerin olmaması)
  VS.NET eklenti Desteği
  Multi-Thread Debugging Desteği
  Farklı .NET dillerinde projeleri aynı proje üzerinden yönetebilme

• Tüm kendi özelleştirmelerinizi Export / Import edebilirsiniz. Bu sayede tüm özelleştirmeleri bir defa yapmanız yeterli. Daha sonra Tüm VS sistemlerine bunları basitçe taşıyabilirsiniz.
• Pencereler iki ana durumda saklanıyor, birinci geliştirme süreci, ikincisi debugging yaparken. Bunlar her zaman son olarak kullandığınız şekilde saklanıyorlar. Mesela debugging yaparken "Immediate" penceresini ikinci monitöre taşırsanız, bir sonraki debugging' e başladığınızda "Immediate" penceresi gene ikinci monitöre geçecek ve debugging' i bitirdiğinizde geliştirme sürecindeki yerine geri dönecektir.
• Visual Studio' da Bilmeniz Gereken Kısa Yollar

VS.NET 2008 Team System ve MBUnit

VS.NET 2008 Team System Unit Testing Framework' ü ile birlikte geliyor ama normalde bu sadece MS Unit Testleri ile çalışıyor. Eğer siz de benim gibi Row Testing' ten vazgeçemeyenlerdenseniz nUnit (son versiyonu) ya da MbUnit gibi bir framework kullanıyor olacaksınız ve bu durumda VS.NET' in Test çözümü yerine ekstra bir yazılıma ihtiyaç duyacaksınız.

MbUnit v3' VS.Net 2008 Team System için tam entegre bir çözüm geliştirmiş yani ekstra bir Unit Testlerinizi test edecek ekstra bir araç yerine VS.NET ile olan Test pencerelerini kullanabilir hale gelebilirsiniz. Bunun için şunlara ihtiyacınız var :

• VS.NET Team Team System 2008 + SP1
• MbUnit v3

Ek olarak MbUnit v3 yenilikleri, MbUnit ve VS.NET ve VS.NET' te test projelerini nasıl belirtebilirsiniz yazılarını okumanızı şiddetle tavsiye ederim. Şu an ben bunu kullanır hale geldi ve TestDriven.NET ya da ReSharper olmadan VS.NET içerisinde testleri çalıştırmak çok keyifli.

VS.NET 2008 Hızlı Kod Yazma Eklentileri

Bu konuda iki tane çok popüler eklenti var :

• CodeRush + Refactor! Pro ( VB.NET için ücretsiz versiyonu da var)
• ReSharper (C# için ücretsiz versiyonu da var – bunun linkini bulamadım ama eminim böyle bir şey var!)

Maalesef bu iki eklentinin de tam verisyonu ücretli ve biraz da pahalı ama verdikler hız etkisini düşününce muhtemelen iki ay içerisinde paranızı geri almış olacaksınız. İkisi arasında benim tercihim CodeRush.

Bazı diğer eklentiler.

Şekil Yapma

• Güzel bir programalama fontu seçin (Benim favorim Consolas)
• Kodlama panelindeki renklendirmeyi düzenleyin (Ben klasik renkleri çok az değiştirerek kullanıyorum, arkaplanı ise genel açık-gri seçiyorum)

VS.NET İpuçları

Bir sürü ipucu sitesi ve kaynağı var ama Sara Ford' un websitesi sanırım bu sitelerin içerisindeki en iyilerden biri. Şu an itibari ile 372 ipucu var, bazıları "File altında Open diye bir menü var, biliyor muydunuz?" derecesinde salakken bazıları gerçekten de çok güzel. Takibe ve arşivlerini analiz okumaya değer.

Visual Studio sandığınızdan çok daha güçlü, güzel ve gelişmiş şekilde. Son olarak ben de zamanında VS.NET' e küçük bir eklenti yazmıştım, The Guardian (download). VS.NET 2008 ile çalışığ çalışmadığını bile bilmiyorum ama ilginizi çekebilir. Süper dağınık bir yazının sonuna geldik, umarım siz parçaları birleştirebilir ve bu yazıdan işinize yarayan bir şeyler çıkartabilirsiniz.

Programcılık kısa zamanda takıntıya dönüşen işlerden biri sanırım. Sitenin düzenli takipçileri farketmişlerdir bu aralar pek bir şey yazamadım. Genel mevzular dışında yoğun şekilde programlama yapıyorum. Son üç günüm tam anlamıyla feciydi. .NET ile SSL trafiğinede müdahaleyi sağlayacak bir proxy server yazmak ile uğraşıyorum. Aslında daha önceden XSS Tunnel için bir proxy yazmıştım ancak o proxy SSL, keep-alive desteklemiyor ve daima tek bir server ile HTTP objeleri üzerinden konuşuyordu.

Dolayısıyla TCP ile sadece tarayıcıdan proxy' ye gelen istekleri işliyordum, diğer taraf gene .NET' in HTTPWebRequest objelerini kullanıyordu. Gelen cevabı da değiştirip tarayıcıya geri gönderiyordum.

Bu yeni sistemde ise tam bir proxy implemantasyonu yapıyorum. Yaptığım iş tam olarak MITM – Attacking / Debugging proxylerin yaptığı işin aynısı. Bunun da bir çok gereksinimi var. SSL' e MITM yapmanız gerekiyor, HTTP Protokolünü kendiniz implemente etminiz gerekiyor. Son üç-dört gündür vaktimi harcadığım konular:

• .NET' te TCPClient ile SSL bağlantısını self-signed bir sertifika ile kabul etme
• TCPClient ile Chunked encoding' i destekleme
• HTTP/HTTPS implementasyonu
• Gzip, Deflate' i anlama, decode edebilme

Bazıları uzun, bazıları kısa sürdü ama bazı noktalarda ciddi derecede bunalıma girdim. Eğer 3 saat süreceğini planladığınız bir iş 2 gün sürüyorsa moraliniz bozuluyor ve bazen öyle bir noktaya geliyorsunuz ki "Acaba sonuçlar buna değecek mi?" ya da "Hiç bir zaman çalışmayacak mı?" gibi soruları kendinize sormaya başlıyorsunuz.

Ama Allaha şükür dört günün sonunda bir dizi hata ayıkladıktan sonra, tuhaf sorunlar ile karşılaştıktan sonra, HTTP RFC' lerini daha detaylı okuduktan sonra sistem çalışmaya başladı. Kodu deneysel aşamadan kurtarıp adam akıllı bir hale sokmak ve çeşitli şekillerde test etmek, performansı artırmak biraz daha vakit alacak ama bundan sonrası basit.

Bu arada programcılıkta akıcı noktayı yakalamak ile ilgili bu grafik çok hoşuma gitti. Neyse bu kadar işten sonra ödülü hakettim değil mi?

Yazar Call of Duty 5 Multiplayer' ı açar ve "Capture the flag" çığlıkları arasında çeşitli Yankee ve Japon askerlerini öldürür....

YAGNI - You Ain't Gonna Need It,  yazılım çevrelerinde kabul gören ve benim de şiddetle izlemeye çalıştığım prensiplerden biridir. Basit şekilde "bir şeye ihtiyacın yoksa yapma, ne zaman ihtiyacın olur o zaman yaparsın" diye özetlenebilir.

Bugün aklıma şu soru geldi: Bu prensibi bilgiye de uygulayabilir miyiz? Mesela "İspanyolca öğrenmeye henüz ihtiyacım yok, niye gidip İspanyolca öğreneyim ki?" Ya da "Ruby on Rails" seksi duruyor ama henüz benim bir işime yaramıyor gibi. Bu konu hafiften Genel Kültür Çağımızın En Büyük Yalanıdır konusu ile de ilişkili, henüz ben bir karara varamadım, karara varıp varmamak pratik yaşantıda ne kadar şeyi etkileyecek emin değilim ama ilginç sonuçlar getirebilir.

SQL Injection'dan Korunma Video

Küçük bir sistem üzerinde çalışıyorum, Tag desteklemesini istiyorum. Veritabanını planlarken Tag kısmına gelince kafamda bir iki fikir canlandı. Hemen internetten diğer sistemlerin Tag desteklerinin nasıl olduğuna baktım. Özetle "Best Practice" leri incelemek lazım.

Tags: Database schemas makalesi süper 3 ana modelden bahsediyor ve basit şekilde artı / eskilerini irdeliyor. Tagschema diye de tamamen bu konuya odaklanmış deli bir blog var (oha artık sadece bununla ilgili blog mu olur!).

Tags: Database schemas makalesinden sonra benim aklımdakini ortaya koymak istedim nitekim sistemi de bu şekilde geliştireceğim. Muhtemelen bu model' de daha önceden yapılmış ve kullanılmaktadır zaten.

Kafamdaki yapı Tag + Trove Kategori sisteminin birleşmesi ile oluşmakta. Ancak Tag' ların serbestliğini kısıtlamamak için onlarda "Unattanded Tag" olarak girilebilecekler. Daha sonradan veya giriş anında gönüllü veya yönetici sahipsiz tagları ilgili kategoriler ile ilişkilendirebilecek.

Burada ortaya çıkacak sorunlardan biri iki kategoride aynı isme sahip olan taglar (mesela: grafik>rezil, programlama>rezil) karışıklığı. Aslında bu tag sistemi yapısının ana düşüncesini kırıyor mı kırmıyor mu tam çözebilmiş değilim. Örnek olarak bir makale "rezil" tagı içeriyorsa tüm diğer alakasız rezillikler ile de ilişkilimidir? Bir açıdan evet bir açıdan hayır. Bu durumdaki taglarada "Relative Tag" lar diyebiliriz. Bu da iki tip tag ve sonuç oluşturacaktır.

Database Yapısına bakacak olursak şu şekilde olmalı;

Post
-------------
id
title
post

TroveTag
---------------
id
parent_id
tag

TagAndPost
----------------
post_id
tag_id

Yeni bir post anında önceden olmayan Taglar oluşturulacak ve db' ye girilecek. Eğer önceden varsa onunla ilişkilendirilecek ("Relative Tag" sorunu burada soru olarak çözümlenmeli - ya da direk es geçilmeli)

Dezavantajlardan biri çok pratik bir query ile datalar çekilemeyecektir. Sonuç olarak elimizde Sonsuz kategori destekleyen gerçek kategorili ve Tag' lı bir sistem var. Bu da blog sistemlerindeki ikinci "kategori" tablosunun ortadan kalkmasına ve sınıflandırma sisteminin tek yerden kontrol edilmesine de izin veriyor. Ek olarak postlar arasındaki ilişkilerde daha kesinleşiyor. Mesela bu yöntem ve biraz ekstra SQL ile "ilişkili yazılar" çok daha verimli şekilde sunulabilir.

Sadece e-mail ile yazışma yapan bir pozisyonda ya da donanımlar üzerinde ar-ge yapan bir pozisyonda olabilirsiniz. Ancak burada önemli olan kullandığınız yazılımları, araçları iyi tanımanız ve kilit olanlar ile yakın dost olmanıdır.

Grafiker, Sekreter, Programcı, Güvenlik Uzmanı olmanız önemli değil Outlook' u, Open Office' i, Excel' i, Visual Studio' u, Photoshop' u sonuna kadar sömürerek en verimli şekilde kullanmanız önemli. Size hergün ekstra bir dk. kazandıracak ayarları yapmanız, kısayolları bilmeniz ve özelleştirmeniz önemli. Şahsen .NET' te kendinizi geliştirirken Visual Studio IDE' si üzerine bir kitap, yardım dosyası ya da makale okumamanızı talihsizce bir hareket olarak nitelendiririm.

İkinci bir nokta ise silahınızı iyi seçmek. Şu an bir çok konuda bir çok yazılım var. Kimini ücret yüzünden tercih edebilirsiniz kimini ise daha önceki yakınlıklarınız yüzünden. Örnek olarak VS ile geliştirme yapıyorsanız Kod Kontrol Sistemi (CVS, VSS vs.) nizi seçmeniz gerekiyor. Bu klasik CVS olabileceği gibi, VSS (Visual Source Safe), Vault vs. de olabilir. Bu yazılımlar arasında gerekli karşılaştırmaları yapın, fiyat performansınızı düşünün, Visual Studio ile entegrasyonlarını görün, bunları test edin ve beğendiğinizi kullanmaya başlayın.

Anında aksiyona dalmaktansa sakin davranın, önce kurcalayın daha sonra yardım dosyalarına, başlarken (getting started) kısmına bir göz atın. Daha sonra da piyasadan geri kalmayın yeni yazılımlara fırsat buldukça gözatın, her zaman yeni ve daha iyiler gelmiş olabilir. Bazen de yeni versiyonlar ve yazılımlar tamamen çöp olabilir. (Bu çöp lafının bu şekilde cümlede kullanılması gavurların "trash" kelimesini bu şekilde kullanmalarından ileri geliyor ve çok amerikanvari salakça bir kelime)

Aynı şekilde ORM sisteminin seçimi de güzel örneklerden biri, sık değiştiremeyeceğiniz ve kritik geliştirme sürecinizin bir parçası. Ek olarak şu an sırf .NET için 30' un üzerinde ORM uygulamasının olduğunu söyleyebiliriz.

Bunun yanında hergün kullandığınız Internet Explorer, Firefox, Opera, Konquer veya herneyse. Onu da bilmeniz yönetebilmeniz, hızlı kullanmanız, diğer aygıtlarınızla entegre edebilmeniz, hızlandırmanız, sevmeniz, saymanız gerekiyor. Herkes kullanıyor diye sömürmelesiniz.

Özetle silahını seç ve sev. Bir de bu işten zevk alırsanız ki o zaman geceleri lanet olası karanlıktan "geeeeek", "geeek" sesleri duyabilirsiniz (bakınız gene amerikanvari cümle yapısı içerisine girdim ki yakında -hey dostum senin sorunun o koca beyaz kıçın- diye başlık atmaktan korkuyorum). Bu da artık daha az radyasyona maruz kalmanız gerektiğini sevgilinizin beyninden sonra sizinde beyninizde kesinleştirir.