Yazılım Günlüğü

[25/7/2005]

Dün gece kaç gündür scrumdevelopment grubunda süregiden bir tartışmayı okumaya başladım: Critical Chain yani Kritik Zincir yönetimi ve bunun yazılım projelerinde kullanılması.

Öncelikle bu gruptaki tartışmaları izlerken Scrum diye ortaya çıkan insanların aslında ne kadar zengin bir birikime sahip olduklarını gördüğümü söylemeliyim. Pek modaya takılacak insanlara benzemiyorlar.

İşin diğer ilginç yanı, yazılım mühendisliğinde Kritik Zincir’in tartışılması oldu. Bir süredir üretim planlaması alanında çalışıyorum ve bu sahada TOC (Theory of Constraints) denen bir yaklaşım var: kapasite darboğazların analiz edilip planlamanın buna göre yapılması şeklinde özetlenebilecek bir yaklaşım. Bunun yazılım projelerinde uygulanması da Scrum grubunda tartışılınca konu daha da ilgimi çekti. Kritik Zincir yaklaşımı klasik proje planlamadan oldukça farklı. Projenin planlanması aşamasında WBS (Work Breakdown Structure)’dan çok projenin çıktılarına bakarak, sondan geriye doğru gelerek bir planlama yapıyor.

Bu yöntemde her bir iş (task) için bir başlama ve bitirme tarihi tespit etmek yerine her iş için gerekecek iki süre tespit ediliyor: işlerin iyi gitmesi halinde o işin bitirilebileceği olası süre ve işler aksasa da iyi kötü garanti edilebilecek söz verilebilir süre. (Belki bizim yönetim bilimcilerimiz bunları farklı isimlerle adlandırmışlardır ama google bana bunları görebileceğim bir kaynak bulamadı.) İlk süre elbette ikincisinden daha kısa sürüyor ve planlamada esas alınan o. Yani bir nevi iyimser bir plan yapılıyor. Ancak bu süre ile garanti edilebilir süre arasındaki fark da ihmal edilmiyor. Tüm işlerin garanti edilebilir süreleriyle olası süreleri arasındaki zaman farkları, projenin sonunda toplanarak tampon bir bölge oluşturuluyor.

Proje faaliyete geçtiğinde dikkat sürekli kalan işte, yapılan kısmında değil. (İşte bu açıdan Scrum’la oldukça benzerlik taşıyor. Scrum’da da kazanılan değere (Earned Value’ya) değil, burndown chart ile ne kadar iş kaldığına bakıyorsunuz sürekli.) Yönetici tamponun bir kısmının kullanılacağını kabul ediyor baştan. Ama tamponun kullanılma hızını sürekli kontrol altında tutuyor. Eğer tamponun kullanılma hızı, tamamlanan işlerin hızıyla orantılıysa paniğe gerek duymuyor, çünkü her işin hep olası zamanlarında bitmesini beklemek saflık olur.

Kritik Zincir yaklaşımının önemli bir faydası da var: WBS tabanlı “klasik” proje yönetiminde tahminlerde bulunurken her bir iş (task) için, başarımızı garanti etmek için en olası süreyi değil, garanti edilebilir süreyi tahminimiz olarak söyleriz. Parkinson kanunu bize bir iş için, daha çabuk bitme potansiyeli olsa bile hep kendisi için planlanan süreyi kullandığını söylüyor. Kritik Zincir yaklaşımı ile olası ve garanti edilebilir süreler arasındaki fark gözle görülür hale geldiğinden bu psikolojik yavaşlatıcı etkenden bir nebze olsun kurtulabilmek mümkün görünüyor. Scrumdevelopment grubunda buna dair yazılım dünyasından da bir örnek üzerinde bayağı tartışıldı.

Çok iyi yazılmış ama yine de biraz zor bir metnin bağını vereyim burada: Focused Performance sitesinde Parkinson kanunu ve sürecin geri kalanıyla ilgili bayağı ciddi bir makale bulabilirsiniz. Bu konuda asıl literatürü geliştiren Eli Goldrat imiş. Kitapları herhalde ilgiyle okunabilir.

Scrum tartışmasına dönersek, Scrum’da tampon olarak bahsettiğimiz iki süre arasındaki fark yerine az önceliği olan özelliklerin geliştirilmesi kullanılıyor. Diğer yandan Kritik Zincir’deki gibi bir bağımlılık ağı (dependency network) bulunmuyor. Scrum’da Sprint’e başlarken hangi işleri yapacağınızı yapıp bırakıyorsunuz o kadar. Zaten bir sprint’de hangi işleri ne kadar sürede yapacağınıza karar vermek için yaklaşık dört saatlik bir toplantınız var. Genelde kimin yapacağına dahi karar verilmeksizin başlanması öngörülüyor. - Ben özellikle bu kısmına hala ikna olabilmiş değilim ama neyse. – Neyse, farklılıkları var elbet. Ama ilginç bir alana açıldığı için tartışma izlemeye değiyor.

~o~

[3/7/2005]

Longhorn ile registry ve dosya sisteminde de transaction bağlamında işlem yapmak mümkün olacak. 

~o~

[3/7/2005]

C# 2.0’da özellik (property) okuyucu ve yazıcıları (getter ve setter) için farklı erişim modları tanımlayabiliyorsunuz. Yanılmıyorsam bu C# 1.0’da yoktu. Şöyle ki:

    public Person Owner

    {

        get { return _owner; }

        internal set { _owner = value; }

    }

Bu özellik sayesinde daha estetik bir API tasarımı yapmak mümkün. Örneğin her şahsın bir araba koleksiyonu olsun:

    public class Person

    {

        private CarCollection _cars;

        public CarCollection Cars

        {

            get

            {

                return _cars;

            }

        }

    } 

Her araba da sahibini tanısın:

    public class Car

    {

        public Person Owner

        {

            . .

        }

    }

Sunduğumuz API ile bir araba bir şahsın araba koleksiyonuna eklendiğinde, arabanın da sahibini tanımasını şu şekilde gerçekleştirilebilir:

    Person p = new Person("Ali");

    for (int j = 0; j <5; j++)

    {

        Car c = new Car("Ford", 1900+j);

        p.Cars.Add(c);

        c.Owner = p;

    }

Burada tek sorun, API’ımızı kullanan kişinin p.Cars.Add(c) ve c.Owner = p; satırlarını sürekli beraber kullanmayı hatırlamasının gerekmesi. Sonra, arabayı listeden çıkardığında da Owner‘ı tekrar null olarak ataması gerekecek.  İşte burada internal ile bir çözüm geliştirebiliriz, bu durumda CarCollection sınıfımız şöyle olacaktır:

    public class CarCollection

    {

        private List<Car> _elements = new List<Car>();

        private Person _owner;

        public CarCollection(Person owner)

        {

            _owner = owner;

        }

        public void Add(Car car)

        {

            this._elements.Add(car);

            car.Owner = _owner;

        }

        public void Remove(Car car)

        {

            this._elements.Remove(car);

            car.Owner = null;

        }

    }

}

Şahıs sınıfında

        public Person(string name)

        {

            _cars = new CarCollection(this);

        }

Araba sınıfında da

        public Person Owner

        {

            get { return _owner; }

            internal set { _owner = value; }

        }

şeklinde bir kod yazacağız. Böylece API’ımızı kullanan üçüncü şahıslar Owner’a değer atayamayacak, onu sadece okuyabilecekler.  Yani p.Cars.Add(c); gibi tek satırla hem araba şahsın araba koleksiyonuna eklenmiş olacak, hem de araba’nın sahibi otomatik olarak atanmış olacak. API’ımız kullanan kodun her seferinde

       p.Cars.Add(c);

       c.Owner = p;

çiftleri halinde kod yazması gerekmeyecek.

Zaten c.Owner = p; gibi bir kod da her zaman derleyici hatası verecek.

Bu yaklaşım eğer bir sınıf kütüphanesi geliştiriyorsak çok faydalı. Yok eğer bizim geliştirdiğimiz sınıfları kullanan diğer kodlar da bu sınıflarla aynı assembly (.dll ya da exe) içindeyse, internal anahtar sözcüğü tüm assembly için geçerli olduğundan onlar da Owner’a değer atayabileceklerdir. C#’da, C++’daki gibi friend anahtar kelimesi olmadığından bu tip çözümler sadece sınıf kütüphaneleri geliştirdiğimizde faydalı oluyor.

Tüm kod şöyle oluyor:

    public class Car

    {

        private string _make;

        public string Make

        {

            get { return _make; }

            set { _make = value; }

        }

        private int _model;

        public int Model

        {

            get { return _model; }

            set { _model = value; }

        }

        public Car(string make, int model)

        {

            _make = make;

            _model = model;

        }

        private Person _owner;

        public Person Owner

        {

            get { return _owner; }

            internal set { _owner = value; }

        }

    }

    public class CarCollection

    {

        private List<Car> _elements = new List<Car>();

        private Person _owner;

        public CarCollection(Person owner)

        {

            _owner = owner;

        }

        public void Add(Car car)

        {

            this._elements.Add(car);

            car.Owner = _owner;

        }

        public void Remove(Car car)

        {

            this._elements.Remove(car);

            car.Owner = null;

        }

    }

    public class Person

    {

        private CarCollection _cars ;

        public CarCollection Cars

        {

            get

            {

                return _cars;

            }

        }

        private string _name;

        public string Name

        {

            get { return _name; }

            set { _name = value; }

        }

        public Person(string name)

        {

            _cars = new CarCollection(this);

            _name = name;

        }

    }

Örnek kod:

    Person p = new Person("James");

    for (int j = 0; j < 10; j++)

    {

        Car c = new Car("Ford", 1900+j);

        p.Cars.Add(c);

        Console.WriteLine(c.Owner.Name);

    } 

~o~

[21/6/2005]

Scrum ve diğer güncel meselelerden biraz olsun uzaklaşalım.

2003'de yapılan bir tıp araştırmasına göre oyun oynamak, bir müzik aleti çalmayı ya da dans etmeyi öğrenmek ya da yabancı bir dili çalışmak beyninizin hafıza kaybını azaltıyor; Alzheimer gibi hastalıklara karşı da bir koruma sağlıyor. Sonunda neden Almanca kursuna gittiğimi soranlara verecek teknik bir cevabım da oldu :)

Dil öðrenmek dedik de: Ruby'nin babası Yukihiro Matsumoto'nun 10 Öğüt'ünden ilki farklı stillerdeki bilgisayar dillerini öğrenmek: script dili, nesneye yönelik diller, fonksiyonel ve mantıksal diller gibi. Beni cesaretlendirdi bu iş, bugünlerde fırsat buldukça Prolog hatırlamaya çalışıyorum. En son Prolog yazalı sekiz sene olmuş sanırım. Ticari olarak ilk göze çarpanı Visual Prolog ama .NET ya da Java ile entegre değil. P# diye akademik bir derleyici de var ama o önce kodu C#'a çeviriyor, sonra derliyor. Direk IL kodu üretmiyor. Bu arada bir de ML vardı tabii, hayal meyal hatırladığım. .NET'de çalışan bir türevi çıkmış bugünlerde deneme projesi olarak. Direk IL kodu üretiyor. Bakalım, ML'i kullanmayalı daha da uzun zaman oldu ama belki bir fırsat çıkar, bakacağız...

~o~

[1/6/2005]

Planlanandan önce Scrum kursumuza kavuştuk. Niyetim daha sonraları Ken Schwaber'den almaktı bu kursu ama şirketteki başka ekipler lokal bir kursa yazılınca, onlarla ileride fikir alışverişinde bulunabilir, tecrübelerimizi paylaşabiliriz diyerek biz de yazıldık.

Dürüst olmak gerekirse, kursa katılmadan önce Scrum hakkında çok fazla bir şey bilmiyordum ama yaklaşımım olumluydu. Kurstan sonra biraz daha soğukkanlı bakmak gerektiğini düşünüyorum. Bu belki direk Scrum'la ilgili değil, eğitmenlerin "klasik yöntemler yanlıştı" yaklaşımından kaynaklanıyor. Özellikle "klasik proje yönetimi"ne getirdikleri bir sürü eleştiri vardı ki, hepsine katılmak mümkün değildi. Neyse, çok dert değil.

Kurslara katılanların sayısı pek azımsanacak gibi değil aslına bakarsanız. Neden peki? Öncelikle her zaman sektörde süreç iyileştirmeye yönelik bir talep oluyor. Bu talebin günün yükselen süreçlerine yönelmesi de doğal. Diğer çevik yöntemlerin hepsini detaylı olarak incelemedim ama Scrum biraz daha dengeli duruyor bunlara bakınca: örneğin eşli programlamaya dair çok bir şey söylemiyor (yapıp yapmamak size kalmış); bir aylık ya da dört haftalık sürümler üzerinde artan fonksiyonalite için çalışmak öneriliyor; ancak öncesinde bir planlama süresini kabul ediyor - tam bir baştan büyük tasarım önermese de. Dökümantasyona çok büyük bir meydan okuması yok, ancak çalışan kodu önceliyor. Süreç severler için de kendisini ciddi bir süreç olarak tanımladığını söyleyelim, örneğin Scrum Ustası için "sürecin sahibi" deniyor. Bu da süreçseverler için onu cazip kılacak bir yönü. Bunun yanında zamanı önceliyor: uzun tartışmalara, toplantılara pek sıcak bakmıyor. "Bugün bildiklerinle verebileceğin en iyi kararı ver, mükemmeliyetçi olma; sonra onu uygula (yani kodu yaz), ne yaptığına dön bir bak, sonraki adımı planla" gibisinden özetlenebilecek bir tempo yakalamanızı istiyor. Bu açıdan da bazı yöneticilere cazip geleceği açık.

Şu anki projede uygulayıp uygulamayacağımızı henüz kararlaştırmadık ancak bizim için cazibesi var: bir süredir ciddi ilerleme kaydedebilmiş değiliz. Bu açıdan zaman çerçevelerinde yaşamayı önermesi, her zaman tartışmayı çalışan kod üzerinden yapması bizim için cazip olacak. Önümüzdeki günlerde nasıl ilerlediğimizi günlüğe yansıtmaya çalışacağım yine.

~o~

[23/5/2005]

Bugünlerde kapamalarla ilgili bir çok blog görünüyor. Nedir kapamalar? (Closure : kapama)

Kapamalar, Ruby gibi dillerle gündeme geldi – eminim yeni bir kavram değiller, hatta Lisp’de bloklar olarak biliniyorlarmış. C# ile anlatmaya çalışırsak, bir yönteme bir parça kodu parametre olarak geçmek için kullanılan dil yapıları kapamalar. C# bunu anonim metodlarla destekliyor. C günlerinden kalanlara fonksiyon işaretçileri dersek sanırım birşeyler çağrıştıracak.

Örnekte geciken siparişleri bulmak için önce ‘klasik’ foreach bloğuyla, sonra da kapama ile bunu nasıl yaptığımızı gösteriyoruz.

            List<Siparis> siparisler = new List<Siparis>();

            /// Siparis ekle, cikar, vs...

            /// ...

            // Geciken siparisleri bildik yolla bul!

            List<Siparis> gecikenSiparisler1 = new List<Siparis>();

            foreach (Siparis s in siparisler)

            {

                if (s.Gecikti) gecikenSiparisler1.Add(s);

            }

            /// Geciken siparisleri kapama ile bul!

            List<Siparis> gecikenSiparisler2 =

            siparisler.FindAll(delegate(Siparis s)

            {

                return s.Gecikti;

            });

Burada FindAll() yöntemine parametre olarak verdiğimiz kod parçasına kapama diyoruz.

Nerelerde kullanılabileceği konusunda hala şüphelerim var, liste işlemlerinde faydası olduğu bariz, ama daha az kod yazmaya falan yaramıyor. Performansına dair hiçbir iddia da yok. Biraz daha oynamak gerekecek sanırım. Okuması biraz zor olabilir, hele içice kullanılmaya başlarsa. C dilinde sevmediğim yön tüm fonksiyon işaretçilerinin içice kullanıldığı kodları okumak zorunda kalmaktı.

~o~

[17/5/2005]

Uzun bir aradan sonra tekrar bloglamaya devam ediyoruz. Tatil, projedeki yoğun günler ve süreç değişiklikleri. Eğer bu yönde ilerlemeye devam edersek, yakında Scrum ile denemeler yapmaya başlayacağız. Umarım bu devam eder, ben de buradan size tecrübelerimi anlatmak fırsatı bulurum.
 
O zamana kadar yazılım nasıl müşteriye ulaşır konusunda eski Microsoft çalışanı, bugünün Googlecusu Mark Lucovsky'nin yeni blog'undaki şu notlara dikkatinizi çekerim. Ne dersiniz, Microsoft'un masaüstü ofis uygulamalarını, ya da .NET platformunu bir servis olarak sunması mümkün olur muydu?

~o~

[15/3/2005]

Sanal PC konusunda yeni bir hamle de mikroişlemci üreticilerinden geliyor. Intel ve AMD de bu konuda çalışmaya başlamışlar.

~o~

[27/2/2005]

Biraz da haftasonu havasına uygun bir not düşelim. Don Box blogunda çocuklarına hangi dili öğretse onu düşünüyor. Sorusuna bir hafta olmadan yüzü aşkın cevap gelmiş. Siz ne dersiniz? :)

Bizim sektörün çocuk muhabbeti yapıyor olması da ilginç bir gösterge. O klasik, asosyal imajımıza ne oldu bizim?

~o~

[27/2/2005]

Teknoloji benim gibileri heyecanlandırmaya devam ediyor. Dün nasıl çalıştığıma bir baktım da, nereden nereye gelmişiz. Senaryo şöyle: Elimde bir ofis PC'si, bir de dizüstü bilgisayar var. Elimdeki prototip için çeşitli programların ve sunucuların hem üretim versiyonlarına hem de betalarına bakıyorum. Önce üzerinde XP çalışan ofis PC'sine, sanal PC üzerinde çalışan bir Windows 2000 Server kurdum, bir-iki betayı oraya yükledim. O da yetmedi başka bir sunucuya da Windows 2003 Server ve başka betalar. Şimdi elimde dört tane işletim sistemi var. Sonra eve geldim. Dizüstüm ADSL'e kablosuz erişim noktasından bağlanıyor. ADSL üzerinden de şirketin sistemine güvenli bir şekilde bağlandım. Sonra ofisteki PC'lere Remote Desktop üzerinden girdim, ofiste gibiyim, o sunucuların işlemcilerinden rahatlıkla faydalanıyorum. Dizüstümde Visual Studio yavaş çalıştığından kodlamayı ve hata ayıklamayı ofis bilgisayarında yapıyorum. Remote Desktop bu kadar hızlı bir tecrübeyi bana sağlıyor. Elimin altında dört tane bilgisayar, bir yandan da TVde müzik kanalları arasından bir şeyler seçmeye çalışıyorum.

1990 yılında (15 sene olmuş, az da değil hani), lise sona geçtiğimde aldığım ilk x86'da sabit disk sürücüsü bile yoktu. Babama Commodore 64 ya da Amiga aldırmayı başaramamıştım, ufak bir Gameboy'um olmuştu sadece o zamana dek. Geçen bir arkadaşın ailesiyle buluştuk. Önce dışarıda yemek yedik. Yedi yaşındaki oğlunun elinde ufak bir oyun konsolu vardı. Orada futbol oynuyordu. Sonra evlerine çaya gittik. Evde Play Station'da karşılıklı futbol oynadık. Misafir diğer ailelerden birinin de çocuğu o sırada bizimle aynı odada, PC'de araba yarışı yapıyordu.

Bakalım buradan nereye gideceğiz.

~o~

[26/2/2005]

Microsoft, MSDN'de Indigo için bir giriş makalesi yayınladı. Indigo XML ve Web Hizmetleri üzerinden hem .NET sistemleri arasında hem de .NET ve J2EE sistemleri arasında çalışma birliğini (interoperability) gerçekleştirmeyi hedefliyor. ASMX, Remoting, Enterprise Services veya MSMQ gibi teknolojilerle çalıştıysanız, Indigo bir sonraki adım.

~o~

[8/2/2005]

Bugün video ile XP ve birim test geliştirilmesiyle ilgili yeni bir video sayfası daha gözüme ilişti. Kent Beck'in yaklaşık bir saatlik sunumunu ve Google'daki XP tecrübelerini bu adresten dinleyebiliyorsunuz.

~o~

[29/1/2005]

Internet altyapısı hızlandıkça teknik bilgilere sözlü ya da görüntülü olarak erişmek de mümkün oluyor. Uzun uzun makaleler okumaktansa da sunucuyu dinleyebileceğiniz bu tip eğitimlerin makale okumaktan kimi açılardan faydalı olduğunu düşünüyorum. Örneğin konuşmacının nerelere vurgu yaptığını direk takip edebiliyorsunuz.

MSDN Webcast'ları, NET sınıf kütüphaneleri geliştirme teknikleri sunumları, ve NetObjectives'in akan seminerleri bunlardan bazıları. Farklı öğrenme tarzları için yeni çözümler...

~o~

[13/1/2005]

UML'in emektarlarından Grady Booch'ın hesaplarına göre 1945'ten bu yana 750 milyar satır kod yazılmış. Bunların bir kısmı kullanılmadı bile tabii. Her satırın 100 ila 200 dolar arasında maliyeti olduğunu hesaplıyor Booch.

Booch bir de çok ilginç bir projeye girişmiş: 100 seçilmiş yazılımın mimarisi üzerine arkeolojik bir çalışma yapıyor. Henüz çok az veri toplamış durumda ama eğer proje istediği gibi şekillenirse çok ilginç bir bilgi birikimini yazılım topluluğuna kazandırmış olacak. Nasıl işletme derslerinde bazı şirketlerin başarıları durum çalışması (case-study) olarak okutulyorsa, ileride bu tip birikimlerin de geniş kitleler tarafından çalışıldığını görebiliriz. Booch'un ele alacağı projeler arasında .NET, The Sims ve Yüzüklerin Efendisi'ndeki savaş sahnelerinde binlerce birimin simülasyonunu gerçekleştiren Massive bulunuyor.
 
Siteye e-posta adresi ve bir şifre seçerek hemen üye olabiliyorsunuz.

~o~

[12/1/2005]

Java ya da C# ile çalışanlar Collection sınıflarının faydalarından haberdardırlar. Ancak bu sınıfların bir sorunu fazlasıyla esnek olmalarıdır. Örneğin bir diziyi (array) tanımlarken o dizide hangi tip veri saklayacağınızı belirtebilirsiniz.

    String[] stringArr = new String[5];

Fakat, bir ArrayList tanımlarken bunu belirtemezsiniz.
 
    ArrayList stringListesi = new ArrayList();
 
Bu ise sizi derleme sırasında görebileceğiniz hataları kaçırma riskine sokar, işin büyük kısmını test aşamasına bırakır.
 
    stringListesi.Add(Guid.NewGuid()); // Burada hata alabilmeliydik, çünkü NewGuid() metodu bir string döndürmüyor.
 
Ayrıca listelerden verileri alırken de ekstra tip-dökümü (type-cast) yapmanız gerekir:
 
    string ilkString = (string) stringListesi[0];
 
C# 2.0'da gelen Generics özelliği ile bu tip sorunları derleme aşamasında yakalabilmek ve daha sağlam kod yazmak mümkün olacak:

Generics'e zaman ayırmakta fayda var.
 

~o~

[31/12/2004]

Gördüğünüz gibi sol taraftaki Folders kısmında en üstte takip ettiğim günlükler görünüyor. Peki programı yeni kurmuş birisi olarak yeni bir günlüğü daha listenize eklemek istediniz diyelim. Ne yaparsınız doğal olarak? News & Blogs’un üzerine gider ve farenize sağ tıklarsınız değil mi? (Evet, daha burada Microsoft kullanıcısı olduğum belli oldu belki de :) Ama yine de dinleyin derim.)

Hmmm, yeni bir günlük ekleyeceğiz ama nasıl ekleyeceğiz şimdi. İnsanın gözü ‘New’ ya da ‘Add’ gibi bir şey arıyor. New Folder var, onu bir deniyorum ama oradan pek bir şey çıkmıyor. Halbuki Local Folders’ın üzerinde sağ tıklasam hemen yeni bir klasör açmak mümkün olacaktı:

Denemeye devam, şimdiden bir kaç defa tıkladık, daha yeni kurduk programı halbuki. İlk sağ tıklamaya geri dönüp bu sefer Manage subscriptions’ı deniyoruz, ilk sırada o var çünkü. Şöyle bir şey geliyor karşımıza:

Burada da Add demeli herhalde. Bir daha tıkladık,

Hah, buraya RSS için URL gireceğiz! (Aslında bir şey girmeden de OK diyebilirsiniz, program hiç şikayet etmiyor!) Tamam, şimdi oldu. Burada OK diyeceğiz, sonra RSS Subscriptions sayfasında da OK diyeceğiz. İlk seferinde hep doğru seçimleri yapabilirseniz 5 tıklamada işinizi görebilirsiniz. Halbuki yeni klasör açmak iki tıklamada yapılabiliyor. Hmmm, demek ki diyorum bu RSS okumaya göre değil pek. Peki e-posta için mi tasarlanmış daha çok? Belki de öyledir. Adres defterine bir göz atalım:

Orada da pek umut yok. Personal Address Book üzerinde sağ tıkladığınızda ilk sırada Properties geliyor, pek sık kullanılan bir şey olsa gerek, deneyelim:

Evet, değiştirememeniz için gri olarak yazılmış bir isim, ama o da ne? Buna rağmen OK ve Cancel düğmeleri var. Belki de gri olmasına rağmen değiştirilebiliyordur, deneyelim. Yok, olmuyor. Hmmm! Çok eğlenceli doğrusu :)

Burada en sonda Properties.

~o~

[30/12/2004]

Blog'un Yükselişi ve 2005
 
Marriam-Webster sözlüğünde yılın kelimesi 'blog' oldu.
 
Tahminlere göre bu sene blog yazmadığı için bir sürü yönetici işinden olacak. Çünkü artık pazarla ve müşterilerle hiperaktif olarak en iyi iletişim kurma yöntemlerinden birisi blog. Ancak yine bir çok kişi de blog yazdığı için işinden olacak. Tehlikeli bir iş :)
 
Başka bir tahmine göre blog işinden para kazanmaya çalışacaklar olacak. Medya bu işin içine girecek, köşe yazarları köşe yazısı yerine blog yazmaya başlayacaklar.

~o~

[25/12/2004]

Yazılım dünyası değişiyor. Bundan belki beş sene önce eski uygulamalara rahatlıkla kem gözle bakılabilir, bazıları 'yeniden yazılır', bazıları da çöpe atılırdı. Belalı bir kod size devredildiğinde 'biz bunu yeniden yazalım' falan diyebilirdiniz, işinizden de olmazdınız.

Eskimiş kod tabanı için on senede bir 'yeniden yazma' bakım maliyetlerini ve yeni teknolojilere geçmeyi kolaylaştırabilir. Ama sürekli 'yeniden yazma' modunda olmak mümkün değil. Bugün büyük bir kurumda belki 30 farklı uygulama çalışıyor. Ve bunların yazıldıktan sonra bir müddet sorun çıkarmadan çalışması herkesin dileği.

Ancak ihtiyaçlar bitmiyor. Eklenen her yeni özellik, uygulamaların entegre edilmesi gereği, yenilenen ekler, yeni eklerin ileride başka uygulamalarda da kullanılmasının düşünülmesi, ... derken yazılım mimarlarının işi gittikçe zorlaşıyor.

Bugünlerde elimde benzer bir sorun var. Varolan dev ve yaşlı bir uygulamaya ekler yapmak, ve onun yazılacak yeni modülle sorunsuz çalışmasını sağlamak. Yeni modülün özgün mimarisinden ödün vermeden ancak eskiyle de uyum içinde çalışabilmek. Frank Lloyd Wright'in Fallingwater adlı yapıtı gelir bu durumlarda gözümün önüne hep: http://www.paconserve.org/index-fw1.asp. Uyumun çok güzel bir örneği. Sayfayı her tazelediğinizde farklı bir resim geliyor karşınıza, kış resmi en güzeli.

~o~

[22/12/2004]

Merhaba,

Mehmet Kerem Kızıltunç