31.10.06

Yazılım yapı taşları

Türkiye'ye geldiğimden beri bir çok yazılım firması ile tanışma fırsatım oldu. Bu tanışmalarda beni en çok şaşırtan oldukça saygın yazılım firmalarının bile yazılım üretiminin temel taşı olan sürüm denetimi, yayım yönetimi, ve hata takibi gibi uygulamalarını kullanmamaları oldu. Bu konularda konuşmak istediğimde cevap hemen hemen hep aynıydı, "Haklısın aslında yapmamız lazım ama..", "Biz zaten hep yedek kopyalarımızı alıyoruz.", "Bizde zaten her programı yazan sadece bir kişi var" veya "Biz bu sistemleri kullansakta kullanmasak da işlerimiz yürüyor, paramızı kazanıyoruz".
Aynı sözleri daha önce çalıştığım firmalarda da duymuştum. Özellikle yeni başlayan küçük ölçekli firmalarda, yazılımın bir an önce bitirilip ürünün piyasaya sürülebilmesi veya projelerin çabuk bitirilebilmesi için bu tür yapı taşları tamamen ikinci plana itilmişti. Sürüm kontrol veya yayım yönetimi faydalı araçlar olarak görülmediği gibi, vakit kaybettiren bürokratik araçlar olarak benimsenmişti.
Mühendislik bilimi tekrarlanabilir sonuçlar üzerine kurulmuştur. Yazılım üretiminin de bir mühendislik olabilmesi için bu tekrarlnabilirliğin sağlanması gerekir. Bu tekrarlanabilirlikde ancak sürüm kontrolu, yayım yönetimi ve sorun takibi gibi araçların doğru kullanılması ile mümkün olur.
Sürüm kontrolu ve yayım yönetimi uygulanmayan bir şirkette yeni başlanılan bir projeyi ele alalım. Programcımız kodlamaya başlar ve proje gereksinimleri doğrultusunda kodlamaya devam eder. Proje devam ederken bazı değişiklikler gerekir programcımız bu değişiklikleri yapar. Daha sonra bu yaptığı değişikliklerden bazılarının geri çevrilmesi istenir. İşte bu anda programcının elinde bir sürüm kontrol sistemi olmadığı için, daha önceden yaptığı değişiklikleri eliyle düzeltir. Ama aynı hataya bir kez daha düşmemek için kodun değişik zamanlarda kopyasını almaya başlar. Bu kopyaları düzenli tutabilmek için her birini tarih atılmış bir dizine kopyalar vs.
Daha sonra müşteriye ürün gönderilir ve bu ürün kopyasıda müşteri adı ve tarih ile bir dizine kopylanır. Bir de bakarsınız ki programcımız programlama yükünün yanında birde manuel olarak sürüm kontrolü ve yayım yönetimi ile uğraşmaktadır.
Bunun yerine daha sağlıklı ve daha verimli çalışan bir sürüm kontrol uygulması kullanılabilir. Şirket bünyesinde bir kez harcanılacak bir planlama ve gerçekleme safhasından sonra tüm projelerin sürüm kontrolleri ve yayım yönetimleri yapılabilir, bunlar yazılım üretim süreçlerinin birer parçası haline getirilebilinir.
Faydası tek kişilik programlama ekiplerinde çok kolay görülen bu araçların, çok programcılı projelerdeki yararları ortak kullanılan kodlar ile daha da belirginleşir. Bır projede kullanılan koda başka bir projeden erişmek istenildiğinde yapılacak en kolay şey o kod dosyası aynen yeni proje içerisine kopyalanır. Aynı işlem bir kaç temel kod için bir sürü projeye kopyalandığında elimizde aynı kodun onlarca kopyası olur. İleride bu kod içinde bulnacak bir hatanın düzeltilebilmesi için tüm kopyalarında düzeltilmesi gerekir. Bunu önleyebilmek için bir yol bu kodun bir kütüphane içine konup tüm projeler tarafından ortaklaşa kullanılmasını sağlamak olabilir.
Bu ilk bakışta geçerli bir çözüm olarak gözüksede tek başına sağlıklı bir çözüm değildir.
Aynı kütüphane ye bağımlı iki proje olduğunu düşünelim. Birinci proje ihtiyaçları doğrultusunda kütüphane üzerinde değişiklikler yapması gerektiğinde ne yapmalıdır? Yaptığı değişikliklerin ikinci projecyi nasıl etkiliyeceğini bilmediği için kütüphaneyi yayımlayamaz (veya yayımlar ama diğer proje çalışmaz hale gelebilir.). Ya kütüphaneyi tamamen değiştirecek ve yeni bir kütüphane yayımlayıp birinci projenin bağımlılığını bu kütühnaye yapıcak, veya ilave edilmek istenilen fonksiyonları yeni bir kütüphane içinde toplayıp bunu projesine ekliyecek, bu da kaçınılmaz olarak kod tekrarına yol açıcak ve ilk anlattığımız senaryoya dönülecek.
Tahmin ettiğiniz gibi bu sornun çözümüde sürüm kontrol, yayım yönetimi ve testlerden geçiyor. Projelerimizi elimizdeki kütüphanelerin belirli sürümlerine bağımlı yaparak ve yazdığımız kodlarda kapsamlı testler kullanarak yukarıda bahsettiğimiz sorunların çözümü oldukça kolay.
Bir kütüphanede değişiklik yapılmak istendiğinde programcı bu değişiklikleri yapar ve kendi kodu ile test eder, daha sonra yapılan değişiklikleri sürüm kontrol sistemine eklemeden önce bu kütüphanenin yayımlanması gerekir. Yayım yönetim sistemi kütüphanenin yeni sürümünü kabul etmeden önce, yapılan değişikliği bağlı olduğu her proje için test edilmesini ister. Eğer yani yapılan değişiklikler başka bir projenin işleyişini bozuyorsa, kütüphane değişik bir sürüm numarası ile yayımlanır ve üzerinde çalışılan projenin ayar dosyaları değiştirilerek projenin bu yeni kütüphaneye bağlanması sağlanır.

Örneklerle anlatmaya çalıştığım gibi, bu tür uygulamalar başlangıçta zaman kaygı gibi gözüksede uzun vadede çok değerli yatırımlardır.

Özgür


Not: Aşağıdaki liste tam değildir, linkler örnek teskil etmesi amacıyla verilmiştir. Her bir ürünün avantajları veya desavantajları hakkında diğer sayfalardan bilgi alabilirsiniz.


Sürüm Kontrolü Yazılımları:
CVS
Subversion
Visual Sourcesafe

Yayım Yönetimi:
Maven
Yayım Yönetimi Bloğu

Hata Takibi:
bugzilla

17.10.06

Apache2 altinda SSL sertifikasi - Linux Debian

Apache2yi paket olarak kurduktan sonra aşağıdaki adımları kullanarak sisteminize güvenli bir web sunucusu kurabilirsiniz:

1. Sertifika için gerekli olan anahtar ve sertifika dosyalarınızı /etc/apache2/ssl altına kopyalayın.
2. /usr/share/doc/apache2/examples/ssl.conf.gz dosyasını unzip yapın, ve
ssl.conf dosyasını /etc/apache2/sites-available/ dizinine kopyalayın.
3. #a2ensite /etc/apache2/sites-available/ssl.conf kullanarak Apachenin SSL icin bir sanal sunucu çmasını sağlayın.
4.#a2enmod ssl komutu ile Apachenin SSL modülünü aktif hale getirmesini sağlayın.
5. ssl.conf dosyasını açıp SSLCertificateFile ve SSLCertificateKeyFile değerlerini /etc/apache2/ssl dizinine kopyaladığınız dosya isimleri ile değiştirin.

6. /etc/apache2/sites-enabled altında bulunan diger tüm dosyalarda
<VirtualHost *>ve NameVirtualHost * 'i aşagidaki gibi değiştirin:
<VirtualHost *:80> ve NameVirtualHost *:80

7. ssl.conf dosyanızda DocumentRoot olarak belirtiğiniz dizinin altına yerleştireceğiniz sayfalara
https://www.yourdomain.com/dosyaadi.html olarak ulaşabilirsiniz.



4.10.06

test post

testing

This page is powered by Blogger. Isn't yours?