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

WordPress.com hesabınız güvenli

WordPress.com günlüklerinin yönetim alanları SSL şifrelenmiş iletişim katmanı ile korunuyordu. 15 Aralık 2006 tarihli günlük girdisi ile bu özelliğin kaldırıldığı (!) duyurulmuştu. Bu özelliğin kalkmasından sonra umuma açık İnternet bağlantısı sunulan alanlarda WordPress.com hesabımıza giriş yapmayı bırakmıştık. Bilgi güvenliğimiz¹ için oldukça önemli olan bu özellik tamamen kaldırılmış mıydı?

Hayır, SSL katmanı WP.com’dan asla tamamen kaldırılmadı, sadece gizlendi. Eğer WP.com günlüğünüzün kullanıcı girişi sayfasına aşağıdaki gibi bir URL ile erişirseniz kullanıcı adınız ve şifreniz sanal ortamda şifrelenmiş olarak iletilecektir. (“https://” protokolüne dikkat edin.)

https://mustafaulu.wordpress.com/wp-login.php

Giriş yaptıktan sonra yönetim alanınıza da aşağıdakine benzer bir URL ile eriştiğinizde bütün yönetim faaliyetleriniz güvenli bir yöntemle iletilecektir. (“https://” protokolüne dikkat edin.)

https://mustafaulu.wordpress.com/wp-admin/

¹ İnternet’te dolaşırken bilgi güvenliğinizi önemsiyorsanız SSL kullanımına dikkat etmelisiniz. Kişisel bilgilerinizi girdiğiniz sayfalarda SSL etkinleştirilmiş olmalıdır. Aksi taktirde sizinle aynı bağlantıyı paylaşan herhangi birisi bilgilerinizi ele geçirebilir.

(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.