Önce hosting firmasının sunucusundaki PHP yorumlayıcısında PDF eklentisinin olmadığını öğrendim. Bu nedenle hosting firması değiştirmem gerekeceğini düşünmeye başladım. Ancak biraz daha araştırınca sadece PHP ile geliştirilmiş ve herhangi bir C PDF kütüphanesi ihtiyacı duymadan PDF formatında çıktı üretebilen bir PHP projesi ile tanıştım: FPDF.

FPDF basit yazabilen bir PHP sınıfından ibaret bir proje. Bu sınıfı genişleterek kendi projenize uygun PDF çıktısı üretecek yeni bir sınıf yazarak kullanmanız gerekiyor. Böylece PDF dökümanının dinamik bir şekilde yazılması sürecinin tamamına (mesela yeni sayfaya geçilmesinde yapılacak işlemlere) müdahale edebiliyorsunuz.

<?php

require('fpdf.php');

class PDF extends FPDF

{


function Header()
{
    // her yeni sayfanın üst kısmına yazılacak
    $this->SetFont('Arial','B',16);
    $this->SetTextColor(255,192,203);
    $this->MultiCell(0,5,"sample header text",0,'L');
}
}


$pdf=new PDF();
$pdf->AddPage();
$pdf->SetFont('Arial','',12);
$txt="FPDF is a PHP class which allows to generate PDF files with pure PHP, that is to say ".
    "without using the PDFlib library. F from FPDF stands for Free: you may use it for any ".
    "kind of usage and modify it to suit your needs.\n\n";
for($i=0;$i<25;$i++)
    $pdf->MultiCell(0,5,iconv('utf-8', 'iso-8859-9', $txt),0,'J');
$pdf->Output();

?>

Türkçe True Type fontları da FPDF’in kullanabileceği formata dönüştürerek sorunsuz Türkçe karakter yazdırmanız mümkün oluyor. Üretilen PDF’lere bu fontlar da gömülüyor ve her PDF gösterebilen ortamda sorunsuz bir şekilde Türkçe karakterleri gösterebiliyor. Tek dezavantajı UTF-8′den anlamıyor. Türkçe yazdırmanız gereken herşeyi iso-8859-9 formatında yazdırmanız gerekiyor. Normalde UTF-8 kodlaması kullandığım için bu durum benim için büyük bir problem olarak karşıma çıktı. Ancak iconv() işlevi yardımıma koştu. Veritabanından okuttuğum tüm UTF-8 içeriğini iconv() ile iso-8859-9′a dönüştürerek FPDF yardımı ile PDF’e yazdırdım.

Basit PDF yazdırma dışında ihtiyacım olan gelişmiş özellikler için ise yine www.fpdf.org‘daki scriptler yardımıma koştu. Her birisinin ayrı ayrı yetenekleri olan onlarca script FPDF’in özelliklerini ve yeteneklerini genişletmektedir. Örneğin çapraz yazı yazmak için Rotation script’i kullanılabilir. Benim amacım çapraz silik yazı yazarak watermark oluşturmak olduğu için Watermark script’i işimi gördü. Bunun yanında PieChart türünde bazı grafikler çizme ihtiyacım olduğu için Sector script’ini de kullandım. Öğretmenlerin sadece çıktı alabilmeleri için PDF Security de uygulama ihtiyacım vardı. Bu nedenle Protection script’ini de projeye dahil ettim.

Üretilen sınav sayfasında her bir sorunun resmi/resimleri ile beraber cevap şıkları da dahil olarak ne kadar yer kaplayacağı önceden bilinemiyor. Bu nedenle oluşturduğum PDF üreteci sınıfın geçici bir instance’ı ile PDF sayfası hazırlıyor ve artan boşluğu hesaplıyorum. Böylece yeni yazılacak olan sorunun ne kadar yer kaplayacağını önceden hesaplamış oluyorum. Buna göre de sayfa yapısında sorular arasında eşit miktara boşluk bırakarak soruların dengeli ve düzenli bir şekilde yerleştirilmesini sağlıyorum. Bu hesaplama bana iki kez PDF oluşturma maliyeti getiriyor. Ancak bu durum bu güne kadar bir performans sorununa neden olmadı.

FPDF’in PDF yazma performansı oldukça yüksek. 5 sayfalık bir PDF’i günümüz için orta güçte olan bir bilgisayarda 0.5 saniyede yazabilmekte. PDF security uygulandığında ise aynı PDF yaklaşık 7 saniyede üretilebilmekte.

FPDF’in oldukça iyi bir dökümantasyonu var. İngilizce sıkıntısı yaşayanlar için dökümantasyonun Türkçe tercümesi Çağlar Ülküderner tarafından yapılmış.

FPDF’i iş başında görmek ve ürettiği sonucu yakından incelemek için sınav üretme demo’sunu http://www.successtosbs.com‘dan gerçekleştirebilirsiniz. Öğretmen Girişi sayfasından Demo Girişi bağına tıklamanız demo kullanıcısı ile oturum açmanız için yeterlidir.

PHP’den PDF üretme ihtiyacı olanlara FPDF’i şiddetle öneririm.

İşin teknik ayrıntılarına inecek olursak ilk aşama oturum açma kısmı tamamen kurumun LDAP / Active Directory sunucusuna ait. İkinci aşamada geliştirdiğimiz yazılım devreye giriyor.

İlk aşama başarılı oturum açma bilgisi alınır alınmaz bir OTP üretiliyor ve SMS ile ilk aşama oturumu açmış olan kullanıcının cep telefonuna gönderiliyor. Kullanıcı ikinci aşamada şifre olarak SMS ile gelen OTP’yi kullanıyor. Yazılımın içinde gömülü olarak çalışan radius sunucusu Juniper SSL-VPN kutusuna ikinci aşama oturum hizmeti veriyor.

Geliştirdiğimiz bu yazılımda radius server işleri için TinyRadius projesini kullandık. SMS gönderimi için ise kurumun sağladığı Web Servislerini AXIS2 projesinin kütüphaneleri yardımıyla kullandık. LDAP sorgulama hizmetleri için JNDI (Java Naming and Directory Interface) kullandık.

JGoodies

JGoodies görsel olarak profesyonel SWING uygulamaları geliştirmeniz için Form Layout, UIF Lite, Looks gibi kütüphaneler sağlamaktadır. Form Layout standart java layoutlarından farklı olarak özellikle bilgi giriş ekranı tasarlamak istediğinizde kullanabileceğiniz oldukça güçlü bir layout manager’dır. Yatayda ve düşeyde hizalı SWING görselleri kullanmanızı sağlar. UIF Lite aralarında görünmez tutamaçlı Split Pane, Inner Frame, Title, Titled Separator gibi görsellerin bulunduğu ve tasarladığınız arayüzün sade olmasına radımcı olan bazı SWING görselleri sağlar. Looks kütüphanesi ise fontların, SWING görsellerinin, renklerin bir uyum ve ahenk içerisinde olması için bazı Look and Feel’ler sağlar. JGoodies’in sitesini incelediğinizde SWING ile profesyonel görünümlü ve doğal hissiyatlı uygulamaların geliştirilmesi için ufkumu nasıl açtığını rahatlıka göreceksiniz.

JGoodies
First Aids for SWING UIs
Efficient SWING Design
JGoodies Libraries
JGoodies Applications

L2FProd Common Components

L2FProd profesyonel görünüme bir adım daha yaklaşabilmeniz için görsel SWING bileşenleri sağlamaktadır. Bu bileşenlerden bazılarını tanırsak; Windows XP explorer pencerelerinin sol tarafındaki gibi bir görünümde link şeklinde düğmeler sağlamak ve açılır kapanır gruplama yapabilmek için JTaskPane, JTaskPaneGroup, JLinkButton görselleri; MS-Outlook’un sol tarafındaki gibi kayarak açılan paneller üzerindeki düğmeleri sağlayan JOutlookBar; Firefox gibi uygulamalarda benzerlerini görebildiğimiz JButtonBar; JTipOfTheDay penceresi ve daha birçok görsel bileşen sağlar.

L2FProd Common Components

HelpGUI

HelpGUI SWING uygulamalarınız için HTML tabanlı yardım belgelerini sunmanız için kullanılan görsel bir araç. Şekil olarak Windows’un help penceresine oldukça benzemekte. Tüm yardım içeriğini .jar dosyası içine gömebilirsiniz.

HelpGUI

JCalendar

Standart Java SWING bileşenleri tarih ve saat seçmenizi sağlayacak bir bileşen içermemekte. JCalendar oldukça başarılı bir tarih – saat seçme aracı sağlamaktadır.

JCalendar

Bu bileşenlerin oldukça faydasını gördüm. Sizlerin de işine yarayacaklarını düşünüyorum.

Arayüz Responsive olmalı

Grafiksel Kullanıcı Arabirimi (ing. Graphical User Interface) hızlı olmalı, kullanıcı komutlarına hızlı yanıt vermeli, donup kalmamalıdır. Arayüz multi-threaded bir biçimde geliştirilmelidir. Bir işlem 200 ms’den uzun sürecekse mutlaka bir progress bar gösterilerek kullanıcıya işlem yapıldığı ve beklemesi gerektiği hissettirilmelidir. İşlem tamamlanana değin arayüzdeki kontrollere dokunması engellenmeli ve fare göstergesi kum saatine dönüştürülmelidir. Bu esnada arka planda kalan ve asıl iş yapan thread görevine devam etmelidir. MVC (Model View Controller) bağlamında arka planda asıl iş yapan thread (model & controller) progress bar’a (view) sürekli olarak ilerleme bilgisi göndermelidir. Eğer ilerleme durumu belirsiz ise (ing. non-deterministic progress), en azından kaçıncı adımı veya işlemekte olduğu veriyi durum bilgisi olarak progress bar’a veya üzerindeki label’lara aktarmalıdır. Bu şekilde kullanıcı uygulamanın donmadığı ve işlem yaptığı konusunda ikna olacaktır. Uzun sürme ihtimali olan her türlü işlemde bu kurallara uyulmalıdır.

Önerilen kodlama şekli ise uzun sürme ihtimali olan her işlem başlangıcında ayrı bir thread ile progress dialog instance’ı hazırlanması (progress bar içeren bir dialog), otomatik olarak 200 ms sonra belirmesidir. 200 ms’den daha kısa sürede işlem sonuçlanırsa da progress dialog’un zamanlayıcısının durdurularak iptal edilmesi ve belirmesinin önüne geçilmesidir.

Bir uygulamanın arayüzünü oluşturan tüm görsel bileşenler (kullanıcının karşısına daha sonra çıkacak olan paneller, sonradan açılacak olan pencereler, …) uygulama açılışında mutlaka yaratılmalı (ing. instantiate), yerleşimi yapılmalıdır, ancak gösterilmemelidir. JVM’in ilk kez instance’ı hazırlanacak olan görsel bir nesneyi hazırlaması oldukça maaliyetli ve uzun sürmektedir. Kullanıcıyı sonradan bekletmektense uygulama açılışında splash screen gösterilirken bir progress bar ile görsel bileşenlerin yüklendiği ve cache’lendiğine dair bilgi verilmesi ve arka planda bu işlemlerin yapılması daha uygundur. Bu yöntemle geliştirilmiş Java Uygulaması çok daha responsive olacak ve çalışma hızı olarak o platformdaki doğal bir uygulamaya yakınmış gibi hissedilecektir.

JList, JComboBox, JTable mümkünse FixedCellWidth ve FixedCellHeight değerleri önceden hesaplanarak verilmeli ve çizim sırasında yeniden hesaplamanın önüne geçilmesi gerekmektedir. Bu şekilde en az 10 kat daha hızlı JList, JComboBox ve JTable’a sahip olacak ve çok daha fazla veriyi bu bileşenlerle gösterebileceksiniz.

Bir JList, JComboBox, JTable içindeki JColumn’larda kullanılan Renderer’lar her tür için ortak bir instance olmalı. Bu tür görsel bileşenlerin önünde yer alacak olan diğer pencereler, pencerenin yerinin değiştirilmesi, yeniden boyutlandırılması, scrollbar aracılığı ile kaydırılması nedeni ile tekrar tekrar Renderer’a çizim için başvurulmakta ve her defasında renderer çizim süreci içinde en ufak bir “new” çağrısı bulunması durumunda uygulamanın bellek kullanımı zamanla artacak, garbage collector bu hıza yetişemeyecek ve bir süre sonra uygulama cevap veremez hale gelecektir. Bu nedenle Renderer çizim sürecinde kesinlikle “new” çağrısı yer almamalı, tüm instance hazırlıkları Renderer’ın constructor’unda halledilmelidir. Renderer çizim sürecinde sadece çizilecek olan görselin modelinde yer alan değerlere göre parametrik değişimler yapılarak önceden instance’ı hazırlanmış bileşenler (metinler, simgeler, kenar çizgileri, zemin renkleri) kullanılmalıdır.

Arayüz’ün hızlı cevap vermesi için yukarıdaki kurallara uygun bir şekilde öncelikli olarak bir splash screen gösterilmeli, splash screen’in uygun bir yerinde bir progress bar ve ilerleme açıklamaları içeren bir label gösterilerek arayüzün gösterilme aşamasına kadar yapılan tüm hazırlıklardan kullanıcı bilgilendirilmelidir. Böylece kullanıcı uygulamanın çok hızlı açılmakta olduğunu düşünecektir.

Fazla çizgilerden kaçınılmalı

Görsel nesneleri daha kolay erişilebilir ve anlaşılır kılmak için gruplarız. Ancak standart gruplama görsellerimiz genelde gereksiz çizgileri yanlarında getirirler. Bu çizgiler kullanıcının gözünü yormaktadır. Fazla çizgilerden kaçınmak arayüzü daha sade, göz yormayan ve anlaşılır yapacaktır. Aradaki farkı görmek için ekran görüntülerine bakınız.

Kenar boşluklarından korkmayın

Pencere ve Dialog’larda kenar boşlukları eklemekten çekinmeyin. Pencere ve Dialog’ların kenarlarına çok yakın olan görsel nesneler kullanıcının gözünü yorar. Geniş kenar boşlukları için çok yer kaplar, görsel nesneler için yer kalmaz gibi düşünülse de oldukça farklı ve rahat bir görüntü sunar. Aradaki farkı görmek için ekran görüntülerine bakınız.

İşletim sisteminin görünüme uyun

İşletim sisteminin görünümüne uyarak kullanıcının işletim sistemi üzerinde kullanmış olduğu diğer programların renk ahengi, hissiyat, yazı tipi gibi  alıştığı look and feel’i kullanıcıya sağlayın. Böylece kullanıcı uygulamanıza daha kolay alışacaktır.

Yazı tipi taban çizgisini koruyun. Standart java look and feel’ı olarak gelen Metal LAF’ta ComboBox’lar oldukça yüksek, Button’lar oldukça alçak, Label’lar alabildiğine alçak şekilde hazırlanmış. Bu görsellerin yatay kenar çizgileri birbirini tutmamakta, eğri büğrü bir görüntü sunmaktadır.

Düşey hizalama önemli

Görsel nesneleri göze hoş görünmesi için düşey olarak hizalamak gerekir. Arayüzdeki her nesne kendi telinden çalarcasına rasgele yerleştirilmiş gibi görünürse zamanla göz yorgunluğuna neden olacaktır.

	Olumsuz Yönler: Label yazı tipleri kalın yazı ile yazılmış, işletim sistemi doğal görüntüsüne uygun değil Renk ahengi işletim sistemi doğal renk ahenginde değil JEditBox, JLabel, JComboBox, JButton türlerinin yükseklikleri farklı Kenar boşluğu bırakılmamış, düğmeler kenarlara yapışık olmuş Çok fazla çizgi var Düşeyde hizalı değil
	Olumlu Yönler: Her tür görsel için işletim sistemi standartlarına uygun font seçimi yapılmış Renk ahengi işletim sistemi ile uyumlu Görsellerin yükseklikleri aynı Kenar boşlukları bırakılmış. Titled Border yerine sade gruplama kullanılmış, fazladan rahatsız edici çizgi yok Düşey hizalama düzgün

Oturum açma ekranı tasarımı

Uygulamaya oturum açma ekranı (ing. login screen) olarak arka planda uygulamanın ana penceresi, önde oturum açma penceresi uygun değildir. Bu stil, henüz oturum açılmamışken uygulamanın yapabilecekleri ile ilgili yabancı kişilere fikir verir. Güvenlik açısından da sakıncalı, görsel olarak da erişilemeyecek görsellerin boş yere gösteriliyor olması da uygun değildir. Bu stilin yerine uygulama çalıştırılır çalıştırılmaz uygulama ana penceresini (ing. main window) göstermek yerine sadece oturum açma ekranı gösterilmesi daha uygundur. Hatta uygulamanın ana penceresinde card layout kullanılarak oturum açma ekranının ana pencere ile aynı boyutta, ayrı bir panel olarak, güzel bir tasarım ile desteklenmesi çok daha profesyonel bir görünüm katacaktır.

Kısa yol tuşları, bağlam menüsü, araç çubuğu, standart menü kullanımı

Kullanıcıya uygulamanızı kullanması için ne kadar çok alternatif yol sunarsanız, uygulamanız o kadar kullanıcı dostu olacaktır. Kullanıcı var, fare ile çok oynar; kullanıcı var, sadece menülerle çalışır; kullanıcı var, sadece klavyeyi kullanır. Hepsine hitap edebilmek, hepsi için de kullanıcı dostu olmak anlamına gelirken, sadece bir veya ikisine dikkat etmeniz durumunda kullanıcıların bir bölümü için uygulamanızın kullanıcı dostu olmaması anlamına gelecektir.

Animasyonlar

Bir animasyonun süresi bellidir. Genelde animasyon yapmak istendiğinde animasyonun kaç adımda tamamlanacağı veya ne kadar sürede bir yeni bir karenin çiziminin yapılacağı önceden hesaplanır. Sonra da hesaplanmış olan bu süre kadar uyuma ve tekrar uyanıldığında yeni karenin çiziminin gerçekleştirilmesi işlemi yapılmaktadır. Bu yaklaşım oldukça güvenilir ve iyi gibi görünmektedir. Ancak donanımdan donanıma karelerin çizilme süresi ve animasyonun tamamlanma süresi değişmektedir. Çünkü her karenin çizilmesinin de bir maliyeti vardır ve zaman kaybı olarak yansımaktadır. Bu nedenle animasyon yapılırken mutlaka gerçek zaman da hesaba katılmalı, gerekirse bazı kareler atlanarak zamanı gelenlerin çizilmesi sağlanmalıdır.

Bu kurallara uyduğunuz sürece uygulamanız profesyonel ve doğal görünecektir. Kötü nam salmış olan çirkin görünüşlü Java uygulaması izlenimi vermeyecek, doğal görünümde olacak, sanki o platformda çalışan doğal bir uygulama gibi hızlı çalışacaktır. Bu yazıda bahsetmiş olduğum bu kurallara uymanızda yardımcı olacak Look and Feel’lardan, Layout’lardan, Standart SWING görselleri dışında ilave SWING görsellerinden ayrı bir yazıda bahsedeceğim.

Günümüzde geliştirilmekte olan yazılımların büyük çoğunluğu çevrimiçi çalışmaktadır. Her ne kadar güvenlik duvarı, saldırı tespit sistemi, saldırı önleme sistemi, uygulama katmanı güvenlik duvarı gibi birçok güvenlik önlemi alsak da, çevrimiçi çalışan yazılımımıza erişmek için açık kapılar bırakmak zorundayız. Bu nedenle yazılımın kendi kendini koruması günümüzdeki olmazsa olmaz ihtiyaçlardandır. Aksi taktirde yazılımımız yapması gereken işi tam olarak yaparken, diğer yandan hiç yapmaması gereken işleri de yapabilir duruma gelebilmektedir. Bu nedenle yazılımların güvenlik ön planda tutularak geliştirilmesi önem kazanmaktadır.

Bir yazılımın güvenli olup olmadığı birkaç yöntemle test edilebilir. Bilindik numaralar ile çalışma anında kandırılmaya çalışılabilir (penetrasyon testi). Bu yöntem ile bir miktar güvenlik açığı tespit edilerek çözülebilir. Ancak tüm güvenlik açıklarının bu yolla tespit edilmesi mümkün değildir. Peki ya kolayca yeniden oluşturulamayan bir durumla karşılaşıldığında ne olacak? Samanlıkta iğne arar gibi ne olduğunu tam olarak algılayamadığımız sorunun kaynağını aramaya çalışırız. Bu aşamada statik kaynak kod analiz yöntemi kullanılmaktadır.

Statik kaynak kod analizi gözle kod üzerinden geçerek yapılabilir. Ancak bu çok uzun ve zahmetli bir süreç. İşin içinde insan faktörü de olacağı için zamanla yorulan göz ve beyin bir miktar hatayı kaçırmaya başlayacaktır. Statik kaynak kod analizi ile verinin izlediği yol boyunca ne tür kontrollerden geçirildiği, güvenlik açısından sakıncalı bulunan işlevlerin kullanılıp kullanılmadığı, threadler arası race condition gibi durumların söz konusu olup olmadığı, … gibi birçok açıdan incelenebilmektedir.

Statik kaynak kod analizi yapan araçlar bulunmaktadır. Örneğin açık kaynak kodlu ve özgür bir yazılım olan findbugs Java uygulamalarındaki olası hatalı durumları tespit etmekte kullanılmaktadır. Doğrudan java bytecode düzeyinde çalışmaktadır. Güzel sonuçlar üretmekle beraber, yanlış bulguları da oldukça fazladır. Statik Kaynak Kod Analizi teknolojisinin oldukça başlarında yer alan bir araç diyebiliriz.

Statik Kaynak Kod Analizi konusunda birçok özgür ve ticari yazılım olan araç var. Hepsinden tek tek bahsetmem mümkün değil. Ancak WikiPedia‘dan oldukça kapsamlı bir liste alınabiliyor. Benim burada bahsetmek istediğim araç, en iyi ve doğru sonuçları üreten, en yakın rakibinden bile 6 – 12 ay kadar önde giden, yoğun kullanılan programlama dillerinin hemen hemen hepsini de destekleyen, statik kaynak kod analizi sektörünün lideri Fortify‘dır.

Fortify ile ilk tanıştığımda kendi geliştirdiğim koddaki bulgularını, önerilerini görünce kendisine hayran oldum. Beni çok şaşırttı ve etkiledi. Statik kaynak kod analizi için kullanmış olduğum uygulamalar arasında en az hatalı ve en kapsamlı sonuç üreten araç Fortify Source Code Analyzer’dır (Fortify SCA). Tespit edilen hata örneklerle beraber ayrıntılı bir şekilde açıklanmakta, oldukça ayrıntılı bir çözümleme yöntemi de tarif edilmektedir. AuditWorkbench ile kodun sorunlu satırları üzerinde hızlı ve kolay gezinme imkanı sağlamaktadır. Kaynak kodu güvenlik, sağlamlık, kod kalitesi gibi değişik açılardan incelemektedir. Oldukça ayrıntılı geliştirici raporu sunabilmektedir. Developer lisansı ile alındığında Fortify Manager adındaki ürün de Fortify tarafından sağlanmaktadır. Fortify Manager ile projelerinizin trendlerini izleyebilir, hangi projelerinizde ne tür hatalar tespit edilmiş, hangi geliştiriciniz ne tür hatalar yapmış gibi yönetim kadrosunun karar almasını kolaylaştıracak raporları kolayca sunabilmektedir. Gecelik build’lara ant entegrasyonu sayesinde müdahil olarak düzenli olarak projelerinizin Fortify ile taranması sağlanabilmektedir. Fortify SCA Java, tüm .NET dilleri, ASP.NET, Classic ASP, VB script, VB6, PHP, C, C++, Javascript, PL/SQL, T-SQL, COBOL, XML ve PROPERTIES dosyası olan yapılandırma dosyalarını inceleyebilmektedir. Hem de lisansının aldığı andan itibaren tüm bu dillerdeki kaynak kodlar Windows, Linux, Solaris, AIX, HP-UX platformlarında statik kaynak kod analizine tabi tutulabilmektedir.

Fortify’ın Türkiye’deki temsilcisi Pro-G‘dir. Fortify SCA aracı kullanılarak, dış kaynak kullanarak geliştirtmiş olduğunuz yazılımların teslimatındaki kabul testleri kriteri olarak veya kendi öz yazılımlarınızın kullanıma geçmeden önce kaynak kod analizini yaptırmak isterseniz Türkiye’de Pro-G ile görüşmeniz gerekecek. Yoğun bir şekilde yazılım geliştiriyorsanız Fortify’a sahip olmak maddi açıdan daha uygun olabilir. Fortify’a sahip olmak için yine Pro-G ile görüşebilirsiniz.

Türkçe karakter sorunlarımız saklama, gösterim, sıralama, büyük – küçük harf dönüşümü gibi kategorilere ayrılabilir. UTF serisi kodlama standartları ile beraber saklama ve gösterim sorunları büyük ölçüde çözülmüştür ve sistemler arası uyumlu hale gelmiştir. UTF standardının yardımı ile eskisi kadar çok Türkçe karakter sorunu ile karşılaşmaz olduk.

Ancak ı ve İ harflerimiz ile ilgili öyle bir sorunumuz var ki, ne yazık ki çözülmesi ile ilgili umudumu kaybetmiş durumdayım. İngiliz i harfinin büyük hali I olmaktayken, Türkçe i harfi’nin büyük hali ise İ olmaktadır. Ancak her iki i harfinin de her kodlama standardındaki sayısal değeri aynıdır. Aslında karakteristik olarak benzer karakterler olsalar da bu özellikleri nedeni ile birbirinden oldukça ayrı karakterlerdir.

Kullandığımız alfabenin Latin ailesinden geliyor olması nedeni ile ne yazık ki tüm yabancı isimler orijinal hali ile yazılarak kullanılmaktadır. Örneğin Linux ismi, Linüks değil de Linux olarak yazılmaktadır. Bu metni Türkçe olarak büyütürsek LİNUX, İngilizce olarak büyütürsek LINUX olarak yazılmaktadır. Ancak orijinalini yazma eğilimimiz olduğu için LINUX olanını kullanırız. Bu durum tüm kuralları alt üst etmektedir. Bu, bizim dilimizde bir metnin bir bütün olarak Türkçe olması söz konusu olamayacağı anlamına gelmektedir. Örneğin bu cümle Türkçe olarak yazıldı, ama içindeki Linux özel ismi Türkçe değildir ve büyük hali de LINUX‘tur.

Bu durum nedeni ile özellikle ana dili Türkçe olmayan geliştiriciler tarafından geliştirilmiş olan (tüm yabancı menşeyli yazılımlar bu kategoridedir) yazılımlarda Türkçe karakter sorunu bulunmaktadır.

Örneğin; PostgreSQL’in Türkçe sıralama ve harf küçültüp büyütme yapabilmesi için dil seçimi ile ilgili tüm çevre değişkenlerinin tr_TR olarak kurulu olması ihtiyacı bulunmakta. Ancak aynı PostgreSQL’in sunucu süreçleri İngilizce dili olarak kurulmuş olan çevre değişkenli bir ortamdan başlatılmaktadır. SQL cümleciklerinin özel kelimelerinin tamamı standart tanım gereği İngiliz dili ile ifade edilen kelimeler (INSERT, INTO, INDEX, …) olması ve küçük büyük harf ayrımı yapılmaması gerektiği belirtilmiş durumda. PostgreSQL küçük büyük harf ayrımını yapmamak için hepsini küçük harfe dönüştürerek bir yapıda tutmakta ve kullanıcının girdiği SQL cümleciklerinin SQL özel kelimelerini de küçülterek bunlarla karşılaştırmakta. Ancak kendi içinde tuttuğu yapı insert, into, index iken kullanıcının girdisi ınsert, ınto, ındex’e dönüştürülmekte. Bu nedenle büyük harflerle yazılmış SQL sorguları işletilememekteydi. Yıllar önce bu sorunu fark edip PostgreSQL geliştiricileri ile paylaştım. Yerel ayarlardan etkilenen bir küçültme işevi olan tolower()’ı kullanmamalarını, özellikle İngilizce küçültme yapan ayrı bir işlev kullanmalarını rica ettim. Beni kırmayıp, sorunu güzelce anlayıp 3-4 günde çözüm getirdiler ve bir sonraki sürümde bu yamanın dahil olacağını ilettiler.

Aynı sorun PHP’de de var. Tamamiyle İngilizce harflerden oluşabilen PHP fonksiyon isimleri ne yazık ki aynı hataya düşülerek yerel dil duyarlı bir işlevle küçültülmeye çalışılmaktadır. Sonuç PostgreSQL ile aynı olmaktadır. PHP geliştiricilerine de hata raporu ilettim. Ancak bu durumu 2003 yılından beri biliyoruz deyip gene çözüm sağlamamayı yeğlediler. Ben her defasında hazırlamış olduğum bu yamayı kullanarak yeniden PHP derlemek zorunda kalıyorum.

Aynı sorun ne yazık ki Java’da da var. Ingilizce olması gereken ifadeler Türkçe yerel dil ayarlı ortamda bambaşka bir hal almakta. Özellikle içinde i ya da I harfleri bulunuyorsa. Karşılaştırmalar çalışmamakta, Bean’lerin setter veya getter methodları bulunamamakta.

Önceleri UNIX’in libc kütüphanesini tasarlayanları suçladım. Yerel duyarlı tolower() / toupper() işlevini geliştiren zihniyet, sadece İngilizce olabilecek olan ifadelerin küçük büyük harf ayrımı yapılmaksızın her yerel dil ayarı altında karşılaştırılabilmeleri için tolower_english() ve toupper_english() sürümlerini hazırlamaz mı hiç? Ancak işin ayrıntılarına inince bu da çözüm sağlamıyor. Lütfen okumaya devam ediniz.

Bu savaşı devam ettirdik ve Türkçe bilmeyen geliştiricileri yola getirdik diyelim. Bu sefer de hem Türkçe hem İngilizce olabilecek olan veri türleri ile ilgili sorunlarımız var. Örneğin bir kullanıcı doğrulama sürecinde ad ve soyad bilgilerini kullandığımızı düşünelim. Küçük ve büyük harf ayrımı da yapmadığımızı düşünelim.

ismail -> İSMAİL (Türkçe bir isim olan İsmail’in doğal dilinde büyütülmesi)
michael -> MICHAEL (Yabancı bir isim olan Michael’in doğal dilinde büyütülmesi)

Uygulamanızı kullanan hem Türk hem de yabancı kullanıcılar olduğunu düşünün. Türk olan kullanıcı ismail, İsmail, İSMAİL gibi verileri girecektir. Ancak yabancı olan kullanıcı Michael, MICHAEL olarak girecektir. Buna göre siz hangi dilde küçültme veya büyütme yaparak karşılaştırmaya sokacaksınız? Ülkemizin köklü bankalarından İş Bankası bu sorunu i ve ı’yı aynı harf kategorisine koyarak çözmüş. “sezai, SEZAİ, sezaı, SEZAI” bu girdilerin hepsi de Türkçe olan Sezai ismini doğrulamaktadır. Benzer şekilde “michael, MİCHAEL, MICHAEL, mıchael” girdilerinin hepsi de yabancı olan Michael ismini doğrulamaktadır. Bu yaklaşım sistemi çalışır duruma getiriyor, günü kurtarıyor olsa da kesinlike doğru çözüm değildir. Yanlış ifadeler doğru gibi kabul edilmektedir.

Ben bu ı ve İ sorunundan bıkmış durumdayım. Ama ne yazık ki çözüm yolu yok. Türkçe i harfini kodlama standardında İngiliz i harfinden ayrı tutsak bu sefer şekil olarak aynı oldukları için karışacaklar. Sırf bu sorunu çözmek için alfabemizi de değiştiremeyeceğimize göre bu sorunla yaşamaya devam edeceğiz. Yanlış da olsa İş Bankası’nın uyguladığı yöntem, sistemi çalışır tutan tek yöntem gibi göründüğü için ben olsam hiç beğenmesem de aynı yöntemi uygulardım.

Karşılaşmış olduğum bu sorunları; Windows’ta 64 bit tamsayı gösterimi sorunları, Dosyaların olduğundan kısa okunup kısa yazılması ve Qt ile klasör seçiminin UNIX gibi görünmesi gibi 3 başlık altında toplayabiliriz.

• Windows’ta 64 bit tamsayı gösterimi sorunları.
  Şifreleme yazılımında 64 bit olması gereken sayısal bir değeri standart olması (c89) için “long long” türünde tanımlamış ve kullanmıştım. Bu değerin görüntülenmesi için snprintf’e format string’i olarak “%lld” vermiştim. Linux’te gayet güzel çalışıyordu. Windows’ta da sorunsuz derlendi. Ancak çalışma anına gelince değer 2 milyarın üzerine çıktıktan bir süre sonra negatife dönüştü.

  Yaptığım araştırmalar sonucunda “long long” türü 64 bit olarak c89 standardında tariflenmiş. Bu standarda Microsoft da uymuş. Ama bu “long long“un bir “*printf” ve “*scanf” işlevlerinde kullanılabilecek bir format string’i standarda bağlanmamış. Microsoft da kendisi “%I64d” biçiminde bir format kullanmış. c99 standarı yayınlandığında “%lld” format string’i “long long” türü için format string’i olduğu kabul edilmiş. Buna herkes uyarken Microsoft eskiye dönük uyumlu olmayı ve nasıl olsa bu işi yapan bir format string’im var mantığı ile “%I64d” format string’ini kullanmaya devam ederek yeni standarda uymamış.

  Özet olarak Windows’taki “*printf” ve “*scanf” işlevlerinde 64 bit bitlik “long long” türünü kullanmak istediğinizde format string’ine dikkat etmek gerekir.

• Dosyaların olduğundan kısa okunup kısa yazılması.
  Linux’te geliştirmiş olduğum uygulamalarda dosyaları hep “open()” işlevi ile açarım. Windows’ta da aynı “open()” işlevini kullandığımda dosyalar aynı şekilde açılıyor. Ancak “read()” ve “write()” işlevlerinde bazı dosyalarda hata alınıyor. Sorunun sadece binary dosyalarla ilgili olduğunu keşfedince, Windows ortamındaki “open()” işlevinin “O_BINARY” bayrağının kurulu olması zorunluluğu olduğunu, bu bayrağın kurulmazsa binary dosyalarda sorun çıkartacağı belirtilmiş. “O_BINARY” bayrağını kurarak “open()” işlevi ile dosya açtığımda “read()” ve “write()” işlevleri aynı Linux’teki gibi davrandılar. Windows’ta “open()” sırasında “O_BINARY” bayrağını kurmayı unutmamak gerek.
• Qt ile klasör seçiminin UNIX gibi görünmesi.
  Qt ile klasör seçim penceresini açtıktan sonra döndürdüğü değer kullanıcının seçtiği klasörün tam yoludur (ing. absolute path). Ancak tüm klasör ayıraçları “\” yerine sanki UNIX sistemiymiş gibi “/” şeklindeydi. Buna parametrik bir çözüm bulamadım ve tüm “/“ları “\“a dönüştürerek kullandım.

Buna benzer başka sorunlarla karşılaştıkça yazmaya çalışacağım. Dikkatli olmak gerek. Windows ortamı standart dışı bir ortam. Microsoft’un standartlara uymak yerine kendi kafasına göre değişik uygulamaları var. Bir gün sizin de karşınıza çıkabilir.

Geçenlerde Pro-G olarak bir iş aldık. AES-256-CBC algoritması ile simetrik şifreleme ve şifrelenmişi geri açma yazılımı.

Müşteri PGP ve asimetrik şifreleme ile bu işi yaptıklarında bir DVD boyundaki verinin donanımdan donanıma fark etmekle birlikte 10-24 saat arasında sürdüğünden şikayet ediyordu. Bu uzun sürecin iş süreçlerini yavaşlattığından yakınıyordu.

OpenSSL ile yaptığımız teorik testlerde 1 DVD boyutundaki veri AES-256-CBC ile yaklaşık olarak 7-20 dakika arasında değişen bir sürede şifreleniyor veya şifrelenmiş veri açılabiliyordu. Bu sürede kullanılan donanım, ortalama dosya büyüklükleri gibi etkenler önemli rol oynuyordu.

İşi resmi olarak aldıktan sonra kendisine verilen bir klasörü belirtilen türde dosyalar için tarayan ve hedef klasöre aynı hiyerarşide şifrelenmişini veya şifreli ise açılmışını oluşturabilecek, openssl’in crypto kütüphanesini kullanan özel bir kütüphane geliştirdim. Tabii ki Linux ortamında.

Hazırladığım test çalıştırılabilirleri ile yaptığım testlerde sürelerin aynen openssl’in komut satırından kullandığımda elde ettiğim süreler ile örtüştüğünü teyid ettim.

Sıra geldi müşterinin kullanabileceği görsellere. Kendim ezelden beri UNIX adamı olduğum için Windows ortamındaki geliştirme araçları ve teknolojileri bana oldukça uzak gelmekte. Bu nedenle platform bağımsız (ing. cross-platform) derlenerek, ilgili hedef sistemde doğal olarak (ing. native) çalışabilecek, ancak ana geliştirme ortamının Linux olacağı bir çözüme ihtiyacım vardı.

GTK ve Qt arasında gidip geldim. Qt ve python ile geliştiren Likya‘lı arkadaşlarım olması nedeni ile Qt’de daha hızlı başlangıç yapabileceğime ve C++’ın avantajlarından yararlanabileceğime karar vererek Qt’yi kurcalamaya başladım. Hız artırmak için Likya’lı Mustafa kardeşimden randevu aldım. Kendisi de beni kırmayıp qt-designer ile GUI oluşturulduktan sonra nasıl C++’a çevrilir, nasıl bir proje haline getirilir konusunda 2-3 saatlik bir vaktini bana harcadı. Kendisine çok teşekkür ederim.

Zaman içinde proje tamamiyle GUI olarak kullanılabilir duruma gelince sıra geldi Windows ortamında derlemeye. Windows sanal makinama mingw, g++, Qt kurulumu gerçekleştirdim. Linux’te geliştirmiş olduğum GUI programım aynı Linux’teki gibi başarıyla derlendi ve çalıştı. Hem de aynı Linux’teki gibi “make” ile. Tabii ki Windows’a özgü bazı davranış bozuklukları ve API değişiklikleri oldu. Onları da zaman içinde yaşadıkça çözdüm. Her birisi ayrı bir gönderi konusu olabilir. Vakit bulabilirsem onlardan da bahsederim.

Ancak benim vurgulamak istediğim UNIX’ci birisi içim Windows ortamında uygulama geliştirmek oldukça zor. Eliniz kolunuz bağlı kalıyor. Bu nedenle UNIX benzeri bir ortamın cygwin, mingw gibi araçlarla MS-Windows ortamında da sağlanıyor olması, GTK ve Qt gibi platformlar arası taşınmış görsel kütüphanelerin bulunuyor olması benim gibi UNIX adamlarının Windows üstünde de işlevsel olmasına oldukça yüksek katkısı oluyor.

Özet olarak şifreleme yazılımı Windows üstünde çalışıyor olmasına rağmen vi, make, g++, openssl ve Qt kullanılarak geliştirilmiş oldu. En güzel yanı da aynı yazılımı aynı görsellik ve işlevsellik ile Linux, Mac OSX, Solaris, AIX gibi sürümlerini de doğal olarak sağlayabiliyor olmak.