Eclipse eklentisi geliştirme eğitiminin 2. haftası

1. hafta: OBSS’nin Eclipse eğitiminden notlar

Bu haftaki eğitimin ikinci bölümü devam ederken ben birinci bölümden izlenimlerimi paylaşmak istiyorum.
Birinci bölümde Eclipse’in arayüzünde değişiklik yapabilen bir eklenti üzerinde çalışıldı. Ana menüye seçenekler eklemek, araç çubuğuna yeni düğmeler eklemek ve bir “view” oluşturmak gibi işlemlerin nasıl gerçekleştirilebileceği anlatıldı.
Ara verildiğinde Eclipse’in eklenti arayüzünün ne kadar esnek olduğu konusunda biraz sohbet ettik. Bir arkadaş basit bir arayüz yazmak için Eclipse’in fazla karmaşık olduğunu düşündüğünü söyledi. Evet basit bir arayüz için Eclipse birinci tercih olamaz. Bir eklenti geliştirmeye başlamadan önce ortaya çıkarmak istediğiniz ürünün gereksinimlerini ve Eclipse’in bu gereksinimlerin ne kadarını size sağladığını belirlemelisiniz. Eğer Eclipse ihtiyacınız olan bileşenleri sunuyor ise eklenti yazmak verimli olacaktır. Bunun tersi bir durum oluştuğunda Eclipse işinizi yavaşlatacaktır.
Örneğin OBSS’de Graymound çatısı için bir Eclipse eklentisi yazılmış. Bu eklentinin yazılabilmesine olanak sağlayan Eclipse bileşeni EMF’dir. Eğer EMF olmasaydı OBSS bir eklenti yazmayı göze almazdı.

OBSS’nin Eclipse eğitiminden notlar

OBSS

Salı günü 19:15 – 21:15 arasında OBSS firmasının düzenlediği Eclipse eklentisi (plugin) geliştirme eğitimindeydim.

Eğitimin ilk bölümünde Eclipse ve Eclipse’in eklenti geliştirme arabirimi hakkında genel bilgiler anlatıldı. Ara verildiğinde Hüseyin fırsatı değerlendirip şirketin geliştirdiği Graymound çatısı hakkında bilgi verdi. İkinci bölümde ise Graymound çatısının ana geliştiricisi Eclipse bileşenlerinin (feature) nasıl oluşturulduğunu ve yayımlandığını anlattı.

Bir sonraki hafta aynı gün aynı saatte eğitim devam edecek.

Lighty HTTP sunucusu (lighttpd)

Bilgisayarımda FeedAPI eklentisini ve onun için yazdığım bazı eklentileri test ediyorum. Cron görevlerini 10 dakikada bir çalışmak üzere ayarladım.

Düne kadar Eclipse, Firefox ikilisi ile çalışırken bilgisayar bir süre sonra tepkisiz kalıyordu. Cron görevleri olmadığı zaman gayet rahat çalışabildiğimi bildiğim için bu tepkisiz kalmanın sebebinin Apache olduğunu biliyordum.

Önce Apache’nin ‘prefork‘ yerine ‘worker‘ modelini kurmak istedim. Ne yazık ki Ubuntu ‘worker’ modelini desteklemiyormuş. Desteklememesinin nedeni ise pek çok PHP uygulamasının ‘thread safe‘ olmaması. Bunun üzerine Lighty‘yi denemeye karar verdim. Apache’yi kaldırıp Lighty’yi kurmak gerçekten çok kısa sürdü. Şimdilik bu değişimden memnunum. Artık bilgisayarım tepkisiz kalmıyor.

Aşağıya paket yöneticisi ile kurulumu yaptıktan sonra uygulanması gereken bazı komutları yazıyorum:

cd /etc/init.d/
sudo ./apache2/apache2 stop
sudo ./lighttpd/lighttpd start
sudo lighty-enable-mod cgi
sudo ./lighttpd/lighttpd force-reload

Drupal maceram devam ediyor

Uzun zamandır Drupal üzerinde çalışıyorum.
Çekirdek dağıtımın içerisinde gelen eklentileri inceledim. drupal.org/handbooks adresindeki kitapları kısmen okudum. FeedAPI eklentisi üzerinde biraz çalıştım. Webcomic eklentisini Drupal 5.x sürümü için güncelledim.
Artık blogkure.net için çalışmaya başlayabilirim.

(Linux’ta) Masaüstü yöneticisinin veri yolu (PATH) değerini değiştirmek

Sık kullandığımız bir programı çalıştırmak için her seferinde programı yerleştirdiğimiz dizinin tam yolunu yazmak bize zaman kaybettirir. Örneğin şu sıralarda çok kullandığım bir programın çalıştırılabilir dosyaları “/opt/arm/3.4/bin” dizininin içerisinde. Bu dizindeki “arm-linux-gcc” komutunu çalıştırmak için her seferinde “/opt/arm/3.4/bin/arm-linux-gcc” yazmak yerine bir sefer “export PATH=$PATH:/opt/arm/3.4/bin” komutunu çalıştırıyorum. Bundan sonra “arm-linux-gcc” komutunu istediğim yerde tam yolunu belirtmeden kullanabiliyorum.

Sistem her başladığında yukarıdaki basit ayarın kendiliğinden yapılmasını sağlamak için “/etc/profile” dosyasının sonuna “export PATH=$PATH:/opt/arm/3.4/bin” satırını ekledim. Bu değişiklik sayesinde kabukta (shell) çalışırken kendime kolaylık sağlamış oldum fakat masaüstü yöneticisi (gdm) farklı bir katmanda (!) çalıştığı için aynı değişiklik masa üstünden veya dosya yöneticisinden çalıştırdığım programlarda geçerli olmadı.

Mesela NetBeans programını masa üstüne yerleştirilmiş olan kısayolu kullanarak çalıştırdım. Birşeyler derlemek istediğimde “arm-linux-gcc komutu bulunamadı!” gibi bir hata verdi.

Bu hatanın üstesinden gelmek için masa üstü yöneticisinin ayar dosyasında bir değişiklik yapmak gerekiyor.¹ Önce “/usr/share/gdm/defaults.conf” dosyasında “[daemon]” bölümünün altındaki “DefaultPath=” ile başlayan satırı alıyoruz. Bu satırı “/etc/gdm/gdm.conf” dosyasındaki “[daemon]” bölümünün altına kopyalıyoruz. Şimdi de kopyaladığımız satırın sonuna “arm-linux-gcc” dosyasının bulunduğu klasörü ekliyoruz. Bu işlem sonucunda şöyle bir satır elde ediliyor: “DefaultPath=( varsayılan değerler ):/opt/arm/3.4/bin

gdm.conf” dosyasını kaydettikten sonra bilgisayarı yeniden başlatmak gerekiyor. Bilgisayarınız açıldığında masa üstü yöneticisi ile aynı dili konuşuyor olacaksınız.

¹ Burada anlatılan ayarlar Debian GNU/Linux üzerinde denenmiştir. Diğer dağıtımlarda farklılıklar olabilir.

Drupal deneyimim

Bir süredir Joomla! ve SMF etkileşimiyle oluşturduğum bir site için alternatif arayışındaydım. Artık bu arayışım sona erdi. Drupal‘ı buldum.

Joomla! ve SMF’nin beni tatmin edememesinin bazı nedenleri var. Birincisi Joomla!’nın standart dağıtımında bir topluluk sitesi için ihtiyaç duyulan özelliklerin hiçbiri bulunmuyor. Kullanıcı yönetimi, mesaj tahtası, kişisel günlük, yorumlar, geri izlemeler ilk olarak aklıma gelen eksiklikler. Üçüncü şahısların yazmış oldukları eklentiler ise her zaman güvenlik sorunları oluşturuyor.

SMF’yi kullanmaktan vazgeçmemin ise farklı bir sebebi var. SMF’nin kullandığı lisans sözleşmesi diğer açık kaynak yazılım lisansları ile uyumsuz. Bana göre bu uyumsuzluk SMF’nin gelişimini yavaşlatıyor. Örneğin bu tarihte en güncel olan 1.1.3 sürümünde hala WYSIWYG editörü bulunmuyor. Piyasada bazı açık kaynaklı WYSIWYG editörleri bulunmasına rağmen lisans kısıtlamaları nedeniyle bu editörler SMF paketine dahil edilemiyor. Bu nedenle SMF geliştiricileri bütün bileşenleri sıfırdan yazmak zorundalar. Sonuç olarak özgür yazılım camiasının desteğinden mahrum olan SMF’nin gelişimi sancılı oluyor.

Joomla! ile SMF’nin bütünleşmesini sağlayan köprü eklentisi de lisans uyumsuzluğu nedeniyle askıya alındı. Bu nedenle yakında yepyeni sürümleri yayımlanacak olan iki yazılımın da yolları tamamen ayrılacak.

Drupal’ı tercih etmemin nedenlerine gelelim. Kullanmaya başlayalı henüz birkaç saat geçmesine rağmen yazılımdan oldukça etkilendim. Topluluk yönetimi için ihtiyaç duyulan özellikler (kullanıcı yönetimi, mesaj tahtası, kişisel günlük, yorumlar, geri izlemeler) standart dağıtımın içinde geliyor. Bu özelliği, amacım bir topluluk sitesi oluşturmak olduğunda, Drupal’ı diğer seçenekler arasında ilk tercihim yapıyor.

Drupal’ı öne çıkaran bir diğer sebep de drupal.org’daki temalar dizini. Yeni bir tema arayışına girdiğimde bakacağım ilk adres bu dizin olacaktır. Bu sayede zaman kaybı en aza inecek ve temanın güncellemelerini daha rahat takip edebileceğim.

Artık bir topluluk sitesi kurmak istediğimde yazılım tercihim Drupal olacak. Bunun dışındaki çalışmalarda işin gereksinimlerine göre diğer sistemleri göz önünde bulunduracağım.

Joomla! 1.5 neler getiriyor?

joomla_screenshots

Joomla! 1.5 RC1 yayımlandı. Daha önce yazdığım gibi bu sürüm web sunucularında kullanılabilecek kararlılıkta.

İlk olarak gözüme çarpan yenilikler

URL’ler daha okunaklı hale getirilmiş. Bunu sağlamak için eski sürümdeki gibi URL’lerde yazı numarası yerine yazının başlığı kullanılmış. URL’lerde “ç,ğ,ı,ö,ş,ü” karakterleri de kullanılabiliyor.

RSS ve Atom sağlayıcısı (Haber akışı) yeniden yazılmış. Artık haber okuyucu programlarda (Google Reader, vb.) yazının içindeki bağlantılar ve resimler de gösterilebiliyor. Ayrıca farklı bölüm ve kategoriler için de haber akışı alınabiliyor.

FTP katmanı kullanılarak dosya ve dizin erişim izinlerinde oluşan problemler önlenmiş.

XML-RPC erişilebilirliği eklenmiş. Joomla! 1.5’in kendine ait bir XML-RPC API’si bulunuyor. Masaüstü uygulamalarının bu API’yi kullanmaya başlamaları zaman alacağı için Blogger API desteği de verilmiş. MetaWeblog API desteği de yolda.

Yönetim panelinin kullanımını zorlaştıran bazı özellikler yeniden düzenlenmiş. Örneğin 1.0 sürümünde yazının giriş paragrafı ile içeriğini ayrı editörlere yazmak gerekirken 1.5 sürümünde ikisini de tek bir editöre yazabiliyorsunuz. Ayrıca “mosimage” eklentisi de kaldırılmış. Artık yazılarınıza resim eklemeyi editörün içerisinde gerçekleştiriyorsunuz.

Bir diğer düzenleme de eklenti, tema ve dil paketlerinin kurulum sisteminde yapılmış. Artık her türlü paketi tek bir yerden yüklüyorsunuz. Joomla! 1.5 kurmak istediğiniz paketin içeriğini kurulum sırasında anlayabiliyor.

Yönetim panelinde Ajax bileşenleri kullanılarak sayfayı yenilemeden bazı ayarların yapılabilmesi sağlanmış. Aynı şekilde yazıyı kaydetmeden önizlemesini görebiliyorsunuz.