UNIX Manual Page Editor: RManEdit

RManEdit is a editor to prepare man page. I used Ruby & Gtk for RManEdit. RManEdit has many features like other editors. You can get more information from  here.

Nagios plugin to monitor Couchbase

I've created CouchBase plugin for Nagios. I used Python for plugin. I put plugin in Github. You can access here. Nagios Plugin Couchbase is available under the GPLv3. Your suggestions and feedbacks will be valued and highly appreciated.


Nagios plugin couchbase supply to monitor a lot of summary statistics:
Cache miss ratio, creates per second, disk read, high and low watermark, set per second, memory usage, operations per second..  etc.

You can monitor vbucket resources with option "--vbucket". You can see all option using "--help" parameter and you should read from Readme for more information about usage. And a screenshot:

Unix Man Sayfası Hazırlama Editörü: RManEdit 2.0.2

Ruby ve Gtk kullanarak kodladığım RManEdit 1.0.1 sürümünde tek sayfa açılabiliyordu. Şimdi 2.0.2 sürümünde ise çoklu sekme yapısı, bul değiştir, sihirbaz özellikleri ekledim. RManEdit diğer metin editörlerinin sahip olduğu bir çok özelliğe sahip. Projenin kurulum ve kullanım bilgilerine buradan ulaşabilirsiniz. Projeden bir kaç ekran görüntüsü:

Ruby Kodlama Biçimi Önerisi

Bir çok dilde kodlama yapılırken uyulan kurallar var. Aslında bu kurallar bir zorunluluk değil, kodun anlaşılırlığını kolaylaştırmak, kod yazımında bir ortaklık sağlamak için üzerinde anlaşılmış tavsiyeler. Python için bu konuda PEP 8 ile belirlenmiş kuralların bir kısmı. PEP 8 belgesi hakkındaki Türkçe yazıyı da bir üst dönemden Ahmet Can burada yazmış. Oldukça da güzel olmuş yazı.

Ruby ile kodlamayı daha çok sevdiğimden ve genelde Ruby kullandığımdan, Ruby için kodlama standartları nasıl diye biraz araştırdım. Resmi bir belge bulamadım. Ancak Github'da bir kaç belge buldum bu konuda. Bunlardan en çok yıldız alan, en çok kullanılana uymak daha doğru diye düşündüm. Bu belge baktıklarım arasında en çok kullanılan anladığım kadarıyla. Bu yüzden bu belgenin Türkçesini de Github'da tutmaya karar verdim. Ancak bire bir çeviri yapmadım. Yazdığım belgeye buradan ulaşabilirsiniz.

Belgede yazan girintiler 2 boşluk olmalı, fonksiyon yazımları, while kullanımı gibi bir kaç konuda daha Ruby'ciler ile aynı görüşte olduğumu öğrenince pek mutlu oldum :) Mesela bana sorarsanız Python'daki 4 boşluk fazla ama herkes böyle 4 boşluk kullandığından 2'ye düşürmüyorum Python'da, ya da özellikle betik dillerinde çok fazla farklı for yapısı oluyor. Bu durum Ruby'de de böyle. O zaman benim için bu durum kafa karıştırıcı oluyor. Dizi, hash yapısı gibi yerlerde .shift, .each gibi yapılar kullanıyorum. Herhangi bir for yapısını ise while ile sağlıyordum. Bu çevirdiğim belgede de bu durum böyle önerilmiş :)

Bir de belgeyi okurken Ruby ve programlamada bilmediğim kavramları öğrendim.  Duck-typing, factory method pattern gibi kavramları daha önceden duymamıştım açıkçası. Mesela Ruby'de "%" karakterinin dizge (string) yazımında bilmediğim özellikleri varmış, Ruby'de sembol kavramını da daha önce kullanmamıştım. Bu gibi bilmediğim kavramları öğrenmek de bana faydalı oldu. 

3. Sınıf Biter Sonrası Staj

Bu yıl 3. sınıfı bitirip artık 4 oldum. Biraz tuhaf bir yıl oldu benim için. Hem biraz hastaydım, biraz küsmüş derken yılı sonlandırdım. İlk dönem fazlasıyla rahatsızdım midemden. Zaten zayıf bir insan olarak hepten zayıfladım :) Ama gene de boş geçirmedim tabiki yılı. Tabi Necdet hoca boş geçirmemem için dürtükleyip duruyordu o ayrı :)

Bu dönem aslında hiç istediğim gibi çalışamadım. Okul sınavlarımı çok boşladım bu yıl, aslında pek boşlamazdım sene sonunda genelde iyi sonuçlar elde ederdim. Sanırım bu yıl sınavlara sallamadan nasıl oluyor bir deniyim mi istedim ne istedim ben de bilemedim :) İlk dönem olan derslerden Java vardı ama ben Java'yı sevmiyorum. Yazımı gereksiz uzun bence. C++ daha çok seviyorum açıkçası. Bir de 2. sınıftayken okuldaki derslere çok hevesli başlardım. Ancak okuldaki hocalarda aynı tepkiyi alamadım. O yüzden artık okuldaki derslerde pek heveslenmiyorum "vay be bunu öğreneceğim" şeklinde. Zaten 3. sınıf olduğumuz için aldığımız son programlama dersi olarak Java vardı. Bundan sonraki dersler hep işletim sisteminin çalışması, programlama dilleri ve kavramları, mikro işlemciler gibi dersler. 3'ün ilk döneminde veri tabanı dersi de aldık, ben bu yıl pek çalışmadığımdan onu pek verimli geçiremedim, açıkçası buna da üzüldüm biraz. Veri tabanı iyi öğrenmek isterdim. Aslında arka planda tamamen veri tabanı tasarımına dayanan uygulamalar yazmayı sevmem, ama sevmemem boşlamamı pek gerektirmezdi. Belirli bir seviyeye kadar varlıklar arasında ilişki kurmayı ben de yapıyorum tabi. Ama daha karmaşık şeyler üzerinde çalışmadım.

Bu dönem bana sorarsanız dersler bakımından ağır değildi. Konular 2. sınıfı geçirdikten sonra daha rahat anlaşılırdı benim için. Bir de okul dışında uygulama yapınca kavraması daha basit oluyor. Ezberleyip geçmekten farklı bir hal alıyor. 2. sınıftan daha fazla okul dışında işlere bakmak için vakit vardı bence. Ancak ben zaman yönetimini pek yapamadım.

Bu yıl Linux dağıtımlarına yönelik 2. sınıfa oranla oldukça şey öğrendim. Lpi 101 sınavına çalışmıştık bir grup olarak okulda, ona giren her arkadaşımla birlilkte başarıyla sonuçlandırdık Lpi 101 sınavını. 1. dönem fazla rahatsız olduğumdan ara tatilde RManEdit'i yaptık. Ve gene ilk dönem Gnome'un Outreach for Women etkinlğine katılarak projelere katkı vermeye başladım. Aslında katkı verdiğim uygulamayı da zor şartlar altında çalıştırıp yamayı göndermiştim. Benim makinemde problem olduğundan okuldan bir makine kullanmak zorunda kalıyordum. O zamanda sabahtan akşama kadar okulda durduğumdan dışarıda yemek yemek (yiyememek) midemi daha fena getiriyordu. Ara tatilde uzun bir süre ev yemekleri yediğimden midem biraz daha düzeldi. Derken 2. dönem ortasından sonra mide ilaçları kullanmadan devam edecek kadar iyileşebildim :)

2. dönem RManEdit'in eksik yerlerinin bir kısmını tamamladım. Bir de Yakından Eğitim projesi olan Nagios Couchbase Plugin'e başvurdum. Nagios eklentisi projesini de başarı ile neticelendirebildim. Bir de gene Necdet hocanın Gnome projelerine katkı ver sıkıştırmaları nedeniyle jhbuildi kurmak ile olan yakından ilişkim bilgisayara her format attığımda yeniden başladı. Aslında bana sorarsanız projelere katkı vermek için en güzeli dağıtımların kararlı olmayan hallerini kullanmak. Gündelik ihtiyaçlar için iyi diyemem, ama katkı vermek için iyi. 2. dönem bir de Muğla'da ilk sunumumu yaptım. 4. sınıflardan Ahmet ve Serhat ile birlikte Özgür Yazılım projelerine nasıl katkı verilirden bahsetmiştik. Muğla'da yoldan, heyecandan, midem fena olursa yemek yiyemediğimden halsiz kalırım ve kötü olur diye korkmuştum aslında. Ancak öyle olmadı :)

Reflü kötü bir şey :( İlk zamanlar kötü aslında bir süre ilaç kullandıktan sonra midenizi pek zorlamazsanız çok sorun olmuyor.

Şimdi ise bu hafta çalışmam gereken bir sınavım kaldı. Sonrasında staja başlamadan önce okumam gerekli olan belgeler var. Stajımı sistem yönetimi üzerine yapacağım. Kaan ve İşbaran sistem yönetimi üzerine bir kaç şeyden bahsetti staj görüşmemde. Artık sistem yöneticilerinin sunucu bakımını tek tek elle yapmadığını, çalışan makine sayısının da sürekli değiştiğini, bunun için sistem yöneticilerinin sunucu yönetimi sağlayan betikler yazdğından bahsetti. Aslında sistem yöneticisi olmak istemiyorum ama sistem yöneticilerinin kullandıkları teknolojilere karşı merakım var :) Bu yüzden stajda bu tür şeyler öğrenmenin beni sıkacağını sanmıyorum.

Son olarak bu dönem de bittiği için artık ben de 4. sınıfım :)

Yakından Eğitim Projemde Son Durum

Üzerinde çalıştığım Yakından Eğitim projesi olan Couchbase'i Nagios üzerinden izlemek için yaptığım eklentide geçen haftadan bu yana eksiklerin büyük kısmını kapattım. Sınav haftam nedeniyle danışmanımdan izin almıştım. Zaten final dönemi sıkıştırdığından 10 gün daha proje bitirme süresi uzatıldı.

Eklentiyi ilk şuan master dalında bulunan haliyle yayınlamıştım. Ordaki hali sorguyu sadece düğüm (node) seviyesinde yapıyordu ve Couchbase üzerindeki daha az özelliği kontrol ediyordu. Bu hafta githubda yapmam gereken bulabildiğim özellikleri ekledim. Ayrıca Rest Api kullanarak sorguları küme (cluster) seviyesinde yapılmasını da sağladım. Deb ve Rpm paketleri için bir alt yapı hazırlayıp, proje Readme'sini oldukça genişlettim. Eklenti web arayüzünden kullanılabildiği çıktılar konsolda ekranada dökülebildiği için "--help" ile çalıştırıldığında parametrelerinin açıklamasının görülmesini sağladım ve bir de uygulama için man sayfası hazırladım. En son dün kodu PEP 8 ile uyumlu hale getirdim.

Aslında projenin devel dalındaki hali bile şuan alınıp kullanılabilir durumda. Hatta bu hafta master ve devel dallarındaki halini alıp deneye bir kaç arkadaş projeye yönelik geri bildirimde bulundu.  Oldukça mutlu oldum bu duruma. Projeyi buradan alıp deneyebilirsiniz hata bildirimi, özellik ekleme gibi geri bildirimlerde bulunulursa da oldukça mutlu olurum :)

Python Uygulamalarına Debian ve Rpm Paketi Yapmak

Yazdığımız uygulamaları paketlemek kullanım açısından oldukça kolaylık sağlar. Eğer yaptığımız projeyi Python kullanarak kodladıysak bir setup.py dosyası oluşturarak hem paket oluşturmak hem de paket oluşturmadan kullanmak için de bir kolaylık sağlamış oluruz. setup.py dosyasında hangi dosyanın sistemde hangi dizin altına kopyalanacağı, proje lisansı, geliştiricisi, web adresi gibi bilgileri tanımlarız. Sadece setup.py'yi kullanarak "sudo python setup.py install" diyerek sistemimize uygulamayı kurabiliriz.

Debian Paketi Hazırlamak:

Debian tabanlı sistemler için paket oluştururken öncelikle bir uygulama içerisinde "debian" dizini oluşturmalıyız. Bu dizin içerisinde mutlaka olması gereken dosyalar ise şu şekilde:

ebru@debian:~/nagios-plugin-couchbase$ ls -ll debian/
toplam 20
-rw-rw-r-- 1 ebru ebru 153 Haz  5 22:00 changelog
-rw-rw-r-- 1 ebru ebru   2 Haz  5 22:00 compat
-rw-rw-r-- 1 ebru ebru 374 Haz  5 22:00 control
-rw-rw-r-- 1 ebru ebru 660 Haz  5 22:00 copyright
-rwxrwxr-x 1 ebru ebru 175 Haz  5 22:00 rules

Bu dosyaların her birini kendimiz elle tek tek oluşturabileceğimiz gibi "debianize" distutils komutunu da kullanabiliriz. Ben ilk önce tüm dosyaları kendim oluşturuyordum ancak bu şekilde biraz zahmetli. Çünkü ürettiğimiz control, changelog dosyalarının basitte olsa kendilerine özel herkes tarafından ortak kullanılan biçimi var. Örneğin changelog dosyasında yıldızdan sonra bir boşluk bırak değişiklikleri yaz, "--" ifadesinden sonra geliştirici adını yaz gibi. Bu tanımlamaları kendim yaparken biraz buradan ve Debian'ın kendi sayfasından yararlanıyordum. Daha sonra burada paketleme işinin daha basit yöntemini gördüm.

$ python setup.py --command-packages=stdeb.command debianize

Yukarıdaki gibi setup.py'yi kullanarak debian dizinimizi ve içerisinde olması gereken dosyaları üretebiliriz. Bu dosyaları ürettikten sonra geriye kalan sadece küçük kontroller oluyor. Zaten bunun sonucunda yukarıda belirttiğim (debian dizini altında) dosyaları oluşturuyor. Eğer setup.py'yi işimizi görecek şekilde doğru bir şekilde yazmışsak her şey debian dizini altında eksiksiz geliyor. Örneğin ben setup.py içinde uygulama adını kelimeler arasında boşluk bırakarak yazdığım için deb paketi üretirken uygulama adını parse edemiyorum gibi bir hata verdi. Bu gibi durumlar oluşmazsa hatasız debian dizini altındaki dosyalarımız oluşacaktır. debian dizini altındaki dosyalarımızın içeriği nasıl diye bakacak olursak:

debian/changelog    # projemizde sürümden sürüme meydana gelen değişiklileri belirttiğimiz dosya.

debian/compat    # Tek satırdan oluşan, debhelper paketinin sürümünü belirtir. debhelper deb paketlerini inşa etmek için kullanılır.

debian/control    # Bu dosyada projenin sürümü, bağımlılık bilgisi, geliştiricisi, lisansı, uygun olduğu mimari bilgisi bulunur.

debian/copyright    # Projeyi kimin hangi lisans ile lisansladığı bilgisi yer alır.

debian/rules    # deb paketini üretmek için bir debian Makefile'dır.

Daha sonra aşağıdaki gibi deb paketimizi oluşturabiliriz:

$ dpkg-buildpackage -rfakeroot -uc -us

RPM Paketi Hazırlamak:

Rpm paketlerinide Fedora tabanlı sistemler için gene setup.py yardımı ile hazırlayabiliriz. Eğer setup.py'mizde bir eksiklik yoksa sorunsuz bir şekilde spec dosyamızı oluşturabiliriz. Ben rpm paketi üretirken ilk başta hata aldığımdan önce sadece bir .spec dosyası üretmeyi denedim. .spec dosyası rpm paketi üretilirken bağımlılık, lisans, geliştirici bilgisi, hangi dosyanın nasıl kopyalanmasının gerçekleştirileceği gibi standartların bulundğu bir dosya. deb paketleri için olan debian dizinin toplanmış hali gibi düşünebiliriz. Direkt rpm paketini "python setup.py bdist_rpm" şeklinde üretebiliriz. Eğer önce benim gibi .spec üretip içeriğine bakmak istersenizde "python setup.py bdist_rpm --spec-only" şeklinde yapabilirsiniz.