Yaptığım araştırma ve incelemeler sonrasında sanal makinayı DSL (Damn Small Linux) ile kendi sitesi üzerinden web browser içinden applet olarak test ettim. Performansı oldukça başarısızdı. Ancak yine de Java dili ile x86 makina yapılabilmiş olması ve Linux işletim sistemini grafiksel kullanıcı arabirimi ile kullandırabiliyor olması Java dilinin gücünü göstermektedir.

GPL2 lisanslı JPC’ye ulaşmak için http://www-jpc.physics.ox.ac.uk/ adresine tıklayabilirsiniz. Yapmış olduğum denemenin ekran görüntüleri aşağıdadır.

İş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.

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.