nic.tr

.tr ile biten domain'leri yöneten nic.tr'nin web sitesi işlevsel açıdan mükemmel. Yapanları buradan tebrik ediyor, anne ve babalarının ellerini "Böyle evlatlar yetiştirdiniz, ne mutlu size" diyerek öpüyorum, gözlerimden mutluluk gözyaşları süzülürken... Ciddiyim. İnternette nadiren işlerimi bu kadar kolay halledebiliyorum.

TÜBİTAK

TÜBİTAK'çının kafasına bir fiske vurduğunuzda çıkan ilk ses "TÜ" olur. Kafa içerisinde oluşan ilk yankı "Bİ" sesini verir, üçüncü ve son yankının verdiği ses ise "TAK"tır. Yankılardaki ses değişimi, içerideki bilgi yığınından kaynaklanır:Yaratıcılık azaldıkça yankı sayısı artar. "TÜBİTAKTOKSEKSEK" gibi...

TÜBİTAK ve Mantıksız Çeviri Mantığı

Bugüne kadar hiçbir TÜBİTAK çevirisini 20 sayfadan fazla okuyamadım. Bilim dilini bu derece kabızlaştıran yankılı kafa, bir süredir PARDUS adında ulusal bir işletim sistemi pompalıyor. Öğrenimim ve iş deneyimim sırasında farklı işletim sistemi türleri gördüm fakat ulusal olanına rastlamamıştım. Ulusal İşletim Sistemi'ne karşı, Zaman Gazetesi sponsorluğunda Ilımlı İslâmî İşletim Sistemi...

Tekimcil Halayık Damacanası

Geçen gün bir internet sitesinde rastladım; sivri zeķâlı bir arkadaş "Design Pattern"ı "Tasarım Örüntüsü" olarak çevirmiş. Kanaatimce, Design Pattern kavramını sen ortaya atmadıktan sonra ister "Tasarım Örüntüsü" de, ister "Halayık Damacanası" de, fark etmez. Örnek: Singleton Design Pattern yerine Tekimcil Halayık Damacanası. Aynı şekilde, işletim sistemi kavramını temelinden sallamadıktan sonra ister ulusal işletim sistemi hazırla, ister ahlaklı çevik sportif işletim sistemi hazırla, fark etmez, memleketi kurtaracak değilsin.

Yani?

İlle de çevireceksek, çevirilerde birebir kelime karşılığı değil, anlam karşılığı kullanmalıyız. Örnek olarak, Çözüm Kalıbı, kavramı temsil etmekte Tasarım Örüntüsü'nden daha başarılı görünüyor. Tasarım Kalıbı da kullanılabilir. Tasarım Şablonu kullananlar da var, fakat Almanca kökenli "şablon" kelimesini telaffuz ederken ağzımın aldığı şekilden hoşlanmıyorum.

Hepsi Boş

Kendi kafamızla düşünüp üretmek neden bu kadar zor?

İsâbet

Open Source for the Enterprise - Ya Da - Açık Yazılım Stratejisi - Bölüm 5

Elimde bedâva Photoshop varsa Gimp kullanır mıyım? Hâyır. Photoshop'a 700 dolar ödemek zorundaysam Gimp kullanır mıyım? Evet. Gimp'in salak yaratığını sevebilir miyim? Hâyır. Açık yazılım maskotlarının neden bu kadar sevimsiz olduğunu açıklayabilir miyim? Belki. Örnek: Gimp yaratığı, Java Duke, Linux pengueni... Açık yazılımda ÇOK ciddî bir tasarım eksiği var. Örnek:Her neyse... Kitabın beşinci bölümü, bundan önceki bölümlerden faydalanarak sisteminize açık yazılımı dâhil edip yedirmeniz için izlemeniz gereken stratejiye ışık tutuyor.

ENJEKSİYON

Önceden de defalarca söylediğim gibi, açık yazılıma girişecekseniz takımınızın öğrenmeye açık ve zekî olması gerekiyor. Bilgiyi tek kişide toplamayın, takıma yayın. Böyle bir takıma sâhip olacak imkanlar mevcut değilse dışkaynak kullanımını düşünün. Başarılı bir stratejinin temel noktaları şunlar olabilir:

• Ekibinizi tanıyın ve neler yapabileceklerini bilin.
• Açık yazılımı güvenli bir ortamda deneyin, takımınıza yazılımı tanımak ve onunla oynaşmak için gerekli kaynağı verin.
• Takımın yeteneğini, önce değerlendirme, ardından kurulum ve ayarlama ve son olarak uygulama ve bakım alanlarında belli bir süreye yayarak kuvvetlendirin.
• Bu yeteneği ve bilgiyi kişilerin değil, kurumun yetenek ve bilgisi haline getirin (ortak bilgi veritabanı, bilgiyi kişilere yaymak, vs.).
• Bilgi ve yetenek arttıkça ve fırsat oldukça daha çok açık yazılım kullanın.

Ekibin yetenek seviyesine göre uygulanabilecek adımlar:

1. Kundak Safhası:
   • Kurulumu ve ayarlaması en kolay açık yazılımı kullanın.
   • Kurulum ve destek için gereken yeteneği takımda oluşturun.
   • Hangi dilde ve hangi alanda yazılmış açık yazılımın takım için daha uygun olduğuna karar verin.
   • Takımı Linux'a ucundan bulaştırın.
2. Emekleme Safhası:
   • Daha ileri seviye açık yazılımın kurulumu, ayarlanması, çalıştırılması ve gözlemlenmesi için gereken yeteneği takımda geliştirin.
   • Odağı belli bir alana ve programlama diline yöneltin.
   • Linux'un çözümün bir parçası olup olmayacağına karar verin.
3. Yürüme ve Koşma Safhaları: Efendim bu aşamaya geçmeden önce kendinize bir sorun: Bu kadar ileri gitmeye gerçekten gerek var mı? Cevap evet ise bu noktadan sonra bilgiyi ve yeteneği kuruma yaymanız çok zor, kilit adamlar oluşacaktır. Sizin için güzel bir alternatif, açık yazılım danışmanlık şirketlerinden sürekli destek almanız olabilir. İlle takımı bir önceki aşamadan bu aşamaya geçirmek istiyorsanız açık yazılım projelerine eklentiler geliştirmeye başlayabilir, Linux çekirdeğinde değişiklikler yaptırabilirsiniz.

UYGULAMA

Bu kısımda birkaç gereksiz sınıflandırma var. Enjeksiyon başlıklı kısımdaki bilgi yeterlidir.

YÖNETİM

Kurumun boyutuna göre açık yazılım kullanımının yönetimi değişiyor. Küçük firmalarda takım ve lider(ler) biraraya gelip sözlü ve esnek bir anlaşma sağlayabilirler fakat büyük kurumlarda bu işin resmîyete dökülmesi gerekiyor: raporlar, imzâlar, mühürler, kilitler, vs. Bu resmî stratejiyi oluşturacak sorulara şunlar dâhil olabilir:

1. Hangi alanlarda ve hangi durumlar için açık yazılım kullanılacak?
2. Açık yazılım bünyeye dâhil edilmeden hangi kıstasları sağlaması gerekiyor?
3. Hangi durumlar için hangi lisanslar kabul edilebilir?
4. Açık yazılım ürün ortamında kullanılacak mı?
5. Kurum açık yazılım geliştirilmesine destek verecek mi? Geliştirilen kod umuma açılacak mı?
6. Açık yazılım geliştilmesinde kaç kişilik bir takım çalışacak?

Büyük bir kurum bunları kağıda dökerse ileride doğabilecek felâketlerden kendini koruyabilir. Sonuna kadar katılıyorum. Hattâ küçük firmalar da bu konuları kağıt üzerinde sabitlemeli. Disiplin için bu gerekiyor. Sözler havada esniyor hâfızada değişiyor, yazı kalıyor. Ciddiyim. Kağıda dökünüz.

Open Source for the Enterprise - Ya Da - Siz Söylemeyin, Analize Söyletin - Bölüm 4

Siz söylemeyin, analiz söylesin. Bu bölüm Return on Investment (ROI), yani yatırımın geri dönüşü kavramının açık yazılıma uygulanmasına ayrılmış. ROI raporu, tahmin edileceği gibi, yönetime sunuluyor ve IT'cilerce pek kanıksanmıyor, çünkü:

• ROI incelemesinin sonuçları öznel nitelikte olduğundan yapılan kabullere göre değişebiliyor.
• Açık yazılımın sistem mimarisine getirdiği sadeliği ve esnekliği rapora dahil edemiyorsunuz, yani sadelik ve esneklik kendi başına para etmiyor.
• IT'ciler kullanılan yeni teknolojinin gelirleri nasıl artıracağını kestirmekte zorluk çekiyor, ya da kestirmek istemiyor.

Fakat IT'ciler istemese de yöneticiler ve finansçılar ROI'ye bayılıyor ve ROI güzelce kullanılıyor. Kısaca, allem edip kullem edip, kabulleri esnetip ROI'yi makul değerlere çekiyorsunuz ve yönetime kabul ettiriyorsunuz. İkna meselesi.

AÇIK YAZILIM İÇİN ROI

ROI'nin formülü şu şekilde verilmiş:

(Geri Dönüş)/(Yatırım) = ROI

Geri Dönüş = (Kar Artışı + Tasarruf)
Yatırım = (Değerlendirme Masrafı + Lisans ve Bakım Masrafı + Kurulum Masrafı + Entegrasyon ve Özelleştirme Masrafı + Operasyon ve Destek Masrafı)

Bu denklemin anlamlı olabilmesi için bilinmesi gerekenler:

• Değerlendirilecek zaman dilimi nedir? 1 sene mi? 2 sene mi?
• Mukayese edilecek alternatifler mevcut mu? Kısa zamanda çok kar mı istiyoruz, uzun vadeli tasarruf mu istiyoruz?
• Şirketin beklediği en düşük ROI nedir?
• Masraflara altyapı giderleri (elektrik, barındırma, vs.) dahil edilecek mi?

Birden fazla alternatif için ROI hazırlanıyorsa, yukarıdaki konularda tutarlı olmak gerekiyor.

Şimdi payda kısmında bulunan masrafları inceleyelim:

• Değerlendirme Masrafı: Açık yazılımın değerlendirilmesi önce bulunmasını, ardından bir makinaya kurulup kurcalanmasını gerektiriyor. Bu işlemin süresi de yazılım ekibinin kabiliyetine göre değişiyor. Önceki bölümlerde anlatılanları biliyorsak, bu sürecin maliyetini az çok kestirebiliriz. Ticari yazılımda ise analiz rolünü IT değil yönetim alıyor.
• Lisans ve Bakım Masrafı: Açık yazılımın her zaman bedavaya gelmiyor: Red Hat ve SuSe Linux kurulum ve güncelleme paketlerine üyelik için, JBoss dökümantasyon için, Resin ise ticari kullanım için belli bir ücret istiyorlar. Birtakım şirketler de açık yazılım danışmanlığı yaparak sistemin kurulumu ve bakımı için belli bir ücret alıyorlar.
• Kurulum Masrafı: Açık yazılımda kurulum sihirbazları olmadığı için, yine IT ekibinin kabiliyet seviyesine göre kurulumun zaman maliyeti oluyor.
• Entegrasyon ve Özelleştirme Masrafı: Halihazırdaki sistemle uyum sağlamak için açık yazılıma eklenti yazılması gerekebilir, veya başka yazılımların kullanılması gerekebilir. Bu masraflar açık yazılım için daha yüksek oluyor çünkü ticari yazılım, birtakım platformlar için genişletilmiş oluyor. Fakat tabii ki açık yazılım kullanmak esnekliği artırıyor ve iyi bir IT takımıyla ticari yazılımın destek veremeyeceği bir platforma entegre edilebiliyor. Kullanılacak açık yazılıma ve IT ekibinin kapasitesine bakarak hazırlanan entegrasyon ve özelleştirme masrafı da paydaya ekleniyor.
• Operasyon ve Destek Masrafı: Sistemi kullanmaya devam ettikçe doğacak masraflar bu kaleme dahil edilmiş: test ortamının sağlanması, sistemin genişlemesi için yeni sunucuların eklenmesi, yedekleme veya çökmeye karşı kullanılacak yeni sunucular, vs. Yapılan analizin vadesi ve sistemin gerektirebileceği değişiklikler göz önünde bulundurularak bu kalem de kolayca hesaplanabilir.

Bu bilgileri kullanarak detaylı bir analiz yapıyorsunuz, Microsoft'un Linux ROI'sini Windows'tan düşük gösterirken yaptığı gibi kabulleri esnetiyorsunuz ve ROI'ye ne istiyorsanız onu söyletiyorsunuz. Güzel giyinin ve güzel kokun. Unutmayın ki, analizler, kendilerine istediğiniz şeyi söyletmeniz için vardır.

J7BE - Java 7 Bakkal Edition

Java'nın etrâfındaki kaosu dindirecek, dimağımı bulandıran sis perdesini yırtacak, basit olanı anlaşılmaz hâle getiren onlarca pazarlama numarasını tuzla buz edecek çözüm: Java 7 Bakkal Edition.

Ya Java'yı sâdeleştirin, ya da ölümüne razı olun.

Özgür zeķâya nasıl muhtâcız...

Open Source for the Enterprise - Ya Da - Ehline Helaldir, Naehle Haram - Bölüm 3

Bu bölümde yazar, bir kurumun açık yazılım kullanmak için sahip olması gereken yeteneği irdelemiş. Hangi olgunluk seviyesindeki açık yazılımı kullanmak için hangi yeteneklere ihtiyaç var? Elemanlarınızın yetenek seviyesini ve alabileceğiniz riskin büyüklüğünü nasıl tespit edersiniz? IT departmanınızın açık yazılım yeteneklerini nasıl geliştirirsiniz?

Yazar harika bir örnek vermiş: Yönetime açık yazılım kullanmak için başvuran yazılım ekibini, ailesinden eve yavru köpek almasını isteyen çocuğa benzetiyor. Aile "bakacaksan olur tabii" diyor. Çocuk hevesini alıp acı gerçekleri fark edince hayvancağızla ilgilenmeyi kesiyor, pisliği temizlemek de anne babaya kalıyor. Bu kabusu yaşamamak için yazılım ekibinizin yetenek seviyesini belirlemeniz gerekiyor.

AÇIK YAZILIM YETENEK SEVİYELERİ

Yukarıdaki grafikten anlaşılacağı gibi, en büyük azınlığı yenilikçi dahiler oluşturuyor. Başka bir azınlıksa statükocular. Toplumun genelinin kafa yapısını da yansıtan bir grafik olduğunu fark ettiniz mi?

Şimdi bu seviyeleri kısaca inceleyelim:

1. Başlangıç Seviyesi
   
   1. Açık yazılım paketlerinin kurulumu ve bu kurulumda kullanılan araç-gerecin (compiler, rpm, vs.) kullanımı hakkında yüzeysel bilgi sahibidir.
   2. Kullanılan işletim sistemi ve network sisteminden bihaberdir. Armut piş, ağzıma düş diyerek bu tür işleri operasyon ekibine yükler.
   3. Yazılım ayarlarından sadece temel olanlarıyla ilgilenirler: loglama konumunun belirlenmesi, portların seçimi, vs.
   4. Programın çalışması esnasında da sadece temel kontrolleri yapabilirler: program düzgün çalışmaya devam ediyor mu, donanım kaynakları yeterli mi, vs.
   5. Birden fazla açık yazılım birarada çalışıyorsa bunların arasındaki bağlantıyı sağlayabilir.
   Bu seviyedeki kullanıcılar bile açık yazılım kullanımı konusunda sıradan bilgisayar kullanıcısından epey öndedirler. Temel Linux, Apache, MySQL ve Mozilla Firefox bu seviyedeki kullanıcıların baş edebileceği seviyede örnekler...


2. Orta Seviye: Bu seviyedeki kullanıcının başlangıç seviyesinin üstünde sahip olması gereken yetenekler şu şekilde:
   
   1. Kurulum sırasında derleme yapabilir.
   2. Programın ayarları için gerekirse koda girerek temel değişiklikler yapabilir. Bu değişikliğin ardından kodu tekrar derleyip kurulumu yeniler.
   3. Açık yazılım community'sine aşinadır. Forumlarda etkindir, soru da sorar cevap da verir.
   Bu seviyeden sonra bir çıta var; bu çıtayı yukarıdaki grafikte de görebilirsiniz. Ne mutlu "Ben bu çıtayı atladım" diyene.


3. İleri Seviye: Çıtayı atlayan yazılımcının meziyetleri:
   
   1. Proje kodunun herhangi bir yerinde değişiklik yapabilir. Örneğin Linux çekirdeğine dalıp kafasına göre takılabilir.
   2. Proje kodunu, işletim sistemini, donanım kaynaklarını ve network'ü en iyi performans için evirip çevirebilir.
   3. Programın çalışması esnasında her türlü incelemeyi yapar, gerekirse çakılmaya karşı programlar yazar. Programın çalışmasına tamamen hakimdir.
   4. Kullanılan açık yazılımın kullandığı tüm framework'lere ve diğer açık yazılım araçlarına tamamen hakimdir. Gerekirse başka yazılımlarla beraber çalışması için koda kanca takar.
   5. Açık yazılımın yazıldığı programlama dilini adı gibi bilir. Ufak bug-fix'ler yapar, kodda istediği değişikliği yapar. Rahattır.
   6. Community'de kilit adamlardan sayılır. Açık yazılım camiasından güzel çevre yapmıştır, icabında uzman arkadaşlarından anında yardım alır.
   Bu kadar donanımlı bir adamı kadrolu çalıştırmanın ciddi bir tehlikesi var: işten çıkarsa göt gibi ortada kalırsınız. Yazarın bu tehlikeye karşı önerdiği çözüm bu seviyedeki yazılımcıları sadece kiralayarak, dış-kaynak olarak kullanmak.


4. Uzman: Açık yazılım dünyasının yıldızları olan bu zatların donanımını anlatmaya pek gerek yok. Uzman işte. Ünlü oluyorlar genellikle.

Şimdi ekibinizdeki yazılımcılara bakın, yeteneklerini belirleyin; bir de kullanacağınız açık yazılımın olgunluğuna bakın. Mümkün görünüyor mu?

YETENEK VE RİSK

Açık yazılım kullanarak geliştirdiğiniz yazılımın kaldırabileceği risk seviyesi de kararınızda etkili olmalı. İşte risk toleransına göre projeler:

1. Deneysel: Uçuş serbest. Dilediğiniz gibi bozun yapın.
2. Düşük Öncelik: Kullanılan sistemlerdir fakat uzun süreli çakılmalar pek önem taşımaz. Proje yönetimi için kullanılan Wiki siteleri bu sınıfa örnek gösterilmiş.
3. Bu Sınıfa İsim Bulamadım, Kitapta Operational Diyor: Bu uygulamaların 1-2 saatten fazla çakılı kalmaya tahammülü yoktur.
4. Kritik: Mesela bankaların ATM sistemleri bu sınıfa giriyor. En küçük çakılmaya tahammülü yoktur. Kullanılan açık yazılımda risk varsa bu sınıf için pek de makul bir seçim olmaz.

AÇIK YAZILIM YETENEĞİNİN GELİŞTİRİLMESİ

Bu mesele bir gecede olacak iş değildir. Eğitimi de zaman ve emek yatırımıdır. Ticari yazılıma para yatırırsınız, açık yazılıma zaman yatırırsınız; yani yine para yatırırsınız. Para para para. Demir ustası demiri döve döve öğrenir. Yazılımcı da yapa boza öğrenir. Ticari yazılıma yatırımla kıyaslandığında daha avantajlıdır, şöyle ki, açık yazılım konusunda kendini eğiten bir IT ekibinin yeni açık yazılım projelerini benimseme süresi gitgide azalır. Açık yazılım eğitimi bir şirket politikasıdır, bir düşünce biçimidir. Sevgiler.